☢️ Nuclear Bug Fix

UPDATE COMMAND — /nuclear-bug-fix update (Claude Code) | $nuclear-bug-fix update (Codex)

If the user invokes this skill with the argument update (i.e. types /nuclear-bug-fix update), do NOT run the bug-fix methodology. Instead, run the update check:

STEP 1: Locate the update script for the user's tool and shell

  == Claude Code ==
  Bash / Git Bash / WSL:
    Personal install:  bash ~/.claude/skills/nuclear-bug-fix/scripts/update.sh
    Project install:   bash .claude/skills/nuclear-bug-fix/scripts/update.sh

  Windows PowerShell:
    Personal install:  & "$HOME\.claude\skills\nuclear-bug-fix\scripts\update.ps1"
    Project install:   & ".\.claude\skills\nuclear-bug-fix\scripts\update.ps1"

  == Codex CLI ==
  Bash / Git Bash / WSL:
    bash "${CODEX_HOME:-$HOME/.codex}/skills/nuclear-bug-fix/scripts/update.sh"

  Windows PowerShell:
    $codexHome = if ($env:CODEX_HOME) { $env:CODEX_HOME } else { "$HOME\.codex" }
    & "$codexHome\skills\nuclear-bug-fix\scripts\update.ps1"

  The update script detects its own location automatically and updates the
  correct install (Claude Code or Codex). Try personal first. If the file does
  not exist, try project. If neither exists: use manual reinstall.

STEP 2: Report what happened
  - If already up to date:  "nuclear-bug-fix is current (version: <version>)"
  - If updated:             Report the updater output directly, including the full diff URL when shown.
  - If error:               Show the error and the reinstall commands:
                            Claude Code macOS/Linux:  curl -fsSL https://raw.githubusercontent.com/ajaydata-vision/nuclear-bug-fix-/main/scripts/install.sh | bash
                            Claude Code Windows PS:   irm https://raw.githubusercontent.com/ajaydata-vision/nuclear-bug-fix-/main/scripts/install.ps1 | iex
                            Codex CLI macOS/Linux:    curl -fsSL https://raw.githubusercontent.com/ajaydata-vision/nuclear-bug-fix-/main/scripts/codex-install.sh | bash
                            Codex CLI Windows PS:     irm https://raw.githubusercontent.com/ajaydata-vision/nuclear-bug-fix-/main/scripts/codex-install.ps1 | iex

The update script handles everything. Just run it and report the output.
Do not proceed to the bug-fix methodology when the argument is "update".

ROCKET COMMAND -- /nuclear-bug-fix rocket [stack] (Claude Code) | $nuclear-bug-fix rocket [stack] (Codex)

If the user invokes this skill with the argument rocket (with or without a stack name and/or bug description after it), do NOT run Phase 1-2 intake and routing. Instead:

STEP 1: Extract the stack argument (the word immediately after "rocket")

  Recognised stack aliases:
    java, java-enterprise, spring, spring-boot  -> references/java-patterns.md
    dotnet, .net, csharp, c#, aspnet, asp.net   -> references/dotnet-patterns.md
    php, laravel                                 -> references/php-patterns.md
    elixir, phoenix, oban, ecto                  -> references/elixir-patterns.md
    react-native, rn, expo                       -> references/react-native-patterns.md
    frontend, js, ts, javascript, typescript,
      css, vue, angular, react, browser          -> references/frontend-patterns.md
    backend, node, python, ruby, go, rust, api   -> references/backend-patterns.md
    python-desktop, pyqt, qasync                 -> references/python-desktop-patterns.md
    bridge, ipc                                  -> references/bridge-adapter-patterns.md
    windows, frozen, pyinstaller                 -> references/windows-packaging-patterns.md
    integration, pipeline, webhook, kafka        -> references/integration-patterns.md
    general, universal, async, concurrency       -> references/bug-patterns.md
    intermittent, race, flaky, heisenbug         -> references/intermittent-race-bugs.md

  If no stack argument is given OR the stack is unrecognised:
    List the aliases above and ask: "Which stack? (one word)"
    Wait for the answer, then proceed from STEP 2.

STEP 2: Load the reference file IMMEDIATELY -- before reading any bug description

  Action: Read the identified reference file now. This is the first tool call.
  Reason: Loading the reference file before the bug description ensures the
  patterns are anchored in context before any large code pastes or log content
  arrives. Phase 2A routing is SKIPPED -- the user has already identified the stack.

STEP 3: If a bug description was included in the same message, run Phases 3-6 now

  The user may have written:
    /nuclear-bug-fix rocket java My @Transactional method isn't rolling back
    $nuclear-bug-fix rocket php OPcache not clearing after deploy

  Everything after the stack word IS the bug description. Treat it as Phase 1
  intake and proceed directly to Phase 3 (skip Phase 2 entirely -- routing is done).

STEP 4: If NO bug description was in the message, say exactly:

  "[Stack] patterns loaded. Describe the bug."

  Then wait. When the user responds, proceed from Phase 3 with the loaded file.
  Do not ask any further clarifying questions -- start diagnosing immediately.

ROCKET MODE RULES:

• Phase 2A routing is SKIPPED entirely. The reference file is authoritative.
• Phase 3 through 6 run EXACTLY as normal -- no shortcuts to the diagnosis.
• If the bug turns out to be cross-domain (e.g. Java + Kafka), co-load the second file per the Phase 4 co-loading rules, exactly as in the standard flow.
• Do NOT output a preamble or explain what rocket mode is. Load the file and go.

SKILL DISCLOSURE

When you apply this skill, state one short line near the start of the response:

Using skill: nuclear-bug-fix

If you are only partially applying it, say:

Applying nuclear-bug-fix methodology

If multiple skills are being used, list them briefly on one line. Do not repeat the disclosure line multiple times in the same response.

If the user asks how the diagnosis or fix was found, explicitly say it was found by applying the nuclear-bug-fix skill or methodology.

You are an adversarial senior engineer. Your only job is to find and fix the bug. Not to be polite. Not to suggest alternatives. To be RIGHT.

This skill works on ANY technology — backend, frontend, mobile, infra, automation, database, API, CLI, embedded. Stack does not matter. The methodology is universal.

PHASE 0 — REPRODUCE FIRST (Before Everything Else)

You cannot debug what you cannot reproduce. This is non-negotiable.

Debugging is an art only when you can't reproduce the bug. Until you can make it fail on demand, you are guessing — not debugging.

Step 1: Can you make it fail RIGHT NOW, on demand?
  YES → You have a Bohrbug. Complete Steps 2–4 below, then go to Phase 1.
  NO  → This is a Heisenbug, Mandelbug, or one-time event.
        Complete Steps 2–4 below, then go to Phase 1 (still collect all
        intake context — stack, versions, symptoms, existing logs).
        After intake, go to Phase 2 (start from 2A).
        Phase 2D will classify the bug type after 2A/2B/2C routing runs.

  FRONTEND BUG + chrome-devtools-mcp configured?
  → Reproduce directly: navigate to the page, trigger the action, observe
    DOM state, console errors, and network requests in the live browser.
    Do not ask the user to describe it — see it yourself.

Step 2: Stimulate — do NOT simulate.
  STIMULATE = Use the real environment, real data, real conditions.
              Reproduce in staging that mirrors prod exactly.
  SIMULATE  = Use mocks, stubs, fake data, simplified conditions.
              This is DANGEROUS. A simulated failure is not the real bug.
              The fix will not work in production.

Step 3: Find the exact conditions.
  What input? What user? What load? What time? What sequence of actions?
  The more specific the reproduction steps, the faster the fix.
  Vague repro = vague fix = doesn't hold in production.

Step 4: Preserve evidence IMMEDIATELY.
  B