Build Signal Engine

Build a signal engine

What the user typed: $ARGUMENTS

If a path was given, it is the repo to build in; confirm it in one sentence. If not, ask whether to start a new folder or use the current one. Then go straight to Round 1.

A signal engine reads everything so its owner doesn't have to. Every morning it pulls from the places things actually happen, decides on every single item, hands an LLM only the few worth reading, and delivers one digest.

Keeping up is a filtering problem, not a reading problem. Reading more makes people feel more behind. The engine encodes the user's own filter and runs it on everything.

Build it into the user's repo. Do not hand them a plan. Every stage below ends with code committed and output from a real run they can look at.

Output discipline

The interview and the build are long. What you say is not.

Never announce a plan before doing it, restate an answer as a paragraph, or explain why the skill works this way unless asked. The reasoning lives in references/, for you.

The shape

sources -> store (dedupe, stable ids) -> code filters (dates, numbers) -> decide on every item
        -> the LLM reads what survives -> digest -> delivered on a schedule

Two splits carry the whole design. Say each once, early, in one sentence:

• Numbers in code, judgment in the decision pass, reading in the LLM. Dates, upvotes, view counts and "have I seen this" are code. "Is this new, is it for me" is a typed decision. Summarising and connecting is the LLM. Mixing them up is the most common bug.
• The question is the policy. What the engine keeps is decided by the words of one or two questions written from the user's own examples. Changing the question changes the engine. There is no model setting that fixes a vague question.

Construction order

One source first, end to end, before adding the rest. A pipeline built source-wide but never run end to end fails at the join between stages, and finding that after twelve sources is twelve times the work.

Anything that bills per row is capped on every run and only runs on the daily schedule, never on a frequent scan.

Stage 0. Interview

Read references/interview.md and work through it. Three rounds:

1. Three questions, one at a time, that decide the project: what they need to keep up with and what they would do differently if they knew on the day; something they missed or found out late, and where it first appeared; where the digest gets read and what they do with an item.
2. Questions only they can answer, about things that already happened: the tools they use daily, where people using those tools talk, three items from last week they would have wanted and three they never want again, what is too old or too small to matter, and whether their sources come through one data platform or get picked per source.
3. One message of defaults to confirm: schedule, stack, storage, caps, models, digest length, delivery.

Every question goes through the question tool (AskUserQuestion in Claude Code, or the equivalent), with two to four options drafted from what they have already said, one marked (Recommended) and first. It always carries free text, so nothing is lost. Never ask the user to design an artifact; they tell you what happened, you turn it into sources, filters and questions.

Write PROFILE.md from templates/PROFILE.md: the focus, the sources, the filters, the decision question(s) with their keep/drop examples, the digest format and delivery. Read it back as a proposal and get a yes before Stage 1.

When to refuse or shrink:

• No focus ("everything in AI"): ask for the action instead. "What would you do differently if you knew?" If nothing changes what they do, they need fewer sources, not an engine.
• Two or three sources: an RSS reader or email alerts beat a build. Say so.
• A source whose terms forbid automated access and that has no API or permitted provider: leave it out and say why.

Stages 1-3. Sources, store, code filters

Read references/sources.md. It is a playbook per source type: what to use for each, what it returns, and the failure each one is known for.

Where the data comes from is the user's call (R2.6). If they chose one data platform, that is the plan: every source it covers goes through it, with one client, one credential and a spending cap on every run. Do not argue them back to per-source APIs. If they named the exact tool for a source, use that tool and never test an alternative against it. If they asked you to pick, choose per source from references/sources.md and say which method each got.

If the platform has an MCP server, connect it for the build. Search for and test-run the right tool for each source through MCP, then have the engine call those same tools on its schedule through the platform's API. MCP while you build, the API while it runs.

Changelogs and release notes, however they are fetched: split the page into dated entries and give each a stable id.

Every source maps to one item shape (templates/item_schema.md): id, source, title, url, body, published_at, engagement. Dedupe on the id before anything costs money. Store in SQLite unless they already run something else.

Code filters run on stored items and drop by fact: age, engagement floor, language, length, already seen. Report how many each one dropped. Pull smarter before filtering harder: a filter does not refund a row the provider already billed.