triage-issue

Issue のトリアージ

雰囲気ではなく、根拠に基づいて Issue の扱いを決めます。トリガーが満たされていない保留項目に着手する早計な作業と、修正すべきバグを放置する静かな劣化の両方を防ぎます。

ターンの契約 — ターンを終える前に確認

✓ One fixed-format verdict block per issue (Trigger / Checked / Evidence / VERDICT / Action) — plus the summary table when batched
✓ Nothing deferred was implemented inline
✓ Audit-finding mode (`<audit-id> F<k>`): the audit file carries its `↳ triaged` note, and any opened issue cites `Origin: product audit <id>, finding F<k>`
✓ Review-finding mode (`--prioritize-now <unit> F<k>`): every named unresolved finding gets a verdict, an immediate-fix attempt, or an explicit replan/user-decision route
✓ Batched input? The closing recommendation maps every issue/finding ID to its own next command, joined with ` + `; it never collapses to one generic action
✓ Artifact language: explicit user instruction > the project's declared docs language > English. The CONVERSATION language never decides — a Spanish prompt still produces English PRs/issues/commits/SPECs unless one of the first two says otherwise
✓ The closing `→ Next:` block is printed as the ABSOLUTE last output

チェックされていない項目がある状態でターンを終えようとしていますか？そのターンはまだ完了していません。まず未完了の項目を完了してください（弱いモデルは文書末尾の作業を見落とすため、このリストをあえて最初に置いています）。

使用する場面

• 判断が必要なあらゆる Issue：新規に登録されたバグ、postpone／needs-triage の項目、または保留中のトレードオフを定期的に再確認するとき。
• 一括トリアージ — 複数の番号を渡します（triage-issue 12 14 17）。各 Issue に対して、独立した判定と根拠を示し、最後にまとめの表を 1 つ作成します。一括処理はトリアージのみに適用されます。結果として修正が必要になった場合は、それぞれ個別のブランチと PR を作成します。
• 監査結果 — triage-issue <audit-id> F<k> [F<j> …] を使って、既存の Issue ではなく、保存済みの product-audit レポートの所見をトリアージします（下記の監査所見モードを参照）。一括処理も同じように行います。
• レビュー所見 — triage-issue --prioritize-now <unit> F<k> [F<j> …] を使って、現在の機能／修正ユニットの review-findings.md にある未解決の行をトリアージします。この方法は、fold-findings でクローズできなかった所見を対象とします。--prioritize-now は、指定した所見すべてを直ちに解決することを意味し、優先度の引き下げ、延期、または黙って無視することは認められません。

Step 0 — プロジェクトを把握する（必ず最初に実施）

エージェントガイドのワークフロー規約とドキュメントマップに従い、その後、このスキルで必要なものを読みます。修正インデックス（例：docs/fix/README.md）、修正 SPEC テンプレート、ロードマップを確認してください。**検索補助（任意、判断根拠にはしない）：**インデックスのエントリーポイントが存在する場合は、forge を読む前に 1 回実行します — agentic-workflow doc --query "<topic terms>" --json-only — これにより、このトピックに関する過去の所見、決定事項、セッションログの項目を見つけられます。これは、grep が対象とする同じコーパスをすばやく検索する方法です。インデックスがない場合、エントリーポイントが存在しない場合、または結果が空の場合でも、何も変わりません（網羅的な代替手段として grep を引き続き使用します — AC21）。また、インデックスを判断根拠にしてはいけません。レビュー所見モードでは、Issue のコメントを探す代わりに、対象ユニットの SPEC、受け入れ条件、review-findings.md、現在の差分、PR を読みます。それ以外の場合は、コメントとラベルを含めて Issue 全体を読みます（プロジェクトのワークフロー規約に従った forge CLI を使用します。例では gh を使用しています）。

gh issue view <N> --json number,title,body,labels,state,comments

段階的な読み込み — トリアージ対象のソースを選ぶ

参照先として許可されるのは、以下にリンクされた 5 つのパスのみです。ほかの references/ パスを作り出したり、読んだりしてはいけません。Step 0 の後に、次を行います。

