Update to Diagram Generator

{
  "name": "diagram-generator",
  "description": "Create accurate, readable diagrams for software systems, data models, workflows, APIs, and user journeys.",
  "included_files": [],
  "skill_md_contents": "---\nname: diagram-generator\ndescription: Create accurate, readable diagrams for software systems, data models, workflows, APIs, and user journeys.\n---\n\n# Diagram Generator\n\nUse this skill when the user asks to visualize architecture, processes, dependencies, data, interactions, timelines, or journeys.\n\n## Diagram selection\n\nChoose the smallest diagram that answers the question:\n\n- **Flowchart:** decisions, business processes, or operational workflows.\n- **Sequence diagram:** interactions between users, services, APIs, queues, or databases over time.\n- **Architecture diagram:** systems, boundaries, services, storage, and external providers.\n- **Entity-relationship diagram:** entities, fields, keys, and relationships.\n- **State diagram:** lifecycle states and transitions.\n- **Timeline:** chronological events or delivery phases.\n- **Mind map:** concepts and their relationships.\n- **User journey:** steps, touchpoints, pain points, and outcomes.\n- **Deployment diagram:** environments, infrastructure, regions, and runtime boundaries.\n\nUse Mermaid by default unless the user requests another language such as PlantUML, Graphviz, or D2.\n\n## Workflow\n\n1. Restate the diagram's purpose in one short sentence.\n2. Identify actors, components, boundaries, inputs, outputs, decisions, and dependencies from the supplied context.\n3. Select the diagram type and state it briefly.\n4. Produce a complete renderable diagram, not pseudocode or a partial fragment.\n5. Add only the minimum legend or assumptions needed to interpret it.\n6. If the diagram describes an existing codebase, cite inspected files and label inferred relationships.\n\n## Accuracy rules\n\n- Do not invent services, tables, endpoints, events, or relationships that are not supplied or observed.\n- Label assumptions clearly and ask for clarification when a missing relationship changes the diagram materially.\n- Preserve direction, sequence, cardinality, and ownership.\n- For ERDs, show primary keys, foreign keys, and cardinality when known.\n- For sequences, preserve request/response order, retries, async boundaries, and failure paths.\n- For architectures, distinguish internal components from third-party systems and trust boundaries.\n- For workflows, include validation, error, retry, and completion states when relevant.\n\n## Output rules\n\nWhen the user asks to see a diagram, prioritize the rendered visual. Show source code only when requested or when rendering is unavailable. If rendering is unavailable, provide the complete source in a fenced code block and say which renderer can display it.\n\nFor complex diagrams, offer focused views such as “high-level architecture” and “request detail” instead of producing one unreadable mega-diagram.\n\n## Review mode\n\nWhen reviewing an existing diagram, check for missing actors, ambiguous arrows, overloaded nodes, inconsistent names, missing failure paths, incorrect cardinality, and boundaries that hide important security or ownership assumptions.\n"
}