designlisted

# Design Execution Design Execution is the **upstream** sister to grooming. A 📐 Design or 📋 Planning task arrives with an unresolved decision space; this skill drives that space to a locked spec, applies the spec into the live architecture pages, and files the follow-on Code / Operational / Investigation tasks that `/groom` will then bring to Ready. ``` 📐 Design / 📋 Planning ──/design──▶ 🔲 Backlog Code ──/groom──▶ 🗂️ Ready ──implement──▶ ✅ Done ``` > **Scope note.** Throughout this skill, _"Design task"_ refers to **both > 📐 Design and 📋 Planning** tasks — they share the same workflow shape (open > questions → locked decisions → follow-on Backlog tasks, with or without > architecture-page edits). The skill targets both types and treats them > identically. The only material difference in practice: Planning tasks more > often have an empty `Notion pages affected` list (planning produces task > sequencing, not architecture lock-ins), which is handled transparently by > Step 3.5 (the page-edits loop just iterates a possibly-empty list). This skill exists because the procedure is **load-bearing but routinely improvised**: under context pressure a session executing a Design task tends to batch-lock implementation notes mid-discussion, silently widen scope, edit architecture pages without showing the diff, or call a defer a "resolve." The anti-pattern file already prescribes the shape (`reference/anti-patterns.md`) — this skill operationalizes it. **Read `referenc