DAW — Dilux Agentic Workflow

A development pipeline your coding agent has to walk through. Phases in order, gates it cannot talk its way past, auditors that did not write the code they review, and state that survives closing the terminal.

Works with Claude Code, Codex CLI, Copilot CLI, Cursor, Gemini CLI and OpenCode — one method, six wirings.

As a plugin, and nothing of DAW's lands in your repository. The method lives in the tool; what stays with the project is the AGENTS.md you write, the documents each phase produces, and the pipeline's state.

Those two need their own steps for a reason worth knowing before you start: Copilot reads the plugin manifest for its skills and ignores the hooks in it, so the gates ride user-level hooks instead — install the skills and stop, and it looks alive while enforcing nothing.

Codex CLI, Cursor and Gemini CLI are next. All three already run the method, and the test suite drives each one's real hook with that tool's own event format — what is not finished is the plugin path end to end. Today they install by copying the method into the repository, which works and is one command: see docs/INSTALL.md.

Copying the method in is also what you want on any of the six once you need to change how the method works, rather than only use it. Both ways, and what each one costs, are in docs/INSTALL.md.

Then open your agent in the project and ask it for something. The pipeline starts on its own.

🌍 On language. This repo is in English; DAW is not. Its files are prompts, and they carry an explicit directive: answer in the language the user writes in, and write every artifact — PRDs, specs, commit messages — in that same language. Ask in Spanish, get a Spanish PRD.

Put a coding agent on a real repository and the same three things happen:

• It skips ahead — straight to the implementation, before anyone agreed on what was being built.
• It forgets — forty messages in, the decision you made an hour ago is gone.
• It drowns — give it forty rules and it follows the ones nearest the end of the context window.

None of these is fixed by a better prompt. They are structural.

CLASSIFY → DEFINE → PLAN → CODE → VERIFY → RELEASE, one phase at a time, with a gate between each pair and your approval on every arrow. Only the current phase's rules enter the context. Every phase commits what it produced. The state lives on disk, so closing the terminal costs you nothing.

And the ceremony matches the size of the request: a question gets an answer, a ten-line fix gets a short lane, a feature gets the full run.

→ How it works, in detail — the phases, the tiers, the PRD, security.

A rule written in a prompt is a promise. The model can forget it, misread it, or decide this once does not count.

A rule enforced by a hook is a guarantee. Before every write, code outside the model reads the state and refuses a transition the graph does not carry, and a write of product source from a phase whose rules forbid it. There is no talking past either one, because the decision never reaches the model. Try to write code with no approved spec and the write does not happen — not "the agent apologizes and continues".

Where that guarantee ends, stated plainly: it covers the write tools. A shell command does not go through them, so bash -c 'cat > src/x.py' reaches the disk. DAW does not try to parse your shell to catch it — every spelling it failed to anticipate would fail open, and a guard that reads as total and is not is worse than an honest gap. What it does instead is notice, and say so.

That is the line through every decision here: if a rule matters, it is executable. If it cannot be executed, it does not get to call itself a gate.

A gate is refused-without and recorded. What backs the claim is graded, and the grading is written down instead of implied: the PRD's gate rests on a receipt naming the document's current bytes, the commit gate asks git, and the rest rest on the model's record of what it did.

That grading is not ours. Supply chain security calls the artifact an attestation and the graded version provenance — at SLSA level 1 it may be self-declared by whoever did the work, and from level 2 it is produced by the platform and cannot be forged by the party doing the work. A required status check is the same idea in the shape everyone uses daily: you cannot merge until CI reports the check, and you cannot report it for CI.

Two gates stay self-declared on purpose. sast has nothing to run — it is a model reading code, and a receipt would dress a report up as proof. tests would mean DAW running your suite in your repository, guessing your runner and your environment: CI can do that because CI is the environment, and a gate that cannot be satisfied honestly gets satisfied dishonestly. Both stay in the pipeline, gated and sequenced, and stay honest about what they are.

→ Which gate rests on what, and why

• Claude Code — exercised end to end, and all four acceptance checks pass against the live tool (2.1.220, 2026-07-28; the record is in scripts/acceptance.md). Told to write source with no approved spec, the write is refused by the hook rather than declined by the model.
• OpenCode — the same four, against the live tool (1.18.9, 2026-07-29). That session is also where two defects were found, which is the argument for doing this by hand.
• Copilot CLI — three of the four (1.0.75, 2026-07-29). The fourth is detected and not prevented, and the ceiling is the tool's: its post hook cannot refuse anything.
• Codex CLI, Cursor, Gemini CLI — each adapter is driven through its own hook, with its own event format, by the test suite: it must refuse an illegal transition and let a legal one through. What has not been done for these three is a full session against the live tool, so treat their status as verified at the boundary, unverified in the wild. Reports welcome.

bash scripts/verify_install.sh    # the full suite: install, FSM, and every adapter's enforcement
python3 scripts/lint_method.py    # the prose against the graph, the catalog and the filesystem
python3 scripts/mutate.py         # breaks DAW on purpose and checks the suite notices

CONTRIBUTING.md · SECURITY.md · CODE_OF_CONDUCT.md

Something to report? A bug, an adapter you drove against a real tool, a decision you would have made differently — each has its own form. A vulnerability goes to a private advisory, never a public issue.

Years of building production software with teams, where you find out quickly which parts of a process earn their cost and which ones everybody routes around. DAW is that way of working, built completely for once, with nothing left as an intention. Every decision in it is one I would defend on its own terms, and docs/RATIONALE.md is where I do.

— Pablo Ariel Di Loreto

Apache 2.0. Use it, fork it, adapt it to how your team actually works — that last one is the point. The license grants patent rights explicitly and reserves the names: fork the method freely, call your fork something else.

Copyright 2026 Pablo Ariel Di Loreto.

Built by Pablo Di Loreto — Director of Engineering, Microsoft MVP for Azure & AI, and someone who got tired of explaining the same process to an agent every morning.

DAW is the framework behind the Agentic Orchestration module of AI-First Builders Lab, where students take it apart, rewire it for their own stack, and port it to a second tool.