radarlisted

# radar Ecosystem tracking for the current repo. Deterministic work (version checks, changelog fetching, state) is done by the bundled CLI; your job is the **analysis layer**: read what changed, compare it against THIS project, and say what matters. All data lives in the consuming repo under `.radar/` (git-tracked JSON). Run every command from the repo root. ```bash node <skill-dir>/scripts/radar.js <command> # or `bun` — needed if node is older than 22.18 ``` ## First use in a repo: `/radar init` 1. Run `radar.js init`. 2. Read the project's context (README, CLAUDE.md/AGENTS.md, package manifest, roadmap docs) and **propose seed entries** per category: - `official` — tools the project builds on (for an agent-adjacent project, `anthropics/claude-code` is almost always first) - `competitors` — same-space products - `deps` — libraries whose breaking changes hurt - `inspiration` — idea sources In the same turn, offer the weekly automatic check — say what they'd get, not the flag: a GitHub Actions workflow that runs the check every week, keeps a rolling "Radar digest" issue up to date, and comments on it when new updates land. The user won't know this exists unless you offer it. Also ask where findings should land later. 🔥/💡 is shorthand for you, not vocabulary for the user — they have not seen it defined. Ask with the meaning instead: changes that affect this repo, ideas worth adopting. Keep the plumbing invisible too: the