Radar ledger update
Skill Neetx/ai-security-research-radar/.claude/skills/radar-ledger-update
AI Security Research Radar — AI for security and security for AI
npx -y skills add Neetx/ai-security-research-radar --skill radar-ledger-updateAssembled 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
Safely update TRENDS.md (the AI Radar ledger): append evidence, move stages, manage observation_queue, source_rotation and strategy_notes without breaking the file contract. Use every time TRENDS.md is edited, before committing radar updates, and when promoting or archiving trends.
SKILL.md
5.1 KB, as published. Nobody here has run it
Update the ledger safely
TRENDS.md is the single source of truth and later sessions parse it. The
structure is a contract.
File contract (do not change)
- Header:
# Trend ledger — AI Radar, thenLast updated: YYYY-MM-DD, then the stage legend. - Sections, in this order:
## Active trends,## observation_queue,## source_rotation,## strategy_notes,## study_shelf,## calibration. ## source_rotationand## calibrationare POINTER stubs only: their real append-only content lives inlogs/source_rotation.mdandlogs/calibration.mdrespectively. Keep the two stub headers (the section order is the contract) but NEVER inline log lines back into TRENDS.md — appends go to thelogs/files.- Trend block:
### [id: slug-NNN] Titlewith fieldsalias, optionalpinned: true,stage,confidence,first_observed,last_evidence,evidence:(list),notes:. - Evidence line:
- YYYY-MM-DD — URL — one line of context.
Rules
- Match findings to existing trends via id and
aliasbefore creating a new trend. New trends take the next free NNN and start atseedoremerging. - ROUTE a captured primary, don't default to "queue it": (a) if it lands on an
EXISTING trend's axis, append it as EVIDENCE there — a single primary suffices
for an existing trend; the ≥3-source bar is only for CREATING a trend; (b) if
the queue now holds ≥3 independent groups on one untracked sub-theme, promote
that cluster to a
seedtrend; (c) else it stays a queue item. Leaving an on-axis primary in the queue (hoarding evidence) or a named primary in report prose only is a routing failure. - Max 10 evidence items per trend — drop the oldest. Keep
last_evidenceequal to the newest evidence date. - Stage moves: at most ONE stage up per trend per day, only on new independent
evidence, justified in
notes. Demotions are always allowed. 21+ days without evidence →dormant; at 45+ days the weekly pass moves the entry toARCHIVE.mdas a one-line post-mortem. - Pinned trends (
pinned: true): NEVER auto-archived, no matter how long without evidence — they are the curator's standing-watch axes. They still follow the normal stage rules, INCLUDING goingdormantwhen quiet (the ledger stays truthful about activity); they simply never leave the board. Only the curator adds/removes a pin (or the agent proposes it via amendment). observation_queueitems are dated and marked "unverified" unless opened. It is a WORKING SET (signals pending verification), not a knowledge store — keep it bounded to a soft cap of ~25 live items by a CAP-DRIVEN burndown that runs every session, including quiet/no-evidence passes: while the queue is OVER the cap, resolve the oldest items toward the cap that run regardless of what the scan found; at/under the cap it stops on its own (resolve only the 1–2 oldest if stale). This is owed every run, never deferred to the weekly — a no-evidence pass is not a no-op for the queue. Items leave ONLY by resolution: promoted to a trend (the signal is captured there) or dropped with a one-line reason in the day's/week's report (write-once, permanent). NEVER silently delete — because every removal is either a promotion or a recorded drop, shrinking the queue loses no knowledge. Re-date an item only if it is genuinely still worth watching.- Append one dated line per session to
logs/source_rotation.md(the coverage log; not the TRENDS.md stub). Append dated corrections to thestrategy_notessection of TRENDS.md; never delete curator entries. study_shelf: newest first, formatdate — [name](url) — one line of why; single-artifact items allowed (the trend bar does not apply), opened primary sources only.calibration(nowlogs/calibration.md) is append-only and written by weekly runs only (see theradar-self-evalskill); daily runs never touch it.- Update the
Last updatedline. Keep everything in English.
Validate before commit
grep -n '^## ' TRENDS.md
# expected, in order: Active trends, observation_queue, source_rotation, strategy_notes, study_shelf, calibration
grep -c '^### \[id: ' TRENDS.md # trend count matches expectations
grep -nE '^ - [0-9]{4}-[0-9]{2}-[0-9]{2} — ' TRENDS.md | head -3 # evidence format
grep -n '^Last updated:' TRENDS.md # date is today
# the two externalized logs must exist and only grow (append-only):
test -f logs/source_rotation.md && tail -1 logs/source_rotation.md | head -c 80
test -f logs/calibration.md && tail -1 logs/calibration.md | head -c 80
# TRENDS.md must NOT have regrown a log body (the stubs stay one-line pointers):
awk '/^## source_rotation/{n=0} /^## strategy_notes/{print "rotation stub lines:", n} {n++}' TRENDS.md
If a check fails, fix the file before committing. Commit and push per the conventions in AGENTS.md.