リポジトリのセキュリティ調査を領域ごとに進める。同じサービスを構成する複数のリポジトリを束ねて調査できる。このsessionは調査を指揮し、領域ごとに起動したsubagentが調査してレポートを出力する。
レポートの問題のトリアージと、問題の自動修正、問題を直すpull requestの状態の同期も指揮する。複数sessionにまたがる長期作業を想定し、実行するたびに現状を確認して続きの作業を行う。ユーザーが手動で起動する。
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
リポジトリのソースコードを領域ごとにセキュリティ観点で調査し、レポートを揃える。ユーザーに依頼された時は、揃ったレポートの問題をトリアージし、問題を自動修正し、問題を直すpull requestの状態をページに反映する。 このsessionは指揮役になる。ユーザーと対話し、調査する領域を決め、subagentに作業を任せ、結果を確かめて記録する。調査する領域が1つでも同じである。
指揮役としての振る舞いは、kuden:orchestrator skillを読み込み、その基準に従う。指揮役は調査対象のコードを読まない。
作業は、以下のskillを実行するsubagentに任せる。
| skill | 作業 | 読む物 |
|---|---|---|
| codepatrol-setup | 調査対象リストと観点リストを生成・更新する | コード |
| codepatrol-report | 1つの領域を調査してレポートを出力する | コード |
| codepatrol-triage | レポートの問題を分類し、トリアージページを作る | レポート |
| codepatrol-sync-state | 問題を直すpull requestの状態を、ページに反映する | レポートとpull request |
| codepatrol-autofix | 1つの問題を修正し、pull requestを仕上げる | レポートとコード |
| codepatrol-autofix-deploynote | デプロイの前後にやる事を、release pull requestのコメントにまとめる | pull request |
subagentには、Opus以上のtierのmodelを指定する。
.dev/codepatrol/
config.md ← レポートの書き出し先設定
checklist.md ← リポジトリ固有の機構と観点の補足。マスターのCHECKLIST.mdと一緒に読む
targets.md ← 調査対象リスト。各H2見出しが調査領域。関連リポジトリの一覧もヘッダにある
{領域名}-{YYYY-MM-DD}.md ← 領域ごとの調査レポート（書き出し先がローカルの場合）
同じサービスを構成する複数のリポジトリは、1つの .dev/codepatrol/ と1つのhubページに束ねて調査する。設定を置くリポジトリは1つで、他のリポジトリは関連リポジトリとして targets.md のヘッダに一覧がある。領域名の接頭辞でリポジトリを区別する。関連リポジトリの側には .dev/codepatrol/ を作らず、起動は設定を置くリポジトリで行う。
関連リポジトリのcloneの場所は、開発者ごとに違うので targets.md には書かれていない。memoryにあればそれを使い、無ければユーザーに訊いて、次の起動で訊かずに済むようにmemoryに記録する。subagentには、リポジトリごとに絶対パスで伝える。
いずれかを満たさなければ、何も行わず、満たさない条件をユーザーに報告して停止する。トリアージと、状態同期だけを行う時は、条件2と条件3の確認は要らない:
command -v codex を実行して確認するcodex exec --ephemeral にstdinで渡して1回実行し、出力のヘッダから読む。Luna・Terra等の軽量tierと、Solより前の世代のmodelは相談相手として足りないcodex exec を直接実行するのはこの確認だけにする。Codexへの相談は、subagentがSkill toolで codex-consultation を呼び出して行う。
調査と、リストの生成・更新は、調査用のbranchをcheckoutしたgit worktreeで行う。調査は長時間かかるので、その間もユーザーが自分のcheckoutで他の作業を続けられるようにする。
.dev/codepatrol/ の置き場所は、リポジトリがこのディレクトリをgitで管理するかどうかで決まる。
作業ツリーを用意したら、ユーザーに報告する。作業がどこで行われ、変更がどこに残るのかを、ユーザーが把握できるようにする。
.dev/codepatrol/ の場所subagentには、リポジトリごとのコードを読む場所と、.dev/codepatrol/ の場所を伝える。
.dev/codepatrol/ の3つの設定ファイルが揃っていなければ、無い物を用意する。
無ければ、レポートの書き出し先を決めて記録する。
Cosenseに集約する — レポートをCosenseのページとして作成し、hubページに被リンクで集約する。チームでの共有・議論に向くローカルファイル — .dev/codepatrol/{領域名}-{YYYY-MM-DD}.md に書き出す{プロダクト名} セキュリティレポート）をユーザーに確認する# Codepatrol Report Destination
レポートの書き出し先設定。
- 書き出し先: {Cosense または ローカル}
- project URL: {https://scrapbox.io/プロジェクト名}
- hubページ: {hubページ名}
- レポートページのタイトル規則: `{hubページ名} {YYYY/M/D} ({領域名})`
- 年月日はレポート作成時点、月と日はゼロ埋めなし（例: 2026/7/3）
- 前提: cosense CLI（`npm install -g @helpfeel/cosense-cli`）のインストールとログイン
ローカルの場合は「書き出し先: ローカル」だけを記録する。
既存のconfig.mdのタイトル規則がこの形と違う時は、ユーザーに伝える。config.mdの書き換えはユーザーが行う。
targets.md が無い初回は、codepatrol-setupを任せる前に、同じサービスを構成する別のリポジトリが無いかをAskUserQuestionツールで1回確認する。インフラ設定、アップロードや配信を担う別のサーバー、課金サービス、スマホアプリやブラウザ拡張のようなクライアントが典型である。別のリポジトリにある問題は、そのリポジトリを束ねないと検出できない。
初回に限らず、codepatrol-setupの報告にある「関連リポジトリの候補」はユーザーに伝える。足すと決まった物は、同じように名前・場所・接頭辞を決めて、codepatrol-setupに両方のファイルの更新を任せる。
次の場合に、codepatrol-setupを実行するsubagentを起動し、生成・更新を任せる。
Generated by の記録から、生成したmodelが「実行環境の確認」の条件1を満たすと確認できない。Sonnet・Haiku、Codex、記録なし等である。両方を作り直させるGenerated by の記録から、レビューしたCodexが条件3を満たすと確認できない。「Codexレビュー未実施」の記録がある、Codexの実行環境が書かれていない、条件外のmodel等である。リストのレビューだけをやり直させるFormat の記録が、codepatrol-setup の「設定ファイルの形式」が定める現在の値と違う、または無い。skillの更新で形式が変わった時である。両方を更新させるcodepatrol-setupでのCodexのレビューを経ていないリストで、調査を始めない。Codexが止まってレビューが完了しなかった時は、ユーザーに報告して判断を待つ。
調査を始める前に checklist.md を読み、checklistとレポートの責任境界 に合わない記述が入り込んでいないかを確かめる。問題の断定・深刻度・レポートの問題への言及があれば、調査の担当が読む前に取り除く。事実の記述に書き直すのにコードの確認が要る時は、codepatrol-setupを実行するsubagentに任せる。
subagentの報告から、targets.mdの領域の一覧をユーザーに伝える。領域の分割・統合は、ユーザーがtargets.mdを編集して行う。
targets.md の領域と既存のレポートを突き合わせ、領域ごとに未調査か調査済みか、調査済みなら最後の調査時期を把握して、ユーザーに報告する。
.dev/codepatrol/ にレポートのファイルがある領域が調査済みである。調査時期は、ファイル名の日付から読む進み具合の判定は、レポートの存在と調査時期だけで行う。コードの変更内容から再調査の要否を推定しない。
範囲が指定されていなければ、AskUserQuestionツールで1回だけ確認する。未調査の領域だけか、調査済みの領域の再調査も含めるか、領域を指定するか、である。 再調査を含める時は、いつより前のレポートしか無い領域を再調査するのか、境目の時期も確認する。中断した後に起動し直した時に、同じ境目から残りの領域を求められる。
順番は指揮役が決める。
中断した後に起動し直した時は、範囲と既存のレポートから残りの領域を求め直す。
レポート1本ごとに新しいsubagentを起動し、codepatrol-reportを実行させる。
.dev/codepatrol/ の場所既存の問題の内容は、指示に含めない。
既存のレポートにある問題の名前を、レポートごとに並べたファイルである。領域をまたいで同じ問題に別の名前が付くのを防ぐ。
読むファイルが重ならない領域の組だけを、並列にする。近い領域を並列にすると、同じ問題に別の名前が付く。並列は3本までを目安にする。別のリポジトリの領域でも、対になる領域はファイルが重なる。targets.mdに書かれた対になる領域を、組を決める材料にする。
並列にした組が終わったら、各subagentの報告にある「他の領域と重なりそうな問題」を突き合わせる。同じ問題に別の名前が付いていたら、両方のレポートの該当する問題に、相手の問題への参照と、どちらの名前で1件として扱うかを、1行ずつ足す。
ユーザーに報告する前に、以下を自分で確かめる。
subagentは、作業の中で checklist.md と targets.md を編集する。subagentはcommitしない。指揮役が差分を確かめて、調査用のbranchにcommitする。.dev/codepatrol/ をgitで管理しないリポジトリでは、差分を確かめるだけで、commitはしない。
checklist.md に、責任境界に合わない記述が入っていれば、commitせず、取り除く。checklistは調査の足場で、問題を書くと次の調査を誘導する最初の1本は単独で調査させ、結果をユーザーに報告して確認を待つ。レポートの形と手順に問題が無い事を確かめてから、残りの領域に進む。
それ以降は、1本または1組が終わるごとに短く報告し、承認を待たずに次へ進む。報告には、レポートの場所、問題の件数と深刻度の内訳、Highの問題の名前と要約、実環境の確認が要る項目の有無を含める。
止まってユーザーの判断を待つのは、次の場合である。
出力済みのレポートは、他のレポートやpull requestから参照されている。手順の誤りが後から分かった時も、削除や作り直しをせず、ユーザーに報告して判断を待つ。
どちらも、ユーザーに依頼された時に行う。調査のたびに行う作業ではない。
config.md から、問題を直すpull requestが作られるリポジトリは targets.md のヘッダの関連リポジトリから読む。読むのはヘッダだけである。どちらも、今の調査対象を表す物を読む。調査用のbranchやユーザーのcheckoutに、default branchより新しい物があれば、そちらであるレポートの問題が多い時に、どれを誰が直すかを決める材料を作る。codepatrol-triageを実行するsubagentを起動する。
指示に含める事:
subagentの報告から、作成したページの場所、修正難度ごとの行の数、修正難度に迷った問題をユーザーに伝える。
前のトリアージページがある時は、新しいページを作る前に、前のページで状態同期をしておく。修正PRの行は、前のページの状態のまま引き継がれる。
修正の作業が進むと、ページに書かれた状態が、pull requestの実際の状態からずれていく。codepatrol-sync-stateを実行するsubagentを起動し、ずれを直す。修正の作業が続いている間、繰り返し行う。
指示に含める事:
subagentは、判断が要る事を、ページを直さずに報告する。報告をユーザーに伝え、判断を待つ。
ユーザーに依頼された時に行う。トリアージページの問題を、subagentに1つずつ修正させる。autofix.md を読み込み、それに従う。
codex exec の直接実行で代替しないNo reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Agent Skillを書く時の心得。SKILL.mdに何を書き、何を書かないかの判断基準を定める。AIが読んで従う文書に共通の心得は、kuden:common-rules-for-agent-instructionsにある。 Agent Skillを作成する時、編集する時、レビュー指摘の採否を決める時に読み込む。
The English summary is being prepared. Showing the original description.
ソースコード中のコメントを書く時の心得。コメントに何を書き、何を書かないかの判断基準と、置く位置、日本語の文体を定める。 ソースコードのコメントを書く時、直す時、レビューする時に読み込む。
The English summary is being prepared. Showing the original description.
セキュリティ調査で検出された問題を1つ修正し、pull requestをready for reviewまで仕上げる。 codepatrol skillが起動したsubagentが実行する。ユーザーが直接呼び出す事は想定していない。
The English summary is being prepared. Showing the original description.
本番に出る前の修正が積まれたrelease pull requestに、デプロイの前後に人間がやる事をまとめたコメントを投稿・更新する。 codepatrol skillが起動したsubagentが実行する。ユーザーが直接呼び出す事は想定していない。
The English summary is being prepared. Showing the original description.
リポジトリの1つの領域をセキュリティ観点で調査し、Codexの批判的レビューを経てレポートを出力する。 codepatrol skillが起動したsubagentが実行する。ユーザーが直接呼び出す事は想定していない。
The English summary is being prepared. Showing the original description.
セキュリティ調査に使う調査対象リストと観点リストを、リポジトリのコードを読んで生成・更新する。 codepatrol skillが起動したsubagentが実行する。ユーザーが直接呼び出す事は想定していない。
The English summary is being prepared. Showing the original description.