Eraser dsl

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:

Start [shape: oval]
Decision? [shape: diamond]
End [shape: oval]
Start > Decision?
Decision? > End: Yes
Decision? > End: No

ERD skeleton:

users {
	id string pk
}

orders {
	id string pk
	userId string
}

orders.userId > users.id

Architecture skeleton:

Client
API [icon: aws-api-gateway]
Service [icon: aws-lambda]
DB [icon: aws-rds]
Client > API > Service > DB

Sequence skeleton:

Client > API: Request
activate API
API > DB: Query
DB > API: Result
API > Client: Response
deactivate API

BPMN skeleton:

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
• Intro and scope: What is diagram as code?
• Flow charts: Flow Charts
• ERD: Entity Relationship Diagrams
• Architecture: Architecture Diagrams
• Sequence: Sequence Diagrams
• BPMN: BPMN Diagrams
• Icons: Icons
• Styling: Styling

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.