
Eraser Diagrams
Generate Eraser-compatible architecture diagrams from text syntax for READMEs, specs, and stakeholder reviews.
Overview
Eraser Diagrams is an agent skill most often used in Build (also Validate scope, Launch distribution) that produces Eraser.io architecture diagrams from structured node-and-group syntax.
Install
npx skills add https://github.com/eraserlabs/eraser-io --skill eraser-diagramsWhat is this skill?
- Defines nodes with unique names plus icon and color properties
- Nested groups containerize services, VPCs, and subsystems
- Cloud icon vocabulary (e.g. aws-ec2, aws-rds) for quick infra sketches
- Connection syntax for flows between nodes and groups
- Text-first diagrams agents can emit into repos or Eraser
Adoption & trust: 2.4k installs on skills.sh; 22 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know how your system fits together but lack a fast, versionable way to draw architecture diagrams your agent can maintain.
Who is it for?
Indie SaaS and API builders documenting AWS-style stacks, microservices, or agent pipelines in markdown repos.
Skip if: Teams needing pixel-perfect UI mockups or automatic live inventory sync from a cloud account without manual syntax.
When should I use this skill?
User needs Eraser.io-style architecture diagrams defined as text with nodes, groups, icons, colors, and connections.
What do I get? / Deliverables
You get valid Eraser diagram source—nodes, groups, icons, and links—ready to paste into Eraser or docs.
- Eraser diagram source with nodes and nested groups
- Updated markdown or spec section with architecture figure
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Docs is the primary shelf because the skill teaches diagram DSL for communicating system design artifacts builders ship with the product. Architecture diagrams in build/docs support onboarding, PRDs, and infra explanations without opening a separate design tool manually.
Where it fits
Sketch VPC, app tier, and database groups to sanity-check scope before committing to a cloud bill.
Add an architecture section to the repo README with nested groups for API, workers, and data stores.
Produce a clean topology diagram for a launch post or onboarding doc for design partners.
How it compares
Use for text-native architecture DSL instead of asking the model for one-off ASCII art that does not import into Eraser.
Common Questions / FAQ
Who is eraser-diagrams for?
Solo builders and tiny teams who document infra and product architecture in git and want Eraser-compatible diagram source from their coding agent.
When should I use eraser-diagrams?
While scoping Validate prototypes, writing Build docs/README architecture sections, or preparing Launch materials that explain how your app and cloud resources connect.
Is eraser-diagrams safe to install?
It is documentation syntax only; still review the Security Audits panel on this page before installing skills from third-party repos.
SKILL.md
READMESKILL.md - Eraser Diagrams
# Architecture diagram syntax ## Nodes A node is the most basic building block in a cloud architecture diagram. Node definitions consist of a name followed by an optional set of properties. For example, `compute` is the name of below node and it has an `icon` property which is set to `aws-ec2`. ``` compute [icon: aws-ec2] ``` Node names are required to be unique. Nodes support `icon` and `color` properties. ## Groups A group is a container that can encapsulate nodes and groups. Group definitions consist of a name followed by `{ }`. For example, `Main Server` is the name of the below group and it contains `Server` and `Data` nodes. ``` Main Server { Server [icon: aws-ec2] Data [icon: aws-rds] } ``` Group names are required to be unique. Groups can be nested. In the below example, `VPC Subnet` group contains `Main Server` group. ``` VPC Subnet { Main Server { Server [icon: aws-ec2] Data [icon: aws-rds] } } ``` Groups support `icon` and `color` properties. ## Properties Properties are key-value pairs enclosed in `[ ]` brackets that can be appended to definitions of nodes and groups. Properties are optional. It is possible to set multiple properties like shown below: ``` Main Server [icon: aws-ec2, color: blue] { Server [icon: aws-ec2] Data [icon: aws-rds] } ``` Here are the properties that are allowed: | Property | Description | Value | Default value | |----------|-------------|-------|---------------| | icon | Attached icons | Icon names (e.g. aws-ec2). | | | color | Stroke and fill color | Color name (e.g. blue) or hex code (e.g. "#000000"- note the quote marks for hex codes) | | | label | Text label | Any string. Enclose in double quotes (e.g. "Main Server") if containing a space. Allows multiple nodes and groups to have the same label. | Name of node or group | | link | Internal or external link | A fully fledged URL. Enclose in double quotes (e.g. "https://my-internal-docs.io/api-docs". Supports the full gamut of external links and Eraser-specific links: diagrams, headers, and files in Eraser. | | | colorMode | Fill color lightness | pastel, bold, outline | pastel | | styleMode | Embellishments | shadow, plain, watercolor | shadow | | typeface | Text typeface | rough, clean, mono | rough | The `label` property is useful if you want the node's (or group's) label and name to be distinct. By default, the `label` is set as the node name. But because node names are required to be distinct, you will need to use the `label` property if you have two nodes with the exact same label. ``` // Names need to be distinct, but labels can overlap Server_A [label: server] Server_B [label: server] ``` It is possible to set multiple properties by separating them using `,` like shown below: ``` Server [icon: server, typeface: mono] ``` ## Connections Connections represent relationships between nodes and groups. They can be created between nodes, between groups, and between nodes and groups. Here is an example of a connection between two nodes: ``` Compute > Storage ``` Here are the types of connectors: | Connector | Syntax | Description | |-----------|--------|-------------| | | `>` | Left-to-right arrow | | | `<` | Right-to-left arrow | | | `<>` | Bi-directional arrow | | | `-` | Line | | | `--` | Dotted line | | | `-->` | Dotted arrow | It is possible to add a label to a connection. Here is an example: ``` Storage > Server: Cache Hit ``` It is possible to create one-to-many connections in a single statement. This is instead of creating separate one-to-one connections. Here is an example: ``` Server > Worker1, Worker2, Worker3 ``` If a connection statement contains a name that has not been previously defined as a node or a group, a blank node with that name will be created. Here are the properties that are allowed on connections (lines): | Property | Description | Example | |----------|-------------|---------| | color | Line color | `Storage > Server: Cache Hit [color: gre