---
name: wish
description: "Convert an idea into a structured wish plan with scope, acceptance criteria, and execution groups for /work."
model: fable
effort: high
---

# /wish — Plan Before You Build

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

## When to Use
- Non-trivial work needs planning before implementation.
- User wants to scope, decompose, or formalize a feature/change.
- Prior `/brainstorm` output exists and needs to become actionable.

Wish artifacts live in `.genie/wishes/` in the shared worktree. Execution-group definitions go in WISH.md (git) so other agents and skills can read them; per-group execution state lives in the state DB via `genie task` (see the `work` skill for how groups are claimed and completed). When spawned as a native-team subagent, use the curated context from your dispatch prompt directly.

## Design link pre-flight

Before writing the wish, check the design exists:

```bash
test -f .genie/brainstorms/<slug>/DESIGN.md
```

- **Present:** emit `| **Design** | [DESIGN.md](../../brainstorms/<slug>/DESIGN.md) |`.
- **Absent:** emit `| **Design** | _No brainstorm — direct wish_ |` (no link) — valid for hotfixes, trivial changes, or plans obvious enough that a brainstorm adds no value. The linter (`scripts/wishes-lint.ts`) accepts the literal stub text; a bracket-link to a non-existent brainstorm file fails lint.

## Flow
1. **Gate check:** if the request is fuzzy (no prior design, unclear scope, vague requirements), run `/brainstorm` first and say so.
2. **Align intent:** clarify until success criteria are testable.
3. **Define scope:** explicit IN and OUT lists. OUT cannot be empty.
4. **Decompose:** small, loosely coupled execution groups.
5. **Scaffold** — always copy the template, never hand-write WISH.md:
   ```bash
   mkdir -p .genie/wishes/<slug>
   cp templates/wish-template.md .genie/wishes/<slug>/WISH.md
   ```
   `templates/wish-template.md` (genie repo) is the single source of truth for wish structure — a plain git document, no runtime scaffolder. Copying guarantees the skeleton the parser and linter expect; ad-hoc wishes regularly fail `bun run wishes:lint`.
6. **Fill:** replace the `{{slug}}`/`{{date}}` tokens and every `<TODO: …>` marker with real content. Every group gets acceptance criteria plus a validation command.
7. **Declare dependencies:** `depends-on` between execution groups and cross-wish `depends-on`/`blocks` in the WISH.md — the DAG is a planning artifact in git.
8. **Create tasks** — one per execution group, so `/work` can claim and complete each group and the board reflects progress:
   ```bash
   genie task create --title "<group title>" --wish <slug> --group <group-name>
   genie task list --wish <slug>   # inspect what was created
   ```
   Tasks carry the `--wish`/`--group` linkage; the dependency DAG stays in the WISH.md document, not in task rows. If creation fails (no `.genie/genie.db` yet, CLI unavailable), warn and continue — WISH.md in git is the source of truth and must remain usable by `/work` without task rows.
9. **Handoff:** run `bun run wishes:lint`. If it reports any error, surface it and stop — never hand a structurally broken wish onward. Only after lint passes, auto-invoke `/review` (plan review) on the WISH.md. Never suggest `/work` directly — the review gate comes first.

## Wish Document Sections

| Section | Required | Notes |
|---------|----------|-------|
| Status / Slug / Date | Yes | Status: DRAFT on creation |
| Summary | Yes | 2-3 sentences: what and why |
| Scope IN / OUT | Yes | OUT cannot be empty |
| Decisions | Yes | Key choices with rationale |
| Success Criteria | Yes | Checkboxes, each testable |
| Execution Strategy | Yes | Wave-based plan — mandatory even if a single sequential wave; forces ordering, parallelism, and dependency thinking upfront |
| Execution Groups | Yes | Goal, deliverables, acceptance criteria, validation command |
| Dependencies | No | `depends-on` / `blocks` using slug or `repo/slug` |
| QA Criteria | No | What to verify on dev after merge |
| Assumptions / Risks | No | What could invalidate the plan |

## Rules
- Never write WISH.md from scratch — always `cp templates/wish-template.md`, then edit.
- Lint before handoff: `bun run wishes:lint` must pass before `/review` sees the wish.
- Never emit a bracket-link to a non-existent brainstorm — use the `_No brainstorm — direct wish_` stub.
- No implementation during `/wish` — planning only.
- Every group testable, bite-sized, and independently shippable; no vague tasks ("improve everything").
- OUT scope must contain at least one concrete exclusion.
- Declare cross-wish dependencies early.