/execute

name: execute
description: |
  Plan-driven orchestrator. Reads plan.json (from /blueprint) or requirements.md,
  then dispatches workers to build the system.
  Use when: "/execute", "execute", "plan 실행", "blueprint 실행"
allowed-tools:
  - Read
  - Grep
  - Glob
  - Bash
  - Edit
  - Write
  - TaskCreate
  - TaskUpdate
  - TaskList
  - TaskGet
  - TaskOutput
  - AskUserQuestion
  - EnterWorktree
  - ExitWorktree
  - TeamCreate
  - TeamDelete
  - SendMessage
validate_prompt: |
  Phase 0 must detect input type (plan.json / requirements.md / markdown) and normalize.
  Dispatch mode must be asked via AskUserQuestion.
  Verify depth must be asked via AskUserQuestion.
  All tasks must reach status "completed" or "done" before stopping.
  Verify recipe must run.
  Final report must be output.

/execute — Plan-Driven Orchestrator

**You are the conductor. You do not play instruments.** Delegate to workers, manage parallelization, verify the result.

Core Principles

1. **DELEGATE** — Agent/Team: workers do the work. Direct: orchestrator does. 2. **PARALLELIZE** — Run unblocked tasks simultaneously via `run_in_background: true`. 3. **plan.json is the ledger** — Task state via `hoyeon-cli plan` commands. Never direct file writes. 4. **Contracts guide workers** — If `contracts.md` exists, workers reference it for cross-module agreements. 5. **Context flows forward** — Workers write learnings; next-round workers read them.

---

Runtime Surface

Claude Code

• Use the existing `Agent`, `Task*`, `Team*`, and `AskUserQuestion` surfaces

described below when they are available.

• Claude hooks may enforce orchestration guards and stop transitions.
• Logical subagent names remain the canonical Hoyeon names, for example

`worker`, `verifier`, and `code-reviewer`.

Codex

• Codex v1 is Bash-first and no-MCP. Use `hoyeon-cli` for all plan state.
• Do not edit `plan.json` directly; use `hoyeon-cli plan task` for every status

transition.

• Use logical Hoyeon subagent names in the charter, mapped to Codex adapters when

installed:

• `worker` -> `hoyeon-worker`
• `verifier` -> `hoyeon-verifier`
• `code-reviewer` -> `hoyeon-code-reviewer`
• In Codex, translate every logical `Agent(...)` dispatch in the references to

the native `spawn_agent` tool:

• `Agent(subagent_type="worker", ...)` -> `spawn_agent(agent_type="hoyeon-worker", ...)`
• `Agent(subagent_type="verifier", ...)` -> `spawn_agent(agent_type="hoyeon-verifier", ...)`
• `Agent(subagent_type="code-reviewer", ...)` -> `spawn_agent(agent_type="hoyeon-code-reviewer", ...)`

Pass the worker charter as the agent message, and keep the charter's path-and-ID-only contract unchanged.

• Treat `TaskCreate`, `TaskUpdate`, `TaskOutput`, and `TeamCreate` examples in

the reference recipes as Claude Code protocol notes, not literal Codex calls. Codex execute state is tracked through `hoyeon-cli plan task` plus returned subagent messages.

• If the current Codex session has not loaded the adapter names, fall back to

direct single-worker execution and keep the same charter/output contract.

• Do not rely on hooks, `TeamCreate`, or automatic stop transitions in Codex v1.
• Parallel Codex worker dispatch is allowed for disjoint `parallel_safe` tasks

when the `hoyeon-worker` adapter is prompt-visible. Use `spawn_agent` for dispatch, `hoyeon-cli plan task` for state, and returned subagent messages for evidence.

• `scripts/codex-execute-smoke.sh` validates only single-worker plan state

transitions. It does not prove parallel subagent behavior; verify parallel changes with a bounded live `spawn_agent` smoke.

---

Phase 0: Initialize

Phase 0 is **plan-first**. The orchestrator resolves an input to a valid `plan.json`, asks two questions (dispatch + verify depth), and prepares a worker charter template. **Phase 0 never reads `requirements.md` or `contracts.md` body** — only `plan.json` structural fields (INV-3).

0.1 Parse Input & Resolve

/execute [<spec_dir>] [--work worktree|branch|no-commit]

raw_path = $1  (may be empty)

# (a) No argument → virtual plan path (R-F1.3)
IF raw_path is empty:
  input_mode = "virtual"
  spec_dir   = null   # resolved later in 0.2
  GOTO 0.2

# (b) Argument provided → must exist (R-F1.4)
IF NOT exists(raw_path):
  ERROR: "No such path: {raw_path}"
  guidance: "Provide a directory containing plan.json or requirements.md,
             or call /execute with no argument to synthesize a virtual plan."
  ABORT

spec_dir = raw_path if is_dir(raw_path) else dirname(raw_path)

# (c) Classify what we found
IF exists(spec_dir/plan.json):
  input_mode = "plan"          # R-F1.1
ELIF exists(spec_dir/requirements.md):
  input_mode = "requirements"  # R-F1.2
ELSE:
  ERROR: "{spec_dir} has neither plan.json nor requirements.md"
  guidance: "Run /blueprint on requirements.md, or call /execute without arguments
             for a session-synthesized virtual plan."
  ABORT

0.2 Resolve to plan.json

Handle each `input_mode` — the goal is to end this sub-phase with a validated `plan.json` on disk and `spec_dir` set.

IF input_mode == "plan":                             # R-F1.1
  # Direct use — NO user confirm.
  Bash("hoyeon-cli plan validate {spec_dir}")

ELIF input_mode == "requirements":                   # R-F1.2
  # Try /blueprint first; fall back to inline planning if unavailable.
  IF Skill(blueprint, args="{spec_dir}") succeeds AND exists(spec_dir/plan.json):
    Bash("hoyeon-cli plan validate {spec_dir}")
  ELSE:
    # Inline planning — lightweight alternative to /blueprint.
    # Read requirements.md directly (exception to INV-3 — only during init).
    reqs_content = Read("{spec_dir}/requirements.md")

    # Extract frontmatter (type, goal, non_goals) + sub-requirements
    meta_type = parse_frontmatter(reqs_content).type
    sub_reqs  = parse_sub_reqs(reqs_content)  # [{id, given, when, then}]

    # Check pre-work section (if present)
    pre_work = parse_pre_wor