news-collection
Skill444 starsChanged 9 days agoMITView on GitHub
Collect, filter, and freshness-qualify news items.
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 141
Every collected item carries five facts:
- Very specific: line 231
When several items cover one story, deliver one canonical item, link the rest via duplicates_of.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
News Collection
Gather news items on a topic, filter junk cheaply, verify freshness, and emit qualified items under an evidence contract. Pipeline-shaped: four phases, a gate between each. Content pipelines consume the JSON artifact; pair with fact-check to verify what this skill qualifies.
Instructions
Phase 1: COLLECT
Goal: gather candidate items from available sources (feeds, search results, provided fixtures). Every item carries the five-fact evidence contract: title, url, outlet, author, published_at.
Rule (verbatim from the design): publish times are extracted (article
metadata), never guessed; missing timestamp → recorded as unknown, confidence
lowered and disclosed. A guessed timestamp poisons every downstream freshness
verdict; an honest "published_at": null keeps the item usable with known
uncertainty.
Record each item as one JSON object per the item schema below. Fill
evidence_notes with where each fact came from (meta tag, byline, JSON-LD,
sitemap).
Distinguish outcomes: zero items because sources were unreachable is a collection failure (report it, stop); zero items from reachable sources is a valid empty feed (deliver an empty artifact with counts of zero).
Gate: every collected item has all five fields present — value or explicit
null with a confidence downgrade and a disclosure note. Items with silent
gaps stay in COLLECT until the gap is recorded.
Phase 2: COARSE FILTER
Goal: cheap, high-recall pass over collected items. Three verdicts:
keep / monitor_only / reject, each with a reason code (see
Coarse Filter below).
Rule (verbatim from the design): high-magnitude stories are downgraded to monitor_only at most, never rejected — a false keep is cheap, a silent drop is expensive. A keep costs one extra freshness check; a wrongly dropped major story costs the whole pipeline its value.
This phase runs on a cheap model when dispatched -- it needs recall, not judgment depth. Give the dispatched model: topic, verdict/code tables, asymmetry rule, and items' five facts plus a text excerpt.
Gate: every item has exactly one verdict and one reason code. reject
verdicts on items that look high-magnitude get re-checked once before the
phase closes.
Phase 3: FRESHNESS CHECK
Goal: for each keep and monitor_only item, establish when the story
first became public and whether this page is the original coverage.
- First-public time vs page date -- a page can carry today's date on old news.
- Syndication and aggregator reposts detected; select the canonical coverage.
- Same-story vs new-development rubric -- consolidate duplicates, keep genuine developments. See Freshness Forensics below.
Rule (verbatim from the design): two independent sources or verdict "unclear". Conservative default: unclear over guessed. An "unclear" verdict is recoverable downstream; a confidently wrong "fresh" verdict ships stale news.
Gate: every surviving item carries freshness: fresh | stale | unclear, a
first_public_estimate (or null), and the count of sources backing the
verdict. Duplicate clusters are consolidated to one canonical item with
duplicates_of links.
Phase 4: DELIVER
Goal: emit qualified items as a structured JSON artifact (see Artifact
Schema below) plus a summary table. Every verdict state
appears in the artifact — monitor_only, unclear, and reject items ship
with their verdicts rather than vanishing, so consumers see the full triage.
Gate (deterministic phase checkpoint — emit this table before delivering the artifact; delivery without it is incomplete):
| Verdict | Count |
| keep | n |
| monitor_only | n |
| reject | n |
| unclear (freshness) | n |
| duplicates consolidated | n |
The counts make silent drops visible: collected total must equal keep + monitor_only + reject. If it does not, return to the phase that lost items.
Error Handling
No items collected
- Cause: sources unreachable, or feed genuinely empty.
- Solution: unreachable sources → report collection failure and stop; reachable but empty → deliver an empty artifact with zero counts. The two outcomes stay distinct so an outage is not read as a quiet news day.
No timestamp found anywhere for an item
- Cause: page has no metadata, byline date, or sitemap entry.
- Solution: set
published_at: null,confidence: low, disclose inevidence_notes; freshness verdict for that item isunclear.
Two sources disagree on first-public time
- Cause: syndication chain or republished update.
- Solution: apply canonical-coverage selection
(
references/freshness-forensics.md); if still split, verdictunclear.
Item count mismatch at DELIVER
- Cause: an item was dropped without a verdict.
- Solution: diff item ids against the COLLECT record; assign the missing item a verdict with reason code.
Evidence Contract
Every collected item carries five facts:
| Fact | Type | Missing value handling |
title | string | Empty string only if page truly has none; note in evidence_notes |
url | string | Required -- no URL means unverifiable; exclude from artifact |
outlet | string | Derive from domain when no masthead found; note derivation |
author | string or null | null when no byline; note where you looked |
published_at | ISO 8601 or null | Extracted from metadata, never guessed. null when absent; lower confidence, disclose |
Confidence: high (all five extracted), medium (one derived or weak), low (published_at null or 2+ derived).
Item Schema
{
"id": "string", "title": "string", "url": "string",
"outlet": "string", "author": "string|null",
"published_at": "ISO 8601|null", "confidence": "high|medium|low",
"evidence_notes": "string", "verdict": "keep|monitor_only|reject",
"reason_code": "string", "freshness": "fresh|stale|unclear|null",
"first_public_estimate": "ISO 8601|null",
"freshness_sources": "integer", "duplicates_of": "string id|null"
}Artifact Schema
{
"schema_version": "1.0", "topic": "string",
"collected_at": "ISO 8601",
"counts": {"collected":0,"keep":0,"monitor_only":0,"reject":0,"unclear_freshness":0,"duplicates_consolidated":0},
"items": []
}Conservation rule: collected == keep + monitor_only + reject.
Coarse Filter
| Verdict | Meaning | Goes to freshness check |
keep | On-topic, substantive, plausibly fresh | Yes |
monitor_only | Worth watching: off-topic but high-magnitude, thin, or uncertain | Yes |
reject | Junk: spam, ads, dead pages, clearly irrelevant | No |
Asymmetry rule: high-magnitude stories downgrade to monitor_only at most, never reject. A false keep is cheap; a silent drop is expensive.
Reason Codes
| Code | Pairs with | Meaning |
RC-ONTOPIC | keep | Directly on topic |
RC-DEV | keep | New development of known story |
RC-OFFTOPIC-BIG | monitor_only | Off-topic but high-magnitude |
RC-THIN | monitor_only | On-topic but little substance |
RC-UNCERTAIN | monitor_only | Relevance unclear |
RC-SPAM | reject | Promotional, SEO bait |
RC-IRRELEVANT | reject | Outside topic, low magnitude |
RC-NOCONTENT | reject | Dead link, paywall stub, empty page |
Freshness Forensics
First-public time vs page date
A syndicated repost or refreshed CMS page can carry today's date on old news. Establish first-public time from (in trust order):
- Article metadata (
article:published_time, JSON-LDdatePublished) on the originating outlet's page. - Earliest
published_atacross collected items covering the same story. - In-text anchors ("announced Tuesday") tied to a known date.
Two independent sources or verdict unclear. Independent means separately reported -- two copies of the same wire story count as one.
| Verdict | Condition |
fresh | Two sources put first-public time inside the freshness window |
stale | Two sources put it outside, or page repackages older coverage |
unclear | <2 sources, conflicting evidence, or no usable timestamp |
Syndication detection
Signals of a repost: wire credit in byline, rel=canonical pointing elsewhere, body near-identical to an earlier item, aggregator framing ("read more at"), outlet with no original bylines across beats. A repost inherits the original's first-public time.
Canonical-coverage selection
When several items cover one story, deliver one canonical item, link the rest via duplicates_of. Pick canonical by: originating outlet > earliest published_at > most complete five-fact record.
Same-story vs new-development
| Question | Same story (consolidate) | New development (keep separate) |
| New named facts? | No | Yes |
| New primary source? | No | Yes |
| Event advanced? | No | Yes |
| Only framing/outlet changed? | Yes | -- |
Two+ "new development" answers = separate item.
Other versions1 project uses a version of this.
Word for word · 1
- notque/vexjoy-agent★ 444100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository64 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- assessmentSkill
- dataSkill
- business-opsSkill
- code-qualitySkill
- comment-qualitySkill
- condenseSkill
- joy-checkSkill
- content-engineSkill
- contentSkill
- headlinesSkill
- image-genSkill
- image-to-videoSkill
- series-plannerSkill
- topic-brainstormerSkill
- video-editingSkill
- writingSkill
- domainSkill
- cli-designSkill
- frontendSkill
- frontend-slidesSkill
- jev-designSkill
- webgl-card-effectsSkill
- game-asset-generatorSkill
- game-devSkill
- game-trailerSkill
- motion-pipelineSkill
- browser-jev-automationSkill
- cve-source-checkSkill
- deploySkill
- endpoint-validatorSkill
- headless-cron-creatorSkill
- kubernetesSkill
- githubSkill
- accountsSkill
- auto-dreamSkill
- building-with-jevSkill
- codexSkill
- docs-sync-checkerSkill
- doSkill
- dSkill
- grill-jevSkill
- toolkitSkill
- workflow-helpSkill
- debuggingSkill
- plant-seedSkill
- processSkill
- pr-workflowSkill
- quickSkill
- testingSkill
- with-anti-rationalizationSkill
- workflowSkill
- worktree-agentSkill
- programmingSkill
- architecture-deepeningSkill
- codebase-analyzerSkill
- markdown-converterSkill
- researchSkill
- roastSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

