Agent skill

Execute

by team-attention in team-attention/hoyeon

Plan-driven orchestrator. An agent skill from team-attention/hoyeon.

MITAuto-check: notesAgent Workflows

Install Execute

skills CLI
$ npx skills add team-attention/hoyeon --skill execute -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install team-attention/hoyeon execute --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/team-attention/hoyeon.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/execute .claude/skills/execute && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
execute
GitHub stars
173
Used in
1 other repo
Token cost
~8.3k tokens
SKILL.md length
2,080 words
Files
7 (incl. references)
Skills in repo
36
Repo updated
First seen
Licence
MIT

At a glance

Plan-driven orchestrator. An agent skill from team-attention/hoyeon.

  • Works in 5 steps: DELEGATE — Agent/Team: workers do the… → PARALLELIZE — Run unblocked tasks… → plan.json is the ledger — Task state via… → …
  • Tasks that involve Planning
  • SKILL.md covers Core Principles, Runtime Surface, Phase 0: Initialize and Orchestrator Boundaries…, plus 8 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Execute is an agent skill from team-attention/hoyeon. Plan-driven orchestrator. Reads plan.json (from /blueprint) or requirements.md, then dispatches workers to build the system. Use when: "/execute", "execute", "plan 실행", "blueprint 실행"

Its SKILL.md is about 8.3k tokens, which your agent loads only when the skill is triggered. The skill folder holds 7 other files, including reference files (for example `references/agent.md`, `references/contracts-patch.md` and `references/direct.md`).

It sits in Agent Workflows, covering Planning. The repository describes itself as: Requirements-first Harness — derive, verify, execute. The licence is MIT.

When your agent uses it

  • Tasks that involve Planning

Example prompts

  • “/execute”
  • “execute”
  • “plan 실행”
  • “/execute”

Requirements

  • Pre-approved tools (allowed-tools): Read, Grep, Glob, Bash, Edit, Write, TaskCreate, TaskUpdate, TaskList, TaskGet, TaskOutput, AskUserQuestion, EnterWorktree, ExitWorktree, TeamCreate, TeamDelete, SendMessage

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  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.

What it can do on your machine

Read from SKILL.md and the folder at commit 7cff032. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Grep
    • Glob
    • Bash
    • Edit
    • Write
    • TaskCreate
    • TaskUpdate
    • TaskList
    • TaskGet

    …and 7 more on the same allowed-tools line.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Execute loads about 8.3k tokens when it runs, and up to ~35k if it reads all its reference files. Until then it costs about 48 tokens; SKILL.md has 2,080 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~48
When it runs · the whole SKILL.md, loaded when a task matches
~8.3k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~35k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NotePre-approves every shell command (allowed-tools: Bash)SKILL.md
    allowed-tools: Read, Grep, Glob, Bash, Edit, Write, TaskCreate, TaskUpdate, TaskList, TaskGet, TaskOutput, AskUserQ

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from team-attention/hoyeon at commit 7cff032, republished under its MIT licence (© team-attention). 2,080 words, ~8,313 tokens.

