From founder-os
Diagnose and fix a bug using the SEB method (Screenshot, Error message, Before/After) plus the bisect trick for unknown regressions, gathering real evidence before guessing at a fix. This is the fuller version of /fix-bug — use directly for trickier bugs or when the quick pass doesn't find the cause.
How this skill is triggered — by the user, by Claude, or both
Slash command
/founder-os:debug-sebThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The founder can't read a stack trace, but can take a screenshot and copy
The founder can't read a stack trace, but can take a screenshot and copy error text. The job here is to force evidence collection before guessing, with a deterministic fallback for when there's no clear "before."
Collect S-E-B before touching code — don't skip to "just fix it."
Screenshot: use the playwright MCP server to capture one if the
founder can't easily grab it themselves — it's local browser automation
and explicitly "not a security boundary," so it's fine to use freely.
Error text: copied verbatim, not paraphrased — ask again if it was
paraphrased. Before/after: the last change before it broke, if
known.
If "last working state" is unknown, bisect the recent history. Don't stop after an arbitrary number of commits — search backward, testing after each step, until you isolate the actual first bad commit. A fixed 3-commit rollback can miss a regression introduced further back.
Diagnose in plain terms what went wrong before fixing — one or two sentences, no code-level jargon the founder can't use.
Fix only the isolated cause, not surrounding code, to avoid introducing a second regression while chasing this one.
Verify with /verify-path before declaring it fixed, confirming
the step-1 repro no longer reproduces.
/refactor-safely instead.npx claudepluginhub p/rahlplx-founder-os-founder-os-2Guides completion of development work by verifying tests, detecting environment, and presenting structured options for merge, PR, or cleanup.
Enforces test-driven development: write failing test first, then minimal code to pass. Use when implementing features or bugfixes.
Guides creation and editing of skills using test-driven development with pressure scenarios and subagents to verify agent compliance.