Unattended runs — e11-dev-auto

One iteration of an unattended development loop: intent → spec → implementation → layered self-review → commit, with no human interaction. Where every other workflow halts to ask, this one HALTs with a status and writes down why.

When to use it

• A story or clearly-scoped change you'd trust a competent engineer to take end-to-end.
• Headless pipelines: e11 agent, e11 pipeline, CI-adjacent automation.
• Not for: ambiguous intent (it will HALT blocked, not guess), architectural decisions, anything you'd want to steer mid-flight — use e11-dev-flow interactively instead.

How to invoke

[DA] from Dev, skill:e11-dev-auto with the intent, or headless:

e11 agent dev "run e11-dev-auto for story 3-2"
e11 pipeline          # chains e11-spec-flow → e11-dev-auto per story

The HALT protocol

The run always terminates through HALT with a terminal status — never a question:

Status	Meaning
done	Artifacts written (and committed when VCS is available)
blocked	A human is needed; blocking_condition says exactly why

Status lands in the spec file's frontmatter (draft → ready-for-dev → in-progress → in-review → done/blocked), details under ## Auto Run Result in the spec, and — for machine callers — in:

// {implementation_artifacts}/e11-dev-auto-result.json  (overwritten per run)
{
  "schema_version": 1,
  "status": "done | blocked",
  "spec_file": "<path or empty>",
  "blocking_condition": "<condition or empty>",
  "followup_review_recommended": false,
  "baseline_revision": "<revision, NO_VCS, or empty>",
  "final_revision": "<revision, NO_VCS, or empty>",
  "verification": [{ "command": "npm test", "exit_code": 0, "duration_ms": 8400 }]
}

Automation callers treat result.json as the outcome of record and never parse conversation output. Blocking conditions are a stable vocabulary (unclear intent, intent gaps, spec failed ready-for-development standard, implementation verification failed, verification unavailable, review repair loop exceeded 5 iterations (non-convergence), no subagents, …) so callers can switch on them. The field is always a string — "" (never null) when nothing blocks.

done is gated on evidence. verification records the observed exit code of every command the spec's ## Verification section declares, captured on the final pass after review patches. A run whose environment cannot execute those commands ends blocked with condition verification unavailable — never done on the model's word. Callers may reject any done that lacks its evidence, and orchestrators should re-run the commands themselves and trust their own observed exit codes.

The sprint board ({implementation_artifacts}/sprint-status.yaml) is part of the same contract: orchestrators read its development_status map and never write it — the sprint/story skills own and sync the board.

What a run does

1. Clarify and route — without asking. Resolves the target from the invocation, a supplied spec file, or the sprint board. Ambiguity → HALT blocked with the condition written down. A e11-spec-flow SPEC.md is a first-class input — the canonical route: the kernel and its companions: are ingested as settled intent (no re-clarification), the execution spec records source_spec + source_spec_digest, and the kernel's CAP-N ids carry through to tasks and acceptance criteria.
2. Plan. Derives/loads the spec to the Ready-for-Development standard; the alloy pre-load runs here (gate: e11_platform_preload).
3. Implement. Tasks in order, tests green before progress.
4. Review + self-heal. Review scales with the diff: a small diff (≤120 changed lines by default, small_diff_max_lines) gets one combined reviewer; larger diffs run the full layer list from its customize.toml (blind-hunter, edge-case-hunter, verification-gap, alloy-auditor) as parallel subagents. Triage happens without a human — patches are auto-fixed and re-verified, spec problems loop back to re-derivation (bounded at 5 iterations, then HALT blocked), the rest is recorded. followup_review_recommended is set when the final pass thinks fresh human eyes are warranted.

Subagent support is mandatory — without it the run HALTs blocked / no subagents rather than degrading silently.

Supervising without interacting

• Watch the spec file's frontmatter status.
• After the run: read ## Auto Run Result, then git log / the diff.
• followup_review_recommended: true → run e11-code-review or a checkpoint walkthrough in a fresh context.

Customization

.foundry/custom/e11-dev-auto.toml — review layers (add a compliance layer, disable the alloy layer for non-platform repos), e11_platform_preload, persistent_facts, on_complete. See Customization.

Source

e11-dev-auto/SKILL.md

See also: Quick flow · Phase 4 · Claude Code integration.