/wish

name: wish
description: "Convert an idea into a structured wish plan with scope, acceptance criteria, and execution groups for work."

wish — Plan Before You Build

**Runtime syntax:** in Codex, invoke the plugin copy with the owner-qualified `$genie:<skill>` selector; use bare `$<skill>` only when intentionally selecting a user-tier copy (a separately installed personal copy; Genie no longer seeds this tier). Claude Code and Hermes use `/<skill>`. Cross-skill prose below uses bare names as portable semantic routes; the orchestrator resolves the selector for the active tier.

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 subagent, use the curated context from your dispatch prompt directly.

Design link pre-flight

Before writing the wish, check the design exists and, when present, verify the review evidence with the helper shipped in this skill:

test -f .genie/brainstorms/<slug>/DESIGN.md
node "<wish-skill-dir>/references/design-review-evidence.mjs" verify ".genie/brainstorms/<slug>/DESIGN.md"

• **Present and verification exits 0:** consume the reviewer-bound evidence and emit `| **Design** | [DESIGN.md](../../brainstorms/<slug>/DESIGN.md) |`.
• **Present but verification fails:** stop and return to design review. Missing evidence, a non-SHIP verdict, or a content-digest mismatch cannot be waived; editing DESIGN.md invalidates its prior review. Never repair the failure with a locally recomputed digest — only a new design review may return the `reviewed-sha256` passed to stamping.
• **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. If a design exists, do not scaffold until its digest-bound design-review evidence verifies as SHIP. 2. **Align intent:** clarify until success criteria are testable. 3. **Pass the simplicity gate:** state the simplest complete design, justify every mechanism beyond it with a present requirement or measurement, and defer plausible future complexity behind a concrete trigger. A wish cannot outsource this decision to implementation. 4. **Define scope:** explicit IN and OUT lists. OUT cannot be empty. 5. **Decompose:** small, loosely coupled execution groups. 6. **Scaffold** — always copy the template, never hand-write WISH.md. Resolve the absolute directory containing this loaded `SKILL.md`, replace only the two placeholder assignments below, and run the complete command from the repository root:

<!-- wish-scaffold-command:start -->

   WISH_SKILL_DIR='<absolute directory containing this SKILL.md>'
   WISH_SLUG='<slug>'
   case "$WISH_SLUG" in
     ''|*[!a-z0-9-]*|-*|*-) printf 'invalid wish slug: %s\n' "$WISH_SLUG" >&2; exit 2 ;;
   esac
   WISH_DEST=".genie/wishes/$WISH_SLUG/WISH.md"
   test -f "$WISH_SKILL_DIR/templates/wish-template.md"
   test ! -e "$WISH_DEST"
   mkdir -p "$(dirname "$WISH_DEST")"
   cp "$WISH_SKILL_DIR/templates/wish-template.md" "$WISH_DEST"

<!-- wish-scaffold-command:end -->

The template ships inside this skill as the single source of truth for wish structure — a plain document, no runtime scaffolder. Copying guarantees the skeleton the parser and linter expect; ad-hoc wishes regularly fail structural lint. 7. **Fill:** replace the `{{slug}}`/`{{date}}` tokens and every `<TODO: …>` marker with real content. Every group gets acceptance criteria plus a non-zero validation command proportional to the planned diff's risk and reach. Start with the narrowest checks that can disprove the changed behavior or contract: documentation-only groups, including deterministic generated documentation or plugin skill mirrors, use relevant format, link, example, generator, parity, or content-contract checks; runtime groups use focused behavior tests and add type, lint, or build checks only for boundaries they reach. Escalate shared runtime/core behavior, dependency or lockfile, generated executable or runtime artifact, configuration or schema, CI or release, broad-refactor, or uncertain-impact groups to the repository full gate plus affected build or end-to-end checks. State why the command scope fits; a repository-documented gate is by itself sufficient justification for its scope. Preserve any repository-defined aggregate integration or release gate separately from per-group validation. 8. **Declare dependencies:** use the wish-level `## Dependencies` keys `**depends-on:** <comma-separated slugs or none>` and `**blocks:** <comma-separated slugs or none>` for cross-wish edges. Keep per-group `**depends-on:**` fields under each execution group. The spelling is always hyphenated; the DAG is a machine-readable planning artifact in git. 9. **Create tasks** — one per execution group, so `work` can claim and complete each group and the board reflects progress:

   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 ro