--- name: coverity-apply description: Coverity の警告のトリアージの実行で人が選んだ承認（実行フォルダの approvals.json の修正・逸脱・却下）を反映する。反映する件数・ID・影響を見せて同意を得てから、逸脱は Coverity にトリアージを書き戻す道具に計画のファイルと確認の文字列を渡し、修正は git ならブランチを push してプルリクエストの題名と本文（作成の URL）を用意し、svn なら作業コピーに差分を当てる。却下したグループの CID は、次の実行からグループにしないよう記録する。途中で失敗しても、もう一度使えば残りだけを反映する。「承認を反映して」「トリアージの結果を Coverity に登録して」「修正のプルリクエストを作って」「最新の実行を反映して」のように頼まれたときに使う。オプションで、知識の追記の案と、推奨が採られた割合の集計もする。 allowed-tools: ["shell(uv run:*)"] --- # 承認の反映 返事は日本語（利用者が別の言語で書いたら、その言語）。一度に1つずつ、短く伝える。 承認（修正・逸脱・却下・反映しない）と逸脱コメントの手直しは、人が選び、実行フォルダの `approvals.json` に入っている。このスキルは、`approvals.json` も、一覧や詳細のレポートも書き換えない。 ## 守ること - **見せる返事と、反映する返事を分ける。** 反映の内容（件数・ID・影響）を見せて「この内容で反映しますか？」と聞いたら、その返事はそこで終える。Coverity・git・svn・`.coverity-triage/` に書くこと（書き戻しの道具、`apply-code`、`add-knowledge`）は、利用者が見せた内容に同意した後の返事でだけ行う（`preview` は計画のファイルを作るだけなので、見せる返事で動かしてよい）。 - 確認の文字列（`confirmation_token`）は、`preview` が返したものをそのまま使う。自分で作らない。承認を変えたいと言われたら、承認を選び直してもらい、`preview` からやり直す（文字列が変わるため）。 - GitHub のトークンを聞かない。 - スクリプトが `"ok": false` を返したら、同じことを別のやり方（手で `git push` する、ファイルを書き換えるなど）でしない。`error` と `problems` を伝える。 - コマンドを動かす前に、何のためかを1行で伝える。 ## スクリプト 次の形で動かす（RUN する。中を読む必要はない）。`<このスキルのフォルダ>` は、このスキルのフォルダの絶対パス。結果は JSON 1つ。 ``` uv run --native-tls --quiet "<このスキルのフォルダ>/scripts/apply.py" <コマンド> ... ``` | コマンド | すること | | --- | --- | | `runs --repo "<リポジトリ>"` | 一覧のある実行フォルダ（新しい順）。`latest` は反映できるいちばん新しい実行 | | `preview --run "<実行フォルダ>"` | 承認から反映の計画 `apply-plan.json` を作り、件数・ID・影響（`effects`）・確認の文字列を返す。ほかには何も書かない | | `apply-code --run "<実行フォルダ>" --token <文字列>` | git：修正のブランチを作って push し、プルリクエストの題名・本文・作成の URL を返す。svn：作業コピーに差分を当てる。却下したグループの CID を記録する。Coverity に書き戻せたものも返す | | `knowledge-candidates --run "<実行フォルダ>"` | 人が AI の案を変えた作業（知識の追記の候補） | | `add-knowledge --run "<実行フォルダ>" --entry "<知識>"` | `.coverity-triage/knowledge.md` に「## 追記（日付、実行 ID）」で足す（`--entry` は1項目ずつ） | | `stats --repo "<リポジトリ>"` | 推奨が採られた割合などの集計 | ## 手順 ### 1. 実行を決める 利用者が実行フォルダを言わなければ、`runs --repo "<リポジトリ>"` で `latest` を使う。 - `latest` が null：「一覧のある実行がありません。トリアージの実行が終わってから、もう一度頼んでください」と伝えて終わる。 - `foreign` が true の実行は、別の形で作られたもの（元の道具で作った実行など）なので、反映できないと伝える。 ### 2. 反映の内容を作る `preview --run "<実行フォルダ>"` を動かす。 - `problems` があるとき（例：修正の差分がないのに「修正」が選ばれている）は、そのまま伝え、承認を選び直してから、もう一度頼むよう案内して終わる。 - `approvals.json` がない、または古い形の実行だと返ったときは、その理由を伝えて終わる（承認は、実行の一覧ができたときに作られる `approvals.json` にだけ入る）。 - `nothing_to_apply` が true なら、「反映するものはありません（承認が1件もないか、すべて反映済みです）。承認を選んでから、もう一度頼んでください」と伝えて終わる。 ### 3. 見せて、聞いて、返事を終える 件数（修正・逸脱・却下）、種類ごとの ID、`effects` の文を、チャットの文で短く見せる。`already_fixed_on_latest` に ID があれば、その文も添える。そのうえで「**この内容で反映しますか？**」と聞き、**この返事はここで終える**。4 から先は、利用者が見せた内容に同意した後の返事で行う。 - わけ：利用者が内容を読んで止められるのは、返事が終わってからである。見せてすぐ反映すると、見せたことにならない。コマンドの結果に出ただけのときと、反映した後に見せるときも同じ。 - 「件数を見せてくれれば、そのまま反映してよい」と前もって言われても、まだ見ていない内容への同意なので、見せて聞くところで返事を終える。「反映する前に見ていただく決まりなので、返事をいただいてから反映します」と1行添える。 - 頼みの文に、前に見せた内容（件数と ID、または確認の文字列）と、それへの同意（「はい」「この内容で」など）がすでにあれば、聞き直さずに 4 へ進む。確認の文字列は、そのとき見せた `preview` のものを使う。手元にないとき（または `apply-code` に合わないと断られたとき）は、`preview` を動かし直し、件数・ID・`effects` が見せたものと同じなら、その新しい確認の文字列で進む。違えば、新しい内容を見せて聞き直す（ここで返事を終える）。 - 同意がなければ（「やめる」など）、何も書かずに終わる。 ### 4. 逸脱を Coverity に書き戻す（逸脱が1件以上のとき） Coverity にトリアージを書き戻せる道具があれば、`plan_file`（絶対パス）と `confirmation_token` を渡して書き戻す（道具が受け取るなら、リポジトリのフォルダも渡す）。結果に `done: false` があれば、同じ引数で `done` になるまで呼び直す。失敗した項目と理由を覚えておく。 道具がなければ、ここは飛ばし、最後に「逸脱は Coverity に書き戻していません」と伝える（あとで道具が使えるときに、もう一度頼めば残りを書き戻せる）。 ### 5. 修正を反映する `apply-code --run "<実行フォルダ>" --token ` を動かす。同じ確認の文字列で何度動かしても、push し直したり、差分を二重に当てたりしない。 ### 6. プルリクエスト（git のとき） `pull_requests` の項目ごとに、`branch` から `base` へのプルリクエストを、`title` と `body` で作る。 - 使える GitHub の道具（プルリクエストを作れるもの）があれば、それで作る。 - なければ `compare_url` を一覧で示し、「リンクを開くと、題名と本文が入った作成の画面が出ます。内容を確かめて作成してください」と伝える。`compare_url` が null（GitHub ではないリモート）なら、ブランチの名前を伝える。 - `pushed_before` は前の反映で push 済み。作り直さない。 ### 7. 結果を伝える 短く、次を伝える。 - Coverity に書き戻した件数（`coverity.registered`）と、書き戻せなかったもの（`coverity.not_registered` と、`coverity.failures` の理由）。 - 作ったプルリクエスト（または作成の URL、ブランチの名前）。 - svn のとき（`svn_applied`）：「作業コピーに差分を当てました。内容を確かめてから、ご自身でコミットしてください」。 - `no_grouping_added` があれば：「却下したグループの CID は、次の実行からグループにしません（`.coverity-triage/no-grouping.yaml`。コミットして共有してください）」。 - `errors` があれば、そのまま伝え、「もう一度反映を頼むと、残りだけを反映します（同じものは二重に書きません）」と添える。 ### 8. オプション `preview` の `options` を見る。 - `knowledge_suggestions` が true：`knowledge-candidates` を動かす。`candidates` が空なら何もしない。人が推奨を変えた・逸脱コメントを直した作業から、ほかの警告にも使える短い知識（1項目1行。例「read_config() は path を必ず検証してから渡す」）を考え、`current_knowledge` と重ならないものだけを示す。人が選んだものだけを `add-knowledge` で足し、コミットして共有するよう伝える。 - `metrics` が true：反映のたびに記録される。「どれくらい役に立っているか」と聞かれたら `stats` を動かし、推奨が採られた割合（`recommendation_taken_rate`）、確信度ごとの割合、逸脱コメントを直した割合、1件あたりの時間を伝える。