architect-designlisted

# Skill: architect-design Produce a Google-style design doc that names the problem, proposes a solution, considers alternatives honestly, and surfaces the risks the proposer least wants to write down — well-architected by construction, then converged against review. ## When to invoke Before drafting, confirm: 1. The ask is *design*, not *drawing* — if the user wants a picture more than a proposal, route to `architect-diagram` (if installed) or tell the user to invoke a diagramming skill directly. 2. There is a *real choice* to make. If only one option is on the table and the user just wants it written up, the artifact is a project brief, not a design doc. Say so and offer to write a shorter brief instead. 3. The *audience* is human — peers, a tech-lead, an architecture review. Design docs are read; they are not configuration. If any check fails, push back rather than proceeding. ## Procedure 1. **Frame the problem.** Ask only what is *genuinely missing* — what we're building, who's affected, why now, what would count as success. Skip anything the user already said. Three to five questions max; if the user can't answer one, flag it as an open question rather than blocking. 2. **Consult available knowledge surfaces.** Before shaping the concept, establish what enterprise context you can reach, and **state which surface you detected (or "none")** in the concept. **If** you detect an *internal* knowledge-retrieval surface this session (an