---
name: triage-review
description: 別に調べた Coverity の警告の結果（判定・根拠の場所・確信度・修正の差分・逸脱コメント）を、自分でコードを読んで独立に確かめ、評価基準ごとの合否と、合格・要確認・差し戻しを返す。渡された結果と差分は変えない。決まった点を機械的に見つけるスクリプトと、確かめの結果（review.json）の形を確かめるスクリプトがある。チャットで「この結果を確かめて」「この判定は正しい？」「この修正案と逸脱コメントをレビューして」のように頼まれたとき、トリアージの結果を検証するときに使う。別の人やエージェントが出した Coverity の警告の結果の正しさを聞かれたら、必ずこのスキルを使う。
allowed-tools: ["shell(uv run:*)"]
---

# 結果の確かめ方

別に調べた結果が正しいかを、コードを読んで確かめます。決めるのは、**合格（pass）・要確認（flag）・差し戻し（rework）** の3つだけです。

- **自分で判断します。** 結果を読む前に、警告の ★ の場所と経路の条件をコードで読みます。先に結果を読むと、その見立てに引きずられるからです。
- 根拠は、すべてコードの場所（ファイルと行）で示します。
- 渡された結果・差分・コードは**直しません**。推奨も変えません。直すのは結果を作った側です。
- 差し戻すのは、直す点を具体的に言えるときだけです。言い回しや好みの違いは差し戻しません。

## 進め方

```
- [ ] 1. 材料をそろえる
- [ ] 2. 結果を開く前に、★ と経路の条件をコードで読む
- [ ] 3. 結果と差分を読み、自分の見立てとコードに照らす
- [ ] 4. 機械的に見つかる点を見る
- [ ] 5. 評価基準ごとに findings を書く
- [ ] 6. 合格・要確認・差し戻しを決める
- [ ] 7. 書く・確かめる・返す
```

頼みの文や、それが指すファイル（指示ファイル）が、進み具合のファイルと段を示していれば、節目ごとにそのファイルを上書きします。書けなくても続けます。

### 1. 材料をそろえる

- 警告の情報：CID、チェッカー、ファイルと行、警告経路（★ は問題の起きる場所。Coverity のイベントでは `main` が true のもの）
- 読むコードの場所（解析したリビジョンのコピーか、リポジトリ）
- 確かめる結果（`result.json` の形のファイルか、チャットの文）と、修正の差分（あれば）
- 評価基準：このスキルの `assets/criteria.json` の、`scope` が `item` の基準（20個）。頼みの文が基準のファイルを示していれば、そちらを使う
- 警告経路などが足りないとき：Coverity から警告経路を取れる道具があれば、それで取る。なければ頼んだ人に聞く。聞けないとき（ほかのエージェントからの頼みなど）は、確かめられなかったこととして findings と `note` に書く。推測で補わない。
- リポジトリに `.coverity-triage/knowledge.md` があれば読む。チェッカーごとの見方の資料があれば、それも読む。

### 2. 結果を開く前に、自分で読む

1. ★ の行と、警告経路の各段の前後（20行ほど）を読む。
2. 経路が成り立つための条件（分岐の条件、引数の値、戻り値）を書き出す。
3. 条件の値の出どころを、関数・マクロ・変数の名前で探し、呼び出し元や定義までたどる。すべての呼び出し元が条件を満たさないなら、経路は成り立たない。1つでも満たす呼び出し元があれば、成り立ちうる。
4. 自分の見立て（判定と、決め手の場所）を短く書き留める。

### 3. 結果と差分を照らす

- 根拠の場所（`verdict.evidence`）を開き、その行に書かれたとおりのコードがあるかを見る。
- 判定と確信度が、自分の見立てとコードに合うか。
- 修正の差分：★ に至る経路を断っているか、最小か、関数の外から見た動き（引数・戻り値・公開の宣言）を変えていないか、新しい MISRA / CERT の違反を作らないか。
- 逸脱コメント：理由と場所がコードと合うか、判定区分（「誤検知。」など）が判定と合うか、書き方の決まり（200文字以内、条件の言い方がない など）を守っているか。
- グループや統合した結果なら：すべての CID が同じ原因か、修正がすべての警告に効くか。

### 4. 機械的に見つかる点を見る

頼みの文や指示ファイルに「スクリプトが見つけた点」があれば、それを見ます。なければ、コマンドを使えるときは次を動かします（RUN）。

```
uv run --native-tls --quiet "<このスキルのフォルダ>/scripts/lint_result.py" --result "<result.json>" --repo "<読むコードのフォルダ>"
```

- `<このスキルのフォルダ>` は、この SKILL.md があるフォルダです。結果がチャットの文だけのときは、この手順を飛ばし、下の点を自分で見ます。
- 出力の `points` は、見るべき点の種類です。重みは自分で判断します（たとえば本物のバグで逸脱の推奨は、チームの方針のことがあります）。

