Eraser DSL Authoring

Description

--- name: eraser-dsl-authoring description: 'Author, fix, and review Eraser Diagram-as-Code DSL from natural language requirements using this repository specs. Use this skill whenever the user asks for Eraser DSL, diagram-as-code, flowcharts, ERD/schema diagrams, architecture/cloud diagrams, sequence diagrams, BPMN/swimlane diagrams, syntax fixes, icon/styling updates, or conversion from plain English process/system descriptions into runnable Eraser code.' argument-hint: 'What diagram do you need (type, entities/nodes, relationships, style)?' user-invocable: true disable-model-invocation: false --- # Eraser DSL Authoring Create valid, runnable Eraser Diagram-as-Code and validate it against the specs in `./sources/`. ## Mission - Turn ambiguous requests into clear diagram intent. - Choose the right Eraser diagram type fast. - Produce syntactically correct DSL on first pass whenever possible. - Catch semantic mistakes before returning final output. ## When to Use - Convert product/process/system descriptions into Eraser DSL. - Refactor or fix invalid Eraser DSL syntax. - Choose an appropriate diagram type when user intent is unclear. - Add styling, icons, labels, and links without breaking syntax. - Review an existing diagram for correctness and completeness. ## Not for This Skill - Pixel-perfect visual design requests that require a GUI-only adjustment workflow. - Non-Eraser notations when the user explicitly asks for Mermaid, PlantUML, or draw.io syntax. - Unrelated programming tasks that do not involve Eraser diagram DSL. ## Inputs to Collect Ask for missing essentials before authoring: - Goal: what decision or process the diagram should explain. - Diagram type (or allow auto-selection). - Domain nouns and actions (entities, steps, services, actors). - Required directionality/cardinality/message labels. - Visual constraints: icons, colors, notation, style mode, typeface. If details are missing, proceed with explicit assumptions instead of blocking. Default assumptions when user is vague: - Keep naming simple and unique. - Prefer minimal styling over decorative styling. - Use commonly recognized icons when a clear icon exists; otherwise omit icons. - Preserve existing semantics over visual embellishment. ## Diagram Type Decision 1. Use flow chart for process/logic flow with decision nodes and groups. 2. Use ERD for data model with entities, attributes, and cardinality. 3. Use architecture for cloud/infrastructure components and boundaries. 4. Use sequence for time-ordered interactions between actors/systems. 5. Use BPMN for business process swimlanes with pools/lanes/events/gateways. 6. If multiple types are requested, produce separate blocks and label each clearly. Quick disambiguation hints: - If user mentions "tables", "columns", "relationships", prefer ERD. - If user mentions "request flow over time" or "actor interactions", prefer sequence. - If user mentions "departments", "roles", "approval process", prefer BPMN. - If user mentions "services", "VPC", "AWS/GCP/Azure", prefer architecture. - If user mentions "decision tree" or "workflow steps", prefer flow chart. ## Procedure 1. Restate the target outcome in one sentence. 2. Map requirements to the DSL primitives for the selected type. 3. Draft a minimal valid skeleton first. 4. Add structure details before visual details. 5. Apply properties incrementally: `icon`, `color`, `label`, then style controls. 6. Apply type-specific constructs: - Sequence: `alt/else`, `opt`, `loop`, `par/and`, `break`, and `activate`/`deactivate`. - BPMN: pools and lanes, plus flow object `type: activity|event|gateway`. - ERD: attributes inside entities, then attribute-level relationships when needed. 7. Apply diagram-level styling at the end: `colorMode`, `styleMode`, `typeface`. 8. Run the quality checklist. 9. Return final DSL and assumptions. ## Fast Start Templates Use these as scaffolds, then fill in domain details. Flow chart skeleton: ```text Start [shape: oval] Decision? [shape: diamond] End [shape: oval] Start > Decision? Decision? > End: Yes Decision? > End: No ``` ERD skeleton: ```text users { id string pk } orders { id string pk userId string } orders.userId > users.id ``` Architecture skeleton: ```text Client API [icon: aws-api-gateway] Service [icon: aws-lambda] DB [icon: aws-rds] Client > API > Service > DB ``` Sequence skeleton: ```text Client > API: Request activate API API > DB: Query DB > API: Result API > Client: Response deactivate API ``` BPMN skeleton: ```text Requester { Submit [type: activity] } Approver { Review [type: activity] Approved? [type: gateway] Done [type: event] } Submit --> Review Review > Approved? Approved? > Done : Yes ``` ## Quality Checklist (Completion Criteria) - Naming - Names are unique where required by the selected diagram type. - Quoted names are used for reserved/special characters and URLs. - Connectors - Connector semantics match intent. - Flow/architecture/sequence/BPMN use `>`, `<`, `<>`, `-`, `--`, `-->` correctly. - ERD cardinality uses `<`, `>`, `-`, `<>` correctly. - Type-specific validity - ERD attributes stay inside entities and relations use `entity.attribute` where relevant. - Sequence blocks are paired correctly and message labels are added where needed. - BPMN pools/lanes nesting is valid and gateway/event `type` is correct. - Safety and output quality - No unsupported properties are introduced. - Any undefined reference is intentional, not a typo. - Final output is concise and runnable in Eraser. ## Review Mode When asked to review existing Eraser DSL: 1. Identify diagram type and intended semantics. 2. Flag syntax risks, ambiguity, and likely rendering surprises. 3. Provide corrected DSL. 4. Provide a short fix log with issue -> correction. 5. Keep behavior unchanged unless user asks for redesign. ## Failure Recovery If output is likely invalid or unclear: 1. Return a corrected minimal version first. 2. List the top 1-3 blocking issues that were fixed. 3. Add only essential assumptions needed to unblock execution. 4. Avoid introducing new entities, actors, or flows that were not implied. ## References - Core index: [Diagram As Code](./sources/00-diagram-as-code.md) - Intro and scope: [What is diagram as code?](./sources/01-what-is-diagram-as-code.md) - Flow charts: [Flow Charts](./sources/02-flow-charts.md) - ERD: [Entity Relationship Diagrams](./sources/03-entity-relationship-diagrams-erd.md) - Architecture: [Architecture Diagrams](./sources/04-architecture-diagrams.md) - Sequence: [Sequence Diagrams](./sources/05-sequence-diagrams.md) - BPMN: [BPMN Diagrams](./sources/06-bpmn-diagrams-swimlane-diagrams.md) - Icons: [Icons](./sources/07-icons.md) - Styling: [Styling](./sources/08-styling.md) Reference loading guidance: - Load only the doc for the current diagram type plus `07-icons.md` and `08-styling.md` when needed. - Avoid loading every source file unless the request spans multiple diagram types. ## Output Contract Return results in this order: 1. Chosen diagram type (and why in one line). 2. Final Eraser DSL in one fenced code block. 3. Assumptions (only if needed). 4. Optional: one alternative variant if tradeoffs matter. If user asks for only code, return just the DSL block. Consistency rules: - Prefer one canonical naming style per output. - Prefer deterministic ordering (definitions before connections). - Avoid duplicate semantic edges unless explicitly requested.

Security Status