triage-created-issue: パターンAの過剰発火で自動回答可能な確認事項が人間エスカレートされる

[utsubasa]

概要

triage-created-issue スキルのパターンA（cc-need-human-check）が、技術的に自動回答可能な確認事項に対しても過剰に発火し、不要な人間エスカレートを発生させている。igsa-ai/stratia-app#1455 で実際に発生した。

再現事例: igsa-ai/stratia-app#1455

Issue本文が「クエリ事前入力の唯一の供給元は #1404 で削除されるため、デッドコード化 → 除去」と根拠付きの結論を示していたにも関わらず、トリアージが以下2点を cc-need-human-check にエスカレート:

1. 「プロダクト判断: クエリ事前入力機能は不要 → 除去でよいか」→ 技術的事実として供給元消失でデッドコード化が確定しており、コードベース調査で回答可能
2. 「着手タイミング: #1404 マージ完了まで着手不可でよいか」→ #1404 はトリアージ実行の1分前にクローズ済みだったが、Issue本文のスナップショット（OPEN）を事実として採用

原因分析

3つの構造的問題が重なっている。

1. パターンAに反証シグナルがない

パターンAのシグナル例「仕様・要件に矛盾や曖昧さがあり、コードベース調査だけでは解消できない」に該当するかの判定時、確認事項の「ラベル」（「プロダクト判断」という語句）だけで発火する。Issue本文が既に根拠付きの結論を出している場合の除外条件がない。

2. 「依存関係の再確認は不要」が事実確認をブロック

スキルの前提に「依存関係はすでに解決済みで、着手可能な状態である（依存関係の再確認は不要）」とあるため、確認事項で言及されている Issue（#1404）の現在の状態を gh issue view で確認する動機を持たない。本文作成時点のスナップショットを事実として採用してしまう。

3. パターンA→Cの排他実行がリカバリを阻害

「上から順に評価し、最初に該当したパターンの処理を行ったら以降のパターンは評価しない」というルールにより、パターンA（cc-need-human-check）に該当すると判定された時点でパターンC（cc-answer-issue-questions）は評価されない。「自動回答を試みてから、回答不能な項目だけ人に渡す」という段階的判断ができない。

要件

• パターンAの判定に反証シグナルを追加する: Issue本文の実装プランが既に根拠付きの結論を示しており、確認事項が事実確認（コードベース調査や gh コマンド）で解消可能な場合は、パターンAではなくパターンC（cc-answer-issue-questions）に振り分ける
• 確認事項で言及されている Issue/PR の現在の状態（OPEN/CLOSED）を gh issue view で検証するステップを追加する。「依存関係の再確認は不要」の前提は「依存 Issue の着手判定」に限定し、「確認事項内で参照されている Issue の事実確認」は別途行う
• パターンAとCの関係を見直す: 全確認事項を一括でパターンA判定するのではなく、個々の確認事項ごとに「自動回答可能か」を評価し、全項目が自動回答不能な場合のみパターンAを適用する（一部が自動回答可能ならパターンCで回答を試みたうえで、残りを人間エスカレートする）

参照情報

• 対象スキル: plugins/base-tools/skills/triage-created-issue/SKILL.md（パターンA: 56-81行目、前提: 19-21行目、排他実行: 53行目）
• 関連スキル: plugins/base-tools/skills/answer-issue-questions/SKILL.md（パターンCで呼ばれる回答スキル）
• 再現事例: igsa-ai/stratia-app#1455（トリアージコメント: 2026-07-02T04:55:45Z、#1404 クローズ: 2026-07-02T04:54:18Z）