triage-issue

name	triage-issue
description	GitHub Issue を軽量実装で進めるか forge の SDD フロー（start-requirements/start-design/start-plan）に委ねるかを判定するスキル。feature namespace の要否も判定する。トリガー：「このIssueをトリアージして」「Issueの進め方を判定して」「#N はどう進めるべきか判定して」
user-invocable	true
argument-hint	<issue番号 または URL>
allowed-tools	Bash(git *), Bash(gh issue view *), Bash(gh issue edit *), Bash(gh issue comment *), Bash(gh pr list *), Bash(gh pr view *), Bash(gh pr diff *), Bash(gh repo view *), AskUserQuestion, Read, Grep, Glob, Skill

/anvil:triage-issue

GitHub Issue を実装着手前にトリアージし、「軽量実装」「/forge:start-requirements」「/forge:start-design」「/forge:start-plan」のどれに委ねるべきかを判定する、開発フロー全体の唯一の分岐点となるスキル。コード・設計書・PR の作成/実装は自らは行わない（軽量実装は impl-issue を起動して委ね、SDD は start-* を提案する）。判定結果は会話での報告に加え、Issue 側にも申し送りとして記録する（Phase 9 参照）。

軽量実装ルートの入口は本スキルに一本化されている。anvil:impl-issue は user-invocable: false であり、本スキルの Phase 9-3 からの Skill ツール起動が唯一の開始経路。

判定基準（不確定性の判定粒度・リスクゲート条件）はヒューリスティックであり、使用しながら随時改良する。判定根拠を必ず明示し、後から「この判定は妥当だったか」を検証できるようにする。

Goal

Issue の内容・関連仕様書・類似実装・既存コードを「設計判断ができる水準」まで調査した上で、次の3点を判定して報告する。

1. 不確定性判定: 要件は固まっているか・設計判断は残っているか。いずれかが未確定なら SDD ルート（要件未確定 → start-requirements / 設計未決 → start-design）
2. リスクゲート判定（要件・設計とも確定の場合のみ）: 軽量実装（anvil:impl-issue による直接対応）で良いか、リスクが高いため start-plan 経由で計画書とレビューパイプラインを通すべきか
3. feature 要否判定（SDD ルートの場合のみ）: additive_development_spec.md §1 の適用条件で判定する

ワークフロー

Phase 0: 前処理（リポジトリ解決）

.git_information.yaml があれば読み、なければ gh repo view --json nameWithOwner --jq '.nameWithOwner' で <owner>/<repo> を解決する。

Phase 1: Issue 確認・構造化度チェック

1. gh issue view <issue番号> --repo <owner>/<repo> と --comments で本文・コメントを取得する
2. 構造化度を判定する:
   • <!-- issue-driven-flow:user-content:start --> マーカーがある → /anvil:create-issue 経由で作成された構造化 Issue
   • マーカーがなく、本文が簡潔・テンプレート不完全（例: 「不具合の説明」「再現手順」のみで内容が数行） → 非構造化（メモ書き）Issue
3. 非構造化の場合: 以下が Issue から読み取れるか確認し、読み取れない項目は AskUserQuestion でユーザーに確認する（create-issue 相当の聞き取りをこのスキル内で完結させる。create-issue への差し戻しはしない — 差し戻す先の入力経路をそもそも経由していない Issue のため）:
   • 背景・現象（何が問題か）
   • 期待される動作（あるべき姿）
   • 再現手順（バグの場合）
4. 確認できた不足情報は、この後の Phase での判定材料として使う（Issue 本文そのものを書き換えることはしない。書き換えは後続の実行スキル — impl-issue / start-requirements 等 — の責務とする）

Phase 2: 仕様書調査

references/phase-02-spec-investigation.md の手順に従う。

Phase 3: 実装ルール調査

references/phase-03-rule-investigation.md の手順に従う。

Phase 4: 類似 PR 調査

references/phase-04-pr-investigation.md の手順に従う。

Phase 5: 既存コード調査

references/phase-05-code-investigation.md の手順に従う。

Phase 6: 不確定性判定 [MANDATORY]

判定が決めるのは「要件定義書・設計書が必要か」であり、それを左右するのは不確定性（要件が固まっているか・設計判断が残っているか）である。リスク（壊れた場合の実害等）はここでは扱わない（Phase 7 のリスクゲートで扱う）。以下の 2 判定を順に行い、各判定に Yes/No と一文根拠を必須記載する。