Download SKILL.mdSave it as .claude/skills/execute/SKILL.md (or your agent's skills folder). This skill also uses 6 other files; get the full folder from GitHub.
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…

/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_work(reqs_content)   # see "Pre-work Gate" below

    # Generate task graph inline (no contracts, no journeys)
    draft_tasks = []
    FOR EACH logical group of sub_reqs (by parent R-X):
      draft_tasks.append({
        id: "T{n}", action: "<what to build>",
        fulfills: [sub_req.id for sub_req in group],
        depends_on: [], parallel_safe: true
      })

    # Generate basic verify_plan (gate 1+2 for all)
    draft_verify = []
    FOR EACH sub_req in sub_reqs:
      draft_verify.append({ target: sub_req.id, type: "sub_req", gates: [1, 2] })

    # Preview (same pattern as blueprint Step 2.3)
    print("[execute] Inline Plan (no /blueprint)")
    print_task_table(draft_tasks)
    print(f"Verify: {len(draft_verify)} entries (all G1+G2)")

    choice = AskUserQuestion(
      question: "Proceed with this inline plan?",
      options: [
        { label: "Proceed", description: "Write plan.json and execute" },
        { label: "Edit",    description: "Revise tasks before proceeding" },
        { label: "Abort",   description: "Stop — run /blueprint first for a detailed plan" }
      ]
    )
    IF choice == "Abort": HALT
    IF choice == "Edit": draft_tasks = interactive_edit(draft_tasks)

    # Write via cli
    Bash("hoyeon-cli plan init {spec_dir} --type {meta_type}")
    write_json_to_tmp({tasks: draft_tasks, verify_plan: draft_verify}) → /tmp/plan-inline.json
    Bash("hoyeon-cli plan merge {spec_dir} --json \"$(cat /tmp/plan-inline.json)\"")
    Bash("hoyeon-cli plan validate {spec_dir}")

ELIF input_mode == "virtual":                        # R-F1.3
  # Session-context synthesis with user confirm.
  timestamp = Bash("date +%Y%m%d-%H%M%S").trim()
  spec_dir  = ".hoyeon/specs/adhoc-{timestamp}"
  Bash("mkdir -p {spec_dir}")

  # Synthesize a minimal plan from recent user messages + cwd state.
  # Keep it in memory first; do NOT write until the user confirms.
  draft_plan = synthesize_virtual_plan(
    recent_user_messages,
    cwd_state = Bash("ls -la").trim()
  )
  # draft_plan shape: { meta, tasks[{id, action, fulfills:[], depends_on:[], parallel_safe}], verify_plan:[] }

  # Summary preview (stdout, not a file)
  print("Virtual plan synthesized ({len(draft_plan.tasks)} tasks):")
  for t in draft_plan.tasks: print("  {t.id}  {t.action}")

  choice = AskUserQuestion(
    question: "Proceed with this virtual plan?",
    options: [
      { label: "Proceed", description: "Write plan.json to {spec_dir} and execute" },
      { label: "Edit",    description: "Open an interactive edit loop to revise tasks" },
      { label: "Abort",   description: "Discard and exit" }
    ]
  )
  IF choice == "Abort": HALT
  IF choice == "Edit":
    draft_plan = interactive_edit(draft_plan)  # loop until user says proceed

  # Persist via cli (INV-5). Write, then validate.
  write_json_to_tmp(draft_plan) → /tmp/plan-virtual.json
  Bash("hoyeon-cli plan init {spec_dir} --type {draft_plan.meta.type}")
  Bash("hoyeon-cli plan merge {spec_dir} --json \"$(cat /tmp/plan-virtual.json)\"")
  Bash("hoyeon-cli plan validate {spec_dir}")

At the end of 0.2 we have: spec_dir/plan.json (valid) + input_mode + (optionally) spec_dir/contracts.md.

0.2b Pre-work Gate (optional)

If requirements.md exists and contains a ## Pre-work section, parse it and gate on blocking items before proceeding.

IF exists("{spec_dir}/requirements.md"):
  pre_work = scan for "## Pre-work" section → parse checkbox items
  # Expected format: "- [ ] action (blocking)" or "- [ ] action (non-blocking)"
  blocking = [item for item in pre_work if "blocking" in item]

  IF len(blocking) > 0:
    print("Pre-work items requiring completion:")
    FOR EACH item in blocking:
      print("  - {item.action}")

    AskUserQuestion(
      question: "Have you completed all blocking pre-work items?",
      options: [
        { label: "Yes, all done", description: "Continue to execution" },
        { label: "Not yet",       description: "Abort — complete pre-work first" }
      ]
    )
    IF answer == "Not yet": HALT

If there is no ## Pre-work section, skip silently.

0.3 Load plan.json (structural fields only)

INV-3: read only structural fields from plan.json. Do NOT open requirements.md or contracts.md body here.

plan = Read("{spec_dir}/plan.json") → JSON.parse

# Structural metrics used by 0.4 prompts
task_count     = len(plan.tasks)
parallel_count = count(t for t in plan.tasks if t.parallel_safe)
parallel_ratio = parallel_count / task_count if task_count else 0

# Gate distribution across verify_plan (for the verify-depth hint)
gate_hist = {1:0, 2:0, 3:0, 4:0}
FOR vp in plan.verify_plan:
  FOR g in vp.gates: gate_hist[g] += 1
max_gate = max(g for g,c in gate_hist.items() if c > 0) if any else 0

# contracts.md path — path only, never the body (INV-2)
contracts_path = "{spec_dir}/contracts.md" if exists(spec_dir/contracts.md) else null
0.4 User Configuration (dispatch + verify depth)

Two AskUserQuestion calls in order. Both include a structural hint computed in 0.3.

# --- Dispatch mode (R-F2.1) -----------------------------------------
# Recommendation from task count + parallel_safe ratio:
IF task_count <= 3:          recommended = "Direct"
ELIF parallel_ratio >= 0.6:  recommended = "Team"      # many independent tasks
ELSE:                        recommended = "Agent"

dispatch = AskUserQuestion(
  question: "Dispatch mode? ({task_count} tasks, {parallel_count} parallel_safe → recommended: {recommended})",
  options: [
    { label: "Direct", description: "Orchestrator executes tasks sequentially in its own context (best for ≤3 tasks)" },
    { label: "Agent",  description: "Spawn worker subagents per module group, round-level commit" },
    { label: "Team",   description: "TeamCreate persistent workers claim tasks (best for high parallel_safe ratio)" }
  ]
)

# --- Verify depth (R-F2.2) ------------------------------------------
# Hint shows gate distribution from plan.verify_plan.
hint = "gates present: " + join([f"{g}={gate_hist[g]}" for g in [1,2,3,4] if gate_hist[g] > 0], ", ")
IF max_gate == 0: hint = "no verify_plan entries"

verify = AskUserQuestion(
  question: "Verify depth? ({hint})",
  options: [
    { label: "Light",    description: "Gate 1 only — build/lint/typecheck (caps all sub_reqs at gate ≤ 1)" },
    { label: "Standard", description: "Gates 1-2 — build + sub_req double-review (caps all sub_reqs at gate ≤ 2)" },
    { label: "Thorough", description: "All gates — no cap; runs gate 3 (qa-verifier) where planned" }
  ]
)

# --- Work mode (flag or prompt) -------------------------------------
IF --work flag provided:
  work = flag_value
ELSE:
  work = AskUserQuestion(
    question: "Work mode?",
    options: [
      { label: "Worktree",           description: "Isolated worktree, commit per round" },
      { label: "New Branch + Commit", description: "Create feat/ branch from current, commit per round" },
      { label: "Branch + Commit",     description: "Current branch as-is, commit per round" },
      { label: "No Commit",           description: "No git commits" }
    ]
  )
0.5 Setup — session state + charter template
# (a) Session state
STATE_FILE="$HOME/.hoyeon/$CLAUDE_SESSION_ID/state.json"
Bash: jq -n \
  --arg dispatch "{dispatch}" \
  --arg verify   "{verify}" \
  --arg work     "{work}" \
  --arg spec_dir "{spec_dir}" \
  --arg input    "{input_mode}" \
  --arg contracts "{contracts_path or ""}" \
  '{dispatch:$dispatch, verify:$verify, work:$work, spec_dir:$spec_dir,
    input_mode:$input, contracts_path: ($contracts|select(length>0))}' \
  > $STATE_FILE

