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:
┌ ┐ └ ┘ ├ ┤ ┬ ┴ ─ │ and → ← arrows, no ambiguous ASCII + junctions)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 the headless-browser skill (external dependency — installed from Takazudo/zudo-test-wisdom, not part of this repo) to render diagrams in monospace font and capture screenshots for validation. This is critical for catching issues before finalizing. scripts/preview_diagram.sh still writes the HTML preview and degrades with a warning instead of failing if headless-browser isn't installed.
References:
references/golden-rules.md - Complete rule specificationreferences/examples.md - Good/bad examples and fixestools
Acceptance gate for a branch produced by an OpenAI Codex CLI run — usually Codex implementing a /big-plan epic that was handed off to it. Codex reports the work 'done' (or the user flags it WIP with corrections); this skill confirms the branch actually fulfils the original spec, fixes what falls short, and routes larger discoveries into GitHub issues. Use when: (1) User says '/finalize-codex-work', 'finalize codex work', 'confirm the codex work', 'check the codex branch', or 'codex said it's done', (2) A branch is the result of a Codex CLI session and needs verification against its spec issue/PR, (3) After assigning a /big-plan epic to Codex CLI. Pass -m/--merge to run /pr-complete -c at the end.
tools
Read a Figma design node directly from a share URL via the Figma REST API — no Dev Mode subscription, no MCP, no desktop app. Renders the node to PNG and dumps its full style/layout JSON so the design can be described, compared, or implemented. Use whenever the user gives a Figma design URL (figma.com/design/... or /file/...) and wants to see, read, inspect, reference, or implement that node — including `/fig-url-refer <url>`. This is the URL-based counterpart to `/figrefer` (which needs a Dev-plan desktop MCP); prefer this one when the input is a URL rather than a live desktop selection.
tools
Sync the user's Claude Code workflow skills into the OpenAI Codex CLI settings repo ($HOME/.codex) as Codex-native ports, fix the Codex .gitignore for new local state, then commit and push. Use when: (1) user says '/dev-codex-sync-settings-from-claude', 'sync codex settings', 'sync claude skills to codex', 'port skills to codex', or 'update codex from claude'; (2) after updating ~/.claude workflow skills (big-plan, x, x-as-pr, x-wt-teams) and Codex should catch up; (3) the $HOME/.codex repo has drifted behind $HOME/.claude. The ports are condensed Codex-native REWRITES, never file copies.
development
Analyze a video file (mov, mp4, webm, etc.) or a YouTube video by extracting still frames with ffmpeg and reading them chronologically with vision — Claude cannot ingest video files directly. Use whenever the user provides a video file path or YouTube URL and wants to know what happens in it: "read this video", "watch this video", "check this recording", "what happens in this .mov/.mp4", analyzing a screen recording of a UI bug, or verifying UI behavior captured in a video, even if they don't name this skill.