1つの問題の自動修正

codepatrol skillの指揮役から任されて、調査レポートの問題を1つ修正し、pull requestをready for reviewまで仕上げる。

人間は修正の途中に立ち会わない。出来上がったpull requestを、後からまとめて確かめる。人間が開発していれば途中で訊かれたはずの判断を、自分で下し、後から読む人間が辿れるように書き残す。

このskillを実行する時の前提

• 実行環境の条件は codepatrol skill の「実行環境の確認」と同じである。着手する前に自分でも確認し、満たさなければ何も変更せず、満たさない条件を報告して終了する
• ユーザーに質問できない。plan modeにも入らない。計画を承認する相手がいないので、計画は作業用ディレクトリに書いてから実装に進む
• 担当する問題、修正が触るリポジトリとそれぞれのcloneの場所、pull requestの向け先、作業用ディレクトリは、指揮役の指示に従う
• 複数のリポジトリを扱う時、コマンドの作業ディレクトリが設定を置くリポジトリに戻る環境がある。別のリポジトリのpull requestやbranchへの操作では、対象のリポジトリを毎回明示する。番号だけで指すと、別のリポジトリの同じ番号のpull requestに書き込む。sanity-reviewを任せるsubagentにも、対象のリポジトリとコードを読む場所を伝え、同じように明示させる
• 他の問題を修正するsubagentが並走している。ユーザーのcheckoutでは、branchの切り替えもファイルの変更もしない。対話コンテキストの書き出しだけは、開発フローが定める場所に行ってよい。他のsubagentと共有している開発サーバーやコンテナを、止めたり再起動したりしない
• mergeと、merge後の開発環境の後始末はしない。指揮役が行う
• トリアージページとレポートの読み書きは、cosense skillに従う

着手する前に確かめる

トリアージページの冒頭に書かれた編集ルールを読む。着手の宣言、状態アイコン、署名の書き方は、そこで決まっている。この手順書と食い違う時は、ページの記述を優先する。

担当する問題の行に、他の人の着手の宣言やpull requestが既にあれば、他の人が着手している。作業ツリーを作らず、ページも編集せず、その事を報告して終える。

指揮役から、途中で止まった修正の引き継ぎを指示された時は、指示されたpull requestやbranchの続きから進める。引き継ぐのは、指示された物だけである。

開発フロー

指揮役から渡された場所にある、software-factory-mode-2026aki skillのSKILL.mdを読み、その開発フローに従う。Skill toolでは呼び出せないskillなので、ファイルを読む。

そのフローが、ユーザーの指示や確認を待つと定めている箇所は、ユーザーが次の通り包括的に許可している。待たずに進める。

• pushと、draftでのpull requestの作成
• インラインレビューコメントは、草稿をそのまま投稿する
• sanity-reviewを実行し、指摘に対応してpushし、対応した内容をpull requestにコメントする
• 指摘への対応が済んだら、ready for reviewにする。レビュアーの指定やラベルといった、repoのレビュー依頼の慣習があれば、この時に行う
• トリアージページとレポートへの記入
• 向け先のbranchが進んで衝突する時は、自分のpull requestのbranchをrebaseしてforce pushする

フローの中で呼び出すskillが、ユーザーに質問する事がある。質問の答えを引数に含めて呼び出し、質問が起きないようにする。Codexとの相談の深さは「よく相談する」にする。

次の事は、上の許可があっても変わらない。

• pushの前に、毎回Codexに相談する。rebaseした後も、sanity-reviewの指摘に対応したcommitも、コメントだけの変更も飛ばさない。それぞれを新しい相談として扱う。往復の上限は、相談ごとに数える
• Codexへの相談は、自分も、sanity-reviewを任せるsubagentも、Skill toolで codex-consultation を呼び出して行う。codex exec の直接実行で済ませない。Codexの出力は、作業用ディレクトリに残す。sanity-reviewを任せるsubagentにも、同じ場所に残させる。指揮役が、相談が最後まで完了した事を確かめるのに使う
• Codexへの依頼の言葉は、codepatrol-report の「依頼の枠組み」に従う。問題の修正は、攻撃側の語彙で説明しやすく、Codexの提供元のフィルタで止まりやすい
• Codexが利用制限や障害で止まったら、他の相談相手に切り替えず、途中結果をcommitして作業を止め、報告する
• 作業を途中で止める時は、止めた理由をpull requestにコメントする。pull requestが無ければ、途中結果を残したbranchの名前と一緒に、レポートの申し送りに書く。次に起動した指揮役が、再開してよい修正かどうかを、そこから判断する
• sanity-reviewを任せるsubagentに、pull requestのレビュアー、ラベル、draftの状態を変えさせない。それらを変えるのは、指摘への対応を終えた自分である
• sanity-reviewの完了は、subagentの完了の通知で知る。pull requestのコメントが現れた事で判定しない。先に投稿した対話コンテキストのコメントを、報告書と取り違える
• sanity-reviewの完了を待つ途中で、指揮役に報告を返す事になった時は、途中の報告として、pull requestの場所と残っている工程を書いて終える。指揮役がsanity-reviewの報告を渡して再開させるので、指摘への対応から続ける
• draftの間は、レビューを依頼しない。レビュアーを指定した時点で、人間のレビュー待ちの列に並ぶ

