Track whether configured keywords appeared in real coverage. Keep this simple:
collects dated article evidence, you dedupe and judge with the keyword's meaning snippet, and the CLI only stores config plus seen/alert state.
This is not
. Do not score newsjacking opportunities, generate angles, assess standing, or use monitor profiles.
Before you decide you're in Limited Mode, check whether is installed. It ships as a prebuilt, bundled binary — you do
not need Go, a compiler, or any build/install step to run it. Never look for a Go toolchain, and never declare the CLI "missing" or tell the user they need a "Go environment" without running this check first:
The bundled binary is almost always already installed — assume Full Mode and verify, don't assume it's missing.
-
Find the tracker.
- If the user gave a slug, run
newsjack coverage status <slug>
- If working in a source checkout, prefer .
- If no slug is given, ask which tracker to run unless local context makes it obvious.
- Read the returned .
-
Search each keyword.
-
Read the current date from the system (e.g. run
); do not recall it from memory. Compute
as that date minus
from the config, defaulting to
.
-
For each keyword, call
with exactly:
text
"keyword" after:YYYY-MM-DD
-
If the keyword has aliases, search each alias the same way, but keep the original keyword entry attached.
-
Keep dated, attributed article fields from
:
,
,
,
,
, and snippet/summary when available.
-
Dedupe and check stored decisions before using the LLM.
-
Dedupe exact canonical URLs first, then obvious same-article duplicates by title/outlet/date.
-
Create a minimal candidate JSON file only because the CLI helper consumes a file. Put it in a temporary location, or in a timestamped run folder if your harness normally keeps run artifacts:
json
{
"items": [
{
"keyword": "profound",
"title": "Article title",
"url": "https://...",
"outlet": "Outlet",
"author": "Author or null",
"published_at": "2026-06-05T12:00:00Z",
"snippet": "Search snippet or summary"
}
]
}
-
Run:
bash
newsjack coverage check <slug> --input candidates.json
-
Do not reclassify
unless the user explicitly asks for a fresh review. Use their
to count filtered/known results and suppress repeat alerts.
-
-
LLM classify unknown items.
- Use the keyword's field as the authority for entity matching.
- Reject generic-word usage and wrong entities, especially for ambiguous keywords like .
- Do not alert from title/snippet keyword presence alone. When the snippet leaves the verdict unclear, read the article before deciding.
Use these verdicts:
- : the article is substantially about the intended entity/product/person. Alert.
- : meaningful paragraph-level mention, but not a feature. Save, normally no alert.
- : brief mention only. Save, no alert.
- : the keyword refers to something else. Save, no alert.
- : SEO, scraper, duplicate landing page, job post, docs/help page, or non-news. Save, no alert.
- : insufficient evidence. Save, no alert.
-
Record only newly classified unknown items.
If there are no
, skip
and report from the
result.
If you classified new items, write the minimum
needed by the CLI:
json
{
"items": [
{
"keyword": "profound",
"title": "Article title",
"url": "https://...",
"outlet": "Outlet",
"author": "Author or null",
"published_at": "2026-06-05T12:00:00Z",
"verdict": "real_feature",
"confidence": "high",
"alert": true,
"rationale": "Why this is about the intended keyword."
}
]
}
Include every newly classified unknown item, not only alerts. Saving rejects lets future runs skip them through
.
-
Persist decisions and suppress repeat alerts.
bash
newsjack coverage record <slug> --input decisions.json
Add
only when you already created a run folder for harness provenance. Read the command's JSON stdout directly. Do not write
unless the user or harness explicitly wants artifacts. Only articles in
are newly alertable; previously alerted URLs must not be re-alerted.
-
Deliver the result to the user.
SQLite is the durable record. Do not write a separate report file; compose a short, readable message straight to the user from
and, when run,
:
- If is non-empty, lead with the new real coverage items.
- If there are no new alerts, say there is no new confirmed coverage.
- Include a short run summary: keywords searched, since date, candidate count, skipped-known count, newly judged count, new alert count.
- Include a quiet "Filtered" line with counts by verdict, including prior decisions from known items, not a dump of every junk item.
- Use clickable links.
This skill is meant to run unattended on a schedule, so the message must stand alone — the user should not have to open any file to understand the run.