Prompt templates that get Claude or Copilot to draw the diagram you actually need

Background

"Can you diagram this process for me" is one of the most common things people ask an AI tool to do, and one of the most commonly disappointing answers they get back - a numbered list dressed up with arrow characters, or a generated image that looks plausible until you try to read the actual labels. The model isn't being lazy. It's answering the question you actually asked, which was for a description, not a diagram.

The fix is to stop asking for a picture and ask for Mermaid - a plain text syntax for flowcharts, sequence diagrams, timelines and half a dozen other diagram types that GitHub, GitLab, Confluence, Notion and most modern documentation tools render automatically. Claude and Copilot are both good at writing it, because it's structured text with a fixed grammar, not an image-generation task they're guessing their way through.

The second fix, once you've got Mermaid working once, is to stop writing a fresh prompt from scratch every time. A prompt with the same five parts every time - role, context, the specific inputs, the task, and the output format - turns into a template you reuse with new inputs, not a one-off you have to reconstruct from memory next time you need a diagram. The templates below are built that way: copy one, fill in the brackets, done.

Setup

The shape every template below follows:

• Role - tell it what kind of diagram-builder to be. This isn't decoration; it steers which conventions it defaults to.
• Context - what you're handing it and what you want back (a Mermaid code block you can preview and paste, not prose).
• Inputs - the actual specifics of your process, in brackets, so the model isn't guessing at anything you already know.
• Task - the diagram's actual shape: what counts as a node, what counts as a decision, what the endpoints are.
• Constraints - the failure modes to rule out up front: valid syntax, every branch labelled, no dead ends.

Process flowchart

For a straightforward "this happens, then this, then a decision" process:

You're mapping an operational process into a Mermaid flowchart.

Context: I'll describe a real process. Return it as a Mermaid `flowchart TD`
code block I can preview directly and paste into a doc - nothing else needed.

Inputs:
- Process: [e.g. JOINER ACCOUNT SETUP]
- Trigger and who starts it: [ACTOR AND EVENT]
- Steps in order, as you know them: [LIST - OUT OF ORDER IS FINE]
- Decision points and their branches: [e.g. NEEDS MANAGER SIGN-OFF? YES/NO]
- End states: [e.g. ACCOUNT LIVE, REJECTED, ESCALATED]

Task: build a top-to-bottom flowchart - rectangles for actions, diamonds for
decisions with both branches labelled, rounded nodes for each end state. If
an obvious step is missing (an approval, an error path), add it and flag
that you did.

Constraints: valid flowchart TD syntax that renders without edits. Plain
language in every label. No orphan nodes - every path reaches an end state.

Decision tree

For "which of several outcomes applies, based on a series of questions" - picking a plan, routing a ticket, choosing an access level:

You're building a decision tree that resolves to exactly one outcome.

Context: return a Mermaid `flowchart` where every path from the root
question ends at exactly one recommendation - mutually exclusive, no
overlap.

Inputs:
- The decision: [e.g. WHICH ACCESS TIER A NEW STARTER GETS]
- The questions that drive it, in the order that narrows fastest:
  [LIST]
- Possible answers per question: [e.g. YES/NO, OR A RANGE]
- Final outcomes: [LIST THE LEAVES]

Task: root question first, diamonds branching on each answer, terminal
nodes styled differently from questions. Every branch has to be reachable
and every leaf has to be reached by exactly one path.

Constraints: valid flowchart syntax. Every edge labelled with the answer it
represents. Flag any question that doesn't actually narrow anything, so it
can be cut.

Swimlane / cross-team handoff diagram

For a process where the thing that actually goes wrong is a handoff between teams, not any single step:

You're mapping a cross-team process, and the handoffs matter as much as the
steps.

Context: return a Mermaid `flowchart` using one subgraph per team as a lane,
so it reads like a swimlane diagram.

Inputs:
- Process: [e.g. LEAVER OFFBOARDING]
- Teams/roles involved (the lanes): [LIST]
- Steps and who owns each: [STEP -> OWNER]
- Where work crosses from one team to another: [DESCRIBE]
- Trigger and end state: [DESCRIBE]

Task: one subgraph per team, each step placed in its owning lane, edges
crossing lanes wherever a handoff happens. Make the cross-lane edges the
most visually obvious thing on the diagram, not an afterthought.

Constraints: every step sits in exactly one lane. No lane left empty. Call
out which team is carrying the most steps, and which handoff looks like the
one most likely to get dropped.

Approval / escalation workflow

For anything with sign-off, rejection loops, or a path that escalates to a more senior approver:

You're mapping a multi-stage approval process with conditional routing.

Context: return a Mermaid `flowchart` covering submission through to a final
approved state, including what happens on rejection.

Inputs:
- What's being approved: [e.g. A PURCHASE REQUEST]
- Stages and approvers: [STAGE -> ROLE]
- Conditions that change the route: [e.g. AMOUNT, RISK LEVEL]
- What happens on rejection: [REVISE AND RESUBMIT, OR HARD STOP]
- Approved end state: [DESCRIBE]

Task: a submit node, routing diamonds that send the request down different
paths based on the actual rules, a rejection loop back to the requester, and
one clearly marked approved end state. Show escalation to a more senior
approver where the rules call for it.

Constraints: valid syntax. Rejection loops visually distinct from forward
edges. Flag any loop that could run forever with no exit condition - that's
a real bug in the process, not just the diagram.

Other diagram styles - same pattern, different Mermaid type

The template shape above works for almost anything - swap the diagram type and adjust what counts as a "node" for that shape:

• Sequence diagram (sequenceDiagram) - for showing what calls what, and in what order, between systems or people over time. Inputs become the actors and the messages passed between them, not process steps.
• State diagram (stateDiagram-v2) - for something with a lifecycle - a ticket's states, an order's states. Inputs become the states and the events that move something from one to another.
• Entity-relationship diagram (erDiagram) - for a database schema. Inputs become the tables, their key fields, and how they relate (one-to-many, many-to-many).
• Gantt chart (gantt) - for a project timeline. Inputs become tasks, durations, and dependencies between them.
• Mindmap (mindmap) - for a brainstorm or a topic breakdown, where there's no real sequence, just a hierarchy of ideas branching from one centre.