# (b) Branch/Worktree setup
IF work == "Worktree":
  spec_dir       = Bash("realpath {spec_dir}").trim()
  contracts_path = Bash("realpath {contracts_path}").trim() if contracts_path
  EnterWorktree(name=basename(spec_dir))

IF work == "New Branch + Commit":
  branch_name = "feat/{spec_name}"   # derived from spec_dir basename
  Bash: git checkout -b {branch_name}
  audit_append("BRANCH_CREATE {branch_name} from {current_branch}")

# (c) Context files (next to plan.json)
CONTEXT_DIR = spec_dir
Bash: [ -s {CONTEXT_DIR}/learnings.json ] || echo '[]' > {CONTEXT_DIR}/learnings.json   # initialize to [] if new
Bash: [ -s {CONTEXT_DIR}/issues.json ]    || echo '[]' > {CONTEXT_DIR}/issues.json      # initialize to [] if new
Bash: touch {CONTEXT_DIR}/audit.md

# (d) Worker charter template — paths and IDs only (INV-2, R-N15.1)
# NEVER inline GWT, requirements prose, or contracts body into this template.
CHARTER_TEMPLATE = {
  task_id:              "<injected per task>",
  plan_path:            "{spec_dir}/plan.json",
  contracts_path:       contracts_path,          # path only — see R-F2.3
  contracts_directive:  (contracts_path != null)
                          ? "Read contracts.md before coding — it defines the
                             cross-module surface you must respect."
                          : null,
  sub_req_ids:          "<injected per task from plan.tasks[].fulfills>",
  round:                1,
  prior_failure_context: null
}

CHARTER_TEMPLATE is consumed by dispatch references (direct/agent/team) and by the worker charter recipe (T7). The contracts_directive field fulfills R-F2.3: if contracts.md exists, its path is embedded in every charter together with a "read before coding" instruction; its body is never inlined (INV-2).


Orchestrator Boundaries (INV-3, R-N15.2)

The orchestrator is a router over structure. It must NOT read the body of any spec prose. Enforced everywhere in this skill and all dispatch/verify references.

