/executing-plans

name: executing-plans
description: Assistive /feature coordinator. Select relevant tasks from a maintained spec/plan, delegate a useful batch when warranted, record verified versus pending checks honestly, and give progress summaries without default human-approval stops.
disable-model-invocation: true

executing-plans

Coordinate implementation of an already-authorized `/feature` plan. The spec/plan is a **maintained working agreement**, not an additional permission system. This coordinator schedules work and reports progress; `subagent-driven-development` owns implementation and scoped checks. Keep the feature caller's selected `WORK-ID` through batches and restarts. Read its current context when resuming. For native-owned work, refresh its derived overview with `work.py view <WORK-ID> --save`, reporting the returned local path with task and check results. Plan task IDs stay with the plan; do not mint a new work item for every task or checkpoint. Legacy board work has no native derived view; use its selected board owner. The work item's local completion is separate from checks, review and PR delivery. Retain the caller's original requested outcome, covered delivery actions, explicit exclusions and remaining obligations through task handoffs. A plan change, implemented slice or green narrow PR does not silently close an unfinished feature. A clear earlier same-scope authority survives a branch or task transition; an explicit pause, revocation or narrower grant does not.

Structured-artifact format boundary

Load `{{PLUGIN_ROOT}}/includes/artifacts.md` for artifact I/O and preserve the selected spec/plan representation.

An HTML checkpoint is **not a new user checkpoint in `/sprint`**. The sprint route hands the whole plan directly to `subagent-driven-development`. For `/feature`, checkpoints group meaningful progress. A user-requested attended pause is respected, but no artifact-created approval prompt is required between routine batches.

Phase 1 - Select the next meaningful work

After process recreation, rediscover the same authoritative pair and query `identity` and `eligible` again. Read the relevant criteria, current plan tasks, and actual dependencies through `index`, `outline`, and symbol-scoped `read`. The engine `eligible` response is **advisory**, never a permission grant or a current-test claim. `REVIEW` or `DONE` records implementation progress, not a passing test.

For HTML, inspect the plan's exact checkpoint membership and use the authored checkpoint partition to organize the work. A three-to-five task grouping is optional presentation guidance; it **must not split an HTML acceptance scope** just to meet a count. Retain each checkpoint's full task-ID set for accurate reporting, but do not treat earlier checkpoint numbering as a dependency or approval. A `BLOCKED` member is still visible and cannot silently make the checkpoint complete. Group independent work so it can continue when another member has a real unmet prerequisite.

For Markdown, retain its recorded task statuses and dependencies without auto-conversion. The coordinator may return an underspecified task to `writing-plans` or amend the authorized method and check with a reason. Ask only about a consequential missing decision; no repeated plan approval, negative intent interview, or prerequisite code.

On resume, examine `IN_PROGRESS` work and outstanding workers before attempting any new start. If the state needs correction, use a reasoned `task-reconcile` under current CAS/operation ID. Never infer that work is done merely because a process died; never automatically clear `BLOCKED` or duplicate execution. A stale proof observation is visible but is not a reason to restart the whole specification process.

**Progress assessment:** identify actionable tasks, relevant checks, and genuinely missing inputs. A disputed source requirement or irreversible operation is a real question. Missing optional code-map text, a reviewer adapter, approval nonce, or delivery ticket is not a universal blocker.

Phase 2 - Execute and record a coherent batch

Invoke `subagent-driven-development` with an explicit `scope` containing the selected task IDs (normally an authored checkpoint's relevant work). Do not pass a partial or cross-checkpoint task set **as if** it were evidence of whole-checkpoint acceptance; presentation batches do not confer acceptance. The nested implementation skill may use one author, several well-scoped agents, or direct implementation based on actual value. A fresh author plus two reviewers for each task is not compulsory.

For HTML, progress through ordinary `task-start`, `task-review` (implementation ready), and receipt-free `accept-scope` (implementation `DONE`) as applicable. A fact prerequisite can be checked and recorded with a reported source; an unresolved decision needs the actual user's choice. No `arm-sprint`, `satisfy-prerequisite` reply, `task-reconcile` approval nonce, mandatory context ticket, or `_preflight_current_acceptance` call is necessary for ordinary execution.

The worker returns actual work and checks, including failures or still-unrun verification. These remain outstanding in the batch report. Do not describe `DONE` as `ACCEPTED` or replace command output with a model assertion. If a required check fails, repair the affected work or report incomplete verification; do not rerun all unrelated reviewers solely because an evidence receipt changed. Inspect uncertain worker completion or writes before replaying them. Fix in-scope review findings and rerun affected proof; a reviewer-round count is not permission to waive an unmet criterion.

Phase 3 - Report progress; pause only when requested

Report what changed, the applicable tests/checks actually run and their results, what remains, and the next dependency-clean batch. Use `[NEEDS-TRIAGE]` for discoveries outside the agreed scope. Do not claim the batch shipped or passed every check unless current evidence suppor