判定 1: 要件の確定性 — Issue から「あるべき姿」が一意に読み取れるか（期待動作・受け入れ基準相当が具体的で、対話なしに What が確定するか）:

• No（要件未確定） → SDD ルート、エントリポイント /forge:start-requirements。Phase 8 へ
• Yes → 判定 2 へ

判定 2: 設計判断の残余 — 実現方法に選択の余地・新規性があるか（アーキテクチャ変更 / データ構造・契約の変更 / 新概念の導入 / 複数の実現方式からの選択）。Phase 4〜5 で特定した既存パターンの踏襲で書けるなら「なし」:

• Yes（設計判断が残る） → SDD ルート、エントリポイント /forge:start-design。Phase 8 へ
• No（要件・設計とも確定） → Phase 7（リスクゲート）へ

既知の制約: 判定（特に判定 2 の「既存パターンで書けるか」とリスクゲートの波及実測）には Phase 2〜5 の調査結果が必要なため、「軽量と分かった Issue でもフル調査コストがかかる」という非対称は本設計では解消しない。調査打ち切りの早期化は将来課題とする。

Phase 7: リスクゲート（要件・設計とも確定の場合のみ）[MANDATORY]

要件・設計が確定していても、失敗時の被害が大きい変更は計画書のタスク分解とレビューパイプラインを通す。以下のいずれかに該当するか Yes/No で判定する（数値化・積算はしない）。各条件に Yes/No と一文根拠を必須記載する:

#	ゲート条件
1	後戻り困難な実害の可能性（データ破壊・セキュリティ・配布物破損）
2	サイレントに壊れる性質（テストで検知できず実運用まで気づかれない。別スコープの誤書き換え等）
3	Phase 5 実測で、当該変更を実装するために実際に修正が必要なファイルが 3 ファイル以上になる（対象コンポーネントの将来の利用範囲・呼び出し元の多さではなく、この変更で実際に編集を要するファイル数を測定する）

• いずれかに該当 → SDD ルート、エントリポイント /forge:start-plan（要件・設計は確定済みのため計画から）。Phase 8 へ
• すべて該当なし → 軽量実装（Phase 8 はスキップし Phase 9 の「軽量実装の場合」へ）

Phase 8: feature 要否判定（SDD ルートの場合のみ）

他プラグイン（forge）の内蔵文書へは直接パス参照しない。Skill ツールで /forge:query-forge-rules（args 例: 差分開発フィーチャー 判定基準 additive development spec）を呼び、返された文書パスを Read して additive_development_spec.md §1 の適用条件・除外条件を取得し、そのまま適用する。

• まず判定する: 実装の修正に伴い既存の要件定義書・設計書のいずれかに変更が必要か（文書側が一切変わらない＝実装のみのバグ修正なら、ここで feature 不要・Phase 8 終了）
• 文書側の変更が必要な場合、§1 の除外条件（規模が小さい AND 質的レッドフラグに該当しない）を両方満たすかを判定する
  • 両方満たす → feature 不要（既存の要件定義書・設計書を直接編集する経路）
  • いずれか満たさない → feature 必要（--new または --add）。「バグ修正だから」という名目のみを理由に不要と判定してはならない

Phase 9: 判定結果の報告 + Issue への申し送り + （軽量実装のみ）impl-issue 起動

forge の start 系スキル（start-requirements / start-design / start-plan）は起動しない（ユーザー判断に委ね、提案に留める）。軽量実装と判定した場合のみ、9-1・9-2 の後に 9-3 で impl-issue を起動する。

9-1: 会話での報告

## Issue #<N> トリアージ結果

### 判定
- 要件の確定性: 確定 / 未確定 — <根拠>
- 設計判断の残余: なし / あり — <根拠（要件確定の場合のみ）>
- リスクゲート: 該当なし / 該当（条件 <#>） — <根拠（要件・設計とも確定の場合のみ）>
- 結論: 軽量実装 / SDD（エントリポイント: start-requirements / start-design / start-plan）

### 推奨ワークフロー（SDD ルートの場合のみ）
- feature 要否: <必要（--new|--add） / 不要（既存文書直接編集）>
- 判定根拠: <Phase 8 の適用条件との照合結果>

### 次のアクション
<軽量実装: "9-3 で impl-issue の起動を確認します" / SDD: "/forge:start-plan で ADR-033 を入力に実装計画を策定することを推奨します（起動はユーザー判断）">

9-2: Issue への申し送りコメント（gh issue comment）[MANDATORY]

会話での報告とは別に、gh issue comment <N> --repo <owner>/<repo> --body-file - で 9-1 と同内容の要約を Issue にコメントとして残す。

