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-redgit 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.00037 | $0.07623 |
| Opus 5 | $0.00018 | $0.03811 |
| Sonnet 5 | $0.00007 | $0.01525 |
| Haiku 4.5 | $0.00004 | $0.00762 |
Grade A, and why
tdd-red 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 yesterday.
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 — 669 lines — stays where its author put it; the contents beside it link to each section on GitHub.
TDDのRedフェーズを実行します。失敗するテストケースを作成し、実装すべき機能を明確に定義します。
context
出力ディレクトリ="./docs/implements" 機能名={{feature_name}} タスクID={{task_id}} 要件名={{requirement_name}} 対象テストケース={{test_case_name}} テストケース追加目標数=10以上 信頼性評価=[] 要件定義ファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md テストケース定義ファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md Redフェーズファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-red-phase.md メモファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md タスクノートファイル=./docs/implements/{要件名}/{{task_id}}/note.md
step
- $ARGUMENTS がある場合は対象テストケース名として設定、ない場合は全テストケースを対象とする
- context の内容をまとめてユーザに宣言する
- step2 を実行する
step2
開発コンテキストの準備を実行する：
1. タスクノートの読み込み（唯一のコンテキストソース）
./docs/implements/{要件名}/{{task_id}}/note.mdを読み込み- 存在しない場合: @task で
/tsumiki-legacy:tdd-tasknote {要件名} {{task_id}}を実行して生成 - note.mdには技術スタック、開発ルール、関連実装、設計文書、テスト関連情報、注意事項が集約済み
2. 直前フェーズの出力を読み込み
./docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md- 要件定義./docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md- テストケース定義./docs/implements/{要件名}/{{task_id}}/{feature_name}-red-phase.md- 既存のRedフェーズ記録（存在する場合）./docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md- 開発履歴メモ（存在する場合）
読み込み完了後、step3 を実行する
step3
-
<red_phase_template> の内容を context の情報で埋めて、テストコードを作成する
- 読み込んだコンテキスト情報（タスクノート、追加ルール等）を活用
- 信頼性レベル（🔵🟡🔴）を各テストケースに記載
- 対象テストケース名が指定されている場合は、そのテストケースのみ実装
- 指定がない場合は、未実装のテストケースから10個以上を選択して実装
- Write ツールを使用してテストファイルに保存
- Bash ツールを使用して新規作成したテストファイルのみを実行し、失敗することを確認
- Jest:
npm test -- <作成したテストファイル> - Playwright:
npx playwright test <作成したテストファイル> - pytest:
pytest <作成したテストファイル> - 全テスト実行は不要（verify-completeフェーズで実施）
- Jest:
-
作成したテストコードについて、品質判定基準に基づいて以下を評価：
- テスト実行: 実行可能で失敗することを確認済み
- 期待値: 明確で具体的
- アサーション: 適切
- 実装方針: 明確
- 信頼性レベル（🔵🟡🔴の分布）
-
品質判定結果に応じた処理:
- ✅ 高品質: そのまま step4 へ
- ⚠️ 要改善: 自動修正ループを実施
- 要改善の指摘内容（どの項目が不足/不適切か）を特定
- Task tool (subagent_type: general-purpose) で指摘内容を渡してテストコードを修正させる
- 修正後のテストコードを Write tool で上書き保存
- Bash tool で修正後のテストファイルを再実行し、失敗することを再確認
- 再度品質判定基準に基づいて評価
- 高品質になれば step4 へ
- まだ要改善の場合: もう1回だけ修正を試みる（最大2回まで）
- 2回修正しても要改善のまま → 警告をtasknoteの注意事項に追記し、step4 へ
- ⚠️ テストが成功してしまった場合（Redフェーズなのに失敗しない）:
- テストの期待値やアサーションを見直すsubagent（general-purpose）を起動
- 「まだ実装されていない機能をテストする」という原則に基づいて修正
- 修正後に再実行し、失敗することを確認
- 最大2回まで修正を試みる
- 2回修正しても成功してしまう → AskUserQuestion でユーザに確認
-
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.
- yesterday First seen · 669 lines · 37 tokens per session scan A c455f30cf45e
tdd-red is a command published in the GitHub repository classmethod/tsumiki (974 stars, last pushed 25d ago), licensed MIT. It adds 37 tokens to every session and 7,623 once invoked, about $0.0002 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-30.
Other commands, from other repositories
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.
implement
Execute the implementation plan by processing and executing all tasks defined in tasks.md.