Mermaid flowchart basics

							flowchart TD
  A([Start]) --> B{Ready?}
  B -->|No| C[Gather inputs]
  C --> B
  B -->|Yes| D[Render]
  D --> E([Done])
						

flowchart TD
  A([Start]) --> B{Ready?}
  B -->|No| C[Gather inputs]
  C --> B
  B -->|Yes| D[Render]
  D --> E([Done])

A flowchart shows a process. Steps sit in boxes. Arrows show order. Diamonds ask a yes/no question.

Pick a direction

• flowchart TD — top to bottom (good for short paths)
• flowchart LR — left to right (good for wide pipelines)

You can also write flowchart TB. It means the same as TD.

Name nodes and link them

Give each node an id, then put the label in brackets:

flowchart LR
  A[Collect] --> B[Review]
  B --> C[Publish]

A, B, and C are ids. The text in [] is what readers see. Reuse the same id when you link back to a node.

Useful shapes

Shape	Syntax	Use when
Rectangle	A[Step]	Normal action
Round	A([Start])	Start or end
Diamond	A{Question?}	Decision
Stadium	A([Label])	Soft start/end
Circle	A((Note))	Small status

You do not need every shape. Rectangles and one diamond cover most drafts.

Label the arrows

Put the label between | bars:

flowchart TD
  Ask{Approved?} -->|Yes| Ship[Ship]
  Ask -->|No| Fix[Revise]
  Fix --> Ask

Keep labels short: Yes, No, Retry. Long sentences belong in the boxes, not on the arrows.

Arrow styles

• --> solid arrow
• -.-> dashed arrow
• ==> thick arrow

Dashed links work well for optional paths. Thick links highlight the main path.

Group related steps

Wrap a group in subgraph when a chart grows:

flowchart TD
  subgraph Prep
    A[Draft] --> B[Review]
  end
  B --> C[Publish]

Name the group. Keep groups small. Too many nested boxes make the chart hard to scan.

Writing tips

• One idea per node.
• Prefer verbs: Validate token, not Token validation process.
• If a line wraps three times in the preview, shorten the text.
• Draw the happy path first. Add error branches after it reads clearly.