---
name: coverity-selftest
description: Coverity Connect の警告のトリアージの道具一式が、この PC（Copilot CLI か Claude Code、社内の Coverity、社内のビルド）で動くかを確かめ、結果を伏せ字の report.md にまとめる。範囲は ① 道具とエージェント ② 見本のリポジトリと偽の Coverity での一連の流れ（一括のトリアージと反映） ③ 社内の Coverity（読むだけ） ④ ビルドでの検証 の4つ。「自己診断して」「動作確認をして」「この PC で使えるか確かめて」「②だけ確かめて」「社内の Coverity につながるか確かめて」のように頼まれたときに使う。社内の Coverity には書き込まない。1件の警告の調査や、ふだんのトリアージの実行には使わない。
allowed-tools: ["shell(uv run:*)"]
---

# 自己診断

確かめたことを項目ごとに記録し、最後に `report.md` を作ります。
決まった判定はスクリプトがします。あなたは手順を進めることと、スクリプトでは確かめられないこと（ツールとエージェントの一覧、Coverity との通信のツールの返事、利用者への質問）を受け持ちます。
利用者が日本語以外で書いたら、その言葉で答えます。

## 守ること

- **社内の Coverity に書き込まない。** ③ では、接続の確かめ・警告の検索・警告経路の取得だけをする。書き戻し（確かめも含む）・一括実行・初回解析は、② の見本だけでする。
  社内の Coverity での書き戻しを頼まれたら断り、代わりに、② の見本（偽の Coverity）で書き戻しを確かめることを申し出る。
- 社内のリポジトリのファイルを変えない。社内のソースコードを記録しない（記録は件数・結果・エラーの要点だけ）。
- 結果のフォルダ（`dir`）を、調べるリポジトリの中に作らない。`start` に `--dir` を付けないと、リポジトリの外にできる。
- 認証キーをチャットで聞かない。
- エラーが出ても止まらず、その項目を `fail` で記録して次へ進む。
- 利用者への質問は一度に1つ。答えはそのまま記録する。
- スクリプトが `ok: false` を返したら、`error` を関係する項目に `fail` で記録して先へ進む。同じことを手で代わりにしない。
- 表の部品のツールがツールの一覧に見当たらないときは、ないと決める前に、ツールを探すツール（使えるツールの名前を探すもの）があれば、それで探す。

## スクリプト

次の形で動かします（スクリプトの中身は読まなくてよい）。

```text
uv run --native-tls --quiet "<このスキルのフォルダ>/scripts/selftest.py" <コマンド> --dir "<dir>" ...
```

コマンドごとの引数と、確かめる項目（1-1〜4-3）の一覧は [references/checks.md](references/checks.md) にあります。
自分で見たことは `record` で記録します（結果の文は自動で伏せ字になります）。

```text
uv run --native-tls --quiet "<このスキルのフォルダ>/scripts/selftest.py" record --dir "<dir>" --id 1-3 --status pass --actual "<見たこと>"
```

`status` は `pass`（成功）・`fail`（失敗）・`review`（要確認）・`skip`（未実施）。長い文や引用符を含む文は、標準入力で JSON を渡します（PowerShell でも bash でも同じ書き方）。

```text
echo '{"id": "1-3", "status": "pass", "actual": "<見たこと>"}' | uv run --native-tls --quiet "<このスキルのフォルダ>/scripts/selftest.py" record --dir "<dir>" --stdin
```

## 始める

1. 範囲を決める（言われなければ ①〜④ すべて）。③④ は、調べたいリポジトリ（準備済み）を開いているときだけ。準備がまだなら ③④ を外し、表の準備のスキルを案内する。
   - Claude Code で、表の統括エージェントを `--agent` で会話の主役にして起動したセッションなら、② を外し、② は `--agent` を付けずに起動したセッションでするよう伝える（そのセッションには、書き戻しと反映の確かめのツールがない）。
