How do I install the Radar Source Verify skill?

Run npx skillmds@latest add neetx/radar-source-verify in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Radar Source Verify safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Radar Source Verify?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Radar Source Verify free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Radar Source Verify?

Neetx (@neetx) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Radar Source Verify by neetx — Agent Skill

Name: Radar Source Verify
Author: Neetx

Radar Source Verify

Verify a signal or evidence candidate for the AI Radar ledger: open primary sources, pin exact dates and authors, check source independence, and classify the result as citable evidence or an unverified observation_queue item. Use whenever adding evidence to TRENDS.md, promoting a queue item, or fact-checking a claim found in search results.

Neetx 8f7ada0 3.4 KB Updated Sep 17, 2026

File contents

Verify a source for the ledger

Goal: every evidence line in TRENDS.md has (a) a URL that was actually opened this session, (b) a real date, (c) one line of context.

Procedure

Find candidates with the tavily-search skill (--include-domains arxiv.org,github.com,huggingface.co for primary sources, --time-range for recency). Search snippets are never citable on their own.
Open each candidate with the tavily-extract skill. Opened = citable.
Pin dates — by source type:
- Date by the NEWS EVENT: the evidence-line date is the date of whatever makes the item worth logging now — v1 for a new paper, the acceptance or latest-version date for an older paper that just got accepted/revised, the release date for software. Keep the other dates in the context line, e.g. "(v1 2025-11-12; accepted ACL 2026, v4 2026-04-16)" with the line dated 2026-04-16. This keeps the ledger's freshness machine-readable.
- arXiv: curl -sL 'https://export.arxiv.org/api/query?id_list=ID1,ID2' gives exact v1/latest dates and the full author list (the abs page often hides them from extraction). Use https, not http.
- GitHub: cite the latest release tag and its date, not the access date.
- Hugging Face org pages: "updated X days ago" → compute the estimate and write "(date estimated from the org page)".
- Undated pages: "(undated, accessed YYYY-MM-DD)".
Investigate the content and lineage — never judge by the surface. Do not accept or dismiss a signal on the first/oldest hit or a single date. Open the ACTUAL artifact the signal is about (not just the top search result), and trace the line: is there a newer version, a follow-up paper, a 2026 continuation? A research line can look "stale" only because your first hit is its oldest paper while a fresh one exists (e.g. a 2025 method with a 2026 follow-up). Judge freshness and relevance from the real, latest artifact, not from what the search surfaced first.
Independence check (for the ≥3-sources trend bar): sources must come from different orgs/author groups. Shared co-authors collapse two papers into one group — compare author lists before counting.
Classify:
- Opened + dated + primary → evidence line: - YYYY-MM-DD — URL — one line of context
- Not opened, or secondary-only → observation_queue line marked "unverified", stating exactly what is missing.

Red flags (queue or drop — never cite)

SEO content farms, model comparators/aggregators, market-wire press syndication are never CITABLE — but they can POINT to a real primary artifact. Before discarding one, read what paper/repo/release it is actually about, verify that primary, and cite IT (never the SEO source). Don't let a clickbait wrapper hide a live underlying result.
Releases claimed by aggregators but absent from the vendor's official channel (check the org's HF page or official blog index before believing them).
Vendor-reported adoption numbers: citable, but label them "vendor-reported".

---name: radar-source-verifydescription: Verify a signal or evidence candidate for the AI Radar ledger: open primary sources, pin exact dates and authors, check source independence, and classify the result as citable evidence or an unverified observation_queue item. Use whenever adding evidence to TRENDS.md, promoting a queue item, or fact-checking a claim found in search results.---# Verify a source for the ledgerGoal: every evidence line in `TRENDS.md` has (a) a URL that was actually openedthis session, (b) a real date, (c) one line of context.## Procedure1. **Find** candidates with the `tavily-search` skill (`--include-domains arxiv.org,github.com,huggingface.co` for primary sources, `--time-range` for recency). Search snippets are never citable on their own.2. **Open** each candidate with the `tavily-extract` skill. Opened = citable.3. **Pin dates** — by source type: - Date by the NEWS EVENT: the evidence-line date is the date of whatever makes the item worth logging now — v1 for a new paper, the acceptance or latest-version date for an older paper that just got accepted/revised, the release date for software. Keep the other dates in the context line, e.g. "(v1 2025-11-12; accepted ACL 2026, v4 2026-04-16)" with the line dated 2026-04-16. This keeps the ledger's freshness machine-readable. - arXiv: `curl -sL 'https://export.arxiv.org/api/query?id_list=ID1,ID2'` gives exact v1/latest dates and the full author list (the abs page often hides them from extraction). Use https, not http. - GitHub: cite the latest release tag and its date, not the access date. - Hugging Face org pages: "updated X days ago" → compute the estimate and write "(date estimated from the org page)". - Undated pages: "(undated, accessed YYYY-MM-DD)".4. **Investigate the content and lineage — never judge by the surface.** Do not accept or dismiss a signal on the first/oldest hit or a single date. Open the ACTUAL artifact the signal is about (not just the top search result), and trace the line: is there a newer version, a follow-up paper, a 2026 continuation? A research line can look "stale" only because your first hit is its oldest paper while a fresh one exists (e.g. a 2025 method with a 2026 follow-up). Judge freshness and relevance from the real, latest artifact, not from what the search surfaced first.5. **Independence check** (for the ≥3-sources trend bar): sources must come from different orgs/author groups. Shared co-authors collapse two papers into one group — compare author lists before counting.6. **Classify**: - Opened + dated + primary → evidence line: `- YYYY-MM-DD — URL — one line of context` - Not opened, or secondary-only → `observation_queue` line marked "unverified", stating exactly what is missing.## Red flags (queue or drop — never cite)- SEO content farms, model comparators/aggregators, market-wire press syndication are never CITABLE — but they can POINT to a real primary artifact. Before discarding one, read what paper/repo/release it is actually about, verify that primary, and cite IT (never the SEO source). Don't let a clickbait wrapper hide a live underlying result.- Releases claimed by aggregators but absent from the vendor's official channel (check the org's HF page or official blog index before believing them).- Vendor-reported adoption numbers: citable, but label them "vendor-reported".

Frequently asked questions