Ai Radar

AI Radar

An agent that searches for recent AI developments, scores them against a project context, and appends results to a persistent markdown file in the repo. Designed to be run repeatedly (manually or via /loop) to build a living awareness log.

Invocation

Four modes, parsed by the first argument after /ai-radar:

| Invocation | Mode | What it does | |---|---|---| | /ai-radar | Scan (default) | Full flow — steps 1–9. Searches the web, scores, logs new entries, applies retention. | | /ai-radar show | Show latest | Render the summary of the most recent scan in the log. Skips steps 3–8 (no searches, no fetches, no writes). | | /ai-radar show all | Show running list | Render the accumulated ✅ Yes + 🤔 Maybe items across all scans. Skips steps 3–8. | | /ai-radar tidy | Tidy | Apply the retention policy (trim log to last 10 scans) and report what was deleted. No searches, no fetches. |

Show and tidy modes read/edit the log only — they don't need WebSearch / WebFetch, so the "Required tools" check below doesn't apply. Useful for quickly reviewing what's already on your radar, or pruning the log, without burning tool calls.

How it works

The flow below describes a full scan. Show modes run steps 1–2 and 9 only.

1. Read the project context from PROJECT_CONTEXT.md in the repo root (or ask the user)
2. Read the existing scan log to know what's already been captured
3. Confirm the scan plan — summarise the tier coverage and offer the user an amend-or-go before burning searches
4. Search the web for recent AI developments across targeted source categories
5. Score each finding on two axes and compute a combined score
6. Flag duplicates against the existing log (but still include them, marked)
7. Deep-fetch primary sources for high-relevance entries
8. Append new entries to the scan log markdown file

Required tools (check before starting)

This skill depends on WebSearch and WebFetch. In Claude Code, these are deferred tools — they appear in the deferred-tools list but are not callable until their schemas are loaded via ToolSearch.

Before running step 4 (the searches), ensure both tools are loaded. If you see them in your tool list already, you're fine. Otherwise:

ToolSearch(query: "select:WebSearch,WebFetch", max_results: 2)

If the environment doesn't expose WebSearch or WebFetch at all (e.g. a sandbox without network access), stop and tell the user. This skill cannot fabricate web content — the reliability constraints below explicitly forbid that — so without network tools there is nothing useful to do.

Reliability constraints (mandatory)

This skill produces dated, attributed claims about recent events — the highest-risk surface for confabulation in any agent workflow. A fabricated entry doesn't just waste time; it actively misleads future decisions made from the log. These rules are non-negotiable.

• **No entry without a source URL from a WebSearch/WebFetch result in this run.** Training-data recall is not acceptable. If you can't cite a URL you actually fetched during this scan, the entry does not get written.
• Dates come from the source, not from guessing. If the source doesn't state a publication date, mark date: unknown. Do not infer from training-data priors about when something "usually" happens.
• Attributions must come from the fetched text. If you claim "OpenAI announced X", the fetched page must actually say OpenAI announced X. Don't chain inferences from related results.
• Quotes must be verbatim. If you use quote marks, the text must appear exactly in a fetched source. Otherwise paraphrase without quotes.
• If a scan returns zero citable results, write nothing. The log gains value from restraint. Print a "no new citable developments this run" message to stdout and touch no files. An empty date header is noise.
• Suspect drift by checking yourself. Before writing each entry, re-ask: does my fetched result actually contain every claim in this summary? If any claim is reconstruction rather than quotation, cut it or weaken the wording.

A log with fabricated entries is worse than no log at all.

Retention policy

The scan log is bounded. After each scan — and on demand via /ai-radar tidy — trim AI_RADAR.md to keep only the 10 most recent scan sections. Older sections are deleted, not archived. Change the 10 in step 8b if you want a different limit.

Why 10: for weekly scanners that's 2–3 months of history; for daily scanners about 10 days. Either cadence has enough recent memory for dedup to catch re-surfaced items and enough signal for show all to feel useful, while the whole log stays inside a single Read call.

What counts as a scan section: any block starting with ### YYYY-MM-DD Scan (optionally followed by a parenthetical like (retarget — ...) or (focused — design systems)) and ending at the next ### header or end of file. Same-day multiple scans count as separate sections.

Rules:

• Preserve the file header (title, scoring-method block, `` marker).
• Delete the oldest (count − 10) sections entirely. Never partial-delete.
• Never touch the most recent 10.
• Idempotent: if the log already has ≤ 10 sections, do nothing.
• If you want to preserve a scan before it's trimmed (e.g. for audit), copy it somewhere else before running the next scan — the skill will delete it on schedule.

Step-by-step instructions

1. Load project context

