Prp diagram

Skill Wirasm/prp/.agents/skills/prp-diagram

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.From its SKILL.md

Install

npx -y skills add Wirasm/prp --skill prp-diagram

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

3.4 KB, as published. Nobody here has run it

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.

PRP Diagram — Visual Supplement for a Plan

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.

Resolve the store

# --- 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"

Output path

<plan-basename>.diagrams.md — strip the plan filename's trailing .md, append .diagrams.md.

Plan lives inside $PRP_DIR → write NEXT TO it (same directory).
Plan lives anywhere else → write to $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.

Content policy (strict)

The file contains ONLY:

A single title line: # <plan title> — Diagrams
Per diagram: one bold caption line (**<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.

Choosing diagrams

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"]).

HTML alternative

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.

Report

One line to the user: the expanded absolute output path plus which diagram types were produced.