Skip to main content

​
/wish — Plan Before You Build

Convert a validated idea into an executable wish document at .genie/wishes/<slug>/WISH.md.

​
When to Use

  • User describes non-trivial work that needs planning before implementation
  • User wants to scope, decompose, or formalize a feature/change
  • Prior /brainstorm output exists and needs to become actionable

​
Flow

  1. Gate check — if the request is fuzzy, auto-trigger /brainstorm first.
  2. Align intent — ask one question at a time until success criteria are clear.
  3. Define scope — explicit IN and OUT lists (OUT cannot be empty).
  4. Decompose into groups — split into small, loosely coupled execution groups.
  5. Write wish — create .genie/wishes/<slug>/WISH.md.
  6. Add verification — every group gets acceptance criteria + a validation command.
  7. Declare dependencies — depends-on between groups and cross-wish dependencies.
  8. Handoff — auto-invoke /review on the WISH.md.

​
Wish Document Sections

SectionRequiredNotes
Status / Slug / DateYesStatus: DRAFT on creation
SummaryYes2–3 sentences: what and why
Scope IN / OUTYesOUT cannot be empty
DecisionsYesKey choices with rationale
Success CriteriaYesCheckboxes, each testable
Execution StrategyYesWave-based parallel/sequential plan
Execution GroupsYesGoal, deliverables, acceptance criteria, validation
DependenciesNodepends-on / blocks using slug
QA CriteriaNoPost-merge verification
Assumptions / RisksNoFlag what could invalidate the plan

​
Execution Strategy

Every wish must define waves — this forces the planner to think about ordering, parallelism, and dependencies upfront: 
### Wave 1 (parallel)
| Group | Agent | Description |
|-------|-------|-------------|
| 1 | engineer | Task A |
| 2 | engineer | Task B |

### Wave 2 (after Wave 1)
| Group | Agent | Description |
|-------|-------|-------------|
| 3 | engineer | Task C |
| review | reviewer | Review Groups 1+2 |

​
Rules

  • No implementation during /wish — planning only
  • No vague tasks (“improve everything”) — every task must be testable
  • Keep tasks bite-sized and independently shippable
  • Declare cross-wish dependencies early
  • OUT scope must contain at least one concrete exclusion