Quick flow — e11-spec-flow + e11-dev-flow

The two-skill pair for work that doesn't deserve the full lifecycle. e11-spec-flow distills any intent into a small machine contract; e11-dev-flow turns intent (or that contract) into hardened code. Same skill names as in earlier releases — new engines inside.

For the "how do I work day-to-day" guide, see Quick flow (working guide). This page is the reference for what the two skills actually do.

e11-spec-flow — the spec kernel

Input: anything — a vague idea, brain dump, PRD, brief, RFC, Slack thread, meeting transcript, mixed sources. Output: a spec folder:

{output_folder}/specs/spec-<slug>/
  SPEC.md          ← the five-field kernel — DERIVED, never hand-edited
  <companions>.md  ← load-bearing overflow (glossary, diagrams, catalogs)
  .memlog.md       ← append-only canonical memory the kernel derives from

The five-field kernel: Why · Capabilities (each with stable CAP-N id, intent + success) · Constraints · Non-goals · Success signal. Diagrams always go to companions; upstream artifacts downstream still needs (a UX DESIGN.md, an alloy doc) are referenced as adopted companions rather than duplicated.

Key properties:

• Memlog-derived. Every decision appends to .memlog.md; SPEC.md is re-rendered from it on each run. Same slug → same folder → update in place, capability IDs preserved. This is why PRD/UX/architecture can feed the same spec in any order without merge drift.
• Sparse input handling — express (best-effort distill; every gap becomes an open_questions[] entry) or guided (walk the five fields together). Genuinely too thin → it points you at e11-prd instead of coaching.
• Preservation-validated. A two-pass self-validate checks Spec Law (intent+success per capability, constraints that actually bind, explicit non-goals, testable success signal) and walks the source claim-by-claim so nothing load-bearing silently drops.
• Headless-capable. Machine callers get JSON (per assets/headless-schemas.md) with explicit error_codes (insufficient_intent, missing_slug) instead of questions.
• E11 pre-load (gate: e11_platform_preload): any @engineering11/* mention triggers a skill:e11-knowledge pass before derivation — conventions land in Constraints with alloy:// cites, alloy docs join the companions, gaps halt (interactive) or become open questions (headless).

e11-dev-flow — the quick engine

Invoke with your intent ([DF] from Dev, or skill:e11-dev-flow directly). The engine renders its workflow via a bundled script (scripts/render.mjs) and runs four steps:

1. Clarify and route. Your prompt is the intent. The step loads relevant planning artifacts (with a cached epic-context compile for story work), asks numbered questions only if it must, runs a version-control sanity check and a multi-goal check (independent shippable deliverables get split; deferred goals append to deferred-work.md). Then it routes:
   • Oneshot — zero blast radius, no architectural decisions → a single condensed pass: implement, review, commit. By default it writes no spec-trace file and leaves the sprint board alone — the commit and the terminal summary are the record (oneshot_spec_trace / oneshot_sprint_sync in customize.toml turn the paper trail on). Without subagents, review degrades to a single in-context pass instead of stopping.
   • Plan-code-review — everything else.
2. Plan. Investigates the codebase and writes spec-<slug>.md (Ready-for-Development standard: actionable, ordered, Given/When/Then ACs, no TBDs; 900–1600-token single-goal scope) under {implementation_artifacts}, status-tracked in frontmatter (draft → ready-for-dev → in-progress → in-review → done).
3. Implement. Code + tests per the spec, with the alloy pre-load (gate: e11_platform_preload) before touching @engineering11/* surfaces.
4. Review. Layered self-review — the same finder-skill layers as e11-code-review, from this skill's own [[workflow.review_layers]] (blind-hunter, edge-case-hunter, verification-gap, alloy-auditor).

Re-invoking with an existing spec resumes at the right step from its status. If the work is a sprint story, the engine resolves the story_key and syncs sprint-status.yaml as it moves.

Which one do I start with?

Situation	Start
Intent fits in a sentence and the pattern exists	e11-dev-flow — let it route (likely oneshot)
You want a reviewable contract first, or several skills will consume it	e11-spec-flow, then e11-dev-flow
Nobody will be watching	e11-dev-auto
It needs a PRD	It's not quick flow — Phase 2

Customization

Both skills: .foundry/custom/e11-spec-flow.toml / e11-dev-flow.toml — output paths and folder patterns, e11_platform_preload, review layers (dev-flow), persistent_facts, on_complete. See Customization.

Source

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

See also: Quick flow working guide · Unattended runs · Phase 4.