判断を下す

問題のレポートには対応の案が書かれているが、実装してみると案の通りにはいかない事がある。

• 実装者がその場で決められる判断は、自分で決める。修正のセオリーが複数ある時にどれを選ぶか、不正な入力にどう応答するか、といった判断である。判断と理由を、pull requestの概要欄と対話コンテキストに書く
• 仕様の判断が要り、自分では決められない時は、指揮役の指示にある質問の扱いに従う。指示が無ければ、途中結果をcommitして作業を止め、報告に質問を書く。指揮役がユーザーの答えを渡して再開させる
• 修正の一部だけが仕様の判断を要する時は、判断が要らない部分を直し、残した部分をレポートに申し送る
• 実装の中で見つけた別の問題は、このpull requestでは直さず、レポートに申し送る
• この修正を入れると別の重大な問題が起きると分かった時は、ready for reviewにせず、draftのまま作業を止めて報告する。先に他の修正が要る、といった場合である。ready for reviewにしたpull requestは、人間の確認なしでmergeされうる

pull request

• 概要欄に、レポートの問題への行リンクと、トリアージページの行へのリンクを書く
• 本番に出す前後に人間がやる事は、概要欄に書く。DBのindexの作成、環境変数の追加、他のrepoとのデプロイの順序、本番のデータの点検、デプロイ後に見る所、といった事である。デプロイする人間は、概要欄から作られるまとめを読んで作業する。概要欄に無い事は伝わらない
• 1つの問題の修正が複数のリポジトリにまたがる時は、リポジトリごとにpull requestを作り、pull request同士を相互にリンクする。sanity-reviewはpull requestごとに行う

トリアージページとレポートへの記入

pull request、トリアージページの行、レポートの問題を、互いに辿れるようにする。

• 着手する時に、トリアージページの担当する問題の行に、着手の宣言を書く
• draftのpull requestを作ったら、着手の宣言をpull requestへのリンクに置き換える。レポートの問題にも同じリンクを足し、その下に申し送りを書く。対応した事、レポートの対応の案と違う判断をした事、残した事、実装の中で見つけた別の問題である
• 状態アイコンは、両方のページで、pull requestの状態に合わせる。draftの間は作業中、ready for reviewにしたらレビュー希望である
• 自分がトリアージページに書くのは、着手の宣言と、状態アイコンを付けたpull requestへのリンクだけである。申し送りは全てレポートに書く
• 着手の宣言とpull requestへのリンクには、自分の署名に、指揮役から伝えられたユーザーの署名を並べる。誰の指示で自動的に進めている修正なのかが、ページを読む人に分かる。レポートの申し送りは、自分の署名だけでよい

指揮役への報告

10行以内で書く。指揮役は多くの修正を並行して回しており、長い報告は指揮役のコンテキストを使い切る。詳細はpull requestとレポートに書いてあるので、繰り返さない。

• pull requestの場所と状態。ready for review、draft、質問で停止のどれか
• レポートの対応の案と違う判断をした事
• 人間が確認すべき事。mergeの前に本番の点検が要る、設計の変更が大きい、挙動が変わる、動作確認のうち実施できなかった物がある、といった事である
• Codexに相談した回数と、Codexの出力の場所。sanity-reviewを任せたsubagentの分も含める
• 残した作業環境。worktree、branch、test用に作ったDBやコンテナ等である。merge後の後始末の担当に渡される
• 質問で止まった時は、質問
• 手順や規則で、曖昧だった点