alebgl77 Superpowers — Skill Forge
"14-skill power pack"
When to use
- End-to-end feature work that deserves discipline — "let's build this properly, not vibe-code it"
- A bug that resists poking — "debug this systematically", "it fails randomly and I'm lost"
- Pre-merge and pre-ship gates — "review my diff", "run a security pass", "are we ready to release?"
- After an incident — "write the postmortem"
- Any single phase named outright — spec it, plan it, refactor it, profile it, document it
The 14 protocols
| # | Protocol | Core move |
|---|---|---|
| P1 | Brainstorm | Generate 3+ approaches, score against constraints, pick one on the record. |
| P2 | Spec | Acceptance criteria and non-goals written before any code. |
| P3 | Plan | Ordered steps, each independently verifiable. |
| P4 | Scaffold | Skeleton with tooling wired — lint, test runner, entry point, CI hook. |
| P5 | TDD | Red-green-refactor: failing test first, minimal pass, then clean. |
| P6 | Systematic debugging | Reproduce → isolate → hypothesize → fix → regress. |
| P7 | Refactoring | Behavior-preserving change under green tests, one move at a time. |
| P8 | Code review | Line-level and design-level pass — correctness, security, perf, readability. |
| P9 | Performance pass | Measure first, profile the hot path, fix, re-measure. |
| P10 | Security pass | Inputs, authn/z, secrets, dependencies, injection surfaces. |
| P11 | Docs | README, API reference, runbook — written from the reader's seat. |
| P12 | Git hygiene | Small atomic commits, imperative messages, clean history. |
| P13 | Release checklist | Version, changelog, tests green, rollback plan, ship, verify live. |
| P14 | Postmortem | Blameless timeline, root cause, action items with owners. |
Workflow
- Identify the task's phase: idea, build, break/fix, ship, or learn.
- Pick the matching protocol(s) from the table and announce the pick — "Running P6 — systematic debugging."
- Execute the protocol as concrete steps. P6, for example: reproduce deterministically, isolate by bisecting code/data/env, state one falsifiable hypothesis, fix, add a regression test.
- For a full feature, chain: P1 → P2 → P3 → P4 → P5 → P8 → P11 → P12 → P13. Skip a link only by saying so and why.
- End every protocol with an artifact — spec file, failing-then-passing test, review notes, changelog — never just narrative.
- If the task changes phase mid-flight (the build surfaces a bug), switch protocols explicitly; don't blur two into mush.
- Log each run in the output format below and hand the next protocol its inputs.
Output format
## Protocol run — P<n> <name>
Phase: <idea | build | fix | ship | learn>
Trigger: <the ask, one line>
Steps executed:
1. <step> → <result>
2. <step> → <result>
Artifact: <path or inline block>
Verdict: PASS | FAIL — <one-line reason>
Next: P<n> <name> | done
Quality bar
- Protocol named before work started, not retrofitted after
- Every run produced a concrete artifact, not just prose
- P5/P6 runs end with a test that fails without the fix and passes with it
- Feature chains hit at least P2, P5, and P8 — or the skip is justified in writing
- Verdicts are earned: FAIL reported as FAIL, never softened to "mostly works"
Example
Ask: "The login test is flaky — fix it properly."
Run P6: reproduced 5x (fails ~40%), isolated to the token-expiry check reading the real clock, hypothesis "clock skew between test container and issuer" confirmed by freezing time, fixed with an injected clock, regression test added that fails on the old code. Artifact: tests/auth/token-clock.spec.ts. Verdict PASS. Next: P12, one atomic commit.
Credits
Inspired by obra/superpowers.