diagram-architectlisted

# Diagram Architect ## Overview Produce **accurate, presentation-quality diagrams** by interviewing the user first, grounding the content in a real source, rendering with the best-fit JS framework into a live HTML preview, and only asking about **export format after the user approves the look**. The failure mode this skill prevents is **guessing** — drawing a plausible-looking architecture that doesn't match what was built, or exporting before the user has seen and approved it. **Core principle:** Ground first, draw second, **preview → approve → then export**. Don't ask export format up front — ask it only once the user likes the rendered diagram. **REQUIRED SUB-SKILL:** For any non-trivial system (more than a handful of obvious boxes), run **`system-discovery` first** to produce a confirmed entity + connection inventory. A diagram's #1 defect is a missing or wrong *connection* — discovery is what prevents it. Draw nodes from the inventory's ENTITIES and edges from its CONNECTIONS; don't invent, don't omit. Skip discovery only for a trivial diagram you can ground in one glance. ## When to Use - User says: "create a diagram", "draw the architecture", "flow chart", "data flow", "sequence diagram", "ER diagram", "deployment topology", "generate a diagram for X". - Any request to visualize flow, structure, relationships, sequence, state, or topology. - Documenting an implemented system, a proposed design, or a process. **When NOT to use:** simple data charts/plots (bar/lin