MAY read (structural, via hoyeon-cli plan get or Read on plan.json only):

  • plan.json fields: tasks, journeys, verify_plan, meta, contracts.artifact, context
  • Session state in $HOME/.hoyeon/$CLAUDE_SESSION_ID/state.json
  • Worker output JSON returned by dispatch (WorkerOutput payload)
  • audit.md, learnings.json, issues.json for round-to-round context

MUST NOT read:

  • requirements.md body (GWT, behavior prose, decisions, context text)
  • contracts.md body (invariants, interfaces, data shapes — only the path flows through charters)

That body-read responsibility belongs to workers via the self-read pattern in references/worker-charter.md (§1.3, §2 Self-Read). If the orchestrator ever needs to influence behavior based on a requirement's body, route through a worker or through the contracts-patch recipe — never inline-read.


Resume Behavior (R-F8.2 idempotent restart)

On any re-entry (compaction recovery, session restart, /execute re-invocation on an existing spec_dir), the orchestrator MUST treat plan.json as the source of truth and skip any task whose status == "done". This rule applies uniformly across all three dispatch modes.

# Runs at the top of every dispatch recipe, before any worker is spawned.
plan       = Read("{plan_path}") → JSON.parse
done_ids   = { t.id for t in plan.tasks if t.status == "done" }   # INV-9: monotonic
pending    = [ t for t in plan.tasks if t.status != "done" ]

# Downstream readiness uses done_ids to satisfy depends_on.
ready = [ t for t in pending if all(d in done_ids for d in t.depends_on) ]
ModeWhere the skip happens
direct.mdPhase 1.2 (A) — current.status == "done" → CONTINUE (per-task loop)
agent.mdPhase A compute_ready_set() — t.status == "done" → continue (INV-9)
team.mdPhase 1 ready-set filter + Phase 2 claim loop skip already-done

Additional guarantees:

  • Verify (references/verify.md) builds its coverage matrix from done_tasks only, so a partial run resumes verification on exactly the tasks that completed.
  • hoyeon-cli plan task --status X=done is idempotent (INV-5, INV-9); re-issuing it on a task that is already done is a no-op, never a re-transition.
  • The orchestrator NEVER rewrites plan.json directly — resume reads are through hoyeon-cli plan get (INV-5).

Concurrency Rules (INV-4 — no sleep, no polling)

Every parallel burst MUST be emitted as a single message with all background dispatches at once. Results arrive via notifications (TaskOutput, SendMessage, run_in_background:true completion events), never via a sleep / re-read poll loop.

Hard bans — enforced across SKILL.md and every dispatch / verify reference:

  • No sleep <n> between dispatches.
  • No while not done: ... sleep over plan.json or worker state.
  • No hoyeon-cli plan get called in a loop to poll for status == "done".
  • No serial Bash calls in separate messages where a single-message parallel burst would work (e.g. per-round worker fan-out, gate-1 toolchain fan-out).

Already-enforced sites (for reference):

  • direct.md — sequential by design, no polling (one task per loop iteration).
  • agent.md — Phase C notification handler, explicitly await_round_notifications(round_id) with the comment "NO SLEEP" (R-N16.1 fulfilled).
  • team.md — Phase 2 lead loop uses wait_for_SendMessage() events; standing-by workers wait on inbound SendMessage rather than polling plan.json (INV-4).
  • verify.md — INV-4 listed in invariants block; gate-1/gate-2 fan-out runs as a single-message burst.

If you feel tempted to add sleep, you are wrong. Use background dispatch + notification handler instead.


Dispatch Routing

The orchestrator picks one of three recipes based on dispatch from Phase 0.4. All three consume the same Phase 0 state and delegate worker construction to the canonical charter in references/worker-charter.md — no recipe inlines its own charter format.

IF dispatch == "direct":
  Read: ${baseDir}/references/direct.md
  Follow ALL instructions. (sequential — one task at a time in orchestrator context)

ELIF dispatch == "agent":
  Read: ${baseDir}/references/agent.md
  Follow ALL instructions. (round-based parallel — TaskCreate per ready-set group)

ELIF dispatch == "team":
  Read: ${baseDir}/references/team.md
  Follow ALL instructions. (persistent TeamCreate workers claim tasks)

Canonical charter — every dispatch recipe builds worker charters by importing references/worker-charter.md. The charter carries paths and IDs only (INV-2, R-N15.1): task_id, plan_path, contracts_path, sub_req_ids, round, prior_failure_context. No GWT, no requirements prose, no contracts body.

