tsumikiのコマンドTDD編

これはなに？

tsumiki に含まれているTDDなコマンドについて
利用の流れを前提にポイントを説明

前提

TDDとは言ってますが、本来の形のTDDではないのはAIDDと組み合わせる上で仕方ないのか...
「元々本来の形のTDDに近い作りにしてたけど、そうするとトークン消費が激しすぎたので今の形に落ち着いた」という裏情報を得てます。
基本的にTDDのフローをガードレールとして利用する感じで、TDDをして実装したいというのはない。っぽい感じです

/tsumiki:tdd-requirements タスクファイル名　TASK番号

TASKの中での要件を詰めるコマンドです
docs/implements/{要件名}/{{task_id}}/ ここに要件ファイルとかを書き出す感じですね
TDDなコマンドは全体的にSDDの結果のタスクファイルとTASK番号を渡すというシンプルな構造
2025年12月にリリースされるものはタスクファイル名では無くて「要件名」になるらしいですが、余り変わらないとのこと
この段階で、勘違いがないかとかそもそものずれが無いかとかをちゃんと確認すると、この先の実装が楽になります。
当然ですが、信号機による信頼度評価の結果もついているので赤は要チェックだそうです

/tsumiki:tdd-testcases タスクファイル名　TASK番号

tdd-requirementsで作った要件に対して、テストケースを洗い出すコマンドです
docs/implements/{要件名}/{{task_id}}/ ここにテストケースを書き出す感じですね
この段階で、勘違いがないかとかそもそものずれが無いかとかをちゃんと確認すると、この先の実装が楽になります。
当然ですが、信号機による信頼度評価の結果もついているので赤は要チェックだそうです

/tsumiki:tdd-red タスクファイル名　TASK番号

tdd-testcasesで作ったテストケースを作ってredにするためのコマンドです
実際にテストコードを作ってredになるのを確認する所までです
実際に実行に必要な最小限のモックは作るっぽい

/tsumiki:tdd-green タスクファイル名　TASK番号

tdd-redで作ったテストを通すための最小限の実装をするコマンドです
可能な限り100%を目指してるはずですが、たまに次の工程に回してる時を見かけますね

/tsumiki:tdd-refactor タスクファイル名　TASK番号

tdd-greenはあくまで最小限の実装なので、ちゃんとしたコードにリファクタするコマンドです
この段階で一般的なセキュリティー的な確認とかも基本的なモノは実施してるっぽいです

/tsumiki:tdd-verify-complete タスクファイル名　TASK番号

ここまでのtddタスクがちゃんと終わっていることを確認するコマンドです
tdd-testcaseで作ったテストケースが作り終わってるのかとか、ちゃんと全てのテストが通っているのかとか一通り確認を実施してレポートするまでです
もし、ここでダメだったらtdd-redまたはtdd-greenから実施する感じです

ここまで完了したらちゃんとレビューしてコミットしましょう

/tsumiki:kairo-implement タスクファイル名　TASK番号

上記をまるっと実行するコマンドです。
ノンストップでtdd-requirementsからtdd-verify-completeの完了までずっと動かし続けます。
普通に1時間とか動作してることが多いみたいです
次のリリースでtdd-testcasesで一回立ち止まるオプションが追加されると風の噂で聞いてます

まとめ

AI駆動開発をする上で、適切なガードレールを設定しつつコマンドを分離することで複数の異なる指示を混ぜること無く実施する感じのコマンドデザインになってますね
ちなみに、TDDで実装してくださいでもTDDで実装してくれるのでは？という疑問に対しては「それだと信号機による信頼度評価が付けにくかった」ということで、信号機による信頼度評価を付けることが凄く大事みたいです。