napkin

name	napkin
description	The back-of-napkin senior. Turn any messy plan, strategy, roadmap, or system description into four boxes and three arrows — discrete phases, the gate that unlocks each one, and the flywheel that compounds. A thinking discipline, not a diagram renderer: it draws the line where the plan has no proof (so you stop building ahead of demand) and circles the loop that pays for itself. Token-frugal by design — the model emits a small spec, a script does the drawing. Use whenever the user says "napkin", "napkin this", "sketch this plan", "fit it on a napkin", "phases", "roadmap", "flywheel", "gate this plan", "distill this strategy", "phase-gate", "how does this compound", or pastes a sprawling plan and wants the shape of it.
license	MIT
version	0.3.0
argument-hint	[text or @file] [--lite|--full|--ultra] [--ascii|--mermaid|--svg] [--verbose]
user-invocable	true

napkin

He asks for a napkin and a coffee. He hands your plan back as four boxes and three arrows. If it doesn't fit on a napkin, it's not a plan yet.

Coding agents draw diagrams. napkin makes your agent think in gated progression like a senior who's seen every over-built roadmap and isn't impressed. A renderer turns words into boxes. napkin draws the line where the plan has no proof, and circles the loop that compounds. The diagram is the byproduct. The clarity is the point.

When he wakes up

Make a plan legible — not a technical UML/ERD/architecture render (use a dedicated diagram skill for those). Signals: "napkin this", "sketch this plan", "what are the phases", "gate this", "flywheel", "how does this compound", or a pasted wall of strategy.

How it works: the model thinks, the script draws

You (the model) do the thinking — extract the shape into a small spec. The bundled script does the drawing — deterministic, aligned, any format. That's why napkin is token-frugal: you never hand-emit Mermaid or SVG.

1. Boxes — 3–6 discrete phases, ordered by dependency (not topic). Each gets a short imperative name + one-line "what happens".
2. The line (gate) — on every transition, the condition that unlocks the next phase (a metric, event, or proof — never a date). No condition in the input? Do not invent one — set "ungated": true. That line exposes where the plan assumes success, and it's the single most valuable thing this skill does.
3. The loop (flywheel) — a feedback loop where a later output feeds an earlier input and compounds. No loop? Omit it (the renderer prints "linear — no flywheel"). Never fake one.
4. Tag each box — core (worth it alone) or gated/speculative, so the sketch shows how far the plan is de-risked.
5. Emit the spec, then render (below). Default: --full --ascii.

The spec → render step

Emit a compact JSON spec, then run the renderer:

echo '<SPEC_JSON>' | node scripts/render.mjs - --format ascii

{"title":"optional",
 "phases":[{"id":"p1","name":"MVP","body":"build ──► users ──► WAU","tag":"core"},
           {"id":"p2","name":"Paid","body":"billing ──► first paying","tag":"gated"}],
 "gates":[{"from":"p1","to":"p2","cond":null,"ungated":true}],
 "flywheel":{"from":"p2","loop":["revenue","team","product","revenue"]}}

Formats: --ascii (default, signature, cheapest) · --mermaid · --svg --out f.svg. Intensity is just how much of the spec you fill:

• --lite (alias --minimal) = boxes only
• --full (alias --gated, default) = + gate conds
• --ultra (alias --flywheel) = + the flywheel loop + tags

Fallback (no node): draw the ASCII by hand per reference/ascii-style.md and run its text validation checklist. Prefer the script — it guarantees alignment.

Token economy (this is the point — read these rules)

napkin spends as few of the user's tokens as possible:

• Emit a spec, not a drawing. The script renders Mermaid/SVG — you don't hand-type them (saves ~1–5k output tokens and dodges the 32k output cap that forces other diagram skills into slow section-by-section builds).
• ASCII default. ≈2–3× cheaper than HTML, 5–8× cheaper than SVG. Only go richer when asked.
• No vision loop. We do not render-to-PNG and re-inspect (~1.5–2.5k tokens/round). Validation is a cheap text re-read (see ascii-style.md).
• Progressive disclosure — load reference files ONLY when needed:
  • reference/ladder-patterns.md → only if structure is non-obvious / a named shape is asked.
  • reference/gate-ladder.md → only when unsure how to phrase/classify a gate.
  • reference/flywheel-patterns.md → only on --ultra.
  • reference/render-formats.md → only on --mermaid / --svg.
  • reference/ascii-style.md → only on the hand-drawn fallback. For a normal --full --ascii run you need none of them — emit the spec and render.
• Terse output (default). Return just the sketch. Add prose only with --verbose or when the user asks why.

Rules

• Never invent a gate — ungated transition → "ungated": true, don't paper over it.
• Don't force a flywheel that isn't there — omit it.
• Gates are conditions, not dates ("ARR > $10k", not "by Q3").
• Keep phases ≤ 6; collapse sprawl.
• Match the input's domain language; don't impose generic startup jargon.
• Say little. Be right.

Example

Input: "Ship a free tier for signups, then add team features and charge, then go enterprise with SSO and a sales team." → spec with p1 core, gate p1→p2 ungated, p2 gated, p3 speculative, no flywheel → renders:

PHASE 1 ─ Free tier ──────────────────────────── [CORE · valuable alone]
  signup ──► activation ──► WAU
        │
        ▼  GATE: ⚠️ ungated — building ahead of proof
        │
PHASE 2 ─ Team + paid ────────────────────────────────────────── [GATED]
  ...

More: examples/RAIN-FLYWHEEL.md (full flywheel), examples/saas-onboarding.md.