shield_lock
金大哥
← 返回 Skill 列表
extension
分类: 效率与办公无需 API Key

plan-diagram

Generate a visual plan diagram in a dark, hand-drawn (excalidraw) house style. Graphs any logic (not tied to a specific project); prose is written in whatever language the plan is in — English, Chinese, Russian, etc., with full RTL (right-to-left) support. Use when the user asks to turn a plan, flow, decision order, architecture, or multi-system design into an HTML diagram ("plan diagram", "flow chart", "diagram", "流程图", "示意图", or the equivalent in any language). Picks between a vertical FLOW layout (single decision path) and a pan/zoom BOARD layout (multiple parallel coexisting systems), fills the chosen template, writes the HTML into the project, and validates structure.

person作者: anc1024hubgithub
open_in_new仓库download下载资源包

plan-diagram

Turn any plan / flow / decision order / architecture into an HTML diagram in a dark, hand-drawn (excalidraw) house style. The style is fixed; the content and language are not — this skill graphs arbitrary logic and writes the prose in whatever language the source plan uses (English, Chinese, Russian, … — RTL scripts are fully supported). The two templates in references/ define the visual language:

  • references/flow-template.html — vertical FLOW (single decision path)
  • references/board-template.html — pan/zoom BOARD (parallel coexisting systems)

Workflow

  1. Understand the content and note the language. Read the plan the user gives (a .md, a description, or existing docs). Write the diagram in the same language as the plan (or the language the user asks for). Set {{LANG}}/{{DIR}} accordingly (rtl for right-to-left scripts, ltr otherwise). Ask one question only if the layout choice is genuinely ambiguous.
  2. Choose the layout (this is the most important decision — see "Layout choice" below).
  3. Load the design language: references/design-system.md. Load the matching template:
    • FLOW → references/flow-template.html
    • BOARD → references/board-template.html
  4. Fill the template. Replace every {{PLACEHOLDER}} — both the content and the chrome labels (toolbar hint, zoom titles, read-order / overview / decisions labels, the "parallel — coexist" badge) — in the plan's language. Keep every concrete decision (durations, limits, security rules, config requirements, API addresses) — condense wording, never drop facts. Dense prose → .note blocks; reachable results → .sketch.ok / .res.
  5. Write the HTML into the project: docs/html/<name>.html if the project has a docs/ folder (kebab-case, matching the plan's topic); otherwise any sensible docs location or the path the user asks for.
  6. Validate with the script in this skill's base directory (the path given when the skill was invoked): python3 <skill-base-dir>/scripts/validate.py <output>.html Fix anything it flags (unbalanced braces/divs, leftover {{...}} placeholders, missing entry point) before reporting done.

Layout choice — the core decision

Explicit request wins. If the user names a layout ("board", "graph", "flow", or the equivalent in the plan's language), use that layout — even if the auto-rule below would pick the other one. Only when nothing is specified, decide by content shape:

Ask: is the content one path, or a map of coexisting things?

| Content shape | Layout | Template | |---|---|---| | A single ordered decision path: ①→②→③, "check this first, then that", branch/stop | FLOW (vertical) | flow-template.html | | Several systems that exist at the same time (A / B / A+), a 2-D relationship, "these run in parallel" | BOARD (pan/zoom canvas) | board-template.html |

  • If it reads top-to-bottom as "do X, if Y then Z" → FLOW. Example: an access-check order (check A first, then B, branch or stop) or a step-by-step solution to a puzzle.
  • If it's "system A does this, system B does that, both coexist, here's how they relate" → BOARD. Example: a login architecture where several auth methods live together at the same time.
  • When unsure, prefer FLOW — it reads more easily. Only reach for BOARD when the content genuinely is a 2-D map that a vertical list would distort.

Hard rules

  • Write in the plan's language, set direction to match. Fill {{LANG}}/{{DIR}} from that language; use dir="rtl" for right-to-left scripts, dir="ltr" otherwise. Latin/code tokens always read LTR. Don't force any one language or script — the style is fixed, the words are not.
  • Fill every {{PLACEHOLDER}}, including chrome. The validator fails on any leftover {{...}}, which is what stops an untranslated toolbar/label from shipping.
  • Keep the design language exact. Same CSS variables, same .sketch/.q/.branch/.res/.dlg/ .note/.divider classes, same color meanings (see references/design-system.md). Do not invent a new visual style.
  • Every diagram has a visible entry point. FLOW: the h1 + first .step. BOARD: the .readpath 🧭 read-order badge at the top, and start() fits the whole board on load (no pan/zoom skill needed to grasp the structure).
  • Preserve real decisions. Notes carry facts (durations, limits, security exclusions, config requirements, etc.). Condense wording, never delete a fact.
  • Color = logic, not decoration. Blue = decision node / path A; violet = path B / alternate; green = reached/completed result; red = "no" branch / expired; gold = notes & API addresses.
  • Self-contained HTML. Inline <style> and <script>, single Google-fonts link for Vazirmatn. No build step, no framework.

Validation

Always run before reporting done:

python3 <skill-base-dir>/scripts/validate.py <output>.html

(<skill-base-dir> = this skill's base directory, shown when the skill is invoked.)

It checks: balanced {} / () / [], balanced <div>/</div>, no leftover {{...}} placeholders, and (for BOARD) the presence of the .readpath entry badge and a full-view start(). A clean run prints OK. The checks are language-agnostic — a diagram may be in any language.