Radar source verify
Skill Neetx/ai-security-research-radar/.claude/skills/radar-source-verify
AI Security Research Radar — AI for security and security for AI
npx -y skills add Neetx/ai-security-research-radar --skill radar-source-verifyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
3.4 KB, as published. Nobody here has run it
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-searchskill (--include-domains arxiv.org,github.com,huggingface.cofor primary sources,--time-rangefor recency). Search snippets are never citable on their own. - Open each candidate with the
tavily-extractskill. 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_queueline marked "unverified", stating exactly what is missing.
- Opened + dated + primary → evidence line:
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".