tsumikiの効果的な使い方を考えてみる

これはなに？

tsumikiを使うとして、その効果的な使い方を色々使って考えて見た

tsumikiの特徴

• ものすごい勢いでtokenを消費する
• MAXプラン($100)で最短4時間くらいでlimitが来る
• 自立性が高くて結構な時間放置できる

そこから考えられる効果的な使い方

プランの制限を上手く使って最大の効果を得るのが目的
Proプランは1h弱でlimitが来るので フルタイムの開発者 には非推奨です

MAXプラン($100)の場合

tdd-requirements と tdd-testcases をtask毎にいくつか手作業で実行
ミーティングとかお昼ご飯とかで作業が出来ない間に tdd-cycle-full.sh をtask毎に実行して実装を完了させる

MAXプラン($200)の場合

tdd-requirements と tdd-testcases をtask毎に実行しつつ
tdd-cycle-full.sh を3つくらい同時にtask毎に実行する
合計4画面に分割する

共通 git commit

task毎に完了してコードの確認も終わったら、毎回忘れずに git commit する
これをやることで、実装の方針を修正したい場合にも安心して実施できる

共通 分割単位

kairoコマンドは比較的大きめのタスク単位にする
たとえば、一人の人がtsumikiで数日かかるとかの作業単位にする
kairoコマンド単位でブランチを作ってpushするイメージ

共通 contextサイズ

contextサイズ問題は結構大事なので
tsumikiの各コマンドを実行後には /clear か /compact を実行する
tsumikiのコマンドはそれぞれが独立していて、単独でも実行可能なので前のコマンドの記憶が必要ないらしい

こんなときは？

エラーが結構多い

tsumikiを動かしているとgreen等の成功率が70%とか90%とかで終わってることがある
それを解消するには...

/auto-debug コマンドを実行する

limitが来るか、成功率が上がるまで自動的にテスト->debugを実行してくれる
観測によると3時間半ほど自動で稼働し続けてた実績もあり...MAXプラン($100)だと事実上他に動かせないので、PCを使わない時間帯にどうぞ

なんか動きがおかしい

/exit で claude code を再起動しましょう
/clear してもなにか残ってるみたいなので、キッチリ再起動すれば問題なくなることが多いです
vscode 上で動かしてると vscode 自体の動きがおかしくなるので時々再起動してあげると良いと思います

commands の修正が反映されない

/exit で claude code を再起動しましょう
コマンド等はキャッシュしてる動きをするので、修正時には claude code 自体の再起動が必須です

opus使うべき？

tsumikiはsonnetで十分です。
opusは修正にすごく時間がかかるときなど、 ここぞ という時の秘密兵器的な使い方があってます。opusを活用するよりsonnetを並列で動かして仕事を早く終わらせましょう