一键在 Manus 中运行任何 Skill

excalidraw-diagrams

星标2

分支1

更新时间2026年4月23日 07:24

Draw polished, hand-drawn-style Excalidraw diagrams for any technical or conceptual topic. Use this skill whenever the user asks to "draw", "diagram", "visualise", "make an Excalidraw", or "sketch" something. Triggers include: system architecture, data flows, pipelines, concept maps, process flows, comparisons, and any request for a visual explanation. Always run the full three-phase approach: ASCII preview → wait for approval → draw. Never skip to drawing without the ASCII step first.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

pytholic

pytholic/claude-skills

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Excalidraw Diagrams

Core Principle

SHOW BEFORE DRAW. ALWAYS PRODUCE AN ASCII SKETCH FIRST AND WAIT FOR EXPLICIT USER APPROVAL BEFORE DRAWING.

"Looks good", "go ahead", "yes", "draw it" count as approval. Silence or a follow-up question does not.

Phase 1: ASCII Preview

Sketch the diagram in ASCII. Choose layout direction first:

Left → Right	Top → Down
Pipelines, data flows, layered systems (User / Agent / Storage)	Hierarchies, decision trees, sequential steps
2–4 distinct layers	4+ sequential steps or branching

State the choice explicitly, e.g. "Using left-to-right — three-layer system."

ASCII conventions:

[Box]        node
[[ Zone ]]   background container / group
---->        arrow
- - ->       dashed arrow (secondary/indirect)
[i]          side annotation box

After the ASCII, state:

Layout direction and why
Color zones planned (one per logical group)
Any side annotation boxes

Close with: "Does this look right? Any changes before I draw?"

Do not proceed until the user explicitly approves. If they request changes, revise the ASCII and ask again.

Phase 2: Draw

Call Excalidraw:read_me first to load the element format, then call Excalidraw:create_view.

Style preferences to apply:

Fonts: Always fontFamily: 1 (Excalifont) for all text — titles, zone labels, node labels, annotations. Use fontFamily: 3 (monospace) only for command/code names like kb:compile.

Font sizes: titles ≥ 20, node labels ≥ 16, annotations ≥ 14. Never below 14.

Roughness: Always roughness: 1. Never 0 (sterile) or 2 (messy).

Zone backgrounds: One per logical group. Always opacity: 35, fillStyle: "solid", roundness: { type: 3 }.

Zone	Background	Stroke
Input / User	`#dbe4ff`	`#4a9eed`
Agent / Logic	`#e5dbff`	`#8b5cf6`
Storage / Knowledge	`#d3f9d8`	`#22c55e`
Output / Result	`#c3fae8`	`#06b6d4`
Annotation / Note	`#fff3bf`	`#f59e0b`

Node fills (inside zones):

Node type	Fill
Input	`#a5d8ff`
Agent command	`#d0bfff`
Storage	`#b2f2bb`
Output	`#c3fae8`
Note/callout	`#fff3bf`
Neutral	`#e9ecef`

Arrows: strokeWidth: 2 for primary, strokeWidth: 1 + strokeStyle: "dashed" for secondary. Match stroke color to source node's zone color.

Side annotation boxes: Place outside the main flow (right or below) with a dashed leader arrow in #f59e0b. Use for "more info" that would clutter the main diagram.

Drawing order:

cameraUpdate (always first)
Title + subtitle
Zone backgrounds (back to front)
Zone labels (top-left inside each zone)
Nodes (left→right, top→bottom within zone)
Arrows
Side annotation boxes
Final cameraUpdate zoom-out

Use intermediate cameraUpdate calls to pan into each zone as you draw it — this makes the drawing feel alive as it streams in.

Process Violations

Drawing before receiving explicit approval
Treating silence as approval
Re-drawing after ASCII revision without asking again
More than 4 distinct node fill colors (visual noise)
Font sizes below 14
Camera sizes not exactly S/M/L/XL/XXL (non-4:3 distorts)
Separate text elements where a labeled shape would worki

同仓库更多 Skills

同仓库

python-code-review

pytholic/claude-skills

