{"id":"execute-task","name":"execute-task","summary":"CDD検証付き実装計画を使って次のTaskMasterタスクを実行します。次の準備済みタスクを選択し、プランステップにマッチングし、ディスパッチされたサブエージェントを通じて実装し、サブタスクを証拠付きで検証し、完了したタスクをマークし、すべてのタスクが完了するまでループします。","body":"# execute-task\n\nThe execution loop. Three sources converge:\n\n- **Plan** (HOW) — `docs/superpowers/plans/*.md` produced by GENERATE\n- **TaskMaster** (WHAT) — `.taskmaster/tasks/tasks.json` with\n  dependencies and complexity scores\n- **CDD** (PROOF) — acceptance cards per task, evidence-gated\n\nexecute-task is the single skill that runs the full build from \"tasks are\nready\" to SHIP_CHECK_OK. It is autonomous — no AskUserQuestion inside the\nloop. Any gap that would require user input is surfaced through the recon\nescalation ladder (step 11) or the inbox (steps 4 and 8), never via a modal\nprompt.\n\n## Entry\n\nThis skill is invoked either:\n\n1. Directly by the user once HANDOFF has completed and a task-execution\n   mode (A/B/C) has been dispatched, **or**\n2. By the `prd-taskmaster` orchestrator when `current_phase` is `EXECUTE`.\n\nOn entry, confirm that:\n\n- `.atlas-ai/state/pipeline.json` exists and records `phase: EXECUTE`\n- `.taskmaster/tasks/tasks.json` exists with at least one ready task\n- `.atlas-ai/customizations/system-prompt-template.md` is present (may be\n  empty — absence is a setup bug, empty is fine)\n\nIf any of the above are missing, report the gap and halt. Do NOT attempt to\nbootstrap the missing artifact from inside this loop — that is the\norchestrator's job.\n\n## Cycle (per iteration)\n\nEach pass through this cycle moves exactly one TaskMaster task from `pending`\nto `done`. Do the 13 steps in order. Do not skip.\n\n> **Task-start SHA** — at the very beginning of each iteration (before step 2),\n> capture the current git HEAD:\n>\n> ```bash\n> task_start_sha=$(git rev-parse HEAD)\n> ```\n>\n> Record `$task_start_sha` in the execute-log row for this iteration.  It is the\n> oracle of truth for every reachability sweep in step 9b below: \"what modules\n> did THIS task add?\" is `diff $task_start_sha..HEAD`.  The oracle flow already\n> issues per-task start commits; this surfaces the same value in the loop prose.\n\n1. **Heartbeat check**: verify the execute-task heartbeat timer is running.\n   If missing, register one via `CronCreate(\"execute-task-heartbeat\", \"* * * * *\", \"echo heartbeat\")`.\n   Abort the iteration if the timer cannot be created — a missing heartbeat\n   means a missing stuck-session detector, and that is load-bearing.\n\n2. **Inbox reconciliation**: read `.atlas-ai/state/pipeline.json`,\n   `.taskmaster/tasks/tasks.json`, and the current TodoWrite list.\n   Diff them. If the three are stale by more than 5 tasks (i.e. TodoWrite\n   says 10 done but tasks.json says 3 done), report the diff and halt — do\n   not paper over bookkeeping drift by silently reconciling.\n\n3. **Pick next task**: run backend op `next` with the plugin's project-root\n   pointer. Use exactly this invocation:\n\n   ```bash\n   python3 script.py next-task\n   ```\n\n   Parse the JSON result.\n   - If no ready tasks and all tasks are `done`, run `.atlas-ai/ship-check.py`,\n     emit SHIP_CHECK_OK on success, exit the loop.\n   - If no ready tasks but pending tasks exist, the dependency graph is\n     deadlocked — report and halt.\n\n4. **Load plan step**: search for the matching task ID in this priority\n   order, halting only after all three fail:\n\n   1. `docs/superpowers/plans/*.md` (the superpowers GENERATE default output)\n   2. `.taskmaster/docs/plan.md` (the prd-taskmaster HANDOFF default output,\n      whose path is also recorded in\n      `pipeline.json:phase_evidence.HANDOFF.plan_file_path`)\n   3. Any custom path declared in\n      `pipeline.json:phase_evidence.HANDOFF.plan_file_path` (in case\n      a future handoff variant writes elsewhere)\n\n   If none of the three contains the matching task ID, the task was\n   invented downstream of the plan — mark the task `blocked`, inbox the\n   parent orchestrator with `message_type=\"blocker\"`, and continue to the\n   next iteration.\n\n   (Codified 2026-06-04 — yesterday's ai-human-tasker run had its plan at\n   `.taskmaster/docs/plan.md` only, while this step previously read\n   `docs/superpowers/plans/*.md` exclusively. The controller silently\n   improvised; a cold-start successor would have hit the `blocked` path on\n   every task.)\n\n5. **Generate CDD card**: convert the task's `subtasks` field into a\n   `testing_plan`. Each subtask becomes a verifiable check with a concrete\n   evidence path (file, command output, or test name). Write the card to\n   `.atlas-ai/cdd/task-<id>.json`. A task without subtasks is treated as a\n   single RED card.\n\n6. **Set in-progress**: run backend op `set-status` from the current project\n   root:\n\n   ```bash\n   python3 script.py set-status --id <N> --status in-progress\n   ```\n\n   This flip is\n   observable by watchers and anchors the iteration in TaskMaster itself.\n\n7. **Dispatch implementer subagent** — NEVER in-session. The controller\n   must:\n\n   - Provide the FULL task text to the subagent. Never tell the subagent to\n     \"read tasks.json\" — per spec §12, the controller serialises the task\n     into the dispatch prompt.\n   - Inject the plugin customisation block at `.atlas-ai/customizations/system-prompt-template.md`\n     into the subagent's system prompt. If the file is empty, inject nothing\n     and continue.\n   - Tier the model by TaskMaster complexity score:\n     - `1-4 fast` — use the fast tier (Haiku-class)\n     - `5-7 standard` — use the standard tier (Sonnet-class)\n     - `8-10 capable` — use the capable tier (Opus-class)\n   - Wait for the subagent to return a terminal status: `DONE`,\n     `DONE_WITH_CONCERNS`, `NEEDS_CONTEXT`, or `BLOCKED`.\n\n   Rationale: complexity-tiered dispatch keeps the dollars-per-task curve\n   sensible. A complexity-2 boilerplate task does not need Opus; a\n   complexity-9 architectural task should not be given to Haiku.\n\n8. **Route by status**: the subagent's return status drives the next move.\n\n   - **DONE** — proceed to the spec gate, then the quality gate. If both\n     pass, advance to step 9.\n   - **DONE_WITH_CONCERNS** — the subagent completed but flagged concerns.\n     Address each concern before advancing; re-dispatch if needed.\n   - **NEEDS_CONTEXT** — the subagent requested more context. Provide the\n     requested context and re-dispatch. Retry cap at 2 — if the subagent\n     still returns NEEDS_CONTEXT after two re-dispatches, escalate via the\n     recon ladder (step 11).\n   - **BLOCKED** — the subagent cannot proceed. Try one model-tier upgrade\n     first (e.g. standard -> capable). If still blocked, break the task\n     into smaller subtasks via backend op `expand`\n     (`python3 script.py expand --id <N>`). If still\n     blocked, set status=blocked, inbox parent, halt this iteration.\n\n   Do NOT invent new status values. The four above are the only terminal\n   returns. Any other string from the subagent is a protocol violation and\n   should be logged + treated as BLOCKED.\n\n9. **Triple verification** — the plugin's core quality gate, per spec §11.4.\n   Three independent checks must agree.\n\n   **Hard exit-code gate (MANDATORY — bypasses agreement count).** Before\n   invoking the three checkers, run `.atlas-ai/ship-check.py --dry-run`. If\n   it reports any non-zero `Exit status N` in evidence files, the task\n   FAILS regardless of how the agent narratives read. SHIP_CHECK_FAIL is\n   NOT a warning. Narrative claiming the exit code is \"expected\" or\n   \"infrastructure noise\" does NOT override this gate — write a separate\n   `task-fix-N` to address the underlying failure instead. There is NO\n   override path; Gate 5 is unfakable. (Codified 2026-06-04 after T12\n   in ai-human-tasker was marked DONE while `pnpm test` exited 1 with 11\n   failing tests.)\n\n   **9b. Reachability sweep (MANDATORY for wired/live tasks).** After the\n   hard exit-code gate passes, run the reachability sweep for this task:\n\n   ```bash\n   python3 script.py reachability-sweep \\\n       --task <task_id> \\\n       --start-commit <task_start_sha>\n   ```\n\n   This command:\n   - Inspects every source module added between `$task_start_sha` and `HEAD`.\n   - Computes a per-task verdict: `WIRED`, `EXEMPT`, `ORPHAN`, or `ERROR`.\n   - **Writes the verdict dict** into the task's CDD card\n     `.atlas-ai/cdd/task-<id>.json` under the `\"reachability\"` key (atomic,\n     additive — existing card keys are preserved).\n\n   The sweep exit code encodes the verdict:\n   - `exit 0` → WIRED or EXEMPT (pass; proceed to the three checkers).\n   - `exit 1` → ORPHAN or ERROR (see step 10 for the auto-downgrade path).\n\n   For spike/domain-model tasks the sweep returns EXEMPT automatically (no\n   importer search is performed for those tiers).\n\n   > **Why sweep before the triple check?**  A green test on a module\n   > imported by nothing is not \"done\" — it is scaffolded.  The triple check\n   > can pass for an ORPHAN module (all tests pass; doubt and validate agree).\n   > The reachability gate closes that gap: `done` means the module is\n   > reachable from real production callsites, not just reachable from tests.\n   > Wire it or it ships as scaffold.\n\n   The three checks (run only if the hard gate AND the reachability sweep both pass):\n\n   - Plugin-native check: evidence file count vs declared subtask count\n     (from the CDD card in step 5). Missing evidence = fail.\n   - `/doubt` skill — adversarial doubt sweep on the claimed completion.\n   - `/validate` skill — deterministic validation pass (lint / tests / exit\n     codes).\n   - External `Opus subagent` sanity pass — asks a fresh subagent \"would\n     you merge this?\" with the task spec + diff + evidence.\n\n   3+ agree pass -> task passes. Disagreement -> halt this iteration,\n   surface to inbox.\n\n10. **Mark done + propagate state** — branch on the sweep verdict from step 9b:\n\n    **WIRED or EXEMPT** (sweep exit 0) → proceed normally:\n\n    a. Run backend op `set-status` for the parent task.  Because the sweep\n       already wrote the `reachability` block into the CDD card, the\n       `set-status` CLI auto-reads it — no `--reachability` flag needed:\n\n       ```bash\n       python3 script.py set-status --id <N> --status done\n       ```\n\n       If you want to be explicit (e.g. for logging), you may pass:\n       `--reachability WIRED` or `--reachability EXEMPT`.\n\n    b. **Subtask writeback**: for each subtask `S` in `task.subtasks` whose\n       evidence file (per the CDD card from step 5) exists, run\n       `python3 script.py set-status --id <N>.<S> --status done`. Subtasks left\n       `pending` while the parent is `done` are a data-integrity violation\n       that breaks any tool computing progress from subtask state.\n       (Codified 2026-06-04 — yesterday's run left all 39 subtasks\n       `pending` despite 13/13 parent tasks `done`.)\n\n    c. Update `.atlas-ai/state/pipeline.json` per-task: call\n       `mcp__plugin_prd_go__update_pipeline_task_status(task_id=<N>,\n       status=\"done\")` if the MCP tool is available. If not, fall back to\n       atomic read-modify-write using the pattern in\n       `mcp-server/pipeline.py:locked_update()` — read, append `<N>` to\n       `phase_evidence.EXECUTE.tasks_completed`, write to temp, rename.\n       Never leave pipeline.json and tasks.json mutually inconsistent.\n       (Codified 2026-06-04 — yesterday's run promised this write in\n       SKILL.md but never executed it. pipeline.json froze at HANDOFF\n       transition through all 85 minutes of execution.)\n\n    **ORPHAN or ERROR** (sweep exit 1) → **auto-downgrade to scaffold**:\n\n    Do NOT mark the task `done`.  Instead:\n\n    ```bash\n    python3 script.py set-status --id <N> --status scaffold\n    ```\n\n    Then:\n    - Log to `execute-log.jsonl`: `\"reachability_verdict\": \"ORPHAN\"` (or\n      `\"ERROR\"`), `\"auto_downgraded\": true`, and a plain-English note of\n      which modules are unwired (from the sweep's `modules` list in the\n      CDD card).\n    - **Do NOT halt the loop** — continue to the next task (step 1).\n      An ORPHAN module is scaffolded work, not blocked work.  The ship\n      gate (Gate 6, RA3) will report it honestly as `scaffold`, not `done`.\n    - If you need to wire the module, create a follow-up task\n      (`title: \"Wire <module> into <entrypoint>\"`) and append it via\n      `python3 script.py expand --id <N>` or the MCP equivalent.\n\n    > **Throughline:** a green test on a module imported by nothing is not\n    > done — wire it or it ships as scaffold.  The auto-downgrade ensures\n    > the task graph stays honest: Gate 6 will block the ship until every\n    > wired/live task's reachability block reads WIRED or EXEMPT.  If all\n    > wired/live tasks auto-downgraded to scaffold, the ship check will\n    > block at Gate 2 (\"not every task is done\") and the developer must\n    > choose: wire the modules, re-tier them (spike/domain-model), or mark\n    > them explicitly exempt (`reachableVia: cli:...`).  There is no silent\n    > path to SHIP_CHECK_OK with an unwired module at a wired/live tier.\n\n11. **Check stepback triggers**: if 15 minutes have passed with no task\n    moving to done, OR 5 consecutive iterations have failed on the same\n    task class, the recon escalation ladder is MANDATORY. Climb the ladder\n    in this exact order, not out of order:\n\n    `/stepback` -> `/research-before-coding` -> `/question` -> `pivot`\n\n    - `/stepback` — reassess the architectural assumption. Was the plan\n      wrong?\n    - `/research-before-coding` — feed the blocker into the Perplexity +\n      Context7 + GitHub pipeline for fresh external context.\n    - `/question` — batch-research the unresolved unknowns in parallel.\n    - `pivot` — the plan step itself is unsound; kick the task back to the\n      plan author (inbox parent with `message_type=\"plan_pivot_requested\"`).\n\n    The ladder is append-only — if `/stepback` surfaces a fix, apply it and\n    return to step 3. Only climb if the prior rung did not yield progress.\n\n12. **Render progress** — show the execute progress panel: MCP\n    `render_status(phase=\"EXECUTE\")` → print its `rendered` field; CLI\n    `python3 script.py status --phase EXECUTE`. Then emit the atlas-gamify\n    one-line score (tasks done / tasks total, complexity-weighted). This is the\n    human-visible progress signal and also feeds the dogfood debrief.\n\n13. **Loop**: back to step 1 until SHIP_CHECK_OK or a halt condition fires.\n\n## Termination\n\nThe termination sequence is strict — three steps, in order, no shortcuts:\n\n1. Run `.atlas-ai/ship-check.py`. If it does NOT exit 0, halt. Do NOT\n   emit any completion signal. Investigate the gate failure, fix, retry.\n2. **MANDATORY**: invoke `Skill(skill: \"sync\")` to refresh the memory\n   bank (session-context/CLAUDE-*.md, MEMORY.md, capability inventory).\n   This MUST happen BEFORE the SHIP_CHECK_OK token is printed.\n   Orchestrators tail-watch the token; if the memory bank is stale when\n   they react, successor sessions inherit a wrong picture of the world.\n   (Codified 2026-06-04 — yesterday's ai-human-tasker run shipped 15.6k\n   LOC while `session-context/CLAUDE-activeContext.md` still said\n   \"Scaffold complete. No application code yet\".)\n3. Print `SHIP_CHECK_OK` to stdout. This is the ONLY place in your\n   output where the token may appear — emit it nowhere else, to avoid\n   false-positive matches by log-watchers.\n\nThe ship-check script is deterministic. Its gates are documented at the\ntop of `${CLAUDE_PLUGIN_ROOT}/skel/ship-check.py` (copied to `.atlas-ai/ship-check.py` at setup):\n\n- Gate 1: `pipeline.json current_phase == \"EXECUTE\"`\n- Gate 2: every `master.tasks[].status == \"done\"`\n- Gate 3: every task has a CDD card (`task-<id>.json` or combined variant)\n- Gate 4: plan file exists at `.taskmaster/docs/plan.md` OR `docs/superpowers/plans/*.md`\n- Gate 5 (HARD): no non-zero `Exit status N` line in any evidence file\n\nGate 5 is the convergent must-do from the 2026-06-04 audit — a \"PASS\"\nlabel on a non-zero-exit test is structurally impossible after this\nscript runs. There is no override path for Gate 5; it is the unfakable\noracle.\n\nDo not emit SHIP_CHECK_OK on a mere \"DONE\" keyword in a subagent reply.\nDo not emit on \"all tasks marked done\" without the explicit ship-check.\nDo not emit before `/sync` has been called.\n\n## Red flags\n\nThese are the most common pressure points where the loop silently degrades\nfrom \"verified\" to \"performative\". If you catch yourself thinking any of\nthem, stop and repair the gap.\n\n- \"Close enough, mark it done\" -> NO. Evidence OR nothing.\n- \"Let me skip the doubt step this time\" -> NO. Triple verification is non-negotiable.\n- \"I'll retry with same model+prompt\" (BLOCKED) -> NO. Escalate.\n- \"The task says done, don't check evidence files\" -> NO. Task status must reflect evidence.\n\n## Observability\n\nEvery iteration appends a structured row to\n`.atlas-ai/state/execute-log.jsonl`. Field types are strict — text\nnarrative in a typed field is a logging bug, not compliance. The schema:\n\n- `iteration` (integer, or `\"FINAL\"` for the terminal marker)\n- `timestamp` (ISO 8601 string)\n- `task_id` (string)\n- `complexity` (integer or human label)\n- `tier` (string: `\"fast\"` | `\"standard\"` | `\"capable\"`)\n- `subagent_status` (string: `\"DONE\"` | `\"DONE_WITH_CONCERNS\"` | `\"NEEDS_CONTEXT\"` | `\"BLOCKED\"`)\n- `retry_count` (integer)\n- `triple_verify` (string: `\"PASS\"` / `\"FAIL\"` plus free-text rationale)\n- `stepback_triggered` (boolean, REQUIRED — true iff `/stepback` was\n  invoked this iteration). Putting narrative-text in this field is a\n  violation; use `stepback_narrative` instead.\n- `stepback_narrative` (string, nullable — explanation when\n  `stepback_triggered: true`; `null` otherwise)\n- `ladder_rung` (string, nullable — which rung was reached if escalated)\n- `gamify` (string — atlas-gamify one-line score)\n\nThe stepback fields were split (2026-06-04) after a FINAL iteration entry\nwrote a paragraph of narrative into the boolean `stepback` field and was\ntreated as compliance with the `stepback_mandatory` rule. Boolean trigger\n+ nullable narrative is the correct schema.\n\nThis log is the dogfood artifact — debrief tools consume it, the\norchestrator greps it, and future runs read it for retrospective analysis.\n\n## Composition\n\n- **Orchestrator handoff**: this skill is invoked post-HANDOFF. It does\n  not call `/handoff` — that direction is one-way.\n- **Plan editing**: if the plan is unsound, the ladder escalates to\n  `pivot`, which inboxes the plan author. This skill does not mutate the\n  plan in place.\n- **Ship-check**: `.atlas-ai/ship-check.py` is the terminal gate. This\n  skill calls it; it does not reimplement the checks.\n\n## Non-exits\n\nThis skill uses no explicit process termination. A halt condition reports\nthe reason in the structured log and returns control to the caller (the\nuser or the orchestrator). Never kill the shell — the caller owns the\nsession lifecycle.","author":"@anombyte93","ownerProfile":null,"authorContacts":null,"sourceUrl":"https://github.com/anombyte93/prd-taskmaster/tree/main/skills/execute-task","license":"MIT","category":"document","lang":"en","tokens":4778,"stars":0,"calls30d":1,"claimed":false,"visibility":"public","origin":"crawler","version":"0.1.0","createdAt":"2026-08-22","updatedAt":"2026-08-22","files":[],"requires":{"mcp":["plugin_prd_go"],"tools":["Read","Write","Edit","Bash","Skill","Agent","ToolSearch","mcp__atlas-engine","mcp__plugin_prd_go","mcp__plugin_prd-taskmaster_go","mcp__plugin_atlas-go_go"]},"safety":{"flags":[],"scannedAt":"2026-08-22","hasScripts":false,"networkEndpoints":[]}}