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 commands/classmethod/tsumiki/tdd-verify-completegit clone --depth 1 https://github.com/classmethod/tsumikiWhat 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.00046 | $0.05096 |
| Opus 5 | $0.00023 | $0.02548 |
| Sonnet 5 | $0.00009 | $0.01019 |
| Haiku 4.5 | $0.00005 | $0.00510 |
Grade A, and why
tdd-verify-complete 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 2d 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.
This is a copy
86% identical to tdd-refactor — 582 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 409 lines — stays where its author put it; the contents beside it link to each section on GitHub.
TDD開発でテストケースの実装が完全に完了しているかを検証します。
context
出力ディレクトリ="./docs/implements" 機能名={{feature_name}} タスクID={{task_id}} 要件名={{requirement_name}} メモファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md 要件定義ファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md テストケースファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md Refactorフェーズファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-refactor-phase.md 元タスクファイル=docs/tasks/{taskfile}.md
step
- $ARGUMENTS がない場合、「引数に要件名とTASK-IDを指定してください（例: ユーザー認証機能 TASK-0001）」と言って終了する
- $ARGUMENTS の内容と context の内容をまとめてユーザに宣言する
- step2 を実行する
step2: コンテキスト準備
検証コンテキストの準備を実行する：
-
タスクノートの読み込み（唯一のコンテキストソース）
./docs/implements/{要件名}/{{task_id}}/note.mdを読み込み- 存在しない場合: @task で
/tsumiki-legacy:tdd-tasknote {要件名} {{task_id}}を実行して生成 - note.mdには技術スタック、開発ルール、関連実装、設計文書、テスト関連情報、注意事項が集約済み
-
直前フェーズの出力を読み込み
./docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md- 要件定義./docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md- テストケース定義./docs/implements/{要件名}/{{task_id}}/{feature_name}-refactor-phase.md- Refactorフェーズの結果./docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md- 開発履歴メモ（存在する場合）
-
元タスクファイルを直接読み込み
docs/tasks/{taskfile}.md- タスクの完了状態を確認- プロジェクト全体のタスク進捗を把握
読み込み完了後、step3 を実行する
step3: 既存テストのグリーン状態確認
- 必須: @task で全ての既存テストが成功していることを確認
- テスト結果のスコープ分類:
- テストケースファイル（{feature_name}-testcases.md）に記載されたテストファイルを「スコープ内」とする
- それ以外の失敗テストは「スコープ外」として分類
- スコープ内テスト失敗がある場合: 要改善として記録（後のstep7で差し戻し判定に使用）
- スコープ外テスト失敗がある場合: memoファイルに記録し、auto-debug対応を推奨として記録
- この工程では修正禁止: テスト失敗を発見してもここでは修正しない
- テスト実行時間の確認:
- 総実行時間が30秒以上の場合は記録
- 2秒以上かかるテストファイルを特定して記録
- 遅いテストがある場合は以下を推奨として記録:
📝 推奨事項: テスト実行速度の改善 総実行時間: XX秒（30秒以上） 遅いテストファイル: - test/user.test.js: 15秒 - test/integration.test.js: 8秒 改善方法: 1. `/tsumiki:dcs:test-performance-analysis` で詳細分析 2. `/tsumiki:test-optimization-patterns` でパターンを確認 3. 次のTDDサイクルで段階的に改善
- テスト状態（スコープ内/スコープ外それぞれ）を記録し、step4 に進む
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.
- 2d ago First seen · 409 lines · 46 tokens per session scan A aa2c1c3ee661
tdd-verify-complete is a command published in the GitHub repository classmethod/tsumiki (974 stars, last pushed 26d ago), licensed MIT. It adds 46 tokens to every session and 5,096 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. It is 86% identical to tdd-refactor, differing in 582 lines, and is treated as a copy.
Other commands, from other repositories
go-test
Go TDD workflow with table-driven tests.
pm-auto-design2dev
設計レビューから実装完了まで完全自動化（設計レビュー→作業計画→TDD実装）.
feature-plan
Analyzes feature specifications and creates detailed TDD implementation plans with incremental PR breakdown and specialist agent assignments. Use when the user wants to plan feature implementation, break down a feature into tasks, or mentions implementation plan, feature planning, or TDD workflow. WHEN NOT: Writing…
task-verify
PitWay: Run an inprogress task's approved verification command and persist evidence.
execute-plan
Execute an implementation plan methodically with TDD and continuous validation.
eval
Evaluate and improve one healthcare agent's system prompt. Run up to 5 iterations of: prepare fixed questions -> answer -> judge -> improve -> re-score -> commit if better.