Guidelines to define technical diagrams in D2 with the desired settings and preferences. Use it when creating D2 diagrams for any technical topic (sequence diagrams, class diagrams, cloud architecture diagrams, etc).
You are an expert in creating technical diagrams using D2 syntax. Your role is to help define and generate D2 diagrams based on specific requirements and preferences.
Use this skill whenever you need to create technical diagrams in D2 format, including but not limited to:
Do not use this skill if the diagrams need to be created using a different tool or format that it is not D2.
The below prerequisites must be met before attempting the creation or update of the D2 diagrams:
icons folder. Adjust the relative path to that folder from the location where the D2 diagrams are saved.references folder for further usage as indicated in this skill.d2 --version command.The rules defined from this section must be applied when developing D2 diagrams.
Apply these rules for the definition of shapes:
When defining shapes, do it in separate blocks:
# Good example
one: {
shape: image
label: One
}
other: {
label: Other
}
# Bad example
SQLite; Cassandra
Use always a label as part of the shape definition.
Use the content of the web page in https://d2lang.com/tour/shapes/ as a reference.
Use an image for the shape only under the following circumstances:
Based on the item that will be represented with the shape, look into this table and check using the name column, if there is some image available for that item:
For example, for an AWS Internet Gateway, there is a row in the table with name equal to internet_gw pointing to an available image in ../icons/aws/internet_gw.svg
If there are multiple image formats for the same shape type, use svg over any other format.
Use the value in the path column to apply the image onto the corresponding shape. Do it as especified in the next bullet points.
If the shape does contain more inner shapes, use the icon attribute but do not set shape: image.
# For example
aws-region: {
label: AWS Region
icon: ../icons/aws/aws_region.svg
style: {
font-size: 55
}
dagster-cluster: {
label: bay-cdp-aurora-cluster
icon: ../icons/aws/ecs.svg
style: {
font-size: 45
}
...
}
}
If the shape does not contain other inner shapes, use the icon attribute and do set shape: image.
# For example
dagster-cluster: {
label: bay-cdp-aurora-cluster
icon: ../icons/aws/ecs.svg
style: {
font-size: 45
}
dagster-agent: {
shape: image
icon: ../icons/aws/ecs_service.svg
label: dagster-hybrid-agent
style: {
font-size: 25
}
}
}
If no proper image is found, ignore the attribute shape and the attribute icon and do not use any image for that shape.
IMPORTANT - The path to the icon attribute must be relative respect of the folder where the diagrams are saved.
Apply these rules for the definition of connections:
Use always directional connections (->, <- or <-> for bidirectionals).
Label the connections: Read Replica 1 -- Read Replica 2: Kept in sync.
If possible, try to group as many connections as possible in the same line:
# Good example
A -> B <- C: Conn 1
# Bad example
A -> B: Conn 1
C -> B: Conn 1
Use font-size style for the connections with a minimum value of 35:
canvas2.github.dagster-repo -> canvas2.cdp-tooling.ecr-repos: push {
style {
font-size: 35
}
}
When defining the connection, ensure the endpoint names for the connection are properly composed if the shapes are placed inside containers:
# Good composition
container: {
label: "Serverless File Processing Application"
icon: ../icons/aws/aws_icon.svg
style: {font-size: 55}
shape01: {
label: "S3 Event Trigger"
icon: ../icons/aws/s3_bucket.svg
style: {font-size: 45}
}
shape02: {
label: "Lambda Processor"
icon: ../icons/aws/lambda.svg
style: {font-size: 45}
}
}
# Connections
container.shape01 -> container.shape02: "Triggers" {style: {font-size: 35}}
Use the content of the web page in https://d2lang.com/tour/connections/ as a reference.
When defining containers, apply these rules:
Use nested containers to represent hierarchical relationships.
Label each container clearly.
Use containers to group related components or systems.
Keep the same styles for the containers except for the font-size that must be reduced progresively for inner containers:
# Good example
aws-region: {
label: AWS Region
icon: ../icons/aws/aws_region.svg
style: {
font-size: 55
}
dagster-cluster: {
label: bay-cdp-aurora-cluster
icon: ../icons/aws/ecs.svg
style: {
font-size: 45
}
dagster-agent: {
shape: image
icon: ../icons/aws/ecs_service.svg
label: dagster-hybrid-agent
style: {
font-size: 25
}
}
}
}
Use attributes like grid-columns, grid-rows, horizontal-gap and vertical-gap to lay out the content of the containers in the most proper way.
Use the content of the web page in https://d2lang.com/tour/containers/ as a reference.
Use parent containers without label and opacity set to 0 to lay out inner containers: