Roo CodeのBoomerang Modeありかも
最近Roo Codeで使われているBoomerang Modeに関する、筆者の感想と現時点での使いこなし術についての記事です。
- Boomerang Modeが何か
- サブタスクとは何か
- Boomerang Modeでの筆者の使いこなしプロンプト
などを書いています。
Boomerang Modeとサブタスク
Cline/Roo Codeには元々サブタスクという機能があります。ただし、通常範囲で使ってる限りではサブタスクが起動されることはありません。
Roo Codeは、ClineやCursorよりも、きめ細かくモードを定義可能です。Plan/Act だけではなく標準で、Architect/Code/Ask/Debugなどのモードを持っています。モードごとに、ファイル操作などの権限が変わります。
さらに、Roo Codeは .roomodes
というファイルを使って、ワークスペース単位でモードを自由に追加可能です。
.roomodes
を作成することで Boomerang Modeというモードを追加できます。
Boomerang Modeは、サブタスクをコーディネートする特別なモードです。自分自身ではファイルの読み込みすら許可されていません。ArchitectサブタスクやCodeサブタスクを起動することで、作業を行います。
- 親タスク(Boomerang Mode)は、ユーザーからの指示を元に適切にArcitectサブタスクやCodeサブタスクを実行します
- サブタスクは親タスクから受け取った指示のみをコンテキストに入れて作業を行います。このとき指示が不適切だと、正しくコンテキストが構築できません
- サブタスクは「サブタスクの完了」という特殊なコマンドで終了します
- 親タスクは、サブタスクの完了でのメッセージを元にサブタスクの結果を認識します
- サブタスクの完了か、中断・通常終了などの結果を基に次の処理を続行します
これの利点は、コンテキストが制限できること。Memory Bankのような歪なテクニックを使わなくてもそれなりに協調動作が可能なことです。
筆者は元々Memory Bankというテクニックを使っていましたが、最近はMemory Bankを廃して、Boomerang Modeを検証しています。
Sonnetの200kコンテキストという狭いコンテキストでも意外となんとかなるのが利点です。
ただし、Boomerang Modeには問題も山積ではあります。
Boomerang Modeの問題
Boomerang modeに特化したプロンプトやルールファイル(システムプロンプトにあるUSER'S CUSTOM INSTRUCTION)を入れないと、正しく動きません。
よくある問題:
- Architectサブタスクが「実装したいからCodeモードに切り替えさせろ」と言い出す
- 適切なコンテキストが共有されてなくて色々失敗する。よくあるのは、ユーザーの意図が伝言ゲームして、正しく伝わらないこと
- Architectサブタスクが行った設計が不完全で、Codeサブタスクが不完全な実装しかしてくれず、ユーザーのストレスがマッハする
よくある致命的問題:
- 作業が気に食わないので巻き戻そうとしたら、auto-approveで続いてたせいでこちらの発言タイミングが存在せず、巻き戻しタイミングが存在しない。こちらが強制割り込みをして発言をしないとその時点からのやり直しができないのでタイムリープ戦術が使えない(これ自体はサブタスクじゃなくても生じる)
- サブタスクが気に食わなかったので戻したいけど、親タスクにはcheckpointがないので、checkpointへの巻き戻しができず、状態の復旧ができず、全部をgit reset --hard する羽目になる
- APIが刺さったり、Rooのウィンドウがおしゃれデザイン(ウィンドウが茶色一色になって暴走)になったりして、一度Rooを閉じた後、復帰しようとしたら、親タスクとサブタスクがそれぞれ別のタスクとして認識されるため、サブタスクのはずだったタスクを終了したとき、親タスクに戻るコマンドが実行されず、親タスクからはサブタスクが異常終了したように認識される。当然このときサブタスクがレポートすべきことがレポートできない
総じて、通常のやり方よりも「やり直し」がめちゃくちゃやりづらいです。正直バグに遭遇することもわりとあります。
筆者流使いこなし術
さて、Boomerang Modeに限らず最近検証しているのが .clinerules に project ovewview を書くというものです。Clineのリポジトリが実践しているんですが、プロジェクト概要やコントリビュートガイドを .clinerules に書くことでプロジェクトの重要情報をCline/Rooが理解してくれます。
また、コーディングガイドラインも書いて /docs/coding-guideline.md に入れています。
.clinerulesには直接コーディングガイドラインを入れず、ファイル名だけを指定していますが、いっそ入れてもいいかもと思っています。
その上で .roomodes
でBoomerang Modeを設定し、Boomerang Modeでタスクを開始します。
プロンプトが今のところ重要です。
<<実際に指示したい事柄。fooを実装しろなど>>
# **絶対に従え**
* 謙虚に振る舞え
## architectモードのサブタスクへの指示を追加しろ
* 謙虚に振る舞え
* **/docs/coding-guideline.mdに絶対に従え**
* **おまえは設計のみをするサブタスクなので、実際のコーディングは別のサブタスクへ引き継がれる**
* **別のサブタスクが問題なく実装できるようにplans/<日付>-<ブロブ>.mdに設計を出力しろ**。それがおまえの仕事だ
* このプロジェクトにおいて、後方互換性・下位互換性などといった互換性は不要
* 互換性を見つけたら積極的に削除するように計画しろ
* 互換性を作らない設計をしろ
* 設計書において、やることと、やらないことを明確にしろ
* 「やること」に必要な動作確認を設計してチェックボックスにしろ
* coreの動作確認は `bun core:dev run "プロンプト"` で行え。プロンプトは動作確認によって適切なものを設定しろ
* web-uiの動作確認は実際にブラウザで確認しろ
* ルートで使えるコマンド
* `bun run typecheck`
* `bun run test`
* `bun run build`
* `bun run dev`
* `bun run web-ui:...`
* `bun run core:...`
* ユーザーから質問があった場合は、誠実に振る舞え
* ユーザーから質問があった場合は、直接的かつ具体的に回答せよ
* ユーザーから質問があって、その内容がよくわからないときは必ずよくわからないと回答せよ
## codeモードのサブタスクへの指示を追加しろ
* 謙虚に振る舞え
* **/docs/coding-guideline.mdに絶対に従え**
* `cd hoge; bun dev run` のようなコマンドを実行するときは必ず()でくくってsub shell使え
* Architectureモードで作成されたplanのMarkdownに書かれている動作確認を全部しろ
### [IMPORTANT] **同じ現象が3回以上続く場合はこの項目を絶対に思い出せ**
* まずplans/<日付>-debug-<ブロブ>.md(デバッグログ)を作成しろ。
* [IMPORTANT] デバッグ作業は必ずデバッグログを活用して行え
* デバッグのために場当たりに色々追加すると、後で困るから、シンプルに検証しろ
#### デバッグログに書くべきこと
* あるべき正しい姿について定義しろ
* いま遭遇している状態について列挙しろ
* この間にある差分が、解決すべき問題点、検証事項だ。
* 何かの作業をしたらデバッグログを更新しろ
* 検証事項の書き方
* 解決すべきことがらについて書け。これは大筋
* 検証事項を書け。これは細かければ細かいほど良い
* 可能な限り、検証事項が失敗・成功したときに、どうなるかの想定を書け
* 検証事項は具体的な手順を書け
* 検証事項の積み重ねが極めて重要だ。ステップバイステップで検証しろ。
「謙虚に振る舞え」は必須テクニックです。Geminiが特にひどいんですが、Sonnetにしても、自信満々に間違えるし、とても強情という重大な悪癖を持っています。
最後の方のデバッグ手順の指示は、もうちょっといい指示方法がないか、試行錯誤中です。LLMは自分の作業がハマっている認識を持ってないため、ここでの指定はまず効きません。
高速目grepでハマりを見つけたときに、作業を中断させて貼り付けると、それなりにデバッグ能力が向上するので、この指示内容自体は間違いではないはずですが。
まとめ
Boomerang modeは、サブタスクを活用したもので、うまくハマれば適切にサブタスクをコーディネートしてMemory Bankなしでもコンテキストが破綻せずにサブタスクがうまく動いてくれます。
使用コンテキストサイズもある程度抑えられる効果が期待できます。
ただ、サブタスク周りの問題も多く、色々と安定しないところはあります。
Discussion