Skills

My personal collection of agent skills for real engineering. They're small, easy to adapt, composable, and work with any model — each one is a plain folder with a SKILL.md, following the open Agent Skills format, so any agent that speaks it can load them.

This repository is a fork of Matt Pocock's skills. It keeps the structure of the original but maintains its own pared-down set of skills, and does not sync with upstream.

Only the engineering bucket is populated today; the rest of the structure is kept in place to grow into.

Install

Use the skills.sh installer, then pick the skills and coding agents you want:

npx skills@latest add simonsteiner/skills

Skill catalog

Skills live in buckets under skills/ and split on one axis — who can invoke them. User-invoked skills run only when you type them; model-invoked skills can also be reached automatically when the task fits.

Engineering

User-invoked

• arch-review — scan for deepening and maintainability candidates, save a ranked backlog to docs/arch-review/, then ship the batch you confirm as stacked PRs.
• docs-refactor — give each kind of doc exactly one home, fix doc claims the code contradicts, and rewrite the agent instructions into a short AGENTS.md; staged on a new branch with a report and a PR body.

Model-invoked

• address-review-findings — work through the unresolved review threads on one PR or a stack, then reply and resolve.
• attach-media — upload local screenshots and recordings to GitHub and embed them in a PR, issue, or comment, with no external hosting.
• conventional-commit — write Conventional Commits v1.0.0 messages and make the commits, split into atomic ones when the work spans concerns.
• download-media — download the screenshots and recordings attached to issues, PRs, and review comments, private repos included, so the agent can look at them.
• frontend-craft — design and build UI with a point of view instead of templated defaults: pick the surface's mode, plan and self-review a token system, build to a quality floor; also critique, audit, and polish existing UI.
• pr-body — write a PR body shaped by the kind of change: before → after for a fix, a real run for a feature, unchanged output for a refactor, a few lines for a chore.
• review-prs — review open PRs on GitHub or, still untested, Azure DevOps (one, several, or a stack) with no real review yet or much new code since the last one, or a local diff since a fixed point, against correctness, the repo's standards and the spec; comment inline, then fix and resolve. Tips on calling it: docs/review-prs.md.
• setup-lefthook — set up lefthook git hooks matched to the stack and its CI: one fixer per file type, cross-file checks run whole, slow tests on push, and a 5,000-token budget per staged file that tells the agent how to split what's over.
• sync-and-branch — cut a branch from the fresh default branch, carrying uncommitted work along, and sync a fork with its upstream.

Third-party skills

Skills by other people that I use but don't own are curated, not forked. third-party/skills.json records which upstream skills are worth having and why; a sync script installs them straight from their own repos, so nothing is copied into this one:

./scripts/sync-third-party.py          # install (and upgrade) everything curated
./scripts/sync-third-party.py --check  # compare the manifest against what's installed

The annotated list is in third-party/README.md.

Developing

To hack on a skill with live edits, symlink this repo's skills into your local agent directories:

./scripts/link-skills.py          # link every owned skill, prune links to removed or deprecated ones
./scripts/link-skills.py --check  # report owned skills that aren't linked, and dead links

This is the dev-mode equivalent of npx skills add: it links each skill into ~/.agents/skills (and mirrors it for Claude Code under ~/.claude/skills), so edits here take effect immediately. Use it on the machine where you develop the skills, and install with skills.sh everywhere else — pick one path per skill, not both.

On that machine, ./scripts/sync-skills.py runs link-skills.py and then sync-third-party.py (pass --check to check both). The links point at this checkout's working tree, so whatever branch is checked out is what your agents run. That decides when a sync is needed:

What changed	What to do
An existing skill's body, references or scripts (edited here, or pulled)	Nothing; the next invocation reads the new files
An existing skill's name or description	Restart your agents; they read the skill list at startup
A skill added, moved, renamed or removed (here, or in a pull)	Sync, then restart
third-party/skills.json, or an upstream curated skill you want to pick up	Sync (or just sync-third-party.py), then restart

sync-skills.py --check reports whether anything is missing or stale, so when in doubt, run that. T3 Code caches each provider's skill list for its picker, so a new skill can stay missing there until T3 refreshes that list, even after you restart the agent.

./scripts/lint-skills.py checks every skill against Anthropic's skill authoring best practices, the Agent Skills spec and best practices, and the listing rules in AGENTS.md; CI runs it, with shellcheck for the scripts bundled in skills, the rumdl Markdown linter (config in .rumdl.toml) and ruff for the Python tooling (uvx ruff check scripts tests, config in ruff.toml; needs uv), on every PR. What counts as an owned skill — its bucket, its name, no duplicates and no clash with a curated skill — is decided once, in scripts/tooling/skill_inventory.py, and everything about third-party/skills.json in scripts/tooling/third_party.py; the commands at the top of scripts/ read them. python3 -m unittest discover -s tests -t . runs every test: tests/tooling/ for the scripts/tooling/ package, and tests/skill_scripts/ for the scripts bundled in skills, against a fake gh so no test touches GitHub. A skill's evals run with ./scripts/eval-skill.py against the previous version or no skill at all (docs/evals.md). npm install sets up lefthook git hooks that run the same checks on each commit, with rumdl fixing what it can. With the SonarQube CLI installed and logged in, they also scan the staged files for secrets and new dependency risks; without it that job is skipped, and SonarCloud's PR analysis still runs.

Repo conventions are in AGENTS.md, and design decisions are recorded as ADRs in docs/adr/.