How do I install the Prp Diagram skill?

Run npx skillmds@latest add wirasm/prp-diagram-3 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Prp Diagram safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Prp Diagram?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Prp Diagram free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Prp Diagram?

Wirasm (@wirasm) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Prp Diagram by wirasm — Agent Skill

Name: Prp Diagram
Author: Wirasm

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.

Wirasm Updated Sep 21, 2026

File contents

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.

---name: prp-diagram-3description: 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.---# 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```bash# --- 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:1. A single title line: `# <plan title> — Diagrams`2. 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 diagramsDiagram 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 alternativeOnly 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.## ReportOne line to the user: the expanded absolute output path plus which diagram types were produced.

Frequently asked questions