Triage Issue

Triage Issue

Investigate a reported problem, find its root cause, and write an issue document in a local .issues/ folder with a TDD fix plan. This is a mostly hands-off workflow - minimize questions to the user.

Process

1. Capture the problem

Get a brief description of the issue from the user. If they haven't provided one, ask ONE question: "What's the problem you're seeing?"

Do NOT ask follow-up questions yet. Start investigating immediately.

2. Explore and diagnose

Use subagent tool to deeply investigate the codebase. Prefer the builtin scout agent first for fast codebase recon; if the problem still needs deeper diagnosis, follow with worker for targeted investigation. Keep the subagent task focused on exploration and diagnosis only, not implementation. Your goal is to find:

• Where the bug manifests (entry points, UI, API responses)
• What code path is involved (trace the flow)
• Why it fails (the root cause, not just the symptom)
• What related code exists (similar patterns, tests, adjacent modules)

Look at:

• Related source files and their dependencies
• Existing tests (what's tested, what's missing)
• Recent changes to affected files (git log on relevant files)
• Error handling in the code path
• Similar patterns elsewhere in the codebase that work correctly

3. Identify the fix approach

Based on your investigation, determine:

• The minimal change needed to fix the root cause
• Which modules/interfaces are affected
• What behaviors need to be verified via tests
• Whether this is a regression, missing feature, or design flaw

4. Design TDD fix plan

Create a concrete, ordered list of RED-GREEN cycles. Each cycle is one vertical slice:

• RED: Describe a specific test that captures the broken/missing behavior
• GREEN: Describe the minimal code change to make that test pass

Rules:

• Tests verify behavior through public interfaces, not implementation details
• One test at a time, vertical slices (NOT all tests first, then all code)
• Each test should survive internal refactors
• Include a final refactor step if needed
• Durability: Only suggest fixes that would survive radical codebase changes. Describe behaviors and contracts, not internal structure. Tests assert on observable outcomes (API responses, UI state, user-visible effects), not internal state. A good suggestion reads like a spec; a bad one reads like a diff.

5. Write the issue file

Write an issue document as markdown in a local .issues/ folder using the template below.

Requirements:

• Create .issues/ if it does not exist
• Use a durable kebab-case filename based on the problem, e.g. .issues/fix-checkout-tax-rounding.md
• Do NOT ask the user to review before writing it
• After writing, share the file path and a one-line summary of the root cause

Problem

A clear description of the bug or issue, including:

• What happens (actual behavior)
• What should happen (expected behavior)
• How to reproduce (if applicable)

Root Cause Analysis

Describe what you found during investigation:

• The code path involved
• Why the current code fails
• Any contributing factors

Do NOT include specific file paths, line numbers, or implementation details that couple to current code layout. Describe modules, behaviors, and contracts instead. The issue should remain useful even after major refactors.

TDD Fix Plan

A numbered list of RED-GREEN cycles:

1. RED: Write a test that [describes expected behavior]

GREEN: [Minimal change to make it pass]

1. RED: Write a test that [describes next behavior]

GREEN: [Minimal change to make it pass]

...

REFACTOR: [Any cleanup needed after all tests pass]

Acceptance Criteria

• [ ] Criterion 1
• [ ] Criterion 2
• [ ] All new tests pass
• [ ] Existing tests still pass

After writing the issue file, print the file path and a one-line summary of the root cause.

Communication

Honor active caveman mode for user-facing replies per ../../references/communication-mode.md. Keep durable artifacts normal unless the human asks otherwise. Drop caveman for safety/clarity when needed, then resume.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: siarhei-belavus
• Source: siarhei-belavus/agent-public
• License: MIT

Install and usage instructions live in the source repository linked above.