skills/explanatory-doc/SKILL.md
Generate visual, branded HTML documents that explain concepts to non-technical audiences. Use when creating explanatory content for friends, partners, investors, or anyone who needs to understand a technical topic in simple language. NOT for contracts or proposals (use branded-doc). Triggers on: "explain to", "make a document for", "explanatory doc", "visual explanation", "send him/her an explanation", "/explanatory-doc".
npx skillsauth add etanhey/golems explanatory-docInstall 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.
Generate branded, visual RTL Hebrew HTML documents with colored sections, callout boxes, phase cards, checklists, Q&A cards, and tables.
When to use this vs branded-doc:
explanatory-doc = Explaining concepts (trading bot to a friend, study tips, project overview)branded-doc = Contract feedback, proposals, pricing sheets, client documentsbun scripts/explanatory-doc.ts input.json output.html/Applications/Brave\ Browser.app/Contents/MacOS/Brave\ Browser --headless --disable-gpu --print-to-pdf="output.pdf" --no-margins "output.html"# Generate from JSON file
bun scripts/explanatory-doc.ts /tmp/doc-input.json ~/Documents/output.html
# Pipe from stdin
cat /tmp/doc-input.json | bun scripts/explanatory-doc.ts - ~/Documents/output.html
# Generate PDF from HTML
/Applications/Brave\ Browser.app/Contents/MacOS/Brave\ Browser \
--headless --disable-gpu --no-margins \
--print-to-pdf="$HOME/Documents/output.pdf" \
"$HOME/Documents/output.html"
{
"title": "Document Title",
"subtitle": "Optional context line (sources, date range, etc.)",
"date": "March 2026",
"recipient": "Name (optional)",
"sections": [
{
"num": 1,
"title": "Section Title",
"color": "blue",
"blocks": [
{ "type": "text", "content": "Paragraph. Use **bold** for emphasis." },
{ "type": "callout", "style": "warn", "title": "Note Title", "content": "Callout content" },
{ "type": "table", "headers": ["Col1", "Col2"], "rows": [["Cell", "Cell"], [{"text": "+22%", "style": "pos"}, {"text": "-30%", "style": "neg"}]] },
{ "type": "phase", "title": "Phase 1", "risk": "zero", "riskLabel": "Risk: None", "items": ["Step 1", "Step 2"], "note": "Optional note" },
{ "type": "list", "items": ["Bullet 1", "Bullet 2"] },
{ "type": "checklist", "items": ["Green checkmark item 1", "Green checkmark item 2"] },
{ "type": "qa", "items": [{ "q": "Question?", "a": "Answer." }] },
{ "type": "divider" }
]
}
],
"closing": "Optional closing text",
"output": "~/Documents/output.html"
}
| Type | Visual | Use |
|------|--------|-----|
| text | Paragraph | Regular content |
| callout | Colored sidebar box | Key insights, warnings, tips |
| table | Striped table with dark header | Data, comparisons |
| phase | Rounded card with risk badge | Project phases, steps |
| list | Bullet list | Features, items |
| checklist | Green checkmark list | Safeguards, done items |
| qa | Card with blue question | FAQ section |
| divider | Horizontal line | Section separator |
| Style | Color | Use |
|-------|-------|-----|
| info (default) | Blue | General notes, tips |
| warn | Amber | Warnings, caveats |
| danger | Red | Critical warnings, risks |
| success | Green | Positive outcomes, recommendations |
All sections use the same green numbered circle for visual consistency (matching the Avi Huberman style). The color field is available for future customization but currently maps to the same green.
| Color | Use |
|-------|-----|
| blue | Default, informational |
| red | Problems, risks, warnings |
| green | Solutions, positives |
| amber | Caution, expectations |
| purple | People, roles, meta |
Regular cells are plain strings. For colored cells (positive/negative):
{ "text": "+22.8%", "style": "pos" }
{ "text": "-62.7%", "style": "neg" }
| Risk | Badge Color | Use |
|------|-------------|-----|
| zero | Green | No risk at all |
| low | Yellow | Controlled, limited risk |
| medium | Orange | Moderate risk |
| high | Red | High risk |
The document uses a dark slate banner header with the document title (NOT freelancing branding). Modeled after the "Avi Huberman Tips" visual style:
No personal branding (no name/email/phone). The document is about the topic, not the sender.
Each section gets its own page. The script forces page-break-before: always on every section (except the first). This guarantees no component is ever split across pages. The <hr> dividers between sections are hidden — replaced by teal top-border lines on each section.
Because each section gets a full page, make sure sections have enough content to fill the page well. A section with just a 2-row table and one line of text will look sparse. Add explanatory text, callouts with key takeaways, or context paragraphs to fill out short sections.
When generating content for explanatory docs:
bun scripts/explanatory-doc.ts to generate HTML~/Library/Mobile Documents/iCloud~md~obsidian/Documents/personal/Personal/tools
The human-eval UX contract for Phoenix views: turn-by-turn scrollable replay (not a scorecard), hide-but-copyable IDs, collapsed thinking, identity chips, tool filters, tiny frozen starter datasets, mark-wrong-in-thread, mobile-first. Use when: building or reviewing ANY Phoenix/eval view, annotation UI, session replay, or human-grading surface. Triggers: phoenix view, eval UI, annotation view, session replay, human eval UX, grading interface. NOT for: Phoenix data pipelines/ingest (capture scripts have their own specs).
tools
macOS systems specialist — AppKit NSPanel architecture, launchd services, socket activation, MCP bridge resilience, syspolicyd, and high-frequency SwiftUI dashboards. Use when building menu-bar apps, LaunchAgents, debugging syspolicyd/Gatekeeper/TCC, resilient UDS/MCP bridges, or SwiftUI dashboards at 10Hz+.
development
Bulk LLM-judging protocol for fleet-dispatched verdict runs (KG cluster, eval harness). Use when: dispatching or running judge workers (J1/J2/RT), planning bulk-apply from verdict JSONL, or triaging evidence_degraded outputs. Triggers: judge fleet, bulk judge, R3 verdicts, kg-judge, RT gate, evidence_degraded. NOT for: single-item code review, Phoenix view UX (use phoenix-human-view), or non-judge eval pipelines.
development
Quiet-down protocol for sprint close: when the fleet wraps, delete ALL polling crons and monitors, send ONE final dashboard + ONE message, then go SILENT. Use when: fleet wraps, all workers done, overnight queue exhausted, sprint close, Etan asleep/away with nothing approved left. Triggers: fleet wrap, wrap the fleet, stand down, going quiet, sprint close. NOT for: mid-sprint monitoring (keep your loops), spawning a successor (use /session-handoff first).