Brainstorming skill skips design doc review and overwrites it with the plan

[emretfn]

Describe the bug

After the brainstorming skill writes the design document, it immediately invokes writing-plans without giving the user a chance to review the finalized design doc. Additionally, the writing-plans skill overwrites the design document file with the implementation plan content instead of creating a separate file.

To Reproduce

1. Start a brainstorming session for any feature
2. Go through the design discussion and approve the design
3. Brainstorming skill writes the design doc to docs/plans/YYYY-MM-DD-<topic>-design.md
4. Instead of asking the user to review the design doc, it immediately invokes writing-plans
5. writing-plans overwrites the design document file with the implementation plan

Expected behavior

1. After writing the design doc, the skill should ask the user if they're ready to proceed to implementation planning (as the pre-regression version did: "Ready to set up for implementation?").
2. The implementation plan should be saved to a separate file from the design document (e.g., YYYY-MM-DD-<topic>-plan.md vs YYYY-MM-DD-<topic>-design.md).

Logs

N/A

Additional context

Regression

This is a regression introduced in commit 7f2ee614 ("Enforce brainstorming workflow with hard gates and process flow", 2026-02-12).

Before (Oct 31 / Dec 17 versions), the "After the Design" section had an explicit user gate:

**Implementation (if continuing):**
- Ask: "Ready to set up for implementation?"
- Use superpowers:using-git-worktrees to create isolated workspace
- Use superpowers:writing-plans to create detailed implementation plan

Key elements that existed before:

1. "(if continuing)" — transition was conditional, not automatic
2. "Ask: 'Ready to set up for implementation?'" — explicit user confirmation before proceeding
3. Worktree creation step before plan writing (provides file isolation)

Current version (Feb 12) replaced this with:

**Implementation:**
- Invoke the writing-plans skill to create a detailed implementation plan
- Do NOT invoke any other skill. writing-plans is the next step.

The user confirmation gate was removed entirely. The checklist reinforces this by listing steps 5→6 with no gate between them:

5. **Write design doc** — save to `docs/plans/YYYY-MM-DD-<topic>-design.md` and commit
6. **Transition to implementation** — invoke writing-plans skill to create implementation plan

Two distinct problems

1. No user gate between design doc and plan writing

The flow diagram has a "User approves design?" gate, but this applies to the interactive design discussion phase — approving the design concept. After that approval, the design doc is written and writing-plans is invoked immediately. The user never gets to review the written document itself before the transition.

2. Plan overwrites the design document

• Brainstorming saves to: docs/plans/YYYY-MM-DD-<topic>-design.md
• writing-plans saves to: docs/plans/YYYY-MM-DD-<feature-name>.md

In practice, the writing-plans skill updates the existing design doc file rather than creating a separate plan file, destroying the design document content. The old version avoided this because it created a worktree first (using-git-worktrees), providing file-level isolation.

Related

• Claude skips spec and code quality review #528 — Claude skips spec and code quality review (similar pattern of skipping user review gates)

[FYZAFH]

This is indeed a problem. Due to the fact that the document may ultimately be used for automated development lasting over a dozen hours, the framework's early stage (plan generation) and development allocation are somewhat imbalanced, and the automated plan exacerbates this issue.