Look for PROJECT_CONTEXT.md in the repo root. If it doesn't exist, ask the user to describe their project in 2-3 sentences, then create the file so future runs can reuse it.

The schema the skill consumes:

• What we're building — 2–3 sentences on the project
• Tech stack — key technologies
• What AI developments matter most — tiered categories: Highest / High / Medium / Low relevance
• Preferred sources (optional but high-leverage) — two lists:
• Always check: URLs or handles the user trusts, with a one-line reason
• Never cite: URLs or handles known to be unreliable (often aggregators)

If Preferred sources isn't present, don't invent one — fall back to references/sources.md for high-signal defaults. The list grows over time (see step 9's Proposed-sources rule).

2. Load the existing scan log

The scan log lives at AI_RADAR.md in the repo root. If it doesn't exist, create it using the template in templates/radar_template.md (read it with cat from the skill directory).

Parse the existing entries to extract titles and summaries — you'll need these for duplicate detection in step 6.

3. Confirm the scan plan

Before burning any web searches, show the user what you're about to search for and give them a cheap chance to amend. This catches context drift before it wastes a scan.

Render the plan like this (as your chat message, not stdout):

Reading PROJECT_CONTEXT.md. This run will search:
  Highest relevance (2–3): [comma-separated categories from the context]
  High relevance (2–3):    [comma-separated categories]
  Medium relevance (1):    [comma-separated categories]

Preferred sources (always check): [names/domains from the context, or "none set — using defaults"]
Never cite:                       [names/domains from the context, or "none set"]

Want to adjust anything before I run? Reply with changes in plain English —
categories ("drop Lexical, add voice-first UX"), tier moves ("promote creator
tooling"), one-off focus ("this run just Figma"), or source tweaks ("add
leerob.io to preferred sources", "drop MarkTechPost — too many aggregator
reposts"). I'll update PROJECT_CONTEXT.md, restate the plan, and confirm
again. Or reply "go" to proceed.

Handling the user's reply:

• "go" (or equivalent — "yes", "proceed", "run it") — continue to step 4.
• A plain-English amendment — edit PROJECT_CONTEXT.md to reflect the change, re-read it, then restate the plan (re-run this step) and wait for another confirmation. A single amend round-trip; don't ping-pong more than twice without checking in.
• A one-off focus request ("just Figma this run") — treat as a temporary override for this run only. Do not edit PROJECT_CONTEXT.md. State clearly that the override is one-run scope.

When to skip this step:

• If the user's original invocation already specified the focus explicitly (e.g. /ai-radar focus:figma), skip confirmation and proceed.
• If this scan is being run non-interactively via /loop or /schedule, skip — there's no user to confirm with. Note the skip in the summary output.

Why this step exists: project focus drifts. Left unchecked, the scan runs against a stale context and produces a log that's one-sided (recent example: a run on this skill that searched only "highest relevance" categories and missed the product-side tier). The confirmation is a 10-second affordance that prevents a 2-minute wasted scan.

4. Search for developments

PROJECT_CONTEXT.md drives the search plan — not the generic taxonomy below.

Open PROJECT_CONTEXT.md and read the "What AI developments matter most" section. The categories named there (often with specific tooling: e.g. "Claude Code", "Figma Code Connect", "Supabase") are what you should target. Build 5–8 searches that hit those categories first, using the specific tool names as search keywords whenever possible — specific names produce specific hits, generic phrasing produces generic news.

Approximate allocation (deliberately mixed — don't let one tier eat the whole budget):

• 2–3 searches on "highest relevance" categories (tools used daily — things like coding assistants, design tooling, core platform SDK)
• 2–3 searches on "high relevance" categories (things directly usable in the product — stack/domain updates, research, ecosystem libraries)
• 1–2 searches on "medium relevance" categories
• 0–1 exploratory search outside the context (only if a new trend might be worth elevating)

If the context has multiple distinct tiers of "what matters", each tier should get real query budget. A scan that spends all 6 searches in one tier is a failure mode — it starves the other tiers and produces a skewed log.

Query tips:

• Include the current year to bias toward recency
• Name specific tools, orgs, or products — "Claude Code" new feature, "Figma Code Connect" update, "Next.js 16.2" changelog — not generic terms like "AI developer tools"
• After a broad search on a tool, follow up with a narrower query on the most interesting thread

Source priority (preferred sources come first):

1. If PROJECT_CONTEXT.md names Preferred sources (Always check), weave them directly into the query budget — use site: constructions or "" keywords to target them. Spend at least one query per tier on a preferred-source target when the list has any entries.
2. If PROJECT_CONTEXT.md names Preferred sources (Never cite), filter matching domains out of results with -site:. If a search-snippet hit comes from a Never-cite domain, skip it — do not carry it into scoring.
3. For anything not covered by Preferred sources, consult references/sources.md for the default high-signal targets (arXiv, official lab blogs, maintainer GitHubs, etc.) and build queries from there.

Fallback taxonomy (only if PROJECT_CONTEXT.md is empty, very thin, or missing — if the context names concrete tools and categories, ignore this table):

| Category | Example queries | |---|---| | Model releases | new AI model release 2026, LLM benchmark results latest | | Research papers | AI research breakthrough this month, notable arXiv AI paper | | Developer tools | new AI developer tools 2026, open source AI project launch | | Industry moves | AI company acquisition funding 2026, AI startup announcement | | Regulation/policy | AI regulation policy update 2026, AI governance news | | Techniques | new machine learning technique, AI engineering best practice |

5. Score each development

For each distinct development found, assign two scores from 0-10:

Project Relevance (weight: 0.6) How directly applicable is this to the project described in PROJECT_CONTEXT.md?

• 9-10: Directly usable right now, changes how we'd build something
• 7-8: Closely related to our stack/domain, worth investigating
• 5-6: Adjacent — could matter in the next quarter
• 3-4: Same broad field but not directly connected
• 1-2: Interesting but unrelated to this project

Skill Value (weight: 0.4) How valuable is it for the humans on the team to understand this, regardless of project?

• 9-10: Foundational shift everyone in AI/tech should know about
• 7-8: Important career/industry knowledge, competitive awareness
• 5-6: Useful to know, good conversation topic, broadens perspective
• 3-4: Niche — relevant only to specialists in that subfield
• 1-2: Minor update, incremental, low learning value

Combined Score = (Project Relevance × 0.6) + (Skill Value × 0.4)

6. Detect duplicates

Compare each new finding's title and summary against existing entries in AI_RADAR.md. A finding is a duplicate if it covers the same underlying development (even if worded differently). Use your judgment — "OpenAI releases GPT-5" and "GPT-5 launch details" are duplicates; "GPT-5 launch" and "GPT-5 benchmark results" are distinct.

Mark duplicates with a 🔄 flag in the entry but still include them — the new entry may have updated information or a different angle.

7. Deep-fetch primary sources for high-relevance entries

Search snippets are shallow by design. For any entry the user will actually act on, you need the primary source read in full — that's the step that turns "Figma launched an AI thing" into a real explanation.

After scoring and deduplication, for each surviving entry with Project Relevance ≥ 7, WebFetch its primary source URL and rewrite the summary from the fetched content — not from the search snippet.

Rules:

• Fetch only the primary source (the official announcement, release post, docs page). Skip secondary coverage.
• If multiple candidates exist, pick the most canonical: official org blog > maintainer GitHub > third-party article.
• If the fetch fails, is paywalled, or returns nothing useful, note it in the entry and keep the search-snippet summary. Do not guess.
• Every claim in the rewritten summary must still be traceable to fetched content. Richer output means richer confabulation surface — the guardrails apply doubly.

Skip this step for entries below Project Relevance 7 — their search-snippet summary is good enough.

8. Append to the scan log

Add new entries to AI_RADAR.md under a new date header. Use this format:

### YYYY-MM-DD Scan

| # | Score | Title | Verdict | Flags |
|---|-------|-------|---------|-------|
| 1 | 8.2 | [Title here] | ✅ Yes |  |
| 2 | 7.4 | [Title here] | 🤔 Maybe | 🔄 |
| 3 | 5.1 | [Title here] | ⏭ Skip |  |

#### 1. [Title] — Score: 8.2
**Project Relevance:** 9 | **Skill Value:** 7 | **Source:** [primary URL label] | **Date:** YYYY-MM-DD
**Maturity:** private beta | public beta | GA | deprecated | unknown
**Access:** free tier | paid (tier/price) | waitlist | self-host | unknown
**Friction to try:** one-click | multi-step setup | CLI only | requires API keys | unknown

**What it is:** One-line description.

**What it does:** 2–3 sentences grounded in the fetched primary source, covering the capability and how it's used.

**Why it matters for us:** One sentence connecting this to PROJECT_CONTEXT.md — which specific part of our work it intersects.

**Worth exploring?** **✅ Yes** — [one sentence of reasoning] *OR* **🤔 Maybe** — [trigger that would change the answer] *OR* **⏭ Skip** — [why it's noise for us]

**Sources:** [primary](url) · [additional coverage if any](url)

---

Sort entries within each scan by combined score, descending.

Verdict rubric (don't let every entry end up "M

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: hereinthehive
• Source: hereinthehive/ai-radar
• License: MIT

Install and usage instructions live in the source repository linked above.