Skip to content
Back to skills

Spectra Debug

ASecurity

Systematically debug a problem using a four-phase workflow

  • 38 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added May 26, 2026
code-qualitygorailsdebugginggit

Works with

  • cli

Security analysis

A100/100

Scanned May 27, 2026

npx -y skills add PsychQuant/che-ical-mcp --skill spectra-debug --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Spectra Debug?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Spectra Debug
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/psychquant-spectra-debug/badge)](https://www.skillsdirectory.com/skills/psychquant-spectra-debug)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: spectra-debug
description: "Systematically debug a problem using a four-phase workflow"
license: MIT
compatibility: Requires spectra CLI.
metadata:
  author: spectra
  version: "1.0"
  generatedBy: "Spectra"
---

Systematically debug a problem using a four-phase workflow.

**This skill enforces debugging discipline.** No guessing, no random changes, no "let me try this." Every step is deliberate and evidence-based.

**Input**: The argument after `$spectra-debug` describes the bug or unexpected behavior. Examples:

- `$spectra-debug the search returns duplicate results`
- `$spectra-debug crash on startup after upgrading`
- `$spectra-debug file watcher misses rename events`

---

## The Three-Attempt Rule

**Maximum 3 fix attempts per hypothesis in Phase 4 (Fix).** Phases 1-3 (Reproduce, Isolate, Root Cause) are investigation — they do not count toward this limit. If your third fix attempt fails:

1. **Stop fixing**
2. Document what you tried and why it failed
3. Question your hypothesis — is the root cause what you think it is?
4. Research alternatives or try a completely different angle

Do NOT keep trying variations of the same approach. That's a loop, not debugging.

---

## Phase 1: Reproduce

Before anything else, make the bug happen reliably.

- **Find the exact steps** to trigger the bug
- **Identify the expected vs actual behavior** — be precise
- **Determine if it's consistent** — does it happen every time? Only on certain input?
- **Simplify the reproduction** — strip away everything that's not essential

If you can't reproduce it, you can't debug it. Gather more information before proceeding.

---

## Phase 2: Isolate

Narrow down where the bug lives.

- **Binary search the codebase** — which module, which function, which line?
- **Check inputs and outputs** — at each boundary, is the data correct?
- **Add targeted logging** — not everywhere, just at decision points
- **Use git bisect** when the bug is a regression — find the exact commit that introduced it

Goal: pinpoint the exact location where behavior diverges from expectation.

---

## Phase 3: Root Cause

Understand WHY it's broken, not just WHERE.

Ask these questions:

- What assumption is being violated?
- What changed that made this start failing?
- Is this a symptom of a deeper issue, or the actual problem?
- Are there other places with the same pattern that might also be affected?

**Don't stop at the first explanation.** Verify your hypothesis:

- Can you predict the bug's behavior based on your theory?
- Does your theory explain ALL the symptoms, not just some?
- Can you construct a test case that proves the root cause?

---

## Phase 4: Fix

Now — and only now — fix the bug.

1. **Write a failing test** that reproduces the bug. If `tdd: true` is set in `.spectra.yaml`, fetch TDD instructions via `spectra instructions --skill tdd` and follow the Red-Green-Refactor cycle
2. **Make the minimum change** to fix the root cause — not the symptoms
3. **Run the test** — confirm it passes
4. **Run the full test suite** — ensure no regressions
5. **Check related code** — if this pattern exists elsewhere, fix those too

---

## Rationalization Table

| What You're Thinking                      | What You Should Do                               |
| ----------------------------------------- | ------------------------------------------------ |
| "I bet it's this, let me just change it"  | Reproduce first. Verify your hypothesis          |
| "Let me add some prints everywhere"       | Add targeted logging at specific boundaries      |
| "It works on my machine"                  | Find what's different in the failing environment |
| "Let me try reverting this change"        | Use git bisect to find the actual cause          |
| "The fix is obvious, I don't need a test" | The fix is wrong. Write the test                 |
| "Let me just restart the service"         | That hides the bug. Find the root cause          |
| "Maybe if I just clear the cache..."      | Understand why the cache was wrong               |

---

## Guardrails

- **Don't guess** — Every change must be based on evidence
- **Don't fix symptoms** — Find and fix the root cause
- **Don't skip the test** — Phase 4 always starts with a failing test
- **Don't power through** — After 3 failed attempts, stop and reassess
- **Do keep notes** — Document what you tried, what you found, what you ruled out
- **Do check broadly** — A bug in one place often means the same bug exists elsewhere

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.