Topic Scout

Topic Scout

Finds what to cover and writes it to your idea tracker. Built to run once a day.

Where it sits in the pipeline:

[this skill]  scout  →  idea tracker
        ↓ a human picks one and promotes it
     production queue
        ↓ topic-brief    (verify → one-page brief)
        ↓ blog-post / carousel-post

This skill never writes to the production queue. It reads the queue only to check for duplicates. A human promoting an idea is the gate; if the model skips that gate, unverified topics end up in the production queue.

The five ways this fails (all five are defended below)

1. Suggests something already covered → don't skip the three-layer duplicate check.
2. Suggests something already over → a candidate whose deadline you couldn't confirm does not get recorded.
3. Mines the same beat every day → follow the rotation from axis.py. Don't pick by feel.
4. Invents something plausible with no source → no primary-source URL, no record.
5. Ranks by intuition → score only with the rubric in references/scoring.md.

Reference routing

Procedure — once per run

1. Pick the beats

python scripts/axis.py --today

Prints the beats to mine today and the source rows for each. Mine only those beats. Do not swap a beat because another one "looks more interesting today" — once the rotation breaks, you are back to one beat forever within a few days. If the user names a beat, override with --beat "<name>" and leave the rotation state alone.

2. Load existing state (for the duplicate check)

Pull the names of every row from both lists — your production queue and your idea tracker. references/tracker.md has the field names.

• Production queue — every row, whatever its status. A row sitting at "candidate" is still a topic you already have.
• Idea tracker — every row. Re-suggesting yesterday's suggestion is the most common way this skill wastes a run.

3. Collect — walk the primary sources

Open the sources for each of today's beats from the top down. In each one you are looking for exactly one thing: something live right now that gives your audience real money, time, or access.

• Fetch the page. If the body doesn't come back because the page renders client-side, reopen it with a browser tool rather than giving up.
• If walking the sources isn't enough, search — but put the beat name plus the current month in the query. Do not run queries that leave the beat.
• Do not scrape sites behind a login. It breaks their terms and the data is unreliable.

Gather 3–5 candidates per beat, 10–15 total. Don't filter yet.

4. Filter — most candidates die here

Apply in order. Log the reason for each rejection; don't record rejected candidates.

Always run F3 through the script:

python scripts/dedup.py --existing existing.json "candidate one" "candidate two"

Drop anything marked duplicate. Keep anything marked similar, noting what it is similar to — the next round of a recurring thing is a new topic, not a duplicate.

5. Score

Use only the rubric in references/scoring.md: beat base score plus adjustments. Never raise a score because a deadline is close. Urgency belongs in the deadline field, where it breaks ties; it is not a ranking input. scoring.md explains why.

6. Record

Write only the top 3–5 to the idea tracker. Write all ten and nobody reads any of them. Follow the row format in references/tracker.md exactly.

Reporting

Leave only this in chat. Don't paste candidate write-ups — the tracker is the record.

[scout YYYY-MM-DD] beats: <three>
recorded N: <name>(score) / <name>(score) / <name>(score)
rejected M: F1 a · F2 b · F3 c ...
blocked sources: <what you couldn't open and why. omit if none>

Never

• Create or edit rows in the production queue (read-only from here)
• Fill in an amount, date, or eligibility rule that isn't in the primary source
• Scrape pages behind a login wall
• Write hooks, scripts, or outlines here (that's blog-post / carousel-post)
• Write a full brief (that's topic-brief — scouting stops at a one-line summary)