All dispatch references receive these variables from Phase 0:

  • plan_path — {spec_dir}/plan.json (workers self-read it, orchestrator structural-reads it)
  • spec_dir, CONTEXT_DIR — directory paths
  • contracts_path — path to contracts.md, or null
  • work — "Worktree" | "Branch + Commit" | "No Commit"
  • verify — "Light" | "Standard" | "Thorough" (depth cap for verify.md)
  • CHARTER_TEMPLATE — from Phase 0.5, passed through to worker-charter.md

Resume behavior (R-F8.2) is mandatory across all three — see "Resume Behavior" above for the uniform done-skip contract.


Verify Routing

After all plan tasks reach done / failed / blocked, run verification. There is a single verify recipe; verify depth is a parameter that caps gates per sub_req, not a selector between different recipes (T8 design).

Read: ${baseDir}/references/verify.md
Follow ALL instructions; pass `verify` ∈ {"light","standard","thorough"} as the
depth parameter. verify.md reads done tasks from plan.json (structural only) and
evaluates each sub_req / journey against its capped gate set.
Contracts mismatch hook (C4, R-F9.1)

On any worker output that signals a cross-module contract mismatch — during dispatch OR during verify fix loops — the orchestrator invokes the auto-patch recipe before marking the task done or enqueueing a retry:

Read: ${baseDir}/references/contracts-patch.md
Follow ALL instructions. (detect → patch → audit-log → return control)

This hook runs without user confirmation (INV-7), is idempotent per worker output, and routes only through Read / Edit / Write on contracts.md and audit.md — never through hoyeon-cli (INV-5). See references/contracts-patch.md for detection signals (explicit contract_mismatch, contract_issues[], or BLOCKED-with-contract-reason).


Show full SKILL.md (863 more words)Show less

Output Artifacts (R-F13.2, R-F13.3, R-F13.4)

execute produces exactly 5 file artifacts during a run, all inside <spec_dir>/. There is no report.md — the final report is stdout-only (INV-8 / R-F13.4 / C5).

ArtifactOwnerToolLifecycle
plan.jsonorchestratorhoyeon-cliStatus mutated via plan task --status (INV-5, INV-9; never direct edit)
contracts.mdorchestratorEdit / WriteInline patched by contracts-patch recipe (no user confirm; INV-7)
audit.mdorchestratorRead + EditAppend-only timestamped event log (R-F13.2)
learnings.jsonworkersRead + WriteWorkers append on success per worker-charter.md §3.5 (R-F6.4, R-F13.3)
issues.jsonworkersRead + WriteWorkers append on BLOCKED / FAILED per worker-charter.md §3.5 (R-F6.4, R-F13.3)
audit.md (R-F13.2) — append-only timestamped event log

The orchestrator appends one entry per orchestrator-level event. Format: a markdown list item starting with an ISO-8601 timestamp. Entries are append-only — never edit or delete prior entries. audit.md is initialized as an empty file by Phase 0.5.

Event classTrigger siteEntry shape (markdown)
WORKER_SPAWNdirect/agent/team dispatch issues a worker- {ts} WORKER_SPAWN T<id> mode={direct|agent|team} round=<n>
WORKER_RESULTworker returns done / failed / blocked- {ts} WORKER_RESULT T<id> status=<done|failed|blocked>
RETRYper-task retry (R-F7.1)- {ts} RETRY T<id> round=<n> reason="<short>"
BLOCKEDworker returned blocked (R-F7.3)- {ts} BLOCKED T<id> reason="<reason>" propagates_to=[T<id>...]
VERIFY_DISPATCHgate-1/2/3 dispatch (verify.md)- {ts} VERIFY_DISPATCH gate=<n> targets=[<sub_req>...]
VERIFY_RESULTsub_req gate verdict recorded- {ts} VERIFY_RESULT sub_req=<id> gate=<n> verdict=<PASS|FAIL|MANUAL>
GAPcoverage pre-check found uncovered sub_req- {ts} GAP sub_req=<id>
PERSISTENT_GAPgap survived re-dispatch (R-F10.4)- {ts} PERSISTENT_GAP sub_req=<id>
CONTRACTS_PATCHcontracts auto-patch applied (R-F9.2)- {ts} CONTRACTS_PATCH path=<file:line> rationale="<why>" diff="<summary>"
DISPATCH_CEILINGtask hit 5-dispatch ceiling (R-F7.4 / INV-6)- {ts} DISPATCH_CEILING_EXCEEDED T<id>
ABORTrun aborted (persistent fail / dispatch ceiling)- {ts} ABORT reason="<reason>"

