A personal Claude Code marketplace. 44 skills, one plugin, three commands.
Most skill collections are a pile of documents that fire when a description happens to match. This one is wired as a system: a router sizes the work first, the skills chain in order, and a set of hooks enforces the parts that shouldn't depend on the model remembering to load anything.
The organising idea is proportionality. A skill that fires on everything gets turned off; a skill that never fires protects nothing. So a button colour change gets a commit and nothing else, and an auth refactor gets a design conversation, a plan, a worktree, and two reviews.
/plugin marketplace add m-de-graaff/skills
/plugin install toolkit@skills
/reload-plugins
Then just work. Skills load themselves when they apply. /toolkit lists them; /toolkit <name>
runs one directly.
Three hooks install with the plugin and run whether or not a skill was loaded:
| Hook | Does |
|---|---|
SessionStart |
Injects the router, and reports branch, divergence, dirty state, and open PRs |
PreToolUse |
Blocks destructive git — force-push without a lease, reset --hard, clean -fd, --no-verify, merge --admin |
Stop |
Refuses to end a turn on a large uncommitted diff, once per checkpoint |
Turn them off for one repo with mkdir -p .claude && touch .claude/git-workflow-off, or
everywhere with /plugin disable toolkit@skills.
| Skill | Use when |
|---|---|
using-toolkit |
Every task. Routes the request and sizes the chain to the change |
eliciting-requirements |
The request is too vague to design against. One question at a time |
brainstorming |
The design isn't settled — scales from two sentences to a written spec |
writing-plans |
An approved design, multi-step work, before any code |
executing-plans |
A written plan to carry out, with review checkpoints |
subagent-driven-development |
You asked for a plan to be run by subagents |
dispatching-parallel-agents |
You asked for fan-out — or noticing work that could be, and offering |
writing-tests |
Writing a test, or adding coverage. Watch it fail before you trust it |
systematic-debugging |
Anything behaving unexpectedly. Root cause before fixes |
verification-before-completion |
About to say something works. Evidence before claims |
deleting-code |
Removing a feature, a flag, a dependency, or something that looks dead |
requesting-code-review |
Before a PR or a merge. Picks the instrument |
receiving-code-review |
Feedback arrived — from a person, a PR, or a tool |
git-workflow |
Branch, commit, push, PR, release. Owns the hooks above |
jira-workflow |
Notes, discovered work, grooming, sprints, boards. Drafts to files; never writes to Jira |
using-git-worktrees |
Work that shouldn't disturb the current checkout |
writing-skills |
Creating or editing a skill |
| Skill | Use when |
|---|---|
accessibility |
Any user-facing UI. WCAG 2.2 AA, web and native |
security-patterns |
Auth, user input, uploads, secrets, payments, a URL the server fetches |
api-design |
An HTTP endpoint's shape — URLs, status codes, pagination, versioning |
backend-patterns |
What runs behind the handler — queries, caching, jobs, logging |
database-migrations |
Schema changes that survive a rolling deploy. Expand-contract, locks, backfills |
api-connector-builder |
Adding an integration to a repo that already has integrations |
typescript-patterns |
Types at the boundary, unions over optional soup, any and assertions |
fastapi-patterns |
FastAPI — routers, schemas, dependencies, async, auth |
redis-patterns |
Caching, rate limits, locks, queues, pub/sub |
react-patterns |
React components, hooks, Server/Client boundaries, forms |
react-performance |
React that's slow — waterfalls, bundle size, re-renders |
react-testing |
Testing React with RTL, MSW, and axe |
observability |
Logs, metrics, traces, alerts. Cardinality is the thing that bites |
ci-pipelines |
What blocks a merge, what only warns, and why the build is slow |
make-interfaces-feel-better |
Visual polish — radii, optical alignment, type, hit areas |
animation-principles holds the values; everything else cites it. The cluster's default is
less motion, not more.
| Skill | Use when |
|---|---|
animation-principles |
Adding or judging any motion, or needing an exact curve or duration |
reviewing-animations |
A diff that touches motion → a verdict |
auditing-animations |
Motion across a codebase → prioritised plans |
finding-animation-opportunities |
Asking what could animate. A filter — it rejects most candidates |
apple-interface-patterns |
Gestures, drag, sheets, momentum, translucent materials |
animation-vocabulary |
Naming an effect someone described but can't name |
Neither is hooked, and neither changes the work. They shape what comes out of it.
| Skill | Use when |
|---|---|
writing-prose |
Any prose a human reads — commit body, PR, ticket, README, changelog, docs |
reporting-work |
Asked for a status update, or asked for less. Invoked, never volunteered |
| Skill | Use when |
|---|---|
measuring-performance |
Is it slow, and by how much — baselines, vitals, noise floors |
optimization-loop |
Make it faster, as a bounded measured search with a promotion gate |
picking-ui-libraries |
Which library for a frontend task. Invoke it deliberately |
competitive-benchmarking |
Scoring competitors on weighted dimensions. Not software work |
The router picks a chain from the shape of the request:
typo, colour, rename → just do it → git-workflow
"it's broken" → systematic-debugging → writing-tests → verify → git-workflow
"we need notifications" → eliciting-requirements → brainstorming → …
"add feature X", non-trivial → brainstorming → writing-plans → executing-plans
→ requesting-code-review → git-workflow
"refactor the auth module" → + using-git-worktrees, + receiving-code-review
"make X faster" → measuring-performance → optimization-loop → verify
"rip out the old exporter" → deleting-code → verify → git-workflow
Domain skills attach to whatever tier you're already at — they inform the work without changing
its size. A one-line colour change still needs accessibility if that colour carries meaning.
Create skills/<name>/SKILL.md. The frontmatter is the whole registration:
---
name: <name> # must match the directory
description: >
Use when <the situations that should trigger this>. Also use when <the
moment someone realises they need it>.
---
# <Name>
**Core principle: <the one sentence someone would remember>.**The description is the only thing the model sees when deciding to load the skill. Write it to
name situations, not topics — and never summarise the workflow in it, or the model follows the
summary instead of reading the skill. writing-skills covers this properly.
House conventions across this repo:
- Triggering conditions only in the description; under 1024 characters
- No
Related Skillssections — cross-reference by name, inline, where it's relevant - One canonical home per fact. Cite it; don't restate it
- State the reason behind a rule, or it gets argued away in review
- A
Non-goalssection, so the boundary with neighbouring skills is explicit
Nothing else to register. /plugin marketplace update skills to pick it up.
.claude-plugin/marketplace.json the marketplace, listing one plugin
.claude-plugin/plugin.json the plugin
commands/toolkit.md the /toolkit command
commands/jira-apply.md the only artifact that writes to Jira
commands/jira-capture.md end-of-session sweep for work worth a ticket
hooks/hooks.json hooks Claude Code loads on install
hooks/run-hook.cmd cmd/bash polyglot, so hooks work on Windows
scripts/lint-shell.sh shellcheck + syntax check over tracked *.sh
skills/<name>/SKILL.md one directory per skill
skills/<name>/references/ heavy reference the skill links to
skills/<name>/scripts/ executable tools the skill calls
A skill needing a hook keeps the script in its own directory and points hooks/hooks.json at it
— the path is relative to the plugin root, so nothing is copied into hooks/.
Windows. Hooks run through hooks/run-hook.cmd, a cmd/bash polyglot: cmd.exe runs the
batch half and locates Git Bash; a POSIX shell reads the same file as a script. *.sh and
*.cmd are pinned to LF — CRLF breaks the polyglot's heredoc terminator.
These skills are untested. writing-skills calls for running pressure scenarios through
subagents before and after authoring a discipline skill. That hasn't been done here — the
rationalization tables are derived from observed failure modes in the source material, not from
measured agent behaviour. Treat them as considered, not verified.
Most of this is adapted from other people's work. Each adapted skill carries a Source section;
this is the summary.
| Source | Skills |
|---|---|
| ECC — Affaan Mohamed, MIT | accessibility · api-design · api-connector-builder · backend-patterns · fastapi-patterns · react-patterns · react-performance · react-testing · redis-patterns · security-patterns · measuring-performance · optimization-loop · apple-interface-patterns |
| obra/superpowers | brainstorming · writing-plans · executing-plans · subagent-driven-development · dispatching-parallel-agents · systematic-debugging · verification-before-completion · requesting-code-review · receiving-code-review · using-git-worktrees · writing-skills |
| Vercel Labs — MIT | react-performance, via ECC |
| Emil Kowalski — animations.dev | the animation set: animation-principles and the skills that cite it |
| Apple — WWDC design talks | apple-interface-patterns, via ECC |
linus707 — community PR #1659 |
make-interfaces-feel-better |
| addyosmani/agent-skills | eliciting-requirements, from its interview-me |
| ayghri/i-have-adhd — MIT | reporting-work |
| Wikipedia: Signs of AI writing — via blader/humanizer | writing-prose |
Written from scratch: git-workflow, jira-workflow, using-toolkit, writing-tests,
database-migrations, deleting-code, observability, ci-pipelines, typescript-patterns.
picking-ui-libraries and competitive-benchmarking arrived without stated provenance. Each
now carries a Source section that says so explicitly rather than staying silent — if you know
where either came from, replace it.
Adaptation here means rewritten rather than copied: descriptions rebuilt as triggering conditions, duplicated reference material consolidated to one canonical home, and corrections where the original was wrong — each PR records what changed and why.