A personal workflow repo for Claude Code — skills I own, which reference each other and reach into other people's skills for specific tasks.
Not a plugin. A skills repo installed by symlink, the same way ~/.agents/skills works: each folder under skills/ is symlinked into ~/.claude/skills/, so it loads under a bare name — /discuss, not /buddy:discuss. Editing a skill takes effect immediately; there is no reinstall step and no cache.
There is no router and no front door. Skills are found by their description, and reference each other by name.
| Skill | What it does |
|---|---|
topic |
Shared pacing — breadth-first traversal, checkpoints, callbacks. Referenced by the three below. |
discuss |
Talk a topic through to shared understanding. Questions, one at a time, no recommendations unless asked. |
explain |
Transfer understanding. Plain language, short bursts, top-down. |
explain-branch |
explain pointed at a diff: what a branch does, unit by unit. |
answer |
Answer questions and change nothing, until the user says changes are ok. |
scratchpad |
Rules for the .scratchpad/ working folder. Referenced by anything that writes working files. |
commit |
Group a messy working tree into logical commits, one intent each, and commit them. |
Two of these are convention-holders — topic and scratchpad hold rules that other skills point at, so a rule is written once and propagates to everything that references it. That is the pattern to reach for when the same convention shows up in a second skill.
Every skill is model-invocable. No skill sets disable-model-invocation, so all of them are both typeable and reachable by the model and by each other. The description is therefore the routing mechanism: it has to be distinct from every other loaded skill, and there are 45+ of those.
Composition: drive what you can, hand back what you can't. A skill the model can invoke gets invoked directly (spec-flow's skills, and Matt's grilling, tdd, code-review, research, prototype, domain-modeling, codebase-design, diagnosing-bugs). A skill marked disable-model-invocation can only be typed by a human — to-spec, to-tickets, implement, wayfinder, triage, handoff, grill-with-docs — so a buddy skill that needs one stops and tells the user to type it, rather than reading or restating what it does.
No shared state. Skills pass information in conversation. The one exception is .scratchpad/, whose rules live in the scratchpad skill.
Descriptions follow writing-great-skills — one trigger per branch, leading word front-loaded, no synonyms padding the trigger list.
skills/<name>/SKILL.md # frontmatter: name, description. No disable-model-invocation.
./install.sh # symlinks anything new
Before writing the description, check it against the skills already loaded — ls ~/.claude/skills plus whatever plugins are enabled. Two skills matching one intent is the failure mode; the model picks between them arbitrarily.
agents/ is empty on purpose. Add one when a job floods the main context and you only want the conclusion — a read-only reviewer or surveyor, the shape spec-flow uses. Skills first; an agent is what you reach for once you can point at the context problem it solves.
./install.shSymlinks every folder in skills/ into ~/.claude/skills/, and every .md in agents/ into ~/.claude/agents/. Skips anything already there that it doesn't own, and reports what it skipped.