Files
FabledScribe/plugin/skills/systematic-debugging/SKILL.md
T
bvandeusen 88106309f4
CI & Build / Python lint (push) Successful in 2s
CI & Build / TypeScript typecheck (push) Successful in 34s
CI & Build / Python tests (push) Successful in 49s
CI & Build / Build & push image (push) Successful in 1m12s
feat(plugin): add 4 Scribe-native process-skills (restore superpowers gap)
Superpowers was uninstalled but its replacements were never built (only
using-scribe shipped) — a live functional hole. Author the 4 the operator
wants back, each integrated with Scribe's toolset rather than generic copies:
- writing-plans     -> start_planning / kind=plan task, not local .md
- systematic-debugging -> capture issue (symptom->cause->fix, tag issue) on resolve
- verification      -> log results to the task work-log; honest done
- brainstorming     -> recall prior thinking first; capture the decision note

Skipped TDD + receiving-code-review per operator (well-covered by Claude/them).
Manifest + using-scribe list now advertise only the 4 that ship. Remove the
stale docs/superpowers/*.md reference in _INSTRUCTIONS (superpowers is gone).
Plugin 0.1.6 -> 0.1.7.

Refs plan 821 (Phase 3 of 755).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-13 20:52:34 -04:00

1.8 KiB

name, description
name description
systematic-debugging Use when diagnosing a bug, failure, or unexpected behavior — investigate methodically instead of guessing. Triggers on "why is this failing/breaking", a stack trace, a flaky test, or any "it should work but doesn't". On resolution, capture the issue in Scribe so it isn't re-debugged from scratch.

Systematic debugging

Find the root cause, don't patch the symptom. Move one step at a time — a guessed fix that "seems to work" often just moves the bug somewhere else.

Recall first

Before digging in, search Scribe for the symptom — a prior issue note may already hold the cause and the fix. Don't re-debug what's already solved.

The loop

  1. Reproduce — get a reliable, minimal repro. If you can't reproduce it, you can't confirm you fixed it.
  2. Observe — read the actual error / log / state. Don't theorize past the data you have.
  3. Isolate — narrow to the smallest failing case; change one variable at a time so each result actually means something.
  4. Hypothesize → test — state the single most likely cause, then test that one thing. Confirm or rule it out before moving on; don't stack guesses.
  5. Root cause — keep going until you can explain why it failed, not just what made it stop. "It works now" without "because X" is unfinished.
  6. Fix + verify — fix the cause, then re-run the repro to confirm it's gone.

Capture the issue (so it's findable)

When resolved, record it in Scribe (create_note, tag issue): symptom → root cause → fix → how it was verified. Even a problem fixed in passing is worth two lines — that's how the next person (or you) avoids re-deriving it. If the fix was tracked as a task, log the resolution there and set it done.