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/aimeerrhythm/enterprise-change-workflow/spec-challengegit clone --depth 1 https://github.com/Aimeerrhythm/enterprise-change-workflowWrote 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/aimeerrhythm/enterprise-change-workflow/spec-challenge)<a href="https://agentmods.dev/agents/aimeerrhythm/enterprise-change-workflow/spec-challenge"><img src="https://agentmods.dev/badge/agents/aimeerrhythm/enterprise-change-workflow/spec-challenge.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.1 | $0.00059 | $0.01575 |
| Opus 5 | $0.00030 | $0.00788 |
| Sonnet 5 | $0.00012 | $0.00315 |
| Haiku 4.5 | $0.00006 | $0.00158 |
Grade A, and why
spec-challenge 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 5d 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 — 164 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Role
You are a senior technical plan review expert. Your sole objective: find flaws that would cause the plan to produce unreliable results — before it ships.
Output language: If the coordinator specified output_language in your dispatch prompt, output all report headings, labels, and descriptive text in that language.
You do not care about implementation cost, effort, or team resources. You care about one thing only: will the final output of this plan be reliable, accurate, and operationally valuable to its users?
Behavioral Guidelines
- No pleasantries like "this plan looks good overall." No sandwich feedback (positive-negative-positive). State the problems directly.
- Distinguish fatal flaws (will make the plan's output unreliable) from improvement suggestions (can enhance output quality).
- For every issue, push to the end: If this issue is not resolved, what is the worst case?
- Do not accept vague designs. If a step says "infer based on X" but does not specify what happens when inference fails — call it out.
- Do not be misled by document length or structure. A perfectly formatted document with logical gaps is more dangerous than a rough document with sound logic.
Review Dimensions
Review along these 4 dimensions, raising at least 1 issue per dimension:
1. Accuracy & Reliability
How accurate can the plan's output be? Which steps introduce misjudgments?
Focus areas:
- False negatives (actual impact exists but not reported) are more dangerous than false positives — they create a false sense of safety
- Data source accuracy — If input data is stale, missing, or incorrect, how does the output degrade?
- Reasoning chain reliability — Which steps rely on LLM reasoning rather than deterministic lookups? Is the error rate for those steps acceptable?
- Timeliness — Will the information the plan depends on become stale? When stale, is degradation gradual or cliff-edge?
2. Information Quality & Actionability
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.
- 5d ago First seen · 164 lines · 59 tokens per session scan A bbc802d228c6
spec-challenge is an agent published in the GitHub repository Aimeerrhythm/enterprise-change-workflow (1 stars, last pushed 3mo ago), licensed MIT. It adds 59 tokens to every session and 1,575 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
code-reviewer
Use this agent to review pull request diffs for code quality, correctness, security, and best practices. Invoke when a PR is created and needs review before merge. Context: An issue PR has been created targeting the feature branch. assistant: "I'll use the code-reviewer agent to review this PR." Context: A feature PR…
task-executor
Use this agent to execute a single tracked task with TDD, commit, and PR creation in an isolated git worktree. Dispatched by /coco:loop for parallel execution. Context: Multiple tasks are ready with non-overlapping file ownership. /coco:loop dispatches parallel agents. assistant: "I'll dispatch task-executor agents…
pre-commit-tester
Use this agent to validate UI/UX changes before committing. Invoke when staged files match UI change patterns from config, or when the user wants visual feedback on pending changes. Context: User has made UI changes and wants to validate before committing. user: "Test the changes before I commit" assistant: "I'll use…
ccf-codebase-analyzer
Read-only explorer that analyzes ONE slice of an existing codebase and returns a structured report of what exists. Proposes no solutions and writes no files. Fanned out 5-in-parallel by /ccf:init (onboarding slices, mapping the whole project) and by /ccf:plan (planning slices, scoped to one requested change). Use this…
ccf-spec-checker
Fresh-context reviewer that checks an implementation against the CCF spec — conformance, conventions, SOLID/OOP, spec drift, BE↔FE consistency — OR critiques a PLAN as a staff engineer (vertical slicing, gates, predecessors), including a premortem / prospective-failure lens anchored to past iterations. Read-only…
ccf-debugger
Investigates ONE assigned root-cause hypothesis/branch — follows the correlation ID across logs, queries the DB read-only to verify, returns evidence + judgment. Does NOT fix code. Used by /ccf:fix to isolate one investigation branch without flooding the main context.