Loop Engineering これくらいでいい

https://cybozu.connpass.com/event/402785/

Transcript

1. DroidKaigi × iOSDC After Night Loop Engineering これくらいでいい エージェントにプロンプトを書かせて、人間はループ を設計する m mikan( 一瀬喜弘) 10 20 30 40 60 80 95
2. 自己紹介 Speaker object Mikan { val name = "一瀬喜弘" val occupation = Engineer.Android val company = "AbemaTV" val favoriteBooks = listOf( "ソフトウェア設計の結合バランス", ) } X @mikanIchinose GitHub @mikanIchinose 02 / 20
3. 01 ループエンジニアリングとは
4. 言い出した人の言葉 Loop Engineering I don’t prompt Claude anymore. I have loops running that prompt Claude. My job is to write loops. Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. 1 都度プロンプトを打つのをやめて、 エージェントにプロンプトを書かせる 2 人間は ループを設計する 04 / 20
5. ピンとこない …… 言葉は分かる。で、何をすればいいのか 05 / 20
6. ループの作り方は色々ある How を監視させる 1 CI 2 GitHub 3 目標を決めて/goalを実行 4 etc... 上のイベントをフックさせる 06 / 20
7. 僕がやっているループ タスクをマークダウンとして出力させて、 全部完了するまでループさせる 07 / 20
8. 02 commander プラグイン
9. commander-claude/ tree . ├── agents │ ├── actor.md │ ├── adversarial-reviewer.md │ └── experimenter.md └── skills ├── commander │ ├── backlog-format.md │ ├── backlog.schema.json │ └── SKILL.md └── delegate-to-codex └── SKILL.md 09 / 20
10. skills/commander/SKILL.md Markdown --argument-hint: <達成したいこと> disable-model-invocation: true --# Commander あなたはcommander。要求の理解、実装の分析、タスク分解、委譲、進捗管理、レビュー統合が仕事。 ## 入力 $ARGUMENTS ## 役割分担 commanderが行うのは、分析・タスク分解・backlogの管理・コマンドの実行・コミット。 コードを書く作業はAgent toolでsubagentに委譲する。commanderが自分で実装することはしない。 Codexへの委譲やworktreeの管理には `orchestration` skillを使う。 | 役割 | subagent_type | 起動条件 | プロンプトに渡す情報 | |---|---|---|---| | experimenter | `commander-claude:experimenter` | 実装してみないと解けない不確実性があるとき。コード読解で解けるなら起動しない | 検証したい仮説、既知 10 / 20
11. skills/commander/backlog-format.md Markdown --# フロントマターの構造は ./backlog.schema.json を参照 id: 003 slug: viewing-history-usecase status: todo # todo | doing | done sub_task: [004, 005] # 子タスク parent_task: 001 # 親タスク worktree: # 起動後に埋める。actorのworktree絶対パス branch: # 起動後に埋める。actorのbranch references: [docs/docs/path/to/reference] # 実装する際に参照すべきドキュメント --## 背景 なぜこのタスクが必要か。元の要求のどの部分に対応するか。 前提となる調査結果は`tmp/docs/` の該当ファイルを絶対パスで示す。 ## 変更対象 - 触るファイル・モジュールを列挙する - 触ってはいけない範囲があれば明記する(スコープの境界) ## 完了条件 - [ ] 検証可能な条件を1つずつ書く。「正しく動くこと」は条件ではない 11 / 20
12. フォーマットはJSON Schemaで縛る 1 フロントマターの構造を機械可読にする Schema "status": { "enum": ["todo", "doing", "done"] 2 運用規則の詳細はbacklog-format.mdに書 く }, "taskId": { "oneOf": [ { "type": "integer", 3 スキーマは「形」だけを担保する "minimum": 0, "maximum": 999 }, { "type": "string", "pattern": "^[0-9]{3}$" } ] } 12 / 20
13. agents/actor.md Markdown --name: actor description: backlogタスク1件を実装・テスト実装する実装役。 isolation: worktree --# actor あなたはactor。プロンプトで渡されたタスクを完了させることが目的。 スコープ外の改善はせず、気づきは報告に書く。 ## ルール - 実装・テストの設計に入る前に、リポジトリの関連ドキュメントを確認する - 手を動かす作業はcodexに委譲する。`delegate-to-codex` skillを使う - codexの出力を鵜呑みにしない。差分を自分で読み、完了条件と突き合わせてから報告する ## 報告フォーマット 1. worktree絶対パスとbranch 2. 完了条件ごとの充足状況 3. 変更ファイル一覧 4. 検証: 自分で確認した範囲と、commanderに実行してほしいコマンド 5. スコープ外の気づき 13 / 20
14. 03 工夫点
15. メインエージェントに仕事をさせない 理由 長時間動き続けるので、思考が消滅しないようにする commanderはあくまで分析・分解・進捗管理・検証 Tips やらせること / やらせないこと 1 やる: タスク分解・backlog更新・コマンド実行・コミット 2 やらない: 実装・テスト実装(subagentに委譲) 15 / 20
16. SKILL.md を極力小さく保つ 1 最近流行っているskillはどれもシンプル 2 短い方が改善しやすい 3 ルールを沢山書いても、長時間実行してる 間に忘れる (grill-me, ponytail, eli5) Tips ルールを足すより、 ループが拾う場所に置く 長い指示書は、長時間運転には耐えない 16 / 20
17. 04 最近改善したこと
18. クリーンアップをbacklogに移した Before に「掃除する」と書いていた → 掃除してくれない時が多々あった SKILL.md Update After クリーンアップを最終タスク(id: 999)としてbacklogに出力させる → backlogならちゃんと見てくれるだろうという判断 18 / 20
19. references 課題 で参照先を固定した 開発方針と異なる実装をされることがあった Update 対応 フロントマターに references を追加し、 実装中に参照すべきドキュメントを commanderに書かせる references: - docs/architecture.md - docs/testing-guideline.md 19 / 20
20. ご清聴ありがとうございました 20 / 20