Wirasm 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) ---
# Adopt the store that already records this root; mint a key only when none does.
_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/-*$//')"
_home="${PRP_HOME:-$HOME/.prp}"
_hit="$(grep -lsF "\"path\": \"$_root\"" "$_home"/*/project.json 2>/dev/null | head -1)"
PRP_DIR="${_hit%/project.json}"
[ -n "$PRP_DIR" ] || PRP_DIR="$_home/${_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.