.claude

Perform a Schenkerian analysis of a musical piece or section and render it as a Schenker graph with LilyPond, producing .ly, .svg, and .pdf outputs plus a companion prose analysis — optionally layered with a GTTM (Lerdahl & Jackendoff) metrical dot-grid and grouping brackets. Use when the user types `/schenk <piece>` or asks for a "Schenkerian analysis", "Schenker graph/diagram", "Ursatz", "Urlinie", "voice-leading reduction", "structural analysis of this piece", or a "GTTM / metrical / grouping analysis" — even if they never say the word "schenk". Accepts a piece name, a score file (LilyPond, MusicXML, ABC, MIDI), or pasted notation. Asks for a reference score when the notes aren't known with confidence. Requires LilyPond (offers to install it if missing).

Survey a repository for outstanding work and present it as a single backlog. Use whenever the user types /backlog or asks things like 'what's on the backlog', 'what's left to do', 'what should I work on next', 'list the open EPICs / TODOs / tech debt', or 'what work is outstanding here'. Gathers EPIC docs, ROADMAP items, TODO/FIXME/HACK comments in source, an unreleased CHANGELOG, and open GitHub issues into one list; refreshes a BACKLOG.md; and creates/maintains a docs/TECHNICAL_DEBT.md (seeding it with untracked code TODOs plus an automation-flagged code review on first creation). If a repo has no tracked work at all, propose concrete expansions instead of returning nothing. Make sure to use this skill even when the user doesn't say the word 'backlog' but clearly wants an inventory of what's left to build or fix.

Distill an existing codebase into a portable regeneration pack — language-agnostic DECON epics in the /epic house style plus golden test vectors extracted by running the original code — so its functionality can be rebuilt by people or agents in any language without inheriting the original's programmatic design choices. Use when the user types `/deconstruct [subsystem]` or asks to "deconstruct this codebase", "distill this repo into epics", "make a regeneration spec", "reverse-engineer a spec from this code", "write specs so another team or agent can rebuild this" — even if they never say the word deconstruct. Do NOT trigger for forward-looking feature design (that is /epic), teaching material or exercises (that is /codebase-kata), or kernel-purity assessment (that is /domain-kernel).

Dog mode, aka "walking the dog" — Claude writes no code; it walks the developer through a coding task one step at a time while the developer types everything. Use when the user types /dog, /dog off, says "walk me through", or asks for dog mode.

Generate or update an EPIC design document — a domain-driven, phase-structured spec with Context, a Status table, Design sketches, phased Work Items, and a Verification block — in the pkcore/pkdealer house style. Use when the user types `/epic <thing>` or asks to "write an EPIC", "break this feature into stories or phases", "add a design doc to the docs folder", "story breakdown", "update/close out EPIC-NN", or "a progress report / evaluation of <branch>" — even if they never say the word EPIC. Do NOT trigger for ad-hoc planning of the current conversation's task (plan mode covers that) — only when the user wants a durable numbered document in the repo's docs folder. Project-agnostic: works in any repo, detects the existing documentation folder, and allocates the next EPIC number. Also produces the companion forms: progress/evaluation report, SIDEQUEST, DEFECT epic, TUTORIAL companion, and EXECUTION_PLAN / spec splits.

Codify, assess, and enforce the **domain kernel** pattern — a pure, delivery-agnostic core of one domain's logic behind a narrow, ideally language-neutral boundary. Use this whenever the user wants to make a library or crate a "pure core", "domain kernel", "functional core", or "hexagonal / clean core"; assess or enforce kernel purity (no I/O, no format crate leaking into the public API, no default-on serialization); strip filesystem or serialization concerns out of a core library; define a WIT / WebAssembly component boundary so business logic is reusable across stacks and languages; set up clippy / cargo-deny / CI purity gates for a core crate; or write a domain-kernel charter or positioning doc. Trigger even when the user only says things like "make this crate pure", "keep I/O out of the core", "extract the serialization", or "package my logic as a wasm component" without ever naming "domain kernel".

Turn a real codebase into a TDD-style coding kata that teaches the core technology or algorithm behind it. Use this skill whenever the user wants to create a kata, exercise, coding challenge, or training material derived from an existing codebase or library — whether they say "make a kata from this repo," "build an exercise that teaches how X works," "I want to onboard contributors to this project," or "help people learn the algorithm behind this code." Trigger this even when the user just points at a repo and says they want to teach the concepts in it, even if they don't use the word "kata." Also trigger when they want to focus on one specific area — a single rule, function, or module within a larger codebase — or to cover several related concepts together as a progression of exercises.

Squash all unpushed commits on the current branch into a single fresh commit with a new "now" timestamp. Use when the user types /cookit.

Bullet-point summary of changes on the current branch vs main. Use when the user types /debrief or asks for a branch summary.

Generate a step-by-step demo runbook for a specific feature, EPIC, PR, or branch — what to type, what to click, what to point at on screen. Use when the user types `/presentation <thing>` or asks for a "demo script", "demo runbook", "walkthrough", "presentation script", "show-and-tell steps", "live demo plan", or "how do I demo X" — even if they don't use the word "presentation". Project-agnostic: works in any repo (Rust, Node, Python, mixed). Always invoke this skill when the user wants a physical, manual demonstration of work they (or someone) has done, as opposed to a written summary or code review.