| point | 意味 |
| --- | --- |
| `evidence_missing_file` | 根拠のファイルが、読むコードにない |
| `evidence_line_out_of_range` | 根拠の行が、ファイルの行数を超える |
| `undetermined_high` | 判定できない（undetermined）のに、確信度が高い |
| `drift_high` | リビジョンのずれがあるのに、確信度が高い |
| `true_bug_deviation` | 本物のバグなのに、逸脱を推奨 |
| `not_bug_fix` | 誤検知・意図的なのに、修正を推奨 |
| `no_evidence` | 根拠の場所がない |

### 5. 評価基準ごとに findings を書く

`scope` が `item` の基準を、**すべて1回ずつ** findings に書きます。`check` は基準の id です。

```json
{"check": "C-12", "ok": false, "detail": "根拠の src/net.c:42 は変数の宣言で、close はない", "file": "src/net.c", "line": 42}
```

- `detail` には、確かめたことを場所とともに1〜2文で書きます。
- `applies_when` があって当てはまらない基準（MISRA でない警告の C-22 など）は、`ok: true`、`detail` を「対象外（理由）」にします。
- どの基準で何を見るかは [references/criteria-guide.md](references/criteria-guide.md) にあります。初めてのときと、迷ったときに読みます。
- 結果の形（どの項目がなくてよいか、空でよいか）も criteria-guide.md の C-13 にあります。形を知るために、スクリプトや試験のデータを読む必要はありません。

### 6. 合格・要確認・差し戻しを決める

| outcome | いつ | 書くこと |
| --- | --- | --- |
| `pass`（合格） | 直すべき点がない（findings がすべて `ok: true`） | `confidence_cap` は `null`、`rework` は空 |
| `flag`（要確認） | はっきりした誤りとは言えないが、人に確かめてほしい点がある（確信度が高すぎる、根拠の一部を追えない など） | `confidence_cap` に、妥当と考える確信度の上限（`high` / `medium` / `low`）を**必ず**書く。`rework` は空 |
| `rework`（差し戻し） | はっきりした誤りがある：根拠の行にそのコードがない、判定がコードと合わない、修正が ★ の経路を断っていない、逸脱コメントの根拠の場所が違う、グループに原因の違う CID がある | `rework` に、直す点を1点ずつ、場所とともに具体的に書く。その基準は `ok: false` |

### 7. 書く・確かめる・返す

確かめの結果の形です（正は `assets/review.schema.json`）。

```json
{
  "item": "20001",
  "outcome": "rework",
  "findings": [
    {"check": "C-01", "ok": true, "detail": "呼び出し元 connect_all()（src/main.c:55）はエラーのあとも処理を続ける", "file": "src/main.c", "line": 55},
    {"check": "C-12", "ok": false, "detail": "根拠の src/net.c:42 は変数の宣言で、close はない", "file": "src/net.c", "line": 42}
  ],
  "confidence_cap": null,
  "rework": ["根拠の場所を、close を通らずに戻る src/net.c:47 に直す"],
  "note": "経路と判定は正しいが、根拠の行が違う。"
}
```

（例は findings を2つだけ載せています。実際は20個すべてを書きます。）

- ファイルに書くよう頼まれたときは、書いたあとで確かめます（RUN）。`ok` が `false` なら、`problems` のとおりに**確かめの結果のファイルだけ**を直し、通るまで繰り返します。3 回直しても `ok` にならなければ、それ以上は直さず、残った `problems` と今の案をそのまま返して止めます（決まりは曲げません）。

```
uv run --native-tls --quiet "<このスキルのフォルダ>/scripts/check_review.py" --review "<review.json>" --item "<作業の ID>" --checker "<チェッカーの名前>"
```

- 統合した作業なら `--merged` も付けます。`warnings` は目安から外れたところです（当てはまらない基準の `detail` に「対象外」がない など）。
- コマンドを使えないとき（ほかのエージェントからの作業など）は、基準が20個そろって1回ずつか、`flag` に `confidence_cap` があるか、`rework` に直す点があるかを自分で見て、最後まで進めます（決まった形の確かめは、頼んだ側が行います）。

返し方：

- 頼みの文や指示ファイルが返す形を決めていれば、それに従います。決まっていなければ、1行で返します：`20001: 差し戻し — 根拠の src/net.c:42 に close がない`
- チャットで頼まれたときは、ファイルを作らずに、チャットで返します。返すもの：合格・要確認・差し戻しのどれか、`ok: false` の基準とその理由（ファイルと行）、要確認なら確信度の上限、差し戻しなら直す点、人向けの1〜2文のまとめ。ほかの基準は「合格」とまとめてよい。