Planning — Brainstorm + Write Plans

Two phases, one skill: Explore WHAT to build, then document HOW.

When to Use

ALWAYS before:

• Creating features, components, or functionality
• Modifying behavior
• Multi-step tasks
• Any work that changes user-facing behavior

Phase A: Brainstorm (Explore Intent)

The Process

1. Understand Intent — What does the user ACTUALLY want?

   • Ask clarifying questions
   • Don't assume scope
   • Identify hidden requirements

2. Explore Options — What are the approaches?

   • List 2-3 possible approaches
   • Pros/cons of each
   • Recommend one with reasoning

3. Define Scope — What's in and what's out?

   • Must-haves vs nice-to-haves
   • Edge cases to handle
   • Edge cases to explicitly NOT handle
   • Output to:

     openspec/changes/[initiative-name]/specs/

4. Design — How should it work?

   • Data flow
   • Component boundaries
   • API contracts (if applicable)
   • If building UI: Use

     cm-ui-preview

     to preview on Google Stitch before coding

Red Flags — STOP

• Starting code before brainstorming
• Assuming you know what the user wants
• Skipping scope definition
• "It's simple, no need to plan"

Phase B: Write Implementation Plan (OpenSpec Format)

Standard: Fission-AI OpenSpec (

https://github.com/Fission-AI/OpenSpec/

) Output artifacts exactly to

openspec/changes/[initiative-name]/

to ensure human/AI alignment.

When to Write a Plan

• Task has 3+ steps
• Multiple files involved
• Changes affect other components
• User explicitly asks for a plan

OpenSpec Artifacts to Generate

1.

openspec/changes/[initiative-name]/design.md

# Design: [Goal]

## Context & Technical Approach
Why this approach and how it works.

## Proposed Changes
### [Component/File]
- What changes
- Why this approach

## Verification
How to verify it works.

2.

openspec/changes/[initiative-name]/tasks.md

# Implementation Checklist
- [ ] 1.1 First component setup
- [ ] 1.2 First component logic
- [ ] 2.1 Next component integration
- [ ] Verification testing

Plan Rules

✅ DO:
- Break into small, testable steps
- Order by dependency (foundations first)
- Include verification for each step
- Keep steps bite-sized (15-30 min each)

❌ DON'T:
- Write vague steps ("refactor the code")
- Skip verification steps
- Plan more than needed
- Over-engineer the plan itself

Step FINAL: Update Working Memory

After writing an implementation plan, ALWAYS update

.cm/CONTINUITY.md

- Active Goal:    → Set to the plan's #Goal
- Next Actions:   → Set to first 3 tasks from the plan
- Current Phase:  → Set to "planning"
- Working Context: → Key architecture decisions from the plan

Token savings: Next session picks up from CONTINUITY.md (~200 tokens) instead of re-reading the full plan (2,000+ tokens).

Integration

cm-brainstorm-idea

cm-git-worktrees

cm-execution

cm-tdd

cm-ui-preview

The Bottom Line

Think before you build. Document before you code. No exceptions.