Triage

Triage

Triage a bug report end-to-end: reproduce the bug, diagnose the root cause, verify whether the behavior is intentional, and attempt a fix.

General Rules

Do not get stuck on infrastructure problems. If a server won't start, a port is blocked, or a tool is unavailable in the CI environment — bail out after 2 attempts and write your report with the data you already have. Looping on server restarts or missing CLI tools wastes your entire time budget. A partial report with solid findings is infinitely more valuable than no report because you ran out of time fighting a stale process.

Input

You need either:

• issueTitle and issueBody provided in args (preferred — use these directly as the bug report), OR
• A GitHub issue number or URL mentioned in the conversation (use gh issue view to fetch details)

If a triageDir is provided in args, use that as the working directory for the triage. Otherwise, default to triage/gh-<issue_number> (if you have an issue number) or triage/current.

Step 1: Reproduce

Read and follow reproduce.md. Use a subagent for this step to isolate context.

After completing reproduction, check the result:

• If the issue was skipped (host-specific, unsupported version, etc.) — skip to Output.
• If the issue was not reproducible — skip to Output.
• If the issue was reproduced — continue to Step 2.

Step 2: Diagnose

Read and follow diagnose.md. Use a subagent for this step to isolate context.

After completing diagnosis, check your confidence:

• If confidence is low — skip to Output.
• If confidence is medium or high — continue to Step 3.

Step 3: Verify

Read and follow verify.md. Use a subagent for this step to isolate context.