work — Execute Wish Plan

work — Execute Wish Plan

Runtime syntax: invoke the plugin copy through the active runtime's owner-qualified skill selector; use a bare selector only when intentionally selecting a user-tier copy (a separately installed personal copy; Genie no longer seeds this tier). Cross-skill prose below uses bare names as portable semantic routes; the orchestrator resolves the selector for the active runtime.

The orchestrator's skill: execute an approved wish from .genie/wishes/<slug>/WISH.md by dispatching native subagents per execution group, in waves. The orchestrator never executes group work directly. Per-group execution state lives in the state DB via genie task; documents (WISH.md, review notes) stay in git. Map coordination to the active client with references/native-surfaces.md, resolved relative to the directory containing this loaded SKILL.md.

Context Injection

When you are spawned as a subagent for a group, your dispatch prompt carries the curated context: the wish path, which group(s) to work plus the task id to claim, and the group definition extracted from the wish. Use it directly — do not re-parse the wish for information already provided.

When to Use

• An approved wish exists and review returned SHIP on the plan
• Orchestrator needs to dispatch implementation to subagents

Flow

1. Load and enter execution: read .genie/wishes/<slug>/WISH.md and require persisted status APPROVED (or IN_PROGRESS when resuming). Before the first dispatch, the orchestrator sets APPROVED → IN_PROGRESS; read group state with genie task list --wish <slug> (or genie board --wish <slug>).
2. Pick the wave: every group whose depends-on groups are done, per the wish's Execution Strategy.
3. Dispatch the wave in ONE message — one native delegation surface call per group, each using the named engineer role selected from the WISH's Complexity and Model columns with curated context (see Dispatch, Context Curation). Each engineer's brief opens with the atomic claim:

   genie task checkout <task-id> --worker <engineer-name>
   

   If two agents race one task, exactly one wins; the loser gets a conflict error and stands down.
4. Await completion — never poll: background subagents notify you when they finish. Inspect genie board --wish <slug> on demand; completion is push, not poll.
5. Local review: per finished group, dispatch a reviewer subagent (reviewer ≠ engineer) to run review against that group's acceptance criteria. The orchestrator appends each returned evidence block under ## Review Results; the reviewer never edits it. Diagnose before fixing: overdesigned-plan returns to wish/design review without consuming a fix attempt; other FIX-FIRST gaps may use at most 2 fix loops.
6. Quality review: dispatch a reviewer for a quality pass (security, maintainability, perf). On FIX-FIRST, one fix loop.
7. Validate: run the group's validation command yourself through the active runtime's shell surface; record the output and the scope rationale as evidence. Confirm it remains proportional to the actual diff, widening it when implementation reached beyond the plan: documentation-only changes, including deterministic generated documentation or plugin skill mirrors, use relevant format, link, example, generator, parity, or content-contract checks; runtime changes use focused behavior tests and add type, lint, or build checks for boundaries reached. Shared runtime/core behavior, dependency or lockfile, generated executable or runtime artifact, configuration or schema, CI or release, broad-refactor, or uncertain-impact changes require the repository full gate plus affected build or end-to-end checks. Validation may never be zero. A passing full-suite run is always valid evidence — record why that scope was chosen; a missing scope rationale is a gap in the write-up, not in the validation. A repository-documented gate is by itself sufficient justification for its scope. Preserve required aggregate integration and release gates.
8. Group done — only after clean review AND passing validation:

   genie task done <task-id>
   

9. Next wave: re-derive from the WISH.md Execution Strategy (the DAG lives in the document, not in task rows — see State Management); repeat 2-8 until all groups are done.