Reviews Python code changes for quality, correctness, and adherence to project conventions before commits or PRs. Checks for SOLID violations, DRY/YAGNI issues, missing tests, type safety, security concerns, and style compliance. Use when reviewing diffs, preparing PRs, after implementing features, or when the user asks to review code. Python-specific — covers ruff, pyright, pytest, and modern Python 3.13+ idioms by default (falls back to the project's pyproject.toml `requires-python` floor if it pins something lower). For deep silent-failure hunting or type-invariant design, use code-review's targeted agents instead.

2026-07-092

planning-and-task-decomposition

pytholic/claude-skills

Turn clear requirements into an ordered, verifiable implementation plan. Use when a spec or well-understood goal needs decomposition before coding — when the task feels too large to start, the order of work isn't obvious, or scope must be communicated. Trigger phrases include: "plan this", "break this down", "make an implementation plan", "how should we implement this", "create a task list", "what order should we build this in". This skill defines HOW to build and in what order — it assumes WHAT to build is already pinned down. If requirements are loose, unverified, or missing, first run the task-scoping skill (task-scope-and-spec: scope a loose engineering task into a tight, testable spec list) or gather inputs per the Input Gate below.

2026-07-072

task-scope-and-spec

pytholic/claude-skills

Scope a loose engineering task into a tight, testable spec list. Use when the user gives background for a piece of work and wants the requirements narrowed down before implementation. Trigger phrases include: "scope this", "what are the specs", "what's involved", "what would it take", "what's left for this task", "port this to", "bring this logic to", and "spec this ticket/issue". This skill defines WHAT must be true when the work is done — it does not produce an implementation plan, task ordering, or execution steps. For sequencing the specs into ordered, verifiable tasks, use planning-and-task-decomposition instead.

2026-07-072

hac-init

pytholic/claude-skills

Bootstrap the .hac/ (Human-Agent Context) directory in any project. Use when the user says "set up hac", "add .hac", "set up working memory", "initialize hac", or when beginning multi-session work on a project that lacks a .hac/ directory. Language-agnostic — works for Python, TypeScript, Go, Rust, or any project type. Also trigger when migrating existing plan files into .hac/ or when resetting a stale .hac/ directory.

2026-07-032

write-tests

pytholic/claude-skills

Write focused pytest tests covering critical paths, edge cases, and error handling. Avoids redundant tests that bloat codebase. Use for creating minimal but comprehensive test coverage of complex logic, public APIs, and failure scenarios.

2026-06-232

pr-description

pytholic/claude-skills

Generates a minimal, clear PR description from the current branch's diff and the repo's PR template. Use at the end of any task when the user wants to open a PR or needs a PR description written.

2026-06-222

name

excalidraw-diagrams

description

Excalidraw Diagrams

Core Principle

SHOW BEFORE DRAW. ALWAYS PRODUCE AN ASCII SKETCH FIRST AND WAIT FOR EXPLICIT USER APPROVAL BEFORE DRAWING.

"Looks good", "go ahead", "yes", "draw it" count as approval. Silence or a follow-up question does not.

Phase 1: ASCII Preview

Sketch the diagram in ASCII. Choose layout direction first:

Left → Right	Top → Down
Pipelines, data flows, layered systems (User / Agent / Storage)	Hierarchies, decision trees, sequential steps
2–4 distinct layers	4+ sequential steps or branching

State the choice explicitly, e.g. "Using left-to-right — three-layer system."

ASCII conventions:

[Box]        node
[[ Zone ]]   background container / group
---->        arrow
- - ->       dashed arrow (secondary/indirect)
[i]          side annotation box

After the ASCII, state:

Layout direction and why
Color zones planned (one per logical group)
Any side annotation boxes

Close with: "Does this look right? Any changes before I draw?"

Do not proceed until the user explicitly approves. If they request changes, revise the ASCII and ask again.

Phase 2: Draw

Call Excalidraw:read_me first to load the element format, then call Excalidraw:create_view.

Style preferences to apply:

Fonts: Always fontFamily: 1 (Excalifont) for all text — titles, zone labels, node labels, annotations. Use fontFamily: 3 (monospace) only for command/code names like kb:compile.

Font sizes: titles ≥ 20, node labels ≥ 16, annotations ≥ 14. Never below 14.

Roughness: Always roughness: 1. Never 0 (sterile) or 2 (messy).

Zone backgrounds: One per logical group. Always opacity: 35, fillStyle: "solid", roundness: { type: 3 }.

Zone	Background	Stroke
Input / User	`#dbe4ff`	`#4a9eed`
Agent / Logic	`#e5dbff`	`#8b5cf6`
Storage / Knowledge	`#d3f9d8`	`#22c55e`
Output / Result	`#c3fae8`	`#06b6d4`
Annotation / Note	`#fff3bf`	`#f59e0b`

Node fills (inside zones):

Node type	Fill
Input	`#a5d8ff`
Agent command	`#d0bfff`
Storage	`#b2f2bb`
Output	`#c3fae8`
Note/callout	`#fff3bf`
Neutral	`#e9ecef`

Arrows: strokeWidth: 2 for primary, strokeWidth: 1 + strokeStyle: "dashed" for secondary. Match stroke color to source node's zone color.

Side annotation boxes: Place outside the main flow (right or below) with a dashed leader arrow in #f59e0b. Use for "more info" that would clutter the main diagram.

Drawing order:

cameraUpdate (always first)
Title + subtitle
Zone backgrounds (back to front)
Zone labels (top-left inside each zone)
Nodes (left→right, top→bottom within zone)
Arrows
Side annotation boxes
Final cameraUpdate zoom-out

Use intermediate cameraUpdate calls to pan into each zone as you draw it — this makes the drawing feel alive as it streams in.

Process Violations

Drawing before receiving explicit approval
Treating silence as approval
Re-drawing after ASCII revision without asking again
More than 4 distinct node fill colors (visual noise)
Font sizes below 14
Camera sizes not exactly S/M/L/XL/XXL (non-4:3 distorts)
Separate text elements where a labeled shape would worki