The orchestrator writes audit entries via Read + Edit (append) — never via hoyeon-cli (INV-5 / R-N17.1). The contracts-patch recipe writes its own CONTRACTS_PATCH line directly (see references/contracts-patch.md §"audit.md append").

learnings.json + issues.json (R-F13.3) — worker-managed JSON arrays

Both files are flat JSON arrays initialized to [] in Phase 0.5. Workers append entries per references/worker-charter.md §3.5 using Read + Write. The orchestrator only reads these files (round-to-round context, final report).

  • learnings.json — appended on worker success. Schema is owned by worker-charter.md.
  • issues.json — appended when worker returns BLOCKED or FAILED. Same constraint.

Workers MUST NOT use hoyeon-cli to mutate either file (INV-5).

NO report.md (R-F13.4 / INV-8 / C5)

The orchestrator MUST NOT create a report.md, summary.md, or any other report file. The final report is emitted to stdout only (see "Stdout Report Format" below). This rule applies even if the user asks for a file — surface it via stdout and let the user redirect if they want to capture it.


Stdout Report Format (R-F14.1, R-F14.2, R-F14.3)

After verify completes, the orchestrator prints one final report to stdout — no file is written (INV-8 / R-F13.4). The report has 8 fixed sections in this exact order (R-F14.1):

  1. Status — ✅ COMPLETE | ⚠️ PARTIAL | ❌ FAILED
  2. Summary — task counts, sub_req coverage counts, contracts patch count
  3. Post-Work — action items for the user (directly under Summary, action-first; R-F14.2)
  4. Tasks — table: T# / status / commits / round
  5. Verify Coverage Matrix — sub_req × gate table with PASS / FAIL / — / MANUAL / GAP cells (R-F14.3)
  6. Contracts Auto-Patches — list extracted from audit.md CONTRACTS_PATCH entries
  7. Issues Encountered — extracted from issues.json (and audit.md BLOCKED / ABORT entries)
  8. Learnings — extracted from learnings.json
Status determination
StatusCondition
✅ COMPLETEAll tasks done, all sub_reqs PASS / MANUAL (no GAP, no FAIL, no BLOCKED, no ABORT)
⚠️ PARTIALAny PERSISTENT_GAP, BLOCKED task, gate=4 escalation, or verify result MANUAL without failures
❌ FAILEDAny ABORT, DISPATCH_CEILING_EXCEEDED, persistent verify FAIL after fix loop, or failed task
Section sources
SectionSource
StatusComputed from plan.json task statuses + verify results + audit events
Summaryhoyeon-cli plan list counts + verify result tallies
Post-WorkComputed from MANUAL gate=4 entries, PERSISTENT_GAP entries, BLOCKED tasks
Taskshoyeon-cli plan get <plan> --path tasks + git log per round
Verify Coverage MatrixCoverage matrix data from verify.md (see references/verify.md §"Coverage Matrix Render")
Contracts Auto-Patchesaudit.md lines matching CONTRACTS_PATCH
Issues Encounteredissues.json + audit.md BLOCKED / ABORT lines
Learningslearnings.json
Verify Coverage Matrix (R-F14.3)

Rendered as a markdown table — rows = sub_req, columns = gate, last column = overall result. Cell values: PASS, FAIL, — (gate not applicable at depth), MANUAL (gate=4), GAP (no fulfilling citation).

Concrete example
markdown
## ✅ COMPLETE — execute run 2026-04-17T14:32:11Z

### Summary
- Tasks: 13 done / 0 failed / 0 blocked
- Sub-requirements: 50 PASS / 2 MANUAL / 0 FAIL / 0 GAP (52 total)
- Contracts auto-patches: 1
- Dispatch mode: agent · Verify depth: standard · Work mode: branch

### Post-Work
- [ ] MANUAL REVIEW: R-F11.4 (gate=4) — confirm GWT citations match human intent
- [ ] MANUAL REVIEW: R-F12.4 (gate=4) — confirm escalation policy is acceptable

### Tasks
| Task | Status | Commits          | Round |
|------|--------|------------------|-------|
| T1   | done   | a1b2c3d          | 1     |
| T2   | done   | a1b2c3d          | 1     |
| T3   | done   | e4f5g6h          | 2     |
| ...  | ...    | ...              | ...   |

