Top 10 Claude Skills You Should Actually Be Using

Most "Claude tips" content is prompting advice. Skills are a different category entirely — they are packaged, reusable instructions Claude follows on command, built by other engineers and shared as open source. The ten below are all from one free, actively maintained collection: Matt Pocock's Skills For Real Engineers, chosen because each one fixes a specific, common failure mode rather than being a generic productivity gimmick.

Installing the set

In Claude Code, run `/plugin install mattpocock-skills` (or `claude plugins install mattpocock-skills` from a shell) to get the whole collection as a managed bundle that updates automatically. Prefer editable copies, or use Codex or another agent? Run `npx skills@latest add mattpocock/skills` and pick which ones to add. Either way, run `/setup-matt-pocock-skills` once per project afterward — several of these depend on it knowing your issue tracker and doc conventions.

1. /grill-me — interrogate a plan before you build it

grill-me interviews you about a plan or decision until every branch is actually resolved, instead of accepting the first plausible-sounding answer. Use it before anything expensive to reverse.

2. /grill-with-docs — the same interview, for code

grill-with-docs runs the same interrogation for engineering changes and builds a glossary and architecture decision records as you go, so the shared vocabulary survives past the conversation that created it.

3. tdd — red, green, refactor, actually enforced

A reference for test-driven development that covers what a good test actually is, where tests belong, and the anti-patterns that turn "we do TDD" into tests nobody trusts. Useful whenever you want features or bug fixes built test-first.

4. diagnosing-bugs — a discipline for the hard ones

A structured diagnosis loop for bugs and performance regressions that resist a quick fix — it forces you through phases instead of guessing your way to a patch that happens to make the symptom disappear without addressing the cause.

5. code-review — two axes, run in parallel

Reviews a diff against two separate questions at once, in parallel sub-agents: does the code follow this repo's documented standards, and does it actually match what the originating issue or spec asked for. Reports both side by side instead of one blended opinion.

6. triage — a state machine for incoming issues

Moves issues and external PRs through categorize, verify, grill-if-needed, and write-an-agent-ready-brief — turning a messy issue queue into something an agent can actually pick up and act on without you translating it first.

7. domain-modeling — build the shared vocabulary as you go

Actively builds and sharpens a project's domain language — challenging vague terms, inventing edge cases, and writing the glossary and decisions down the moment they crystallize, rather than documenting after the fact.

8. wayfinder — plan work too big for one session

For a chunk of work bigger than one agent session can hold: charts it as a shared map of decision tickets on your issue tracker, then resolves them one at a time until the path is actually clear, instead of charging at a destination nobody has agreed on yet.

9. wizard — a bash script that walks a human through the tedious part

Generates an interactive wizard for manual steps only a human can do — provisioning infrastructure, setting up credentials, clicking through an unfamiliar dashboard — that opens each URL, says exactly what to click, and captures the values where they belong.

10. handoff — compact a session for the next one

Writes a handoff document summarizing the current conversation so a fresh agent (or a fresh version of you, tomorrow) can pick the work back up without re-deriving everything that was already figured out.

None of these are prompting tricks — they are process, packaged. The common thread is that each one exists because a specific, recurring failure mode (agreement without alignment, bugs fixed by guessing, reviews that miss the actual spec, work too big to hold in one head) kept happening until someone wrote a skill that structurally prevents it.