Menu
Bullet-point summary of changes on the current branch vs main. Use when the user types /debrief or asks for a branch summary.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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".
| name | debrief |
| description | Bullet-point summary of changes on the current branch vs main. Use when the user types /debrief or asks for a branch summary. |
| version | 1.0.0 |
Run git log main..HEAD --oneline and git diff main...HEAD --stat to summarize what has changed on the current branch versus main. Output a concise bullet-point list grouped by type (features, fixes, refactors, config/docs). Keep each bullet to one line. No preamble, no trailing summary — just the list.