2. `start --sections <1,2,3,4 のうち> --client "<Copilot CLI か Claude Code>" [--repo "<リポジトリ>"]` を動かす（`--client` は、このセッションを動かしているもの）（`--dir` は付けない。③④ を含むときは `--repo` が要る）。返った `dir` を、この後ずっと使う。
3. 「結果は `<dir>` にまとめます」と伝え、① → ② → ③ → ④ の順に進める。

## ① 道具とエージェント

1. `check-tools`（1-7）。
2. `sample`（2-1）で見本のリポジトリを作る。返った `repo_root` が「見本のリポジトリ」。
3. 1-1：表の Coverity との通信の部品の、接続を確かめるツールを、`repo_root` に見本のリポジトリで呼ぶ。`ok` なら pass。ツールがない・失敗なら fail（返事の要点を記録）。
4. 1-3〜1-6：使えるエージェントの一覧（エージェントを始めるツールの説明にある、エージェントの名前と説明。Copilot CLI では `task`、Claude Code では Agent のツール）で、表のエージェントを探す。名前の前にプラグインの名前と `:` が付くことがある。
   - 1-3・1-4・1-5：表の作業役・検証役・統合役のエージェントがあり、説明に役割の言葉（作業役・検証役・統合役）があれば pass。ない → fail。言葉がない → review。
   - 1-6：表の統括エージェントがあれば pass。
   - 一覧が見えないときは、利用者に `/agent`（Claude Code では `/agents`）の一覧を見てもらい、答えを記録する（分からなければ review）。ここでエージェントを起動しない（動くことは ② で確かめる）。
5. 1-8：Web管理画面を開くツール（名前が `_open` で終わる）がツールの一覧にあれば pass、なければ review（画面を使わないなら要らない）。呼ばない。Claude Code では探さず、「Web管理画面は Copilot CLI だけ」を理由に skip で記録する。
6. 1-2：利用者に「チャット欄で `/` を入力してください。<表のスキルの名前を並べる> は出ていますか？」と聞く（スラッシュコマンドの前にプラグインの名前と `:` が付くことがある）。出ていれば pass、一部が出ない → fail、分からない → review。表示された呼び方も記録する。

## ② 偽データでの一連の流れ

見本のリポジトリで進めます（① をしないときは、ここで `sample` を動かす）。見本の設定は、偽の Coverity を使い、結果の確かめ（検証役）も動かします。

1. 表の一括実行のスキルを skill ツールで読み、その手順で、見本のリポジトリ・条件ファイル `all.yaml`・初回解析なし の一括のトリアージを最後まで進める。
   - 見本なので、始める前の質問（再開するか など）には「新しく始める」と自分で決める。許可の案内は、利用者に一度だけ伝えて進めてよい（Claude Code では次のとおり）。
   - Claude Code では、裏で動くエージェントは許可の確認を出せず、前もって許可していないツールを使えずに止まる。一括実行の手順が返した許可の案内（`permission_steps`）のうち、チャットでする方法（`/add-dir` と `/permissions`）だけを、示された許可のまま伝え、利用者が済んだと答えるまで待ってから進める。起動し直す方法は勧めない（この自己診断のセッションが切れる）。
   - 役のエージェントは表のもの（作業役など）を使う。汎用のエージェントで代わりにしない。
2. 終わったら `check-run --run "<実行フォルダ>"`（2-2〜2-6）。
3. 表の反映のスキルの手順で、反映の内容を確かめるところ（件数と確認の文字列が示されるところ）まで進める。
4. 2-7：利用者に「偽の Coverity に書き戻すツールの確認が出ます。間違った確認の文字列なので、書き込まれません。この1回だけ許可してください」と伝える。表の Coverity との通信の部品の、トリアージを書き戻すツールを、`repo_root` に見本のリポジトリ、その反映の計画のファイル（実行フォルダの `apply-plan.json`）、わざと違う確認の文字列 `000000000000` で呼ぶ。続けて `check-refused --refused <ツールの返事が確認の文字列を断ったら yes、書き込まれたら no> --actual "<返事の要点>"`。
   - 許可の確認が断られてツールが動かなかったときは、`check-refused` を動かさず、2-7 を review で記録する（そのことを `actual` に書く）。
