fix

Debug and Fix

Fix bugs and review findings while staying inside the project's own patterns. This skill has no built-in bug catalog for any specific stack; it teaches a method, not a list of known errors, because that list is different for every codebase.

Input

$ARGUMENTS

Mode Detection

• If arguments contain severity markers (Critical, High, Medium, Low) or a file:line table: Batch Mode
• Otherwise: Single Bug Mode

---

Single Bug Mode

Step 1: Triage

Understand the symptom before touching code:

• What should happen versus what actually happens?
• When and where does it occur (which input, which environment, which trigger)?
• Ask clarifying questions if the description is ambiguous. Don't guess at reproduction steps.

Step 2: Trace the Request Through the Architecture

Every stack has some version of this chain; adapt the names to what the project actually uses:

Entry point (route, CLI command, event handler, queue consumer)
    |
Dispatch (router, framework middleware, controller)
    |
Business logic (service, use case, domain layer)
    |
Data access (model, repository, query layer)
    |
Presentation (view, template, serializer, response)

Read the relevant files along this path, starting from the entry point and following the call chain. If the project has a CLAUDE.md, a rules directory, or an architecture doc, read it first: that's where the actual layer names and boundaries are defined for this specific codebase.

Step 3: Diagnose

Identify the root cause, not just the symptom. Check neighboring code for the same pattern; a bug caused by a missing cast, a missing null check, or a missing escape often exists in more than one place.

Step 4: Fix

Apply the fix following the project's own conventions, not a generic default:

• Match the error-handling style already in use (exceptions, result objects, error codes) rather than introducing a new one.
• Match the existing naming, layering, and helper usage. If the project has a validation helper, a response helper, or an escaping helper, use it instead of inlining the logic again.
• If the fix touches a boundary (user input, external API response, file path from a request), re-check it against the project's security rules, not just the immediate bug.