packages/desktop/apps/electron/resources/docs/mermaid.md
Qwen Code renders Mermaid diagrams natively as beautiful themed SVGs. Use this reference for syntax details.
Header: graph LR (left-right, preferred) or graph TD (top-down)
Directions: LR (preferred), RL, TD, TB, BT
| Syntax | Shape |
|---|---|
A[text] | Rectangle |
A(text) | Rounded rectangle |
A{text} | Diamond (decision) |
A([text]) | Stadium |
A((text)) | Circle |
A[[text]] | Subroutine |
A[(text)] | Cylinder (database) |
A{{text}} | Hexagon |
A>text] | Asymmetric flag |
A[/text\] | Trapezoid |
A[\text/] | Trapezoid (alt) |
A(((text))) | Double circle |
| Syntax | Style |
|---|---|
--> | Solid arrow |
--- | Solid line (no arrow) |
-.-> | Dotted arrow |
-.- | Dotted line |
==> | Thick arrow |
=== | Thick line |
<--> | Bidirectional solid |
<-.-> | Bidirectional dotted |
<==> | Bidirectional thick |
graph LR
A -->|label text| B
C -- label text --> D
graph LR
subgraph Backend
API --> DB
end
subgraph Frontend
UI --> API
end
Client --> UI
graph TD
subgraph backend-services [Backend Services]
direction LR
API --> Cache
API --> DB
end
graph LR
A[Start]:::highlight --> B[End]
classDef highlight fill:#f9f,stroke:#333
style B fill:#bbf,stroke:#333
graph LR
A --> B --> C --> D
graph LR
A & B --> C & D
Header: stateDiagram-v2
stateDiagram-v2
[*] --> Idle
Idle --> Processing: start
Processing --> Complete: done
Processing --> Error: fail
Complete --> [*]
Error --> Idle: retry
stateDiagram-v2
state "Waiting for input" as Waiting
Waiting --> Processing
stateDiagram-v2
state "Active" as Active {
Running --> Paused: pause
Paused --> Running: resume
}
[*] --> Active
Active --> [*]: complete
stateDiagram-v2
direction LR
[*] --> A --> B --> [*]
Header: sequenceDiagram
| Syntax | Meaning |
|---|---|
->> | Solid line, solid arrowhead |
-->> | Dotted line, solid arrowhead |
-) | Solid line, open arrowhead (async) |
--) | Dotted line, open arrowhead |
-x | Solid line with X (lost message) |
--x | Dotted line with X |
sequenceDiagram
participant C as Client
participant S as Server
participant DB as Database
C->>S: POST /api/users
S->>DB: INSERT user
DB-->>S: OK
S-->>C: 201 Created
sequenceDiagram
Client->>+Server: Request
Server->>+Database: Query
Database-->>-Server: Results
Server-->>-Client: Response
sequenceDiagram
Alice->>Bob: Hello
Note right of Bob: Bob thinks
Bob-->>Alice: Hi!
Note over Alice,Bob: Conversation complete
sequenceDiagram
loop Every minute
Client->>Server: Heartbeat
Server-->>Client: ACK
end
sequenceDiagram
Client->>Server: Request
alt Success
Server-->>Client: 200 OK
else Failure
Server-->>Client: 500 Error
end
sequenceDiagram
opt If cached
Server-->>Client: Cached response
end
sequenceDiagram
par Parallel requests
Client->>ServiceA: Request A
and
Client->>ServiceB: Request B
end
Header: classDiagram
classDiagram
class Animal {
+String name
+int age
+makeSound() void
+move(distance) void
}
| Symbol | Meaning |
|---|---|
+ | Public |
- | Private |
# | Protected |
~ | Package/Internal |
| Syntax | Meaning |
|---|---|
<|-- | Inheritance (extends) |
*-- | Composition (contains) |
o-- | Aggregation (has) |
--> | Association |
..> | Dependency |
..|> | Realization (implements) |
-- | Link (solid) |
.. | Link (dashed) |
classDiagram
Customer "1" --> "*" Order : places
Order "1" *-- "1..*" LineItem : contains
classDiagram
class Animal {
<<abstract>>
+String name
+int age
+makeSound()* void
}
class Dog {
+String breed
+bark() void
}
class Cat {
+bool indoor
+meow() void
}
Animal <|-- Dog
Animal <|-- Cat
classDiagram
class Service {
<<interface>>
+start() void
+stop() void
}
class Logger {
<<singleton>>
-instance Logger
+log(msg) void
}
Header: erDiagram
erDiagram
USER ||--o{ ORDER : places
ORDER ||--|{ LINE_ITEM : contains
PRODUCT ||--o{ LINE_ITEM : "is in"
| Left | Right | Meaning |
|---|---|---|
|| | || | Exactly one to exactly one |
|| | o| | Exactly one to zero or one |
|| | o{ | Exactly one to zero or more |
|| | |{ | Exactly one to one or more |
o| | o| | Zero or one to zero or one |
o| | o{ | Zero or one to zero or more |
o{ | o{ | Zero or more to zero or more |
erDiagram
USER {
int id PK
string email UK
string name
datetime created_at
}
ORDER {
int id PK
int user_id FK
decimal total
date created_at
}
USER ||--o{ ORDER : places
Common attribute markers:
PK - Primary KeyFK - Foreign KeyUK - Unique KeyerDiagram
CUSTOMER {
int id PK
string email UK
string name
string phone
}
ORDER {
int id PK
int customer_id FK
date order_date
string status
}
PRODUCT {
int id PK
string name
decimal price
int stock
}
LINE_ITEM {
int id PK
int order_id FK
int product_id FK
int quantity
decimal unit_price
}
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ LINE_ITEM : contains
PRODUCT ||--o{ LINE_ITEM : "included in"
IMPORTANT: Use horizontal layouts (LR, RL) whenever possible. Horizontal diagrams are much easier to view and navigate in the UI.
graph LR (left-right) instead of graph TD (top-down)direction LR after the headerOnly use vertical layouts (TD, BT) when:
One concept per diagram. If a diagram gets complex, split it into multiple diagrams.
graph LR
A[User submits form] --> B{Validation}
B -->|Valid| C[Save to database]
B -->|Invalid| D[Show errors]
Horizontal (preferred):
Vertical (use sparingly):
Use the mermaid_validate tool to check syntax before outputting complex diagrams:
mermaid_validate({ code: "graph TD\n A --> B" })
graph TD, not just graph)[, (, { are properly closedFor labels with special characters, wrap in quotes:
graph LR
A["Label with (parentheses)"] --> B["Label with [brackets]"]