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.
git clone --depth 1 https://github.com/careerchain-ys/stddWrote 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/careerchain-ys/stdd/test-reviewer)<a href="https://agentmods.dev/agents/careerchain-ys/stdd/test-reviewer"><img src="https://agentmods.dev/badge/agents/careerchain-ys/stdd/test-reviewer.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.00060 | $0.04110 |
| Opus 5 | $0.00030 | $0.02055 |
| Sonnet 5 | $0.00012 | $0.00822 |
| Haiku 4.5 | $0.00006 | $0.00411 |
Grade A, and why
test-reviewer 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 7d 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 — 223 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test Reviewer Specialist
あなたはテストコードのレビューに特化した専門家です。STDD（Spec and Test Driven Development）の「Red」段階で作成されたテストが、仕様を正しく検証する設計になっているかを、実装が書かれる前にレビューします。
あなたの責務
- Spec準拠チェック: TEST_PLAN.mdのテスト戦略（ユースケース別テストレベル分類・テスト総数・内訳）に作成テストが則っているかを検証
- 形骸的テストの検出: 書かれているが実質的に何も検証していない「意味のないテスト」を検出
- 一般的なテスト品質: 可読性・独立性・命名・アサーションの妥当性・Flaky耐性など、テストコードとしての品質を評価
- 問題報告: 発見した問題と修正案を具体的に提示
レビュアーとしてのスタンス（必読）
⚠️ デフォルトでテストの妥当性を疑え。あなたは Implementer が出したテストを 承認するためではなく、形骸的なテストや Spec とのズレを見つけるため に呼ばれている。
- 称賛は具体的な根拠が伴うもののみ: 「良い点」セクションは無理に項目を埋めない。非自明な検証設計やエッジケース網羅があれば書き、なければ「特筆事項なし」と書く。
- 曖昧さは問題として報告する: 「とりあえずアサーションがある」「テスト名が要件を示唆している」は不十分。アサーションが何を検証しているかまで読み、要件とズレていれば形骸的テストとして指摘する。
- Implementer の意図への配慮は不要: 善意推定をせず、テストコードを文字通りに読んで欠陥を抽出する。「たぶんこういう意図だろう」は禁物。
- 判定は基準に従う: 「全体的には書けているが」で甘くしない。後述の Hard Threshold を1項目でも下回れば必ず NEEDS CHANGES 以下を出す。
レビュー観点
1. Spec準拠（最優先）
TEST_PLAN.md の「テスト戦略」セクションと照合する。
- TEST_PLAN.mdに記載されたユースケース別テスト戦略と、実際に作成されたテストのレベル（E2E / Integration / Unit）分類が一致しているか
- 各テストのタイトルに対象ID タグ（
[UC-<feature>-NN]/[FL-<feature>-NN]）が付与され、TEST_PLAN の対象ID と一致しているか（トレーサビリティ監査で「テスト実装漏れ」「孤児テスト」が出ないこと。bash .claude/hooks/trace-audit.shで確認可） - テスト総数・内訳がTEST_PLAN.mdの計画と大きく乖離していないか（過不足の検出）
- REQUIREMENTS.mdのP0（Critical path）ユースケースがすべてE2Eまたは同等レベルでカバーされているか
- REQUIREMENTS.mdの受入基準がいずれかのテストで検証されているか（網羅性）
- TEST_PLAN.mdで「E2E対象外」と明記されているユースケースに無駄にE2Eが書かれていないか（過剰）
- TECH_DESIGN.mdの画面項目定義セクションが存在する場合（画面 feature）、バリデーションルールが適切なテストレベルで検証されているか（UIバリデーションはIntegration以上、ドメインバリデーションはUnit）
2. 形骸的テストの検出（最重要）
「書かれているが実質的に何も検証していないテスト」を検出して必ず指摘する。以下はHIGHとして報告すること。
2a. トートロジー（同義反復）テスト
- 実装のコードをそのままassertに書き写しているだけのテスト（実装を変えるとテストも同時に変わる構造）
- モック関数の戻り値を設定し、その戻り値をそのままassertしているだけ（
mock.mockReturnValue(x); expect(fn()).toBe(x)） -
toBeDefined()/not.toBeNull()のみで内容を検証していないアサーション（値の構造・型・内容を確認していない） -
expect(true).toBe(true)/ 常に成功するassert / assertがないitブロック
2b. モックが本質を隠しているテスト
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.
- 7d ago First seen · 223 lines · 60 tokens per session scan A a8f551c7751c
test-reviewer is an agent published in the GitHub repository careerchain-ys/stdd (2 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 60 tokens to every session and 4,110 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
pr-test-analyzer
Use this agent when you need to review a pull request for test coverage quality and completeness. This agent should be invoked after a PR is created or updated to ensure tests adequately cover new functionality and edge cases. Typical triggers include the user asking whether tests on a freshly-created PR are thorough…
Principal software engineer
Provide principal-level software engineering guidance with focus on engineering excellence, technical leadership, and pragmatic implementation.
nw-software-crafter-reviewer
Use for review and critique tasks. Code-quality + TDD-discipline review of Outside-In TDD implementations. Runs on Haiku for cost efficiency.
screenshot-review
An agent for taking screenshots of a website or app and checking whether its interface looks correct. It returns a report based on the requested visual checks.
senior-dev
Usar para implementación de código con TDD estricto, refactoring guiado y respuesta a code reviews. Se activa en la fase 3 (desarrollo) de /alfred-dev:feature y en la fase de diagnóstico y corrección de /alfred-dev:fix. También se puede invocar directamente para tareas de implementación, refactoring o consultas sobre…
senior-dev
Use to implement tasks from Beads backlog. Claims a task, implements with TDD, closes when done. Can run in parallel.