このコメントは監査記録であると同時に、セッションを跨いだ場合に impl-issue が調査結果を復元する永続ストアを兼ねる（impl-issue Phase 0-2 参照）。調査結果の4カテゴリ（関連仕様書・ルール文書・類似 PR・既存コード）は省略せず、該当が無かったカテゴリも「該当なし」と明記する（「調査したが 0 件」と「未調査」を区別可能にするため）。

機械可読マーカーで囲む [MANDATORY]: このマーカーが効くのは同一セッション内の連続フローではなく、セッションが途切れた後（再開・PR失敗からの再開）に限られる。その場面では複数回 triage・手書きコメントが混在しうるため、「どれが最新の正本か」という位置特定に、AI の読解力ではなく本スキルのテンプレートだけが書く固有マーカーを使う（手書きコメントが偶然似た文言を含んでも誤って一致しない）。軽量実装と判定した場合のみ、コメント本文全体を以下のマーカーで囲む:

<!-- anvil:triage-result:v1:start -->
（9-1 と同内容の要約）
<!-- anvil:triage-result:v1:end -->

SDD ルートの場合はマーカーを付けない（impl-issue は軽量実装 Issue に対してしか起動されないため、SDD 判定コメントを機械的に見分ける必要がない。SDD 判定も監査記録として平文コメントには残すが、マーカー対象外）。

軽量実装かどうかの判別自体は、マーカー内の見出し文言（「## トリアージ結果: 軽量実装」）で行う。この文言は impl-issue がどのみち読んで理解する調査結果本文の一部であり、専用の route: フィールドを別途設けても読み違えのリスクは実質的に下がらないため設けない。

マーカーを含まないコメント（手書き・旧スキーマ・SDD 判定）は無視する。マーカー内のスキーマを変更する場合は v1 を v2 へ上げ、impl-issue 側の復元ロジックも同時に更新する。

書く内容の境界 [MANDATORY]:

• 書く: 判定結果（不確定性・リスクゲート・エントリポイント・feature 要否）とその根拠、Phase 2〜5 で特定した関連仕様書・ルール文書・類似 PR・既存コードのパス一覧（要約のみで詳細分析は書かない）
• 書かない: 具体的な実装方法・クラス名・ファイルパスレベルの実装計画（impl-issue Phase 8 の責務。越境しない）

参照の種別を明記する [MANDATORY]: 関連仕様書・ルール文書の各パスには kind: local_path（ローカルの相対パスで impl-issue が Read できる）または kind: github_url（外部リポジトリ・symlink 経由で実体の GitHub URL のみ記録、references/phase-02-spec-investigation.md 参照）を付す。impl-issue はこの種別で取得方法を分岐する（Phase 2 参照）。

軽量実装の場合のコメント例:

<!-- anvil:triage-result:v1:start -->
## トリアージ結果: 軽量実装

要件の確定性: 確定 — <一文根拠> / 設計判断の残余: なし — <一文根拠> / リスクゲート: 該当なし — <一文根拠>。

調査結果（impl-issue が引き継ぐ。4カテゴリとも省略しない）:
- 関連仕様書: <path> (kind: local_path) / <GitHub URL> (kind: github_url) / 該当なし
- ルール文書: <path> (kind: local_path) / 該当なし
- 類似 PR: #<N>（<一言メモ>） / 該当なし
- 既存コード: <path>（<再利用方針の一言メモ>） / 該当なし
<!-- anvil:triage-result:v1:end -->

9-3: impl-issue 起動（軽量実装の場合のみ）[MANDATORY]

9-1・9-2 の完了後、AskUserQuestion で起動確認を 1 回だけ行う:

Issue #<N> は軽量実装（要件・設計とも確定、リスクゲート該当なし）と判定されました。このまま実装（impl-issue）に進みますか？
- はい: impl-issue を起動する（Phase 2〜5 の調査は本スキルの結果を引き継ぐため再実行されない）
- いいえ: ここで終了する（後で /anvil:triage-issue #<N> を再実行すれば再開できる）

「はい」の場合、Skill ツールで anvil:impl-issue を起動する（args: <Issue 番号>）。調査結果は同一セッションのコンテキストで共有され、セッションを跨いだ再開時は 9-2 のコメントから復元される（引き渡し用の一時ファイルは作らない）。

impl-issue が中断・失敗した場合はその内容をそのままユーザーに報告する（本スキル側でリトライや代替経路の提案は行わない）。