### Verify Coverage Matrix
| sub_req   | Gate 1 | Gate 2 | Gate 3 | Gate 4   | Overall |
|-----------|--------|--------|--------|----------|---------|
| R-F1.1    | PASS   | PASS   | —      | —        | PASS    |
| R-F1.2    | PASS   | PASS   | —      | —        | PASS    |
| R-F11.4   | PASS   | PASS   | —      | MANUAL   | MANUAL  |
| R-F12.4   | PASS   | PASS   | —      | MANUAL   | MANUAL  |
| ...       | ...    | ...    | ...    | ...      | ...     |

### Contracts Auto-Patches
- 2026-04-17T14:18:02Z — `contracts.md:88` — interface `FooAPI.call` signature aligned with worker T7 output (`+ retries: number`)

### Issues Encountered
- (none)

### Learnings
- T7: worker self-read pattern — pulling sub_req IDs from plan.json before reading body avoids re-parsing on round 2
- T8: gate=1 toolchain fan-out via single-message `run_in_background:true` cut wall time ~40% vs serial

The example is illustrative; counts, hashes, and timestamps come from live data. The section order, headings, and matrix shape are normative (R-F14.1, R-F14.2, R-F14.3).


Generic Rules

  1. plan.json is the ledger — all task CRUD via hoyeon-cli plan (status/list/get/merge). Never direct file writes (INV-5).
  2. Structural reads only — orchestrator reads plan.json fields, never requirements.md / contracts.md body (see Orchestrator Boundaries above; INV-3, R-N15.2).
  3. Two-turn task setup — Turn 1: all TaskCreate. Turn 2: all TaskUpdate dependencies.
  4. Background for parallel — run_in_background: true for concurrent workers, single-message burst (INV-4; see Concurrency Rules).
  5. Contracts are reference — workers receive contracts_path to Read, not inlined content (INV-2).
  6. Workers self-read — workers fetch their own task state + context files per references/worker-charter.md §2.
  7. Context files — learnings.json, audit.md, issues.json in CONTEXT_DIR. Workers append learnings; orchestrator reads them round-to-round.
  8. Compaction recovery — session-compact-hook.sh re-injects state. Use hoyeon-cli plan list to rebuild; done tasks skip on re-entry (R-F8.2; see Resume Behavior above).

Checklist Before Stopping

  • Input detected and normalized (plan.json / requirements.md / virtual)
  • Plan generated or validated via hoyeon-cli
  • Dispatch/verify/work modes selected
  • All tasks dispatched and completed (status "done"/"failed"/"blocked" in plan.json)
  • Verify recipe ran (single verify.md with selected depth)
  • Contracts auto-patch hook invoked on any mismatch signals
  • Final report output
  • Worktree exited (if entered)

© team-attention, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 6 other files (references) in skills/execute of team-attention/hoyeon.

  • SKILL.md
  • references/agent.md
  • references/contracts-patch.md
  • references/direct.md
  • references/team.md
  • references/verify.md
  • references/worker-charter.md

Open the folder on GitHubat commit 7cff032

Used in 1 other repository

We found 1 copy of this SKILL.md (exact, near-identical or edited) in other folders, from 1 other GitHub owner. This page covers the copy in team-attention/hoyeon, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Execute next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Execute compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Execute this skillteam-attention/hoyeon1731 repos~8.3kAutomated safety check: NotesMIT
Executing Plans Inlineobra/superpowers296k2 repos~5.1kAutomated safety check: PassMIT
Interview Meaddyosmani/agent-skills103k6 repos~3.8kAutomated safety check: PassMIT
OpenSpec Guided OnboardingFission-AI/OpenSpec71k1 repos~4.5kAutomated safety check: PassMIT
Writing Plansgeeksblabla/stateofdev.ma16357 repos~661Automated safety check: PassNone
Subagent Driven DevelopmentAsvarox/allkaraoke26138 repos~1.2kAutomated safety check: PassNone

