What Feed actually is#
Not a lightweight RSS forwarder, and not an all-in-one content engine. Feed is a content-finding and ingestion layer: it pulls in multi-source industry signal, uses AI (when present) to analyse, score and spot trends, and, better-together with Gillish Node, identifies what content the site is missing. It then hands that off ("here is what is worth writing, and what is missing") to a separate Gillish creator tool. Feed never produces the final article, newsletter body, or imagery.
The originating idea is Giststack, reworked for the WordPress + MCP context, treated as the primary reference product, not a clean-room design. NewsBlur (which already exposes its reader to AI agents via an MCP server) is the second benchmark. Feed's distinguishing bet versus Giststack: an MCP server replaces bring-your-own-key as the primary AI path, and the publish target is WordPress directly rather than a webhook into a third-party automation tool.
Finder, not creator#
A deliberate scope refocus: Feed finds, ingests and surfaces content opportunities; it does not draft articles or generate media. Creation is a separate Gillish concern by design. Keeping Feed to one job is what keeps it honest, and what keeps it free.
Free forever, AI-free#
Feed has no Pro tier, no licensing layer, no paywall and no feature gating, permanently. This is a deliberate divergence from the Cairnstone/Node freemium house norm, not a launch-pricing trick.
It holds because Feed's free baseline is AI-free: ingestion, manual curation and manual export cost nothing to run, so there is nothing to meter. Feed itself never hosts or pays for an AI/MCP service. Any AI is a better-together ecosystem layer provided by other Gillish tools, degrading gracefully to manual when absent, with per-user bring-your-own-key as the only fallback, never a Feed cost.
AI path: MCP-first, BYOK fallback#
When AI is present (never Feed-hosted):
- Primary: an MCP server. For Feed's finder scope this is analysis, summarisation, scoring, and trend + gap identification, not drafting (drafting left Feed in the refocus).
- Fallback: BYOK. Where MCP genuinely cannot perform a capability, the user supplies their own provider keys. BYOK is the safety net for capability gaps, not the primary engine.
- Per-capability degradation. The AI layer resolves MCP → BYOK per capability, not all-or-nothing; settings hold optional BYOK keys.
The modules at a glance#
| Module | Scope decision |
|---|---|
| 1, Ingestion & data collection | Stays. Multi-source intake: RSS (the seed), newsletters (per-user inbound address), YouTube, Reddit, and web-scraping sites that offer no RSS. |
| 2, AI processing via MCP | Stays (finder scope only). Analyse & summarise, score & cluster with a "viral score", contextual focus on user-selected ideas. No drafting, no media. |
| 2b, Gap detection with Node | New core seam. Read Node's public surface to learn what the site is missing; combine with ingested signal to prioritise what should fill the gaps. |
| 3, Brand DNA | Open, ownership undecided. May belong to the creator tool; Feed may need only a light relevance-scoring copy. |
| 4, Content generator | Moved out of Feed. Long-form drafting belongs to a separate creator tool; recorded here only as the hand-off target. |
| 5, Image generation & media | Moved out of Feed. Image/infographic generation and the media-library push belong to the creator tool. |
| 6, Organisation & hand-off | Stays, with "publish" reframed as a hand-off: workspaces/folders, a searchable archive of found signal, and the terminal hand-off of opportunities + gaps to the separate creator tool. Copy-for-AI and webhook remain secondary export of the findings. |
Better-together with Node#
Feed's distinguishing job: read Node's public hook surface to learn what content the site is missing, then use ingested external signal plus its own scoring to identify what should fill those gaps. The integration pattern is Cairnstone's proven Node model verbatim, read public hooks only, no hard dependency, degrade gracefully standalone, and Node never has to know Feed exists. The exact Node-side surface and data shape are not yet defined (see open questions).
Open questions#
Deliberately left open, surfaced honestly rather than silently resolved:
- Which tool creates the content? A new build versus an existing sibling, none confirmed.
- Where does Brand DNA live? The creator tool (voices generated content) versus a light copy in Feed (relevance scoring when finding).
- What does Node expose as "missing content", and how does Feed read it? Concept only; the Node-side surface is unknown.
- The Feed → creator hand-off payload shape. Undefined.
How this reconciles with the skeleton#
The skeleton in the repository is the original lightweight shell. Under the refocused vision it remains a valid foundation, the house architecture scales, so no skeleton code is rewritten now. The RSS handler becomes one ingestion adapter among many; the dashboard's Copy-for-AI / webhook becomes the curation export plus the hand-off; the options gain MCP endpoint config and optional BYOK keys. Content/image generation and direct publish are explicitly not Feed's. When development resumes, this finder-scope vision is what gets phased.