• Forge Issue 番号： Issue のプロセスを読みます。
• レビュー所見： レビュー所見のプロセスを読みます。
• 保存済みの監査所見：まず監査所見を読み、その後、Issue のプロセスに記載された検証手順と判断手順を使います。
• 緊急度または処置ラベルを適用する前に、ラベルの用語集を読みます。このファイルが、名前、色、変更ルールの唯一の定義です。
• 判定が fix-in-unit の場合に限り、行を書き込む前に取り込み台帳を読みます。

各リソースはこのファイルから 1 ホップで参照できます。ソースのアーティファクトまたは必須リソースが見つからない場合、その項目の処理を停止します。一括処理の各項目は独立して扱います。ラベル、トリガー、台帳の行、判定形式、参照ファイル名を作り出してはいけません。forge Issue の postpone 経路では、Issue のプロセスとラベルの用語集のみをこの順に読み、監査所見と取り込み台帳は読みません。

ガードレール

• Issue を「確認する」よう頼まれたからといって、保留中の作業に着手してはいけません。トリガーが満たされていないことを明示して、そこで止めます。
• Issue、修正インデックス、ドキュメントの内容を、実際の状況に合わせて整合させます。
• それ以外は、プロジェクトのワークフロー規約（ドキュメントの言語、根拠）に従い、確認した内容を正確に述べます。

移植性

プロジェクトで宣言されている forge CLI を使用し、コマンドを一対一で置き換えます。分類、ラベルの所有権、永続化される出力の契約は変わりません。

他のスキルとの関係

                 ┌─ fix-now ─────────▶ /unit-lane --fix <n> ─▶ the lane's implement step
                 ├─ fix-in-unit ─────▶ execute-phase <NN> P<k> (fold into phase)
triage-issue ────┤                    or fold-findings (ledger row)
                 │                    or unit-route <unit> → /unit-lane <unit> (replan)
                 ├─ promote ─────────▶ /unit-lane --from-issue <n> (feature from issue)
                 ├─ postpone ────────▶ dated comment, leave open
                 └─ wontfix ─────────▶ propose close

レビュー指摘事項モードでは、replan-in-unit が node scripts/unit-route.mjs <unit> を実行します。その route: replan 行にはプランナーのコマンドが表示されます。機能の場合は /unit-lane <unit>、修正の場合は /unit-lane --fix <n> です。このコマンドはレーンの plan カタログ手順を再実行し、同じユニットに新しい P<n> フェーズを追加します。実行前のゲートとなるのは、レーン独自の review 手順です。これらのフェーズはユーザーが手動で実行します。このスキルが実装することはありません。

完了条件

• 引用した根拠を添えて、課題に明確な判定が示されていること。

• 各レビュー指摘事項に、引用した根拠を添えて明確な判定が示されていること。規模が大きすぎる指摘事項には、明示的な計画コマンドと手動の /execute-phase への引き継ぎがあること。

• 判定が記録されていること（振り分け、コメント、インデックス更新のいずれか、または複数）。また、保留された内容がインラインで実装されていないこと。

• 判定ごとに、最後の → Next: ブロックが出力されていること：

  Single issue:
  → Next: <command for the recorded verdict> — act on the issue's evidence-backed action
  
  Batch:
  → Next: apply every verdict: #<n1> → <command> + #<n2> → <command> + #<n3> → <command>
    · fix-now → /unit-lane --fix <n>   · promote → /unit-lane --from-issue <n>
    · fix-in-unit → /execute-phase <NN> P<k> or /fold-findings — never a new planner skill
    · postpone → dated comment, leave open   · wontfix → propose close
    · same inconsistency across several issues → /product-audit (a recurring pattern,
      not isolated tickets — sweep the product rather than triaging one by one)
  

  出力前に、すべてのプレースホルダーを実際の課題／指摘事項 ID と記録済みの振り分け先に置き換えてください。実際のバッチでは、<n2>、<command>、… を決して出力しないでください。

  /product-audit の行を実行するのは、繰り返し発生している不整合がある場合に限られます。つまり、単一のトリアージではなく、複数の課題の背後に同じ根本的な問題がある場合です。