CtrlK
BlogDocsLog inGet started
Tessl Logo

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.

79

Quality

100%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

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:

  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 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 contentDiagram type
Data-model changes (tables, entities, types, relations)erDiagram or classDiagram
Architecture/component changesflowchart — before/after subgraphs when the plan describes both states
Key flows (request paths, pipelines, interactions)sequenceDiagram
Lifecycle/state rulesstateDiagram-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.

Repository
Wirasm/prp
Last updated
First committed

Is this your skill?

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.