Superpowers Planning Execution Workflow: How Brainstorming, Writing-Plans, and Executing-Plans Chain Together

The Gap Between “Good Idea” and “Shipped”

Most agent work does not fail inside a step. It fails between steps. The idea was fine; the implementation drifted. The plan was fine; nobody ran it. The output shipped; nobody checked it against what was asked. The Superpowers library treats this gap as a structural problem with a structural fix: a three-skill pipeline in which brainstorming sets the scope, writing-plans defines the tasks, and executing-plans delivers the result — each skill ending not with a shrug but with an explicit handoff to the next.

This article traces the whole superpowers planning execution workflow end to end. The case study is pleasingly self-referential: the nineteen-article series this page belongs to — fourteen skill deep-dives and five theme articles — was scoped, planned, and executed with this exact chain, and the plan file that generated this article is still on disk, checkboxes and all. A second example, the SYNAS Docker audit, shows the same chain on production infrastructure, where a wrong turn is an outage rather than a re-draft.

The Chain at a Glance

Each skill in the chain answers a different question, produces a different artifact, and enforces a different gate. Confusing the three is the root cause of most skipped steps:

Notice that the deliverables are documents, but the product of each stage is the decision it locks in. The design doc freezes intent. The plan freezes decomposition. Execution produces evidence. Nothing in the chain is writing for writing’s sake: every artifact exists to be the input of the next stage.

Step One: Brainstorming Sets the Scope

The brainstorming skill triggers on any non-trivial task — features, configuration, research, even content series — and opens with one of the strictest rules in the library:

<HARD-GATE>
Do NOT invoke any implementation skill, write any code,
execute any plan, or take any action until you have
presented a design and the user has approved it.
This applies to EVERY non-trivial task regardless of
perceived simplicity.
</HARD-GATE>

Behind the gate is a checklist, not a mood: explore the current state (files, docs, recent history); ask clarifying questions one at a time, multiple choice where possible; propose two or three approaches with trade-offs and a recommendation; present the design in sections scaled to their complexity, getting approval after each one; write the validated design to .hermes/plans/; run a spec self-review (placeholder scan, internal consistency, scope check, ambiguity check); wait for the user to review the written spec; then — only then — invoke writing-plans.

Two details do most of the work. First, the scope check: if the request secretly describes several independent subsystems, brainstorming flags and decomposes it before a plan is ever attempted, because a single plan spanning unrelated systems is unreviewable. Second, the skill’s named anti-pattern — “this is too simple to need a design” — with its rebuttal on the record: “Simple changes have assumptions. A two-minute design catches them.” The design may be three sentences for a genuinely simple task, but it must be presented and approved. Scope is not a vibe the implementer infers; it is an approved document the implementer reads.

Step Two: Writing-Plans Defines the Tasks

Brainstorming produced the what. Writing-plans turns it into a document addressed to a specific fictional reader: “an engineer who has not seen this codebase or this spec.” Everything the plan must state, it states exactly; everything the implementer can reasonably decide, it leaves open. The document opens with a fixed header — Goal in one sentence, Architecture in two or three, Tech Stack, and a link to the spec this plan implements — followed by two sections that often get skipped in ad hoc plans and are load-bearing here:

• Global Constraints — the spec’s project-wide requirements (version floors, naming rules, word counts, newline style) copied verbatim, one line each. Every task implicitly inherits this section, so constraints are written once and cannot silently drift per task.
• Review Focus — the failure modes the spec implies but no task’s tests exercise yet, named up front, each later pinned to a test in the task that owns the code.

Below the header, the plan is decomposed into right-sized tasks: the smallest unit that carries its own test cycle and is worth a fresh reviewer’s gate. Each task names its exact files, declares what it consumes and produces at the interface level (so a subagent seeing only its own task still knows the signatures its neighbors rely on), and breaks the work into checkbox steps where “each step is one action with a checkable result.” A step is done when the implementer can write exactly one reasonable thing from it — unambiguous, not complete.

Before handoff, the author runs a self-review against the spec: coverage (can every requirement be pointed at a task?), step scan (any line that decides nothing is a gap; any body the signature already determines is a transcript), type consistency across tasks, and proportion — the skill’s sharpest line: “A plan longer than the code it describes has written the code instead.” The stage ends with the execution handoff: the human reviews the plan and picks a method — subagent-driven or native execution — with a recommendation argued from the plan itself.

Step Three: Executing-Plans Delivers

Executing-plans begins with a step people do not expect: read the plan and argue with it. The executor loads the file from disk, reviews it critically, and raises concerns with the user before starting work — a plan approved yesterday may have a hole only visible on execution-side reading. Then the loop: for each task, execute it (directly, or via a focused delegate_task subagent whose brief carries the task’s files, interfaces, and verification command verbatim), run the verifications the plan specifies, and confirm completion before moving on. After each logical group of tasks, a checkpoint review re-runs the plan’s verification commands and checks the work against the spec.

Two rules separate this from ordinary “doing the tasks.” The first is the stop list: blockers, critical gaps, unclear instructions, or verification failing three or more times all mean stop and ask — don’t guess. Silent improvisation is how a plan quietly becomes a different project. The second is the deviation record: whatever actually happened versus what the plan said gets written down alongside the plan, and on completion the run ends by handing off to finishing-a-development-branch, not by simply declaring victory. An unfinished task stays visibly unfinished; a done task has its verification output attached. “Done” is an evidenced state, never a mood.

Real Example: The Chain That Wrote This Series

The request that produced this page was one sentence long: an article series about the Superpowers skills for byteittech.com. That is exactly the kind of request that goes sideways without the chain — nineteen articles, no shared conventions, one agent’s taste multiplied by nineteen moods.

Brainstorming ran its dialogue and locked the decisions: fourteen deep-dive articles (one per skill) plus five theme articles (one per cross-skill workflow, including the one you are reading); audience split between engineers and general tech readers; every article a self-contained HTML file on the existing site template; examples drawn from real sessions rather than invented scenarios. The approved design became the input to the next gate.

Writing-plans emitted docs/superpowers/plans/2026-11-06-article-series.md, and its header is worth quoting verbatim because it shows the format doing real work:

**Goal:** Write and deploy an article series about the
14 Superpowers skills and 5 cross-skill themes for
byteittech.com.

## Global Constraints
- Each deep-dive article: 1,200-2,000 words
- Each theme article: 1,500-2,500 words
- Each article needs: meta description, og:image,
  internal links to other articles in the series
- Newline style: LF (verified on live site)

The Review Focus section contains the instruction shaping this very theme article: “Theme articles must show at least 3 skills interacting, not just list them.” Task 2 then breaks the writing into per-article steps, and Step 3’s outline for the executing-plans article names its real example: the SYNAS Docker status report. The plan is even self-aware about its own recursion — Task 2, Step 2’s outline for the writing-plans deep-dive says: “Real example: the article series plan we’re writing right now.” The chain is its own case study, and the plan file sits in the repo as the receipt.

Executing-plans then ran the tasks with verification attached at every level: each article’s word count measured against its band, meta and og tags checked in the rendered head, internal links resolved, the site’s LF newline convention verified against the live page. When this page was written, the checker asked one question from the plan’s Global Constraints — is it between 1,500 and 2,500 words? — and counted, rather than estimating.

The same chain on production metal: the SYNAS Docker audit ran brainstorming’s read-only survey gate (no state-changing command existed until the design was approved), a plan covering container health, service inventory, storage and network topology, and an execution phase that produced a status report with evidence in every row: 32 containers across 26 networks, all healthy, zero restarts in 48 hours. The most valuable output of a planning chain is often an absence — nothing restarted, nothing “tidied,” nothing guessed.

What Happens When You Skip a Step

The chain’s shape is best appreciated from its failure modes, because each is common enough to have its own rationalization:

Brainstorming without planning is vague implementation. A design that says “nineteen articles on the existing template” has settled intent, not decomposition. Without writing-plans’ Global Constraints, nineteen articles written across nine sessions drift to nineteen conventions; the word-count bands never exist, so nothing can be checked against them; and each subagent dispatched to “write the Docker article” resolves the plan’s ambiguities its own way. Ambiguity is cheap when it surfaces in a design question and ruinously expensive when it surfaces as nineteen subtly inconsistent deliverables.

Planning without executing is the plan that never ships. This is the most comfortable failure, because writing the plan feels like the work: it is intellectually satisfying, carries no verification burden, and produces a document you can point at. A plan sitting in docs/ delivers nothing. Executing-plans exists precisely because the distance between a checkbox and a checked box is where projects die — and because only at execution do you discover the plan’s last, real bugs, which is why it mandates critical review and a deviation record instead of blind transcription.

Skipping straight to execution — both gates gone at once — is the classic confident-wrong build. The brainstorming skill books the line for it under Common Rationalizations: “User wants it done fast” / “Fast wrong work is slower than fast right work.” The math is unforgiving: the design dialogue costs minutes; the rewrite it prevents costs the whole implementation, plus the review, plus the apology.

The Handoff Is the Product

Look again at the seams of the chain, because that is where its engineering lives. Brainstorming’s final checklist item is literally “Transition to implementation — invoke writing-plans.” Writing-plans ends by presenting the human a binary choice of execution method and binding the chosen skill to the plan’s header. Executing-plans ends by invoking finishing-a-development-branch. No stage ever asks “so… what should happen next?” The answer is encoded.

The artifacts are the interfaces between stages, in the same sense function signatures are interfaces between modules. The design doc is the plan’s input; the plan is the executor’s brief — paste a task block into a subagent and it has its files, its interfaces, and its verification command with nothing to interpret. That is also what makes the chain parallel-safe: a fresh subagent that has never seen the conversation can execute one task correctly, because the handoff carries everything the conversation knew. Context does not survive between sessions; documents do. The superpowers planning execution workflow is, at bottom, a protocol for making decisions durable enough to outlive the chat that made them.

Related Deep Dives in the Series

• Superpowers Brainstorming: The Design-First Gate for AI Agents — the HARD-GATE, the one-question-at-a-time dialogue, and how SYNAS’ audit approach was shaped before a single command ran.
• Superpowers Writing Plans: A Deep Dive — plan headers, task right-sizing, checkbox steps, and the self-review that catches “TBD” before a subagent does.
• Superpowers Executing Plans: A Deep Dive — the execute-verify-checkpoint loop and the stop-don’t-guess rules that ended in the SYNAS status report.
• Superpowers Using Superpowers: The Bootstrap Skill — the meta-skill that routes a task into this chain in the first place.

This theme article is one of five in the cross-skill series, each tracing how multiple skills interact on a real job. The planning→execution chain is the spine the other four hang from: parallelism only makes sense once a plan has drawn independent tasks, and verification only has meaning once a design has defined what “correct” was supposed to be.