---
name: triage-integration
description: 調べ終わった Coverity の警告の作業のうち、同じ原因のものを 1 つにまとめる計画（integration/plan.json）の書き方。まとめるかどうかの決め方、修正の作り方の選び方、まとめた逸脱コメントの書き方。統合エージェントが使う。ほかのスキルとサブエージェントが読む手順書で、人が直接頼むものではない。
---

# 同じ原因の警告のまとめ方

指示ファイル（呼び出し元の prompt にあるパス）に、決まった方法で見つけた候補と、調べ終わった作業の一覧（結果ファイルと修正の差分の場所）があります。ファイルを読む・探すのは、ふだんのファイルの読み取りと検索の機能で行います。

## 基本の考え方

- まとめるのは、**原因が 1 つ**で、**1 か所を直せば（または 1 つの理由で）すべての警告が片付く**ものだけです。場所が近い、チェッカーが同じ、というだけではまとめません。
- 根拠は、すべてコードの場所（ファイルと行）で示します。
- 迷うときはまとめません（まとめ間違えると、人が別々に判断する機会がなくなるため）。
- コードは変更しません。まとめた修正は、スクリプト（元の差分をつなぐ）か作業エージェント（作り直す）が作ります。

## 手順

1. **候補を読む**：進み具合を `read` にする。候補ごとに、作業の結果ファイル（`verdict`、`fix`、`deviation`）と修正の差分を読む。
2. **同じ原因かを比べる**：進み具合を `compare` にする。
   - 指示ファイルの「警告経路の ★」の場所と、根拠の場所（`verdict.evidence`）を、調べるコードで読み直す。
   - 原因（例：同じマクロの定義、同じ関数の戻り値の確かめ忘れ、同じ構造体の初期化漏れ）が同じかを確かめる。
   - 修正の差分が、同じ原因を直しているかを確かめる。
   - チェッカー別の観点は、スキル `checker-knowledge` を見る（MISRA では「原因の 1 か所を直す」観点がある）。
3. **修正の作り方を選ぶ**（`fix_source`）
   - `item:<ID>`：まとめる作業の 1 つ（`<ID>`）の修正だけで、すべての警告が片付く。
   - `combine`：それぞれの修正が別の箇所を直していて、全部を合わせれば片付く（スクリプトが差分をつなぐ。つなげなければ、作業エージェントが作り直す）。
   - `rework`：どの修正も足りない、または修正どうしがぶつかる。作業エージェントが、元の作業の結果を読んで作り直す。
4. **まとめた結果を書く**：進み具合を `write` にする。下の「計画の形」の `result` に、まとめた作業の見立て・推奨・逸脱コメントを書く。
   - `verdict.summary`：まとめた原因を 1 行で。
   - `verdict.rationale`：なぜ同じ原因と言えるか、それぞれの CID の警告経路がどう同じ原因に行き着くかを順に。
   - `verdict.evidence`：原因のコードの場所と、それぞれの警告の場所。
   - `deviation.comment`：スキル `deviation-comment` の書き方（問題にならない理由だけを 1〜2 文・200 字以内で言い切る）で、**すべての CID に当てはまる 1 つの文**にする。
   - `confidence`：まとめる作業のうち、いちばん低い確信度を超えない（スクリプトもそのように直す）。
5. **ぶつかる修正を書く**：原因は違うのに、修正が同じ箇所を変えている作業は、まとめずに `conflicts` に書く（人が反映するときの注意になる）。
6. 計画を書いたら、呼び出し元に 1 行だけ返す。

## 決まり

- まとめる作業は 2 つ以上。1 つの作業は 1 つのまとまりにだけ入れる。
- 1 つにまとめる CID は、合わせて 10 件まで。
- 指示ファイルの「調べ終わった作業」にある作業だけをまとめる。
- まとめるものが無ければ、`merges` を空にした計画を書く。

## 計画の形

指示ファイルの「計画（書く）」の場所に、次の JSON を書きます。

```json
{
  "merges": [
    {
      "members": ["20011", "20012"],
      "reason": "どちらもマクロ BUF_LEN（include/buf.h:10）の定義が配列の大きさと合っていないことが原因",
      "fix_source": "item:20011",
      "result": {
        "verdict": {"judgement": "true_bug", "summary": "BUF_LEN が配列より 1 大きい",
                    "rationale": "...", "evidence": [{"file": "include/buf.h", "line": 10, "note": "BUF_LEN の定義"}]},
        "recommendation": "fix",
        "confidence": "high",
        "confidence_reason": "...",
        "deviation": {"classification": "Bug", "action": "Fix Required", "severity": "Major", "comment": "..."},
        "fix": {"classification": "Bug", "action": "Fix Required", "severity": "Major",
                "summary": "BUF_LEN を配列の大きさに合わせる", "impact": "...",
                "exceeded_constraints": [], "already_fixed_on_latest": false},
        "revision_drift": {"status": "none", "detail": ""}
      }
    }
  ],
  "conflicts": [
    {"items": ["20021", "20030"], "note": "どちらも src/io.c の 40〜44 行目を変えるが、原因は別"}
  ]
}
```

`result` の各項目の基準は、スキル `triage-report` と同じです（`item` と `group_excluded_cids` は書かなくてよく、書いてもスクリプトが決めなおします）。文字列は空にしません。JSON として正しい形にします。

計画に不備があると、呼び出し元から直す点が伝えられます。そのときは計画だけを直します。