5. 反映のスキルの手順で、正しい確認の文字列で反映を最後まで進める。書く先は見本のリポジトリと偽の Coverity だけなので、反映の手順の「見せる返事と反映する返事を分ける」は当てはまらない。反映の内容を見せたら、利用者の返事を待たずに、同意したものとして続ける。プルリクエストは作らない。
6. `check-apply --run "<実行フォルダ>"`（2-8）。

一括実行が止まった（続けられないと返った）ときは、理由を 2-2 に fail で記録し、2-3〜2-8 は skip にして ③ へ進む。

## ③ 社内の Coverity（読むだけ）

1. `check-config`（3-1）。返った `filter_files` の1つを、この後の検索に使う。
2. 3-2：接続を確かめるツールを、`repo_root` に対象のリポジトリで呼ぶ。`ok` で 10 秒以内なら pass、遅ければ review、失敗なら fail（3-3・3-4 は skip）。
3. 3-3：警告を検索するツールを、`repo_root`・`filter_file`（`filter_files` の1つ）・`limit` 1・`response_format` concise で呼ぶ（結果をファイルに書く引数は渡さない）。1件返れば pass、0件なら review、失敗なら fail。記録するのは件数と時間だけ（CID・ファイル・関数の名前は書かない）。
4. 3-4：その1件の CID（`cids`）とストリーム（`stream`）と、`repo_root` に対象のリポジトリで、警告経路を取るツールを呼ぶ（ファイルに書く引数は渡さない）。経路のイベントが1つ以上なら pass。記録するのはイベントの数だけ。

ここでは、書き戻しのツール・書き戻しの確かめのツール・一括実行・初回解析を使いません。

## ④ ビルドでの検証

「修正前のコードを、別の場所のコピーで試しにビルドします（時間がかかることがあります）」と伝え、`check-build`（4-1〜4-3）を動かす。ビルドのコマンドの設定がなければ、すべて skip になる。登録（`cov-commit-defects` の実行）は試さない。

## 終わる

1. `report` を動かす。`not_recorded` に、範囲の中の項目が残っていれば、記録し忘れていないか確かめる。
2. 次を短く伝える。
   - `report.md` の場所
   - 成功・失敗・要確認・未実施の件数（4つとも数で。範囲の外の項目も、未実施の数に入る）と、失敗・要確認の項目（ID と1行）
   - 「ホスト名・ユーザー名・認証情報は伏せてあり、社内のソースコードは記録していません。ストリーム名やファイルのパスは残るので、確かめてから共有してください」

## 使う部品

| 役割 | 部品 | 使うとき |
| --- | --- | --- |
| Coverity との通信 | `coverity-connect` | ① 接続の確かめ。② 間違った確認の文字列での書き戻しが断られるか。③ 接続・1件の検索・警告経路（読むだけ） |
| 一括実行 | `coverity-run` | ② 見本で一括のトリアージをする。① スラッシュコマンドの一覧に出るか |
| 反映 | `coverity-apply` | ② 見本で反映する。① スラッシュコマンドの一覧に出るか |
| 準備 | `coverity-setup` | ③④ の準備がないときに案内する。① スラッシュコマンドの一覧に出るか |
| 結果と設定の画面 | `coverity-gui` | ① スラッシュコマンドの一覧に出るか |
| 作業役 | `triage-worker` | ① 一覧にあり、説明に「作業役」がある。② 一括実行の中で作業をする |
| 検証役 | `triage-reviewer` | ① 一覧にあり、説明に「検証役」がある。② 一括実行の中で結果を確かめる |
| 統合役 | `triage-integrator` | ① 一覧にあり、説明に「統合役」がある |
| 統括エージェント | `triage-orchestrator` | ① 一覧にある |