The Superpowers Control Loop
The first three moves in obra/superpowers form a single control loop: the bootstrap changes what the agent notices, brainstorming changes what the request means, and approval changes what the agent is authorized to do. This chapter connects those moves so the reader can use them as one mental model rather than as separate rituals. The judgment it supports is practical: an approved design is a meaningful reduction in uncertainty, but it is not yet a safe place to write code.
Three gates, three kinds of uncertainty
A request can fail before implementation in at least three different ways. The agent may not notice that a process applies. It may notice the process but misunderstand the desired outcome. Or it may understand and receive approval yet still have no safe, precise boundary for changing the project. Superpowers addresses these failures in order, because a later gate cannot reliably repair an earlier omission.
The bootstrap addresses attention. It tells the agent to check for a relevant process skill before answering, asking for clarification, exploring files, or taking implementation action. That rule matters because an agent's first move sets the direction of the session. If it begins by editing the nearest function, it has already made assumptions about scope and design. The bootstrap does not decide the feature itself; it makes the process question visible before the feature question consumes the available attention.
Brainstorming addresses meaning. It classifies the request as a spike, bounded change, or architectural effort, then applies the smallest path that can expose the decisions involved. A feasibility spike is not treated like a new subsystem. A compact change to an existing flow does not automatically require a long specification. A multi-part system does not get compressed into one vague promise simply because the user stated it in one sentence. The classification makes the hidden shape of the work discussable.
Approval addresses authority. The agent may explore, recommend, and present a design, but it cannot treat its interpretation as permission to implement. The person directing the work confirms the design or sends it back for revision. This is true even when the design is only a few sentences. The artifact becomes shorter; the change in authority does not.
These gates are related but not interchangeable. A perfectly delivered bootstrap cannot tell the agent which product decision the user intended. A thoughtful design cannot prove that the agent received the startup guidance that was meant to trigger it. An approval cannot protect a branch or supply the task-level detail another implementer will need. The loop works because each gate changes a different variable.