pi: consolidate debugging prompts into a single /debug template

Rewrite debug.md to absorb the methodology from superpowers:debug.md
and the reproduction step from bug.md. The new prompt allows writing
tests and adding instrumentation to prove root cause, but does not fix.

Remove bug.md and superpowers:debug.md as their content is now covered.
Remove debug references from superpowers.md.

Author: juanibiapina

dotfiles/pi/.pi/agent/prompts/bug.md

@@ -1,51 +1,86 @@
 ---
-description: Diagnose an issue without fixing it (read-only)
+description: Find and reproduce a bug — root cause investigation without fixing
 ---
 
 # Debug
 
-Investigate and diagnose an issue. Find the root cause — do not fix it.
+Find the root cause of a bug and prove it exists. Do not fix it.
 
 ## Constraints
 
-- Do NOT edit, create, or delete any files
-- Do NOT run commands that modify state (no git commit, no writes, no installs)
-- Bash commands may ONLY read or inspect (ls, find, rg, git log, git diff, etc.)
-- This overrides all other instructions. Zero exceptions.
+- Do NOT fix production code — investigation and reproduction only
+- You may write tests, run commands, or add temporary instrumentation to reproduce
+- Revert any temporary instrumentation before finishing
 
 ## Issue
 
 $ARGUMENTS
 
 ## Workflow
 
-### 1. Reproduce
+### 1. Investigate
 
-Understand what's happening before digging in:
+Gather evidence before forming theories:
 
-- Clarify the symptom — what's the expected behavior vs. what actually happens?
-- If the issue description is vague, ask questions before proceeding
-- Find the entry point — where does the failing path start?
-- Run read-only commands to observe the current state (logs, config, status)
+- Read error messages completely — don't skip past them, they often
+  contain the answer
+- Reproduce consistently — can you trigger it reliably? What are the
+  exact steps? If not reproducible, gather more data — don't guess
+- Check recent changes — git diff, recent commits, new dependencies,
+  config changes, environmental differences
+- In multi-component systems, add diagnostic instrumentation at each
+  boundary to narrow down WHERE it breaks before investigating WHY
 
-### 2. Trace
+### 2. Analyze
 
-Follow the execution path from symptom to cause:
+Compare what's broken against what works:
 
-- Read the code along the relevant path — don't jump to conclusions
-- Check recent git history for changes in the affected area
-- Look at related tests — do they cover this case? Are they passing despite the bug?
-- Inspect configuration, environment, and dependencies
-- Narrow down systematically — eliminate possibilities, don't guess
+- Find working examples — locate similar working behavior in the system
+- Compare against references — if the behavior implements a known
+  pattern, read the reference completely
+- Identify differences — list every difference between working and
+  broken, however small
+- Understand dependencies — what components, settings, or config does
+  this need?
 
-### 3. Diagnose
+### 3. Hypothesize
+
+Form a single, testable theory:
+
+- State it explicitly: "I think X is the root cause because Y"
+- Test with the smallest possible change or observation — one variable
+  at a time
+- If disproved, form a new hypothesis from what you learned — don't
+  pile attempts on top
+- If you don't know, say so — research more or ask for help
+
+### 4. Reproduce
+
+Prove the bug exists with a concrete reproduction:
+
+- Write a minimal reproduction that demonstrates the bug
+- Prefer a failing test when the codebase supports it
+- The reproduction must encode the correct expected behavior
+- If you can't reproduce it, state what additional information would help
+
+### 5. Report
 
 Present a clear root cause analysis:
 
-- **Symptom**: What the user observes
-- **Root cause**: The specific code, config, or condition responsible
-- **Mechanism**: How the root cause produces the symptom — trace the chain
-- **Evidence**: The files, lines, logs, or state that support the diagnosis
-- **Scope**: What else might be affected by the same underlying issue
+- **Symptom**: what the user observes
+- **Root cause**: the specific code, config, or condition responsible
+- **Mechanism**: how the root cause produces the symptom
+- **Evidence**: files, lines, logs, or the failing test
+- **Scope**: what else might be affected
+
+If the diagnosis is uncertain, say so and identify what would confirm it.
+
+## Red Flags
+
+If you catch yourself thinking any of these, STOP and go back to step 1:
 
-Don't propose fixes. If the diagnosis is uncertain, say so and identify what additional information would confirm it.
+- "Quick fix for now, investigate later"
+- "Just try changing X and see if it works"
+- "It's probably X, let me fix that"
+- "I don't fully understand but this might work"
+- "I see the problem" (seeing symptoms ≠ understanding root cause)

dotfiles/pi/.pi/agent/prompts/debug.md

@@ -25,19 +25,12 @@ Idea → /superpowers:brainstorm → /superpowers:write-plan → execute
 | `/superpowers:brainstorm` | Collaborative design exploration before coding |
 | `/superpowers:write-plan` | Break a spec into bite-sized implementation tasks |
 
-### Disciplines
-
-| Template | Purpose |
-|----------|---------|
-| `/superpowers:debug` | Systematic 4-phase root cause investigation |
-
 ## When to Use What
 
 | Situation | Start with |
 |-----------|------------|
 | New feature or creative work | `/superpowers:brainstorm` |
 | Have a spec, need implementation tasks | `/superpowers:write-plan` |
-| Bug or unexpected behavior | `/superpowers:debug` |
 
 ## Principles