Similar skills

  • Executing Plans Inline

    obra/superpowers

    Has the agent carry out an implementation plan itself, task by task in the current session, keeping a ledger, proving each step with a test and ending with one whole-branch review.

    296k GitHub starsUsed in 2 repos~5.1k tokens
    Agent WorkflowsAuto-check passed
  • Interview Me

    addyosmani/agent-skills

    Asks one question at a time, each with a best guess attached, until the agent is about 95 percent sure what you really want, before any plan, spec or code.

    103k GitHub starsUsed in 6 repos~3.8k tokens
    Agent WorkflowsAuto-check passed
  • OpenSpec Guided Onboarding

    Fission-AI/OpenSpec

    Walks you through a complete OpenSpec workflow cycle with narration while doing real work in your codebase.

    71k GitHub starsUsed in 1 repo~4.5k tokens
    Agent WorkflowsAuto-check passed
  • Writing Plans

    geeksblabla/stateofdev.ma

    A skill your agent uses when design is complete and you need detailed implementation tasks for engineers with zero codebase context - creates comprehensive implementation plans with exact file…

    163 GitHub starsUsed in 57 repos~661 tokens
    Agent WorkflowsAuto-check passed
  • Subagent Driven Development

    Asvarox/allkaraoke

    A skill your agent uses when executing implementation plans with independent tasks in the current session

    261 GitHub starsUsed in 38 repos~1.2k tokens
    Agent WorkflowsAuto-check passed
  • Planning With Files

    jd-opensource/JoySafeter

    Implements Manus-style file-based planning for complex tasks.

    313 GitHub starsUsed in 19 repos~1.8k tokens
    Agent WorkflowsAuto-check: notes

More from team-attention/hoyeon

All 36 skills in this repo
  • Skill Session Analyzer

    team-attention/hoyeon

    This skill should be used when the user asks to "analyze session", "evaluate skill execution", "check session logs", provides a session ID with a skill path, or wants to verify that a skill executed…

    173 GitHub stars~1.9k tokensUpdated 4 mo ago
    Auto-check: notes
  • Browser Work

    team-attention/hoyeon

    Recon-first browser automation. An agent skill from team-attention/hoyeon.

    173 GitHub stars~1.9k tokensUpdated 4 mo ago
    Auto-check passed
  • Check

    team-attention/hoyeon

    This skill should be used when the user wants to verify their changes before pushing, or update the project's rule checklists.

    173 GitHub stars~1.8k tokensUpdated 4 mo ago
    Auto-check: notes
  • Compound

    team-attention/hoyeon

    This skill should be used when the user says "/compound", "compound this", "document learnings", "save what we learned", or after completing a PR.

    173 GitHub stars~1.1k tokensUpdated 4 mo ago
    Auto-check: notes
  • QA

    team-attention/hoyeon

    Systematically QA test any application — web apps, native macOS apps, Electron apps, CLI tools, interactive REPLs, or anything on screen.

    173 GitHub stars~2.6k tokensUpdated 4 mo ago
    Auto-check: notes
  • Dev Scan

    team-attention/hoyeon

    Collect diverse opinions on technical topics from developer communities.

    173 GitHub starsUsed in 1 repo~5k tokens
    Auto-check passed

Categories

Questions about Execute

What does Execute do?

Plan-driven orchestrator. An agent skill from team-attention/hoyeon. Execute is an agent skill from team-attention/hoyeon. Plan-driven orchestrator.

When should I use Execute?

Execute fits situations like: tasks that involve Planning.

How do I install Execute in Claude Code?

Run `npx skills add team-attention/hoyeon --skill execute -a claude-code`. Or copy the skill folder (skills/execute in team-attention/hoyeon) into .claude/skills/execute in your project. Claude Code loads it when a task matches its description.

How do I install Execute in Codex?

Run `npx skills add team-attention/hoyeon --skill execute -a codex`. Or copy the skill folder (skills/execute in team-attention/hoyeon) into .agents/skills/execute in your project. Codex loads it when a task matches its description.

Can I use Execute in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add team-attention/hoyeon --skill execute -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/execute, .gemini/skills/execute, .github/skills/execute and .opencode/skills/execute in your project.

What does Execute need to run?

SKILL.md names no scripts, command-line tools or credentials: Execute is instructions for the agent only. Its frontmatter pre-approves these tools: Read, Grep, Glob, Bash, Edit, Write, TaskCreate, TaskUpdate, TaskList, TaskGet, TaskOutput, AskUserQuestion, EnterWorktree, ExitWorktree, TeamCreate, TeamDelete, SendMessage.

Does Execute access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Execute safe to install?

Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Execute use?

Execute is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Execute use?

About 8.3k tokens (SKILL.md is roughly 33k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 27k tokens, read only when the agent opens those files.

What are the alternatives to Execute?

Skills that share tags, products or a category with Execute: Executing Plans Inline (obra/superpowers, 296k stars), Interview Me (addyosmani/agent-skills, 103k stars), OpenSpec Guided Onboarding (Fission-AI/OpenSpec, 71k stars) and Writing Plans (geeksblabla/stateofdev.ma, 163 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Execute?

team-attention (a GitHub organization) maintains it in team-attention/hoyeon, which has 173 GitHub stars. The repository holds 36 skills in this directory. The repository was last updated on May 21, 2026.

Source: team-attention/hoyeon on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.