ddw-create-adrlisted

# Skill: /ddw-create-adr ## Description Records an architecture or design decision as an ADR (Architecture Decision Record). Captures the context, the options considered, the decision taken and its consequences. ### What an ADR is, and what it is not **An ADR explains a decision that has already been taken. It does not impose anything.** Its reader is whoever, months from now, asks "why is it built like this?" and would otherwise reopen a settled argument or undo something for a reason that was already weighed. Requirements live in the PRD. Design that must be built lives in the spec. Both are validated by a script and both are binding. An ADR is neither: nobody has to obey it, because it describes what was obeyed and why. That is the whole distinction, and it is written here because every other artifact in DDW has a validator pinning its genre and this one has none — nothing catches an ADR that reads like a requirement, so it has to be said rather than checked. In practice: write it in the past, describing. If a sentence of yours says **must**, **shall** or **should**, it is not an ADR sentence — it belongs in the spec, and leaving it here creates a second document telling the implementation what to do, one that no gate reads and no validator judges. An ADR is also not a status report, not a summary of the phase, and not a place to restate the PRD. ## Inputs - The decision's context (detected automatically, or provided by the user) - The relevant source code - The pro