skills/ascii-circuit-diagram-creator/SKILL.md
Create and validate ASCII circuit diagrams with automatic rule checking and iterative refinement. Use when the user requests circuit diagrams in ASCII/text format, or when creating technical documentation with embedded schematics. Ensures golden rules (no line crossings without junctions, no lines crossing labels, proper component connections, correct polarity). Includes preview validation using monospace rendering.
npx skillsauth add takazudo/claude-resources ascii-circuit-diagram-creatorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Creates clear, unambiguous ASCII circuit diagrams through an iterative generate-validate-fix workflow.
A. Create connection list - Write explicit text connections (which pin → which pin) B. Generate ASCII diagram - Create circuit that satisfies ALL connections C. Preview - Render in monospace font, capture as image D. Confirm - Check for rule violations
E. Complete - Deliver both connection list AND ASCII diagram
Start with connections, not the diagram - The connection list is the specification. The ASCII diagram must satisfy every connection in the list.
Connection list is a deliverable - Always provide both:
Preview is mandatory - Label crossings and alignment issues are invisible in plain text but obvious in monospace rendering.
Follow the golden rules - See references/golden-rules.md for complete list:
┌ ┐ └ ┘ ├ ┤ ┬ ┴ ─ │ for lines/junctions, → ← for arrows+ for junctions (ambiguous direction)Write explicit text connections showing which pin connects to which:
Format:
Connections:
- Component1 pin X → Component2 pin Y
- Component2 pin Z → Component3
- Component3 → GND (parallel capacitor)
Example (Buck Converter):
Connections:
- +15V input → U2 (LM2596S) pin 5 (VIN)
- +15V input → C5 (100µF) → GND
- U2 pin 3 (ON) → +15V (always enabled)
- U2 pin 4 (VOUT) → Switching node
- Switching node → L1 (100µH) → +13.5V Output
- Switching node → D1 (SS34 Schottky cathode)
- D1 (SS34 Schottky anode) → GND
- +13.5V Output → R1 (10kΩ) → Tap point
- Tap point → R2 (1kΩ) → GND
- U2 pin 2 (FB) → Tap point
- +13.5V Output → C3 (470µF) → GND
- U2 pin 1 (GND) → GND
Key points:
Create the ASCII diagram that satisfies ALL connections from Step A:
Layout strategy:
└─── to create branches that extend right first, then go vertical├ ┤ ┬ ┴ ─ │ ┌ ┐ └ ┘ for lines/junctions, → ← for arrows+ for junctions - it's ambiguous about connection directionFB ├2─→ Tap)Component representation:
Best practice: Parallel capacitors (filter pairs):
Power ──┬────────────────┬─── To IC
│ │
C1 C2
100nF 470µF
ceramic electrolytic
(CLOSE!) (farther)
│ │
GND GND
Separated section example (recommended for complex circuits):
IC Section:
┌──────────────┐
Input ──────────────┤1 VIN OUT 2├───── Signal Node
│ │
┌──┤3 GND FB 4├──── FB Tap
│ └──────────────┘
GND
Switching Node Section:
┌─────────────┐
Signal Node ────────┬────────────┤ L1 (100µH) ├──────────── Output
│ └─────────────┘
│
└─── D1 (Schottky)
Cathode
│
Anode
│
GND
Input Filter Section:
Input ───┬─── To IC
│
├─ C1 (100µF)
│ │
│ GND
│
└─ C2 (100nF)
│
GND
Key benefits of separated sections:
└─── (right first, then down) or ┬ (split, then vertical)Critical: Verify every connection from Step A is represented in the diagram.
Run the preview script to render in monospace font and capture as image:
bash $HOME/.claude/skills/ascii-circuit-diagram-creator/scripts/preview_diagram.sh <diagram-text-or-file>
The preview creates an "almost empty HTML" with monospace font styling and captures the result using headless browser. This reveals issues invisible in plain text:
CRITICAL: Check the preview image for rule violations by tracing each signal path and inspecting vertical line alignment.
Simply looking at the screenshot is not enough - you must:
├ ┤ ┬ ┴ connect the correct signals?If ANY violations found, return to Step B with fixes.
Preview phase is critical for detecting:
Check against golden rules (see references/golden-rules.md):
Rule 1: Line crossings without junctions
┼ symbols (usually wrong)Rule 2: Lines crossing labels
Rule 3: Disconnected components
Rule 4: Incorrect polarity
Rule 5: Unclear parallel/series connections
Common fixes:
Fix: Line crossing label
Example:
Before (crosses labels): After (routes upward):
VOUT ├4───┬─→ L1 D1 ← Routes UP
│ │
│ (crosses) VOUT ├4───┴─→ L1
D1 ↓
Fix: Disconnected component
┬ ├ ┤ ┴)Fix: Inverted polarity
Fix: Ambiguous parallel/series
├─→ to branch from main signal pathIteration: Repeat B → C → D until all rules satisfied. Usually 2-3 iterations sufficient.
Once all rules satisfied, deliver both:
Optionally explain key connections or design choices if complex.
See references/examples.md for detailed examples of:
Before finalizing, verify:
Use this skill when:
Key indicator: User mentions "ASCII circuit," "text diagram," "schematic in text," or shows existing ASCII circuit that needs fixing.
Preview tool: Uses headless-browser skill to render diagrams in monospace font and capture screenshots for validation. This is critical for catching issues before finalizing.
References:
references/golden-rules.md - Complete rule specificationreferences/examples.md - Good/bad examples and fixesdevelopment
Link Claude Code skill names mentioned in a CodeGrid article (data/{series}/{n}.md) to the author's public claude-resources repo, pinned to the latest commit hash so links don't rot. Use when: (1) user says 'linkify cc resources', 'link the skills', 'link skill names', or invokes /dev-linkify-cc-resources; (2) editing a CodeGrid article that mentions `/commits`, `/pr-complete`, `/skill-creator` or other Claude Code skills and they should point to claude-resources. Only links skills that actually exist in the public repo; skips hypothetical examples and code blocks.
development
Second opinion from Claude Opus on a plan or approach. Use when: (1) Planning phase of /big-plan needs a higher-quality review than /codex-2nd / /gco-2nd, (2) User says 'opus 2nd' or 'opus opinion', (3) Wanting Anthropic's larger model to critique a plan. Spawns a general-purpose Agent with model: opus that reads the plan file and returns structured feedback. Anthropic quota — not free.
tools
AI-based testing via subagent + a per-task test-flow skill. Use when the user wants to verify something that mechanical assertions can't fully capture — image recognition, visual size/position comparison, animation smoothness, multi-step manual flows that need AI judgment. Triggers: 'AI-based test', 'AI test', 'visual verify', 'image recognition test', 'manual operation test', 'human-eye check', 'verify visually', 'compare screenshots', 'looks the same', 'looks correct'. The skill's job is to (1) author a focused test-flow skill that captures the exact procedure + verdict criteria, then (2) dispatch a verification subagent via the Agent tool that loads BOTH the test-flow skill AND a browser-driving skill (/verify-ui primary, /headless-browser fallback) so the subagent has clear context and consistent verdicts. NEVER uses `claude -p` — subagent dispatch goes through the Agent tool exclusively.
development
End-of-workflow audit of touched GitHub issues, PRs, and branches via a Sonnet subagent. Use when: (1) /big-plan, /x-as-pr, or /x-wt-teams finishes its main work and needs to verify every touched resource is in the right state (closed when done, kept when ongoing, deleted when dead), (2) User says 'cleanup resources', 'audit cleanup', or 'check what should be closed', (3) A long workflow ends and the manager wants a structured paper trail of what it closed/kept/deleted. Auto-execute by default — the Sonnet agent proposes, the manager (you) executes safe actions and prints a final report.