forge-triage

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, plan, category, priority, complexity, 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 and what the result should be?

DEFAULT = CONFIRM. needs_info is the rare exception, never a safety reflex. For enhancement / improvement / refactor / UI-polish / "make X consistent" issues, the reporter is NOT expected to pre-specify what/where/to-what-pixel — that discovery is the pipeline's job (triage interprets intent → clarify reproduces/captures → plan designs with codebase access). Bouncing such an issue for "missing detail" is itself a triage failure.

Never ask, at triage, for clarify/plan DELIVERABLES: screenshots/visual examples, a per-element diff list, pixel-exact/numeric ACs, which design is the source of truth, an impact/business justification, or specific file/component/endpoint names. If a draft bounce asks for any of these → delete it and CONFIRM with a one-line interpretation note.