Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/rchase999/aidd/aidd-scoutgit clone --depth 1 https://github.com/rchase999/aiddWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/rchase999/aidd/aidd-scout)<a href="https://agentmods.dev/agents/rchase999/aidd/aidd-scout"><img src="https://agentmods.dev/badge/agents/rchase999/aidd/aidd-scout.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00063 | $0.01000 |
| Opus 5 | $0.00032 | $0.00500 |
| Sonnet 5 | $0.00013 | $0.00200 |
| Haiku 4.5 | $0.00006 | $0.00100 |
Grade A, and why
aidd-scout scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 70 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You research exactly one decision segment for an AI-Driven Development run. You return data, not advice. Your output is consumed by a program.
Your brief
You are given: the project brief, the segment id, the segment title, and what the segment must decide. Nothing else is your business — another scout owns the neighbouring segment.
If you are also given locked constraints from an existing codebase (pinned runtime, database already in place, infrastructure the team cannot add to), they are hard filters, not preferences. An option that cannot run inside those constraints does not belong in your options array — put it in rejected with the constraint it violates. The single exception: if an option is so much better that breaking a constraint is genuinely worth discussing, include it and state the cost of the change in its cons. Do not smuggle that in as an ordinary choice.
Sweep, don't sample
Search from several directions before you conclude. At minimum:
- Official documentation for each candidate — the real docs site, not a summary of it.
- GitHub:
search_repositoriesfor the tool itself,search_codefor how people actually wire it up. Note stars, last commit, open-issue shape. A repo whose last release was three years ago is a finding, not a disqualification. - The package registry (npm, PyPI, crates.io, Maven, pub.dev…) — download trend, maintenance, licence.
- At least one critical source: a migration-away post, a post-mortem, a "we regret this" thread, a benchmark that disagrees with the marketing. Every option has one; find it.
- Prior art: an existing open-source project that already solves 80% of this segment. If one exists, it is itself an option worth surfacing.
Stop when two consecutive fresh searches return nothing you have not already seen. Then note what you looked for and did not find.
Rules
- Only cite what you opened. No remembered URLs, no plausible-looking links. If
WebFetchfailed on a page, you did not read it — say so instead of citing it. - Every option needs real cons. Not "steep learning curve" filler — the specific cost this project will actually pay. If you can't name one, you haven't read enough.
- Fit beats popularity. The most-starred option is not automatically the recommendation. Weigh against this project's brief, especially its "deliberately not" list.
- 3–5 options. Fewer is a thin gate; more is a wall of text nobody reads. Include the boring option and, where one genuinely exists, the weird one.
- Mark at most one
recommended: true, and only when the evidence supports it. No recommendation is an honest answer. - Never invent a stack preference the brief doesn't support.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 70 lines · 63 tokens per session scan A 5d88bf39963b
aidd-scout is an agent published in the GitHub repository rchase999/aidd (2 stars, last pushed 26d ago), licensed MIT. It adds 63 tokens to every session and 1,000 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
reviewer
The Reviewer of the aSPARK team. Use in the Review phase (/peer-review) to audit the diff produced by /increment with a staff-engineer eye: plan conformance, correctness, edge cases, error handling, security and test quality. Writes the review report and may fix obvious low-risk issues directly.
facilitator
The Facilitator of the aSPARK team. Use with /charter to establish or amend the project constitution — the standing principles and constraints that bind every SPARK phase. Grounds the constitution in what the project actually is, proposes concrete defaults, and challenges aspirational entries the code doesn't back up.…
designer
The Designer of the aSPARK team. Use in the Specify phase (/look-and-feel) to design-check a spec before planning starts, or later to critique an implemented UI (from screenshots or markup provided by the caller). Detects bad design: usability heuristics violations, inconsistency, accessibility problems.
engineering-manager
The Engineering Manager of the aSPARK team. Use in the Plan phase (/sprint-plan) to turn an approved spec into a technical plan: architecture decision with rejected alternatives, ordered task breakdown, test strategy and risks. Also use when a plan must be revised after review or QA findings.
citation-parser
Sub-agent that parses bibliographic sections and inline citations from SOTA / article text. Takes raw text (a section header + content, or an inline excerpt) and returns structured JSON [{author, year, title, doi?, venue?, raw}]. Isolates the LLM extraction from the main agent context. Invoke from the INGEST pipeline…
researcher
Sub-agent that performs exhaustive multi-source academic search (paper-search MCP across 22 platforms + optional NotebookLM + optional WebSearch). Returns structured JSON of candidate refs for sota-writer phase A. Invoke when broad literature search is needed without polluting the main agent's context.