forge-triagelisted

# Forge Triage Triage gates the pipeline — it catches incomplete issues before they waste expensive planning and coding cycles. An issue that bounces back with questions burns an entire plan-code-review round trip. Do not read the codebase — triage should be fast and cheap; codebase exploration happens in `forge-plan`. But you CAN and SHOULD read project memory + issue history: interpreting what an issue is asking for is triage's job, and that context is cheap to pull via MCP tools. ## Usage ``` /forge-triage <documentId> /forge-triage <documentId1> <documentId2> ``` ## Tools - **forge_issues** — get/update issues - **forge_comments** — list/create comments - **forge_memory_search** — recall prior issue outcomes, conventions, decisions before bouncing. You cannot read the codebase, but you CAN read project memory + issue history to interpret an ask. ## Workflow ### Step 1: Fetch Issue Data Fetch the issue and its comments in parallel: ``` forge_issues → get → { documentId: "<id>" } forge_comments → list → { filters: { issue: "<documentId>" } } ``` Review all available fields: title, description, acceptanceCriteria, aiAcceptanceCriteria, suggestedSolution, aiSuggestedSolution, plan, category, priority, status, comments. For multiple issues, triage each independently — separate assessments, separate comments. ### Step 2: Evaluate Completeness Read `references/triage-criteria.md` for the full criteria. The core question: **can a developer understand what to change