writing-plans

superbeads:writing-plans

Announce: Using superbeads:writing-plans.

Thin wrapper over superpowers:writing-plans. Runs its full decomposition discipline unchanged and intercepts three specific steps inside that dialogue. Do not restate the override contract or field mapping here — see skills/using-superbeads/SKILL.md.

Override active from the start. While running superpowers:writing-plans: do NOT write any plan file under docs/superpowers/; do NOT offer the subagent-driven vs inline-execution choice; and do NOT invoke superpowers:executing-plans. These are replaced by the beads steps below.

Calibration — task design fields for markdown deliverables: superpowers:writing-plans says "show complete code in every step." For THIS plugin's deliverables (markdown skill/command/hook files), each task's design field must capture required STRUCTURE + key content + exact verification commands — not an entire ghost-written copy of the target file. Right-size tasks accordingly.

Step 1 — Run superpowers:writing-plans

Invoke superpowers:writing-plans via the Skill tool. Execute its full checklist as written:

• Scope check (split if needed)
• Map file structure and decomposition
• Define bite-sized TDD tasks (failing test → implement → pass → commit)
• Apply No Placeholders discipline
• Self-review (spec coverage, placeholder scan, type consistency)
• (intercept) Save plan to docs/superpowers/plans/ → see Step 2
• (intercept) Execution handoff → see Step 4

Step 2 — Intercept: persist plan → child tasks (replaces "Save plan file")

Do NOT write to docs/superpowers/. Instead, immediately after self-review (at the point superpowers would save the plan file), produce the task breakdown — one task per plan Task (type=task), with each task's bite-sized steps destined for its design field, and blocking dependencies — then materialize via /superbeads-materialize MODE B.

Key correctness point: the epic already exists (created by superbeads:brainstorming). Attach every task as a child of that existing epic — do NOT create a new epic. On the primary per-task path that means --parent <epic-id>; on the graph path it means a to_id parent-child edge. Exact syntax and caveats are in commands/superbeads-materialize.md.

The PRIMARY path in MODE B creates tasks one at a time using --design-file, which reliably stores the design field. The graph path (bd create --graph) is a secondary bulk-wiring optimization and does NOT carry design content — if it is used, design must be set afterward via bd update <id> --design-file <file>. Mechanism details and caveats are in commands/superbeads-materialize.md; do not restate them here.

Step 3 — Intercept: review gate → bd show (replaces "User reviews plan file")

Direct the user to review the persisted tasks:

"Plan materialized. Run bd list --parent <epic-id> to see all child tasks, and bd show <task-id> to inspect any individual task. Let me know if you want changes before we move to execution."

Wait for approval. If changes are requested, update tasks via /superbeads-materialize and re-check for completeness.

Step 4 — Intercept: handoff → superbeads:executing-plans (replaces "Execution handoff")

Do NOT invoke superpowers:executing-plans or superpowers:subagent-driven-development. Offer superbeads:executing-plans for epic <epic-id> (the same epic id received from superbeads:brainstorming) — pass that id explicitly so the execution loop can scope all commands to this epic's children.

Scratch safety-net

If superpowers:writing-plans writes a scratch file to docs/superpowers/ despite this override, /superbeads-materialize ingests it and deletes it. See using-superbeads for the procedure.