BDD Superpowers
简体中文
BDD Superpowers is a fork of Superpowers that keeps the original skills-first software development workflow and adds behavior evaluation to the design and planning path.
The base workflow is still Superpowers: brainstorm the design, write a spec, write an implementation plan, implement with TDD, review, and verify. The change is that non-trivial behavior work now carries a horizontal behavior/control harness alongside the normal vertical implementation slices.
In practical terms: TDD still checks local implementation correctness. Behavior Evaluation and Behavior Coverage check whether the whole flow is still doing what the user wanted, even when the code is too large or too opaque for a human to inspect line by line.
This is not the official Superpowers distribution. It is a Superpowers-derived fork focused on BDD-style behavior review, pipeline-level constraints, and design-plan-code alignment.
How it works
It starts the same way Superpowers does. When you ask your coding agent to build something, it should not jump directly into code. It uses the brainstorming skill to understand what you are trying to do, explore alternatives, and turn the conversation into a reviewable design.
BDD Superpowers extends that step with a bounded behavior grill. The agent pressure-tests concrete examples, behavior boundaries, failure signals, invariants, and correction paths without turning the session into hours of exhaustive questioning. It should answer from code, docs, and existing conventions when it can, and ask the user only when the answer would change the design route.
Once the design is written, the spec can include a Behavior Evaluation section. This section is not another implementation plan. It describes what behavior must be observable, what results are expected, what signals mean the system drifted, what invariants must hold across the flow, and where to correct if the evidence fails.
After design approval, the writing-plans skill still produces a Superpowers-style implementation plan with concrete tasks, file paths, tests, and verification. When the spec contains Behavior Evaluation, the plan also includes Behavior Coverage: a short horizontal mapping from scenarios and invariants to implementation tasks and evidence. Technical-only tasks remain valid; the goal is not to force fake BDD onto every local slice.
Finally, review checks more than local test pass/fail. BDD Superpowers adds architecture ownership checks to document review and a shorter version to code review. The reviewer looks for cases where local implementation is correct but the behavior pipeline is wrong, and for cases where convenience glue, caches, wrappers, fallback paths, debug artifacts, or eval artifacts have quietly become product contract or runtime authority.
This matters because many agent mistakes are not "bad code" in isolation. They are wrong ownership: a temporary support mechanism starts deciding routing, truth, method, answer shape, read order, or policy. The reviewer asks what higher-level behavior a mechanism now controls, whether that ownership belongs there, and whether it should be thinned, moved behind a private/eval-only boundary, relocated to an explicit contract/spec layer, or removed.
What differs from upstream Superpowers
- Bounded behavior grill in brainstorming - adds targeted pressure-testing before the design is finalized, without asking dozens of low-value questions up front.
- Behavior Evaluation in specs - captures concrete examples, expected results, failure signals, invariants, observable evidence, and correction paths for non-trivial behavior changes.
- Behavior Coverage in plans - connects the spec's behavior scenarios to plan tasks and verification evidence, while allowing unrelated implementation steps to stay
technical-only.
- Design document self-review - the spec reviewer now checks for missing behavior evidence, ambiguous failure signals, weak invariants, unclear correction paths, hidden ownership, accidental architecture, and support mechanisms becoming product contract.
- Plan document review - the plan reviewer rejects fake per-task behavior coverage, checks whether horizontal scenarios are actually carried through the plan, and blocks plans that make support/eval/debug machinery into product contract.
- Code review reinforcement - code review checks flow-level drift and hidden ownership: local tests passing while the intended behavior or pipeline is not preserved, or implementation glue quietly taking over truth, method, routing, or policy ownership.
Installation
Installation differs by platform. The important rule is: install this fork, not the official Superpowers marketplace package.
When migrating from upstream Superpowers, use a clean delete-and-install flow:
