design-md-authorlisted

# Design.md author Give the next designer or implementer enough information to make a consistent choice. A useful document explains which rule applies, where it comes from, and when an exception is valid. ## Agree on the deliverable through the request | Requested activity | Deliver | |---|---| | Explain or review | Findings and supporting evidence in the conversation | | Draft in chat | Proposed document text, with unresolved choices labeled | | Create | A design reference at the selected product's document path | | Update | A focused change that preserves the document's other decisions | Read the relevant repository instructions and existing changes first. A file called `design.md` may describe software architecture; use its contents and the requested outcome to determine ownership. Use `documenter` for architecture documentation and the appropriate UI skill when implementation is requested. Honor a specified path. Otherwise find the existing document for the product, including case variants and app-specific copies; for a new document default to `DESIGN.md` at that product's root. Resolve a material product/path ambiguity before writing. Preserve custom sections, casing, and unrelated user changes. A design-document request supplies authority for the requested document work. Honor requested outline or section checkpoints, and reuse approvals already given for the work. It does not itself authorize redesigning the application, installing tools, exporting remote tokens,