/fix

Intelligent issue router. Analyzes your issue description and automatically routes to the most appropriate fix command based on type, complexity, and scope.

Syntax

/fix [issues]

When to Use

• Any Bug or Issue: Let ClaudeKit decide the approach
• Unknown Complexity: Don’t know if simple or complex
• Quick Workflow: Describe problem, let router decide
• Multiple Issues: Can detect and route to parallel fixing

Quick Example

/fix [users sometimes getting logged out randomly]

Output:

Analyzing issue...

Keywords detected: "randomly", "sometimes" (intermittent)
Scope: Unknown (needs investigation)
Complexity: High

Decision: Complex issue requiring investigation
→ Routing to /fix:hard

Executing /fix:hard with enhanced prompt...

Arguments

• [issues]: Description of issue(s) to fix (required). Can be single issue or numbered list.

Pre-Routing Check

Before analyzing the issue, /fix checks for existing plans:

Checking for active plan...
Active plan found: plans/251128-auth-system/plan.md

→ Routing to /code plans/251128-auth-system/plan.md

If an active plan exists at <WORKING-DIR>/.claude/active-plan, routes to /code instead.

Decision Tree

Routes are evaluated in priority order:

┌─────────────────────────────────────────────────────────┐
│                    /fix [issues]                        │
└─────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────┐
│ 1. Existing plan found?                                 │
│    → /code <path-to-plan>                               │
└─────────────────────────────────────────────────────────┘
                           │ No
                           ▼
┌─────────────────────────────────────────────────────────┐
│ 2. Type errors? (type, typescript, tsc)                 │
│    → /fix:types                                         │
└─────────────────────────────────────────────────────────┘
                           │ No
                           ▼
┌─────────────────────────────────────────────────────────┐
│ 3. UI/UX issue? (ui, ux, design, layout, style, css)    │
│    → /fix:ui                                            │
└─────────────────────────────────────────────────────────┘
                           │ No
                           ▼
┌─────────────────────────────────────────────────────────┐
│ 4. CI/CD issue? (github actions, pipeline, workflow)    │
│    → /fix:ci                                            │
└─────────────────────────────────────────────────────────┘
                           │ No
                           ▼
┌─────────────────────────────────────────────────────────┐
│ 5. Test failure? (test, spec, jest, vitest, failing)    │
│    → /fix:test                                          │
└─────────────────────────────────────────────────────────┘
                           │ No
                           ▼
┌─────────────────────────────────────────────────────────┐
│ 6. Log analysis? (logs, error logs, stack trace)        │
│    → /fix:logs                                          │
└─────────────────────────────────────────────────────────┘
                           │ No
                           ▼
┌─────────────────────────────────────────────────────────┐
│ 7. Multiple independent issues? (2+ unrelated)          │
│    → /fix:parallel                                      │
└─────────────────────────────────────────────────────────┘
                           │ No
                           ▼
┌─────────────────────────────────────────────────────────┐
│ 8. Complex issue? (complex, architecture, refactor)     │
│    → /fix:hard                                          │
└─────────────────────────────────────────────────────────┘
                           │ No
                           ▼
┌─────────────────────────────────────────────────────────┐
│ 9. Default: Simple, single-file issue                   │
│    → /fix:fast                                          │
└─────────────────────────────────────────────────────────┘

Keyword Detection

Routing Examples

Route 1: Type Errors → /fix

/fix [typescript errors in user service]

Keywords: "typescript"
→ Routing to /fix:types

Route 2: UI Issues → /fix

/fix [button alignment broken on mobile layout]

Keywords: "button", "mobile", "layout"
→ Routing to /fix:ui

Route 3: CI/CD → /fix

/fix [GitHub Actions workflow failing on test step]

Keywords: "GitHub Actions", "workflow", "failing"
→ Routing to /fix:ci

Route 4: Test Failures → /fix

/fix [jest tests failing after refactor]

Keywords: "jest", "tests", "failing"
→ Routing to /fix:test

Route 5: Log Analysis → /fix

/fix [stack trace shows null pointer in auth module]

Keywords: "stack trace"
→ Routing to /fix:logs

Route 6: Multiple Issues → /fix

/fix [
1. Button not clickable on mobile
2. API timeout on /users endpoint
3. Typo in footer copyright
]

Issues detected: 3 independent issues
→ Routing to /fix:parallel

Route 7: Complex → /fix

/fix [users randomly getting logged out, need to investigate session handling]

Keywords: "randomly", "investigate"
Complexity: High
→ Routing to /fix:hard

Route 8: Simple → /fix

/fix [change button color from blue to green]

Keywords: "change", single-file implied
Complexity: Low
→ Routing to /fix:fast

Clarification Questions

If the issue is ambiguous, /fix asks before routing:

/fix [something's wrong with the API]

Issue unclear. Please clarify:

1. What specific behavior are you seeing?
   [ ] Errors returned
   [ ] Slow responses
   [ ] Wrong data
   [ ] Connection issues

2. Is this affecting:
   [ ] Single endpoint
   [ ] Multiple endpoints
   [ ] All endpoints

3. Do you have:
   [ ] Error logs
   [ ] Stack traces
   [ ] Reproduction steps

Prompt Enhancement

Before delegating, /fix enhances your description:

Your Input:

/fix [login broken]

Enhanced Prompt:

Analyze and fix login functionality issue.

Context:
- Issue: Login broken (needs investigation)
- Scope: Authentication system
- Priority: High (core functionality)

Investigation steps:
1. Check authentication flow
2. Verify API endpoints
3. Review session handling
4. Check error logs
5. Test login scenarios

Fix and validate:
- Implement solution
- Add tests
- Verify fix
- Document changes

Complete Example

Scenario: Mixed Complexity Issue

/fix [payment processing fails for international cards]

Routing Analysis:

Analyzing issue...

Keywords: "payment", "fails", "international cards"
Scope: Payment system (likely multiple files)
Complexity: Medium-High
Investigation needed: Yes (specific card types)

Decision: Complex issue requiring investigation
→ Routing to /fix:hard

Enhancing prompt...
Added context:
- Payment provider integration points
- Currency handling considerations
- International card validation rules

Executing /fix:hard with enhanced prompt...

[Fix execution begins]

Manual Override

If you know the right command, call it directly:

# Override router, use specific command
/fix:types [your issue]
/fix:ui [your issue]
/fix:fast [your issue]
/fix:hard [your issue]
/fix:parallel [issue list]

Related Commands

Best Practices

Be Descriptive

# Good: Specific with context
/fix [email validation accepts invalid emails like "test@" without domain]

# Less helpful: Vague
/fix [validation broken]

Include Location if Known

# Good: Location provided
/fix [missing await in getUserData function in user.service.ts]

# Less context
/fix [missing await somewhere]

Trust the Router

Let /fix decide the strategy:

# Just describe the problem
/fix [users reporting slow page loads]

# Don't overthink which command to use

Key Takeaway: /fix is your intelligent bug-fixing entry point. Describe the problem, and it routes to the optimal fix command based on type, complexity, and scope analysis.