Skip to main content

ADW Cycle Standards

The Agentic Developer Workflow turns an idea into a shipped, human-approved change through the same repeatable steps every time. This page is the standard for each step: what it is, what runs it, what it needs to start, what "good" looks like, and the gate it has to clear before the work moves on.

Every step reads the same five fields, so you can hold all of them to the same bar.

Two entry points, one loop

There are two ways in, and they converge immediately:

  • You (a person) start at spec-create using the spec-create skill.
  • The automated pipeline starts at classify, then routes to /feature, /bug, or /chore.

From the spec onward, the steps are identical. Two rules hold the whole way through: it is local-first (runs on your flat subscription before any metered cloud), and it is human-gated (every change ships as a draft PR a person merges).

1. Classify​

Route a raw work item to the right kind of planning. Mostly a pipeline concern; if you are creating work by hand, skip straight to spec-create.

  • What runs it: /classify_issue (used by the automated pipeline).
  • Inputs: an ADO work item (title and body).
  • Definition of good: correctly typed as a feature, bug, or chore, or cleanly rejected as not actionable.
  • Exit gate: a work type is assigned, so the right planning command can run.

2. Spec-create​

Turn an idea into a grounded, buildable spec. This is where most of the skill lives: a good spec is the whole game.

  • What runs it: the spec-create skill (your entry point; it adapts from quick to deep mode, deduplicates against existing specs and tasks, infers the project, type, and priority, and researches the target repo). The pipeline equivalent is /feature, /bug, or /chore.
  • Inputs: a description of the work, plus the target repo's lat.md/ and CLAUDE.md.
  • Definition of good: a one-line goal, testable acceptance criteria, the files likely to change, grounded in real repo context (no invented APIs or files), and not a duplicate of existing work.
  • Exit gate: a spec file exists that a reviewer can read and know exactly what "done" means.

3. Spec-review​

Catch a weak spec before any code is written. This is the cheapest place to fix a misunderstanding, and the most expensive one to skip.

  • What runs it: a reviewer (or architect) pass against the spec-first quality bar. In the pipeline this is the "review the plan" step.
  • Inputs: the spec file from step 2.
  • Definition of good: the goal is unambiguous, the acceptance criteria are genuinely testable, the scope is bounded, dependencies and edge cases are named, and it is grounded in the codebase.
  • Exit gate: the spec clears the bar, or it goes back to spec-create. Garbage spec in means garbage PR out, so this gate earns its keep.

4. Implement​

Turn the approved spec into working code.

  • What runs it: /implement (executes the spec file, with multi-agent orchestration).
  • Inputs: the approved spec file.
  • Definition of good: the diff satisfies every acceptance criterion, tests are added or updated and pass, lat.md/ is updated if behavior changed, and the change stays scoped to the spec.
  • Exit gate: a complete, self-tested change sits on a branch, ready to be checked.

5. Maker-checker (verify)​

An independent check that the work is actually done, before it is allowed to be committed. The agent that wrote the code does not get to grade its own homework.

  • What runs it: /verify_implementation (an independent adversarial verifier that trusts artifacts, not the maker's summary).
  • Inputs: the spec, the git diff, and any test output.
  • Definition of good: every acceptance criterion is demonstrably met by the diff and the tests. Absence of proof is treated as failure, not as "probably fine."
  • Exit gate: the verifier approves. A maker's claim of success alone never passes this gate.

6. Commit​

Record the change with a clear, conventional message.

  • What runs it: /commit (generates a semantic message; the automated pipeline uses a cheaper model for this throwaway step).
  • Inputs: the staged changes plus the work-item context.
  • Definition of good: one logical change, a semantic message that says what changed and why, and only the intended files staged.
  • Exit gate: a clean commit on the branch.

7. Draft PR (the human gate)​

Put the change in front of a person to review and merge. This is the gate that never goes away.

  • What runs it: /pull_request (opens a draft PR by default).
  • Inputs: the branch, the spec, and the work item.
  • Definition of good: the PR description links the spec and summarizes the change, and the CI gate (including lat check) is green.
  • Exit gate: a human reviews and merges. Agents draft; people sign off.

8. Complete​

Close the loop cleanly so nothing is left dangling and the knowledge graph stays honest.

  • What runs it: /spec-complete (updates docs, archives the spec, marks the digest task done).
  • Inputs: the merged spec.
  • Definition of good: docs updated, spec archived to specs/complete/, the task marked done, and lat check green.
  • Exit gate: the loop is closed and lat.md/ still matches the code.

What holds across every step​

  • Human-gated. Nothing ships without a person merging the draft PR (step 7). Steps 3 and 5 are the two places a person or an independent agent can stop bad work early.
  • Evidence over narrative. "Done" means proof: passing tests, a matching diff, a green gate. A confident summary is not evidence.
  • Local-first. The loop runs on a flat, unmetered subscription by default; the metered cloud path is opt-in for unattended runs.
  • Traceable. Every run is traced end to end, so there is an audit trail of what each step did.
Canonical source

The authoritative version of these standards lives in wg-orchestration's lat.md/operations.md (validated by lat check), alongside the ADW dispatch workflow it describes. This page is the readable companion; when the two ever disagree, the lat.md version wins.