--- name: coverity-run description: Coverity Connect の警告のうち条件に合うものを一括でトリアージする手順と、その実行フォルダを扱うスクリプト。警告ごとに作業役のエージェントへ真偽の調査と修正案・逸脱コメント案を頼み、設定により検証役・統合役のエージェントへ確かめとまとめを頼んで、一覧 summary.html と承認の案 approvals.json を作る。次にすることはスクリプトの tick が決め、この手順はそれに従うだけにする。人がこのスキルをコマンドとして呼んだとき（条件の言い方「High だけ」「misra.yaml で 10 件だけ」「最初に解析して」「解析はしないで」「ビルドして確かめて」「前回の続きから」を添えて）、エージェントが実行フォルダとこのスクリプトの場所を渡されて一括の実行を進めるよう頼まれたとき、また、すでにある一括の実行について「進み具合は？」「一覧を作り直して」と頼まれたときに使う。コマンドとして呼ばれていない「警告をトリアージして」だけの頼みでは、新しい一括の実行を自分からは始めない。警告 1 件だけを調べる頼みや、承認したものの反映には使わない。 allowed-tools: ["shell(uv run:*)"] --- # Coverity の警告の一括のトリアージ この手順を進めるあなたは、**次に何をするかを自分で決めません。** スクリプトの `tick` が返す `actions` のとおりに、 Coverity との通信の道具を呼び、役のエージェントに頼みます。ソースを読んで判断したり、ファイルを直したりもしません （調べる・直す・確かめる・まとめるのは、それぞれの役のエージェントの仕事です）。 人への返事は日本語で、一度に 1 つずつ、短く平易に書きます。利用者が日本語以外で書いたら、その言葉で答えます。 ## コマンドの動かし方 スクリプトは、このスキルのフォルダの `scripts/run.py` です。次の形で動かします（PowerShell でも bash でも同じ）。 ``` uv run --native-tls --quiet "<このスキルのフォルダ>/scripts/run.py" <コマンド> <引数> ``` - 頼みの文にコマンドの場所が書かれていれば、それを使います（同じ版のスクリプトで続けるため）。 - パスは `"..."` で囲みます。どのコマンドも JSON を 1 つ返します。 - コマンドを動かす前に、何のためかを 1 行で伝えます（例「前回の実行が残っていないか確かめます」）。 - `ok: false` が返ったら、`error` と `problems`（と `how_to_fix`）を利用者に伝えます。同じことを別のやり方 （ファイルを手で書き換えるなど）でしません。コマンドの一覧と出力の形は [references/actions.md](references/actions.md) にあります。 ## 1. 始める 頼みの文に**実行フォルダとコマンドの場所が書かれている**ときは、それを使い、下の 1〜6 を飛ばして 「2. tick に従って進める」から始めます（新しく作らず、再開の確認も、始める前の質問もしません）。 1. 調べるリポジトリの一番上のフォルダ（`repo_root`）を決めます（ふつうは開いているフォルダ）。 2. `runs --repo ""` で、前の実行を見ます。 - 設定がなくて失敗したら、「.coverity-triage/config.yaml を用意してください（準備の手順があれば、それで作れます）」 と伝えて、始めません。設定と認証情報を対話で用意するスキルが使えるなら（スラッシュコマンドの一覧にあれば。Claude Code では、 使えるスキルの一覧にあれば。名前に `<プラグイン>:` が付いていれば、付けたまま）、 「準備の手順」の代わりに、その呼び方（`/<その名前>`）を書きます。 - いちばん新しい実行が途中（`unfinished: true` で `foreign: false`）なら、次の文のとおりに聞きます （頼みの文が前回の続きからを求めているとき（「前回の続きから」など）は、聞かずに再開します）。 > 前回の実行（日時・条件）が途中です。続きから再開しますか？ 日時は `created_at`、条件は `filter_name` で埋めます。再開するなら `resume --run ""`（4 と同じく `--client` と `--mcp-tool` を付けられます。 Claude Code で動いているときは、4 のとおり `--client claude-code` を必ず付け、読むツールを見えている名前のまま渡します）を動かし、 5 へ進みます。再開では初回解析のする・しないを変えられません（利用者が違う指定をしていたら、 そのことを伝え、新しく始めるよう勧めます）。`same_tool: false` の実行は再開できないので、新しく始めます。 3. 新しく始めるときは、頼みの文の言い方を `new-run` の引数にします（[references/phrases.md](references/phrases.md)）。 例：「High だけ」→ `--impact High`、「10 件だけ」→ `--limit 10`、「最初に解析して」→ `--initial`。 どれにも当たらない言い方は使わず、そのことを短く伝えます。 4. Coverity との通信の道具（警告を探すツールなど）がないときは、新しく始めません。取ってある警告の一覧（issues.json の形）があるかを利用者に聞き、あれば `new-run --issues-file "<ファイル>"` で、それを使って始めます（同じフォルダの `issue-.json` も使います）。なければ、そのことを伝えて止めます。 `new-run --repo "" <引数>` を動かします。Coverity との通信のツールが見えていれば、そのうち読むツール（接続の確かめ・警告の検索・警告の詳細・反映の確かめ）を、1つずつ `--mcp-tool '<登録名>(<ツールの名前>)'` で渡します（ツールの名前が `coverity-x/<ツール>` なら `coverity-x(<ツール>)`。許可の案内に入ります）。書き戻すツールは渡しません。結果の `run_dir` を、この後ずっと使います。 Claude Code で動いているときは、`--client claude-code` を付け（`--issues-file` で始めるときも）、読むツールを、上の形の代わりに、見えている名前のまま（`mcp__<サーバー>__<ツール>` か `mcp__plugin_<プラグイン>_<サーバー>__<ツール>`）1つずつ `--mcp-tool "<その名前>"` で渡します（許可の案内が Claude Code の形になります。`--client` を付けないと Copilot CLI の形になります）。ここでも、書き戻すツールは渡しません。MCP のツールの名前が `mcp__` で始まり、Agent のツールがあるのが、Claude Code で動いている目印です。 `initial` が true なら「最初に、開いているフォルダをビルド・解析して、Coverity サーバに登録します（数十分かかることがあります）」 と伝えます。`note` があれば伝えます。 5. 実行の様子と結果を見る画面を開ける道具があれば、`repo_root` と `run_dir` を渡して開きます（開けなくても、実行は止めずに進めます）。 6. 許可の案内を 1 回だけ示します。始めたら、終わるまで利用者に質問しません。夜通し止まらずに進むよう、`new-run` （または `resume`）が返した `permission_steps` の 2 つの方法を、そのまま示します（実行フォルダの読み書き・ `uv` のコマンド・Coverity との通信のツールを、このセッションのあいだだけ許可する方法）。Claude Code の `/permissions` で足す許可は設定ファイルに残ります（案内に、終わったら消すことが入っています）。 Claude Code で動いているときは、案内を示したら、そのターンを終えて待ちます（裏で動くエージェントは許可の確認を出せないので、 先に済ませてもらいます）。次の文を添えます。 > 許可を済ませたら「始めて」と返してください。Claude Code を起動し直したときは、新しいセッションで、同じ呼び方で「前回の続きから。許可は起動のときに済ませました」と頼んでください。 Claude Code で待ったときは、「始めて」と返ったら、「2. tick に従って進める」へ進みます。Claude Code でも、頼みの文が途中で質問しないよう 求めているとき（「途中で質問せず」など）と、許可を起動のときに済ませたと書いてあるときは、待たずに進めます。待つのは始める前だけで、 始めた後は質問しません。 ## 2. tick に従って進める `tick --run ""` を動かし、返った JSON のとおりに動くことを、`done` か `stop` が true になるまで繰り返します。 | 項目 | すること | |---|---| | `say` | あれば、そのまま短く伝える | | `actions` | 上から順にすべて行う（下の表） | | `wait: true` | 終わったエージェントがあれば、その `task` を知らせる。なければ、そのまま `tick` を呼び直す（待つのは tick がする。スクリプトの処理や結果のファイルを、既定で最長 20 秒待ってから返る。`sleep` などのほかのコマンドで待たない） | | `stop: true` | `say` と `error` を伝えて止める。ほかには何もしない | | `done: true` | 「3. 終える」へ | `actions` の種類： | type | すること | |---|---| | `fetch_issues` | Coverity から条件に合う警告を検索してファイルに書ける道具を、`repo_root`・`filter_file`・`output_file` をそのまま渡して呼ぶ。結果が `done: false` の間は、同じ引数で呼び直す。終わったら `tick --run "" --finished ` | | `fetch_details` | Coverity から警告経路を取ってファイルに書ける道具を、`repo_root`・`stream`・`cids`・`output_dir` をそのまま渡して呼ぶ（`done: false` なら呼び直す）。終わったら `--finished ` | | `launch` | `role` に合うエージェントに、`prompt` を**そのまま**渡して、裏で動かす（`description` はその仕事の説明として使う）。終わったら `--finished `、途中で止まった・起動できなかった・「続けられない」の 1 行だけが返ったときは `--failed --reason '<理由>'` | | `command` | `command` をそのまま動かす（20 秒以内に終わる）。終わったら `--finished ` | `role` に合うエージェントの選び方： - 頼みの文に役ごとのエージェントの id が書かれていれば、それを使います。 - なければ、説明（description）に役の言葉があるエージェントを使います：`worker` は「作業役」、`reviewer` は「検証役」、 `integrator` は「統合役」。 - 合うエージェントがないときは、汎用のエージェントに代わりをさせず、`--failed --reason "その役のエージェントがない"` で知らせ、利用者に「説明に「作業役」（など）とあるエージェントを入れてください」と伝えます。 知らせ方の決まり： - `task` は actions に書かれたとおりに渡します（`worker:20001@1#2` のような印も付けたまま）。 - いくつも終わっていたら、1 つずつ知らせ、そのたびに返る `actions` を先に行います。 - 道具がエラーを返したら、呼び直さずに `--failed --reason '<エラーの文>'` で知らせます。 - 理由や本文は、`'…'`（一重の引用符）で囲んで1つの引数にします（`"…"` の中の `$` や `` ` `` は、シェルが展開します）。文の中の `'` は言い換えます。コマンドは1回に1つで、`;`・`&&`・`|` でつなぎません（下の標準入力の形だけは別）。 - 結果を直す頼み（作り直し・形の直し）も、tick が `launch` で返します。直す点を自分で考えません。 - 5 件ほど終わるごとに、進み具合（`counts`。`done` / `total`）を 1 行で伝えます（内部の値はふつうの言葉にします。下の「実行の様子を聞かれたとき」の表）。 始めた後で道具がないと分かったときは、`stop --run ""` で実行を止めてから、利用者に伝えます（途中の実行を残さないため）。 ## 3. 終える 1. `summary --run ""` を動かします。一覧 `summary.html` と、推奨を入れた承認の案 `approvals.json` ができます。 2. 実行の様子と結果を見る画面を開ける道具があれば、結果の画面を開きます。 3. 次を短く伝えます。 - 一覧のファイル（`summary_html`）の場所、作業の数、修正と逸脱の推奨の数、確信度 低 の数、処理できなかった作業の数 - `say` のうち大事なもの（初回解析・取得・確かめ・ビルドでの検証のことと、合わなかった評価基準 `run_checks`） - 次にすること：「結果を見る画面で承認を確かめてください。推奨を入れてあるので、変えたい作業だけ『修正』『逸脱』 『却下』『反映しない』から選び直します。逸脱コメントはその画面で直せます。終わったら、反映の手順で反映します。」 結果を見る画面のスキルや、承認を反映するスキルが使えるなら、「結果を見る画面」「反映の手順」に、その呼び方（`/<その名前>`）を添えます。 Claude Code で動いているときは、「反映は、--agent を付けずに起動した Claude Code のセッションでします」も添えます （--agent で起動したセッションでは、反映できないことがあります）。 4. 最後まで動いた実行（`stop` で止めたのでない）なら、「4. 振り返る」を行います。 ## 4. 振り返る `status --run ""` の `errors` と `recent`、実行フォルダの `operations.log` を読み、この実行で困ったこと （失敗した作業、詰まったエージェント、データの流れの乱れ、手順やスクリプトの分かりにくさ）を洗い出します。 改善につながる課題ごとに、題と本文を書き残します。 ``` uv run --native-tls --quiet "<このスキルのフォルダ>/scripts/run.py" note-issue --run "" --title '<題>' --body '<本文>' ``` 本文が長いときや改行を含むときは、`echo '{"title": "…", "body": "…"}' | uv run … note-issue --run "" --stdin` のように JSON を標準入力で渡します（PowerShell でも bash でも同じ書き方。改行は `\n`、文の中に `'` を使わない）。書き残した課題は、チャットでも短く伝えます。 課題の起票は、利用者が一件ずつ承認してから行うもので、ここではしません。 ## 実行の様子を聞かれたとき 実行を進めずに様子だけを聞かれたとき（「進み具合は？」「どの作業が止まっている？」）は、`status --run ""` を 動かします（読むだけで、何も変えません。実行フォルダが分からなければ `runs` で探します）。次を短く伝えます。 - 段（`stage_label`）と、処理した件数 / 全体（`progress.label`）、`counts` - 作業中の作業（`items` の `status: in_progress`）と、その段（`phase`・`note`）。`stalled: true` なら「10 分以上動きがない（止まっているかもしれない）」と、最後に動いた時刻か経った時間を添える - 処理できなかった作業（`status: error`）と、その理由（`error`）。重大なエラー（`errors` の `level: critical`） - 終わった作業の推奨と、人に見せる確信度（`recommendation`・`confidence`） 伝えるときは、内部の値（`judge`、`in_progress`、`fix`、`high` などの英語の値や項目の名前）をそのまま書かず、ふつうの言葉にします。秒は分か時間にします。 | 値 | 伝える言葉 | |---|---| | 段 `read` / `judge` / `fix` / `deviation` / `result` | 警告経路とコードを読んでいる / 本物かどうかを決めている / 修正を作っている / 逸脱コメントを書いている / 結果を書いている | | 段 `copy` / `save` / `merge` | 作業用のコピーを用意している / 修正を保存している / まとめた修正を作っている | | 段 `check` / `write`（確かめ）、`compare`（統合） | 結果を確かめている / 確かめた結果を書いている、結果を比べている | | 状態 `pending` / `in_progress` / `done` / `error` | まだ / 作業中 / 終わった / 処理できなかった | | 推奨 `fix` / `deviation`、確信度 `high` / `medium` / `low` | 修正 / 逸脱、高 / 中 / 低 | 一覧を作り直してと頼まれたときは、`summary --run ""` を動かします（人が選んだ承認は変わりません）。 ## してはいけないこと - ソースを読んで真偽を判断する、ファイルを直す、同じ原因かを決める、結果を確かめる（役のエージェントの仕事）。 - 次にすることを自分で決める、actions にないエージェントを動かす、`prompt` を書き換える。 - 実行フォルダのファイル（`run.json`、`result.json`、`review.json`、`approvals.json` など）を手で書き換える。 - Coverity のトリアージを書き戻す、修正を取り込む（人が承認した後に、反映の手順で行う）。 - 始めた後に、利用者に質問する（許可の確認には利用者が答えます）。 うまくいかないときの直し方は [references/troubleshooting.md](references/troubleshooting.md) にあります。