/subagent-driven-development

name: subagent-driven-development
description: Assistive implementation engine for /sprint and scoped executing-plans work. Follow actual dependencies, implement or delegate coherently, run relevant checks, preserve honest evidence, and advance without artifact approval codes or compulsory reviewer cascades.
disable-model-invocation: true

subagent-driven-development

Execute an existing plan. The plan helps the agent remember the intended result; it is not a second permission system. Run meaningful work, correct defects, update progress, and tell the truth about unfinished checks. The active host, user instructions, and independently applicable security/commit controls still govern real actions.

Format and capability boundary

Load `{{PLUGIN_ROOT}}/includes/artifacts.md` for artifact I/O and preserve the selected spec/plan representation. For an explicitly selected Markdown `plan.json` farm workflow, follow `{{PLUGIN_ROOT}}/skills/subagent-driven-development/references/farm-dispatch.md` and its provider, budget and circuit-breaker requirements.

**Scope:** with an explicit `scope` from `executing-plans`, work only on the named tasks; without it, `/sprint` works across the plan. A checkpoint is an organizing group, not independent permission to do the next task. Keep the caller's requested outcome and covered delivery actions alongside the selected task identity. An author unit's completion does not finish a larger authorized outcome or grant a separate commit, merge or publication.

1. Orient and select actual work

Read the selected spec/plan, relevant `.codearbiter/CONTEXT.md`, and the needed build/check commands from `.codearbiter/tech-stack.md`, when present. Read `security-controls.md` for work affecting its rules. In an HTML-knowledge repository a task's `task-context` packet already carries the knowledge records relevant to its paths (`{{PLUGIN_ROOT}}/includes/knowledge.md`). Missing optional orientation is a diagnostic, not a blanket STOP; never guess an essential requirement or execute an unknown command.

If the task belongs to a selected project work ID, use `work.py context` through its installed helper to retain that identity and its actual spec/plan bindings. For an attached plan task, use the bounded `task-context` packet; otherwise fetch relevant knowledge once for the source paths actually in scope. Expand omitted exact records as needed. Do not infer a passed check, completed plan or second work item from an attached summary.

For HTML, use `identity`, `index`, `outline`, exact or batched symbol-scoped `read`, and `eligible`. The engine `eligible` response is **advisory scheduling**, not permission or evidence of a passing test. Read actual task dependencies and `waiting_prerequisites`; do not treat a checkpoint number or an unscoped legacy prerequisite as a universal dependency.

**Read only what matters:** use `task-context` with the current plan `model_sha256` and task ID. It returns referenced criteria, dependency states and scoped facts without claiming a snapshot or approval. If `binding_current: false`, inspect changed requirements. If `context_complete: false`, fetch necessary exact symbols. On `STALE_CURSOR` reread identity; on `RECORD_TOO_LARGE` fetch complete individual records. Without this operation, fall back to existing exact/`read-batch` reads.

For a `fact` prerequisite, check it with ordinary authorized tools and record the actual `prerequisite` observation (satisfied/unsatisfied/unknown, source, outcome and reported origin). For a `decision`, apply the user's already-stated choice where it is actually supported; otherwise ask the consequential question in ordinary language. An agent report is not an authenticated user decision. An unresolved prerequisite affects only the tasks that depend on it; continue independent work.

Record `task-start` when beginning a pending HTML task using the current revision/model hash and a durable operation ID. `task-start` does not need approval receipts, a complete context ticket, a source snapshot, or a reviewer. It cannot clear a recorded stop or start already-running work again.

**After process recreation**, rediscover the same authoritative pair and query `identity` and `eligible` again. Inspect the current worktree, outstanding tool runs, and task results before deciding whether an `IN_PROGRESS` task is still active, partly finished, or ready. Use a reasoned `task-reconcile` to reflect known progress; do not duplicate execution or manufacture evidence. Resume a `BLOCKED` task only after its actual blocker or user's stop has been resolved. CAS/replay remain mandatory: on a lost response, check the journal or retry the same operation ID and identical request rather than reissuing a mutation under a new identity. Read the existing handoff's integration owner, base, shared-file ownership, branch/PR grouping and remaining obligations before redispatch. Preserve an explicit user combine/sequence choice; do not ask the same delivery question because another unit or branch is now active.

2. Implement or delegate the useful unit

Work directly when a focused change is clearer and cheaper. Delegate when genuinely useful for isolation, independent parallel work, or specialist expertise. A **fresh subagent per task is not mandatory**; do not spawn reviewer agents solely because task status or a receipt changed.

Choose a relevant author (backend/front-end/infrastructure) when delegated. Supply the objective, paths, criterion IDs, actual constraints, known current state, and observable checks in a **bounded context packet**. Reuse `_artifactpromptlib.compose_feature_actor_input` and `_contextselectlib.prepare_actor_delivery` when useful to deliver relevant context; neither returns execution permission, and an absent delivery receipt is not grounds to forbid already-authorized work. Respect the host's real subagent permissions and applicable security constraints. Do not pass source-discovered commands to