Skip to content

Fixing a bug

Use /n45-fix when something is broken, behaving incorrectly, or running slowly. N45 investigates, identifies the root cause, and proposes a correction — either applied immediately or planned in detail.

Like /n45-feat, N45 chooses between a hot fix and a structured fix based on what the investigation finds.

The three conditions

All three must be true for the hot fix path. If any one fails, N45 escalates to a structured fix.

Condition What it means
Clear root cause The diagnosis is confirmed. No pending investigation.
No architectural change The fix touches existing code paths only — no new modules or pattern shifts.
No schema or migration The fix doesn't require a database change.

The flow

flowchart TD
    Start([/n45-fix]) --> Investigate[Investigate]
    Investigate --> Project[Read project patterns]
    Project --> Ask[Clarify symptoms & expected]
    Ask --> Diagnose[Diagnose root cause]
    Diagnose --> Decision{Hot fix
conditions?} Decision -->|all 3 met| Hot[Hot fix
branch + executor] Decision -->|any fail| Structured[Structured fix
discovery + spec + roadmap] Hot --> Validation Structured --> Validation Validation([Validation])

Hot fix — example

"The login button does nothing when I click it."

  1. N45 reads PATTERNS and the relevant components
  2. Investigates: finds the submit handler is never bound
  3. Diagnoses: clear root cause, single file
  4. Confirms all three hot-fix conditions are met
  5. Decides: hot fix
  6. Creates a dedicated branch (hot-fix/login-button-no-submit)
  7. Spawns the executor with the diagnosis and the file scope
  8. Returns: changed files, summary, how to test
  9. You validate → commit → merge

Total time: 1–2 minutes.

Structured fix — example

"Our migration corrupted user records. Some sessions show wrong data."

  1. N45 investigates and identifies a partial-update bug in a migration
  2. Detects: requires a recovery script and schema verification — fails condition 3
  3. Decides: structured fix
  4. Runs discovery: maps affected records, root cause, recovery strategy
  5. Generates a spec covering the data fix plan, audit log, rollback
  6. You review the spec
  7. Generates a roadmap (recover → verify → backfill → tests)
  8. Each task is executed and reviewed before moving on
  9. Validation → approval → merge

How it differs from /n45-feat

/n45-feat /n45-fix
Quick path name Quick Feat Hot Fix
Branch prefix quick-feat/... hot-fix/...
Commit tag [quick-feat] [hot-fix]
Trigger New behavior wanted Existing behavior wrong

Otherwise: same triage, same validation, same merge.

See also