--- name: coverity-run description: Coverity のトリアージを実行する。オプションで最初に解析してサーバに登録し、条件に合う警告を取り出し、取得・作業・統合・検証のサブエージェントに順に任せて修正案と逸脱コメント案を作り、一覧 summary.html を作る。次に何をするかは ct.py tick が決める。実行中は画面（ct.py gui）で AI の動きを見せ、最後に画面の「結果」で承認を確かめるよう案内する。途中で止まった実行は続きから再開する。人が /coverity-run で頼む。引数は省略可で、条件ファイルの名前や追加の条件を書く（例 misra.yaml / High だけ / 10 件だけ / 最初に解析して）。 allowed-tools: ["coverity-triage", "shell(uv run:*)"] --- # Coverity トリアージの実行 あなたはオーケストレーション役です。全体を順に進めますが、**次に何をするかは自分で決めません。** `ct.py tick` が返す `actions` のとおりに動きます。**ソースを読んで判断したり、直したりもしません。** それぞれの仕事は、次のカスタムエージェントをサブエージェントとして起動して任せます。 | エージェント | 仕事 | 同時に | |---|---|---| | `coverity-triage-collector`（取得） | Coverity から警告を検索し、警告経路を取る | 1 つまで | | `coverity-triage-worker`（作業） | 警告 1 件（または 1 グループ）を調べ、修正案と逸脱コメント案を作る | 設定 `parallel` の数まで | | `coverity-triage-integrator`（統合。オプション） | 同じ原因の作業をまとめる計画を書く | 1 つまで | | `coverity-triage-reviewer`（検証。オプション） | 結果を独立に確かめる | 1 つまで | - 必ず `actions` に書かれた名前のカスタムエージェントを起動します。汎用のサブエージェントで代わりにしたり、自分で調べたりしません（使えるツールとモデルが、それぞれの定義で決まっているため）。 - 人への質問は、始める前の確認だけにします。始めたら、終わるまで質問しません（人が見ていない間も進められるように）。 最初にスキル `coverity-triage-scripts` を読み、`ct.py` の場所と使い方、MCP のツールとの関係を確かめます。以下の `ct.py X` はそこに書かれた方法で実行します。 ## 1. 始める 1. 対象リポジトリの一番上のフォルダ（`repo_root`）を決める（ふつうは開いているフォルダ）。 2. `ct.py runs --repo ` で前回の実行を見る。 - 設定ファイルが無いなどで失敗したら、「先に `/coverity-setup` で準備してください」と伝えて終わる。 - いちばん新しい実行が途中（`unfinished: true`）なら、「前回の実行（日時・条件）が途中です。続きから再開しますか？」と聞く。再開するなら `ct.py resume --run ` を実行し、結果の `run_dir`、`repo_root`、`work_dir` をこの後ずっと使う。下の「監視の画面を開く」と「修正用のコピーの案内」を行い、2 へ進む。 - 利用者が初回解析を指定していて（「最初に解析して」「解析はしないで」）、途中の実行と違うときは、再開では変えられないことを伝え、新しく始めるよう勧める（途中の実行の初回解析のする・しないは、始めたときのまま）。 3. 新しく始めるとき： 1. 利用者の言葉から条件を決める。条件ファイルの名前があれば `--filter`、「High だけ」などは `--impact High` のように引数で足す。件数の指定は `--limit`。ビルドでの検証の指定があれば `--verify build` など。「最初に解析して」「解析してから」と言われたら `--initial`、「解析はしないで」なら `--no-initial`（どちらも無ければ設定 `verify.initial` のとおり）。 2. `ct.py new-run --repo ...` を実行する。結果の `run_dir`、`repo_root`、`work_dir` をこの後ずっと使う。`initial` が true なら「最初に、開いているフォルダをビルド・解析して、Coverity サーバに登録します（数十分かかることがあります）」と伝える。 3. 下の「監視の画面を開く」と「修正用のコピーの案内」を行い、2 へ進む。 ### 監視の画面を開く 1. 「AI の動きを見る画面を開きます」と伝えて `ct.py gui --repo --run ` を実行する。画面は裏で動くので、コマンドはすぐ戻る（`reused` が true なら、もう動いている画面を使い回して、この実行を表示している）。 2. 次を伝える。 > ブラウザの画面の「監視」で、AI（全体を進める AI と、警告を取る・調べる・まとめる・確かめるサブエージェント）の動きと、重大なエラーを見られます。画面を閉じても実行は止まりません。 - `browser_opened` が false なら、結果の `url` を添えて「このアドレスをブラウザで開くと見られます」と伝える。 3. `ok` が false でも、実行は止めずにそのまま進める（画面は見守るためのもので、実行には要らない）。`error` を 1 行で伝える。最後の「3. 終える」で、結果の画面を開くときに、もう一度だけ試す。 ### 修正用のコピーの案内 修正用のコピーを置くフォルダ（`work_dir`）は、開いているフォルダの外にあります。利用者に次を伝えます（決定 21。再開のときも伝える）。 > 修正案は、あなたの作業中のファイルではなく、`` に用意するコピーの上で作ります。このフォルダの読み書きの確認が出たら、「このセッションでは許可」を選んでください（Copilot CLI では、いま `/add-dir ` と入力しても許可できます）。 ## 2. `ct.py tick` に従って進める `ct.py tick --run ""` を実行し、結果のとおりに動くことを、`done` が true になるまで繰り返します（パスに空白があってもよいように、`"..."` で囲みます）。 結果の読み方： - `say`：利用者に伝えること。あれば、そのまま短く伝える。 - `stop` が true：止める。`say` と `error` を伝え、`initial` に `log_tail`（ログの最後）があれば、その要点も伝える。それ以外は何もしない（初回解析が失敗したときなど）。 - `actions`：いまからすること。順に全部行う。 - `type: launch`：`agent` の名前のカスタムエージェントを、`prompt` をそのまま渡して、**裏で動かす指定（background）で**起動する（1 つ終わるごとに次へ進めるように）。`task` を覚えておく。 - `type: command`：`command` を `ct.py` で実行する（ビルドでの検証など。時間がかかるので、裏で動かす指定で動かし、終わるのを待つ）。`note` があれば先に伝える。終わったら、結果（`build_ok`、`downgraded_to_low`）を短く伝えて `ct.py tick --finished `。`ok: false` で終わった・止まったときは `ct.py tick --failed --reason ""`。 - `type: mcp`：`tool` の MCP のツールを `args` で呼ぶ。`until_done` が true なら `done` が true になるまで同じ引数で呼び直す。全部終わったら `ct.py tick`（取得エージェントが使えないときに、あなたが代わりに取る）。ツールがエラーを返したら、呼び直さずに `ct.py tick --failed collector:search --reason "<エラーの文>"`（`get_issues` のときは `collector:paths`）で知らせる。 - `wait` が true：裏で動いているエージェントが終わるのを待つ。終わったら、`running_tasks` にあるその `task` で知らせる（actions の `task` を覚えていなくても、ここで分かる）。初回解析の間（`stage` が `initial`）は、そのまま `ct.py tick` を呼び直す（tick が少し待ってから返る）。 - `done` が true：3 へ進む。 裏で動かしたエージェントが終わったら： - 終わった（返事が返った）とき：`ct.py tick --run --finished ` - 途中で止まった、エラーになった、起動できなかったとき、または返事が「続けられない理由」の 1 行だけだったとき：`ct.py tick --run --failed --reason "<理由>"` - `task` は actions に書かれたとおりに渡す（`worker:20001#2` のように回数が付いていれば、付けたまま）。 - 複数が終わっていたら、1 つずつ順に知らせる（そのたびに返る `actions` を行う）。 - 結果を直す指示（「次の点を直してください」）も tick が `actions` に入れて返す。自分で直す点を考えない。 そのほか： - 5 件ごとくらいに、進み具合（`counts`）を 1 行で伝える。 - `ct.py tick` が `ok: false` で終わったとき（修正用のコピーを用意できないなど）は、`error` を利用者に伝えて止める。裏で動いているエージェントは終わるのを待ち、`--finished` まで知らせてから止める。 - 起動しようとしたエージェントが見つからないときは、`--failed` で知らせたうえで、利用者に「`/coverity-setup` を実行して、Copilot CLI を再起動してください」と伝える（取得エージェントのときは、tick がメインの AI に代わりに取らせる `mcp` の actions を返すので、そのまま続ける）。 待ち方： - `ct.py tick` は、そのスロットで初めて修正用のコピーを作るとき、大きなリポジトリでは数分から数十分かかります（画面の「監視」には「修正用のコピーを用意中」と出ます）。止めたり、やり直したりせず、終わるまで待ちます（ほかに起動するエージェントがあるときは、tick はコピーを作る前に返すので、起動してからまた tick を呼びます）。 - `ct.py tick` が裏に回ったときは、終わるのを待ち、返った `actions` のエージェントを、ほかのことより先に起動します（空いた枠を待たせない）。返った作業を、エージェントを起動しないまま残してはいけません。tick は同時に 1 つだけ動かします（前の tick が終わってから次を呼ぶ）。 ## 3. 終える 1. `ct.py summary --run ` を実行する。承認の欄には、AI の推奨が最初から入る（`approvals.json`）。 2. `ct.py gui --repo --run --view summary` を実行し、画面の「結果」に、この実行の一覧を出す。`browser_opened` が false なら `url` を伝える。`ok` が false なら、`error` を伝え、一覧のファイル（`summary`）はブラウザで直接開いて読めること、承認を変えるには画面が要るので `/coverity-help` で相談できることを伝える。 3. 次を短く伝える。 - 一覧のファイル（`summary`。`summary.html`）の場所、作業の数、修正と逸脱の推奨の数、処理できなかった作業の数 - 途中の `say` で伝えた注意のうち、大事なもの（初回解析、統合、検証、ビルドでの検証の結果） - 次にすること：「画面の『結果』で承認の欄を確かめてください。AI の推奨を入れてあるので、変えたい行だけ『修正』『逸脱』『却下』『反映しない』から選び直します（選ぶとすぐ保存されます）。行を選ぶと詳細レポートが開き、逸脱コメントを直したり、差分と修正後のファイルを見たりできます。終わったら `/coverity-apply` で反映します」 ## してはいけないこと - ソースを読んで判断する、直す（作業エージェントの仕事）。同じ原因かを判断する（統合エージェントの仕事）。結果を確かめる（検証エージェントの仕事）。 - 次にすることを自分で決める（`ct.py tick` が決める）。`ct.py next`・`ct.py brief`・`ct.py finish` を自分で呼ぶ（tick が呼ぶ）。 - `run_dir` の中のファイル（`run.json`、`result.json`、`review.json`、`approvals.json` など）を手で書き換える。承認は人が画面で選びます。 - `ct.py preview`・`ct.py apply-code`・MCP の `update_triage` を使う（反映は、人が画面で承認を確かめた後に `/coverity-apply` で行う）。 - 監視の画面が開くのを待つ、画面のことで人に質問する（実行は画面がなくても進める）。