From Jesse Vincent's Superpowers
Which skills fit
QCB's workflow?
Superpowers is a coding agent workflow system with 14 skills. Not all of them apply to QCB's web design business — here's the honest breakdown.
Source: github.com/obra/superpowers
Why TDD DOES apply to QCB
QCB is moving from services (one-off website builds) toward products (SaaS tools, templates, info products).
Once you have paying customers, silent bugs are dangerous. A $29/mo invoice generator that returns wrong data — or a template builder that breaks on new uploads — loses trust fast.
TDD means: you find out something broke the moment it happens, not when a customer emails you.
For Cloudflare Workers, SaaS tools, template scripts — tests catch regressions before they ship. That's the shift from "cross your fingers" to "ship with confidence."
"Ask before building"
Activates before any creative work. Asks questions one at a time to refine ideas, explores alternatives, presents design in chunks for validation. Saves a design doc before touching code.
Where it fits QCB:
Every client project. Before starting a site, clarify the goal, audience, and scope. Gets client buy-in on design before wasting time building the wrong thing.
"Two-stage review after each task"
Dispatches a fresh subagent per task. After each task: spec compliance review first, then code quality review. Keeps subagents focused and context clean.
Where it fits QCB:
Already using subagents. This formalizes the review step — spec check, then quality check. Prevents sloppy code from accumulating across long builds.
"Bite-sized tasks with exact file paths"
Breaks work into tasks small enough for an "enthusiastic junior engineer" to follow. Every task has exact file paths, complete code, and verification steps. Emphasizes DRY, YAGNI, TDD.
Where it fits QCB:
Before building any product (SaaS tools, template pipelines, Workers). Gets everything documented so if you switch agents mid-project, nothing falls through the cracks.
"Red, green, refactor"
Write the failing test first. Watch it fail. Write minimal code to pass. Delete code written before tests. The last step is the most important — no "I'll add tests later."
Where it fits QCB:
SaaS tools (invoice gen, meeting notes, monetization tracker). Cloudflare Workers. Any product with API logic or data transforms. Essential once you have paying customers.
"Review early, review often"
Dispatches a code-reviewer subagent to catch issues before they cascade. Reviewer gets precisely crafted context — never your session's history. Keeps your own context clean for continued work.
Where it fits QCB:
Before deploying anything critical — new products, major site changes, Worker updates. Catches issues before they hit production.
"Evidence before assertions"
Claiming work is complete without running verification is dishonesty. Requires running actual verification commands and confirming output before claiming success.
Where it fits QCB:
Before any deployment. "Looks good" is not verification. Running the actual tests, checking the actual URL, confirming the actual output — every time.
"Root cause, not symptoms"
4-phase root cause process. Random fixes waste time and create new bugs. Quick patches mask underlying issues.
Where it fits QCB:
When something breaks in production. Not for everyday web builds, but invaluable when a Worker fails or a site goes down mysteriously.
"Clean wrap-up, clear options"
Presents structured options for merge, PR, or discard after tasks complete. Verifies tests, handles cleanup of worktree.
Where it fits QCB:
Useful when building multi-step products with git branches. For simple one-off site builds, probably overkill.
"Technical rigor, not emotional performance"
Requires technical evaluation, not performative agreement or blind implementation of feedback. Verifies before accepting suggestions.
Where it fits QCB:
When external reviewers give feedback on QCB code. Helps separate useful critique from bad advice.
"Isolated parallel branches"
Creates isolated workspaces on the same repo for parallel branch development. Smart directory selection and safety verification.
Why skip for QCB:
QCB projects are typically one-off site builds, not long-running parallel feature branches. Adds complexity without value for our workflow.
"Create new skills with TDD"
Applies TDD methodology to creating process documentation. For building new skills following best practices.
Why skip for QCB:
Good in theory, but we already have a skill creation workflow. Not a priority right now.
"Intro to the skills system"
Establishes how to find and use skills, requiring Skill tool invocation before any response including clarifying questions.
Why skip for QCB:
We don't use Superpowers as a full system — just pulling specific skills. The intro skill isn't needed.
"Batch execution with checkpoints"
Loads a plan, reviews critically, executes all tasks, reports when complete. Similar to subagent-driven-development but without subagent isolation.
Why skip for QCB:
subagent-driven-development covers this better. No need for both.
"Run agents concurrently"
Dispatch 2+ independent agents for tasks without shared state or sequential dependencies.
Why skip for QCB:
subagent-driven-development already handles concurrent task execution. Duplicative for our needs.