Quick flow — shipping with less ceremony

The end-to-end path for small, single-contributor work: e11-spec-flow → e11-dev-flow. No PRD, no architecture doc, no story listing — often no separate spec step either. Ceremony is a dial, and this page is about setting it deliberately.

Older installs: the Solo Dev agent (flow-solo-dev) is retired — you invoke the two skills directly (or via Dev's [DF]). Same skill names as before, rebuilt engines inside. See Upgrading.

The ceremony dial

From least to most:

Level	What runs	When
Oneshot	e11-dev-flow routes tiny, zero-blast-radius changes through a single condensed pass — implement, review, commit; no spec file or board sync by default (oneshot_spec_trace / oneshot_sprint_sync knobs turn the paper trail on)	Typo-class through small well-understood changes
Plan-code-review	e11-dev-flow's full quick engine: clarify → spec → implement → layered self-review	Most quick work; anything with real blast radius
Spec first	e11-spec-flow distills the intent into a spec-kernel folder; e11-dev-flow (or several skills) consume it	You want the contract reviewed before code, or multiple consumers
Unattended	e11-dev-auto — the whole iteration, no human, HALT with status	You trust the intent; see Unattended runs
Full lifecycle	Phases 1–4	It needs a PRD — stop reading this page

You don't pick oneshot explicitly — e11-dev-flow's routing step picks it when blast radius is zero and no architectural decision hides in the intent. When in doubt it takes the longer path; you can always say "oneshot this" to push.

When to pick this over the story cycle

Quick flow when…	Story cycle (Phase 4) when…
Small change, single contributor	Multi-person coordination, sprint board matters
Pattern is established in the codebase	The pattern itself is the design decision
Spike, fix, tweak, refactor	Production epic with a paper trail
You'd hand-write a one-page spec	You'd hand-write a PRD

e11-dev-flow also runs epic stories perfectly well (it compiles epic context and syncs the sprint board when the intent is a story) — the ceremony saved is in the interaction, not the bookkeeping.

The standard two-step

skill:e11-dev-flow  "Add a /tenants/<id>/usage endpoint to service-billing
                     returning current-month API calls + storage bytes"
   │
   ├─ clarify-and-route: loads relevant artifacts, asks (numbered) only
   │  what it must, checks branch + working tree, splits multi-goal intents
   │
   ├─ plan: investigates the codebase, writes
   │  implementation-artifacts/spec-tenant-usage.md   (status: ready-for-dev)
   │  — tasks with file paths, Given/When/Then ACs, no TBDs
   │
   ├─ implement: alloy pre-load for every @engineering11/* touched,
   │  tasks in order, tests green            (status: in-progress → in-review)
   │
   └─ review: layered self-review (blind-hunter, edge-case-hunter,
      verification-gap, alloy-auditor) → findings triaged   (status: done)

Interrupted? Re-invoke e11-dev-flow — it finds specs with active statuses and resumes at the right step. The spec's frontmatter status is the state machine: draft → ready-for-dev → in-progress → in-review → done.

Want the contract reviewed before any code? Run skill:e11-spec-flow first — it distills any input (idea, brief, thread, transcript) into a SPEC.md kernel + companions folder that e11-dev-flow and e11-dev-auto consume. Deep dive: Quick flow reference.

Stakes, fast paths, and headless — the same dial everywhere

Quick flow is one instance of a Foundry-wide principle:

• Stakes calibration — e11-prd, e11-product-brief, and e11-ux size their process to hobby / internal / launch stakes instead of one-size ceremony.
• Fast paths — the planning skills offer batched-questions fast paths with [ASSUMPTION] tags when you'd rather react to a draft than be interviewed.
• Headless modes — e11-spec-flow, e11-prfaq, e11-product-brief, and e11-dev-auto run machine-driven with JSON outcomes (e11 agent / e11 pipeline from the shell; e11 pipeline chains e11-spec-flow → e11-dev-auto per story).

Gotchas

• The spec is the contract. If you keep changing your mind, update the spec (re-run the flow) rather than letting code drift from it.
• Quick flow won't take multi-goal intents silently. Independent shippable goals get flagged for split; deferred ones land in deferred-work.md so they aren't lost.
• Alloy is consulted automatically (gate: e11_platform_preload). A referenced SDK with no alloy doc halts interactive runs with [R]ead / [S]kip options — skips are recorded and audited by the review layer. Don't bypass; it surfaces real gaps.
• Same-context review is an anti-pattern. The built-in layer pass is a floor, not a ceiling — for anything risky, run e11-code-review in a fresh session, or a checkpoint walkthrough.
• The spec is durable. Keep it; it's the record of why the change looks the way it does.

Source

e11-spec-flow/SKILL.md · e11-dev-flow/SKILL.md · e11-dev-auto/SKILL.md

See also: Quick flow reference · Unattended runs · Ship a story end-to-end (the story-cycle equivalent).