Generate a mermaid-only visual supplement for a plan artifact - the data-model, architecture, and flow diagrams a human wants when absorbing a plan. Use when the user wants to "diagram this plan", "visualize the plan", "draw the plan's architecture", "make diagrams for this plan", or invokes $prp-diagram.
80
100%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Arguments:
$ARGUMENTS(and$1,$2, ...) refer to the arguments given when this skill was invoked. Take them from the user's request; if absent, infer them from the conversation.
Input: $ARGUMENTS — a path to a plan/PRD markdown file. If blank, use the most recent file in $PRP_DIR/plans/.
One agent, one pass, no subagents. Read the plan, produce the diagrams a human wants beside it while absorbing it. Nothing else.
# --- PRP store resolver (canonical; keep byte-identical across skills) ---
_gd="$(git rev-parse --path-format=absolute --git-common-dir 2>/dev/null)"
case "$_gd" in */.git) _root="${_gd%/.git}" ;; "") _root="$PWD" ;; *) _root="$_gd" ;; esac
_root="$(cd "$_root" && pwd -P)"
_name="$(basename "$_root" | tr '[:upper:]' '[:lower:]' | tr -cs 'a-z0-9' '-' | sed 's/^-*//;s/-*$//')"
PRP_DIR="${PRP_HOME:-$HOME/.prp}/${_name:-project}-$(printf %s "$_root" | git hash-object --stdin | cut -c1-8)"
mkdir -p "$PRP_DIR"; [ -f "$PRP_DIR/project.json" ] || printf '{"path": "%s", "name": "%s"}\n' "$_root" "${_name:-project}" > "$PRP_DIR/project.json"<plan-basename>.diagrams.md — strip the plan filename's trailing .md, append .diagrams.md.
$PRP_DIR → write NEXT TO it (same directory).$PRP_DIR/plans/ (mkdir -p "$PRP_DIR/plans").Overwrite on re-run without asking — this is a derived artifact; the plan is the source of truth.
The file contains ONLY:
# <plan title> — Diagrams**<what this shows>**), then one ```mermaid fence.No prose paragraphs, no recommendations, no analysis, no legend sections. Diagrams supplement the plan — they never editorialize it.
Diagram only what the plan actually contains — never invent entities, flows, or states the plan doesn't describe. Skip any category the plan doesn't support.
| Plan content | Diagram type |
|---|---|
| Data-model changes (tables, entities, types, relations) | erDiagram or classDiagram |
| Architecture/component changes | flowchart — before/after subgraphs when the plan describes both states |
| Key flows (request paths, pipelines, interactions) | sequenceDiagram |
| Lifecycle/state rules | stateDiagram-v2 |
Keep each diagram legible: ~40 nodes max — split into two diagrams rather than cram one. Mermaid syntax must be valid: prefer simple constructs over clever ones, and quote labels containing special characters (A["label (with) specials"]).
Only when the user explicitly asks for .html: write a single self-contained html file at the same path with .diagrams.html instead. Same content policy — a title, then per diagram a caption and a <pre class="mermaid"> block. Do NOT embed or link mermaid.js (no CDN, no scripts) — the consuming UI provides the renderer; add an html comment noting that.
One line to the user: the expanded absolute output path plus which diagram types were produced.
1142738
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.