Matt Pocock publishes the engineering workflows he uses with coding agents in mattpocock/skills. The collection is not a replacement for judgment or tests. It is a set of small, composable instructions for requirements discovery, domain modeling, TDD, debugging, code review, and other repeatable work.

Installation commands and available skills can change, so check the repository README before copying them into a long-lived setup.

Choose one installation route

The project has two official routes, and they are intentionally exclusive.

  • Codex and other agents: skills.sh copies editable skill files into a project. You choose the skills and target agents.
  • Claude Code: the official mattpocock-skills plugin installs a managed, read-only bundle and receives updates automatically.

Do not install both routes for the same Claude Code setup. You would expose every skill twice and make it unclear which copy the agent is following.

Install for Codex

You need a working Node.js installation because the official command uses npx. Open a terminal in the repository where you want the skills, then run:

npx skills@latest add mattpocock/skills

The installer asks which skills to copy and which coding agents should receive them. Select Codex, start with a small set, and include setup-matt-pocock-skills. A useful first group is:

  • setup-matt-pocock-skills for repository-specific configuration;
  • ask-matt when you are unsure which workflow fits;
  • grill-me or grill-with-docs for requirements discovery;
  • tdd and diagnosing-bugs for implementation feedback loops;
  • code-review for a standards-and-spec review.

If you want only one skill, use the official single-skill form:

npx skills@latest add mattpocock/skills --skill=grill-me

Update an installed skill explicitly when you are ready to review upstream changes:

npx skills@latest update grill-me

The copied files are yours to inspect and adapt. Before first use, read each SKILL.md and any referenced scripts. This matters because a third-party skill can tell an agent to run commands or edit files; installation is not a security review.

Configure each repository once

After installation, open the project in Codex and say:

Use $setup-matt-pocock-skills to configure this repository.

The setup workflow asks where issues live, which triage labels the project uses, and where generated domain documentation should be stored. Commit the resulting repository instructions only if the team should share them. Do not blindly copy another project’s answers: issue tracking and terminology are part of this repository’s contract.

In Claude Code, install the managed plugin from a shell:

claude plugins install mattpocock-skills

Or install it inside a Claude Code session:

/plugin install mattpocock-skills

Then run /setup-matt-pocock-skills once in each repository. The plugin route needs no extra marketplace command.

Invoke a skill with a concrete task

Codex can reach an applicable skill automatically, but an explicit $skill-name removes ambiguity. Give the skill a real input and a verifiable outcome rather than typing only its name.

Use $grill-me to challenge this offline-sync design before we implement it.

Use $diagnosing-bugs to find why this request is duplicated. Reproduce it first and add a regression test.

Use $tdd to add cancellation to the uploader, one vertical slice at a time.

For Claude Code, use the slash form documented by the collection, such as /grill-me. Do not assume that slash syntax and Codex’s $skill-name syntax are interchangeable.

Verify the installation before real work

Review the files created by the installer with git status --short; only the selected skills and agent configuration should appear. Open one installed SKILL.md and confirm that its name matches the invocation you plan to use. Then try a read-only prompt:

Use $ask-matt to recommend a workflow for diagnosing a flaky integration test. Explain the recommendation, but do not edit files yet.

The response should name an appropriate path—typically diagnosis before implementation—and explain what evidence it needs. Next, invoke that skill on a disposable example or a small real issue. Watch for the behavior promised by its instructions: diagnosing-bugs should seek a reproduction and hypotheses, while tdd should establish a failing test before changing production code.

If Codex does not recognize the name, confirm that the installer targeted Codex and that the skill lives in the location selected by the installer. If two copies appear, remove the unwanted installation route instead of editing both. Verification should happen before granting write access or running a workflow across a large diff.

A practical workflow

For a non-trivial feature, begin with grill-with-docs to resolve requirements and sharpen project language. Turn the agreed direction into a specification or tickets. Use tdd while implementing small slices, switch to diagnosing-bugs when evidence contradicts an assumption, and finish with code-review against both repository standards and the specification.

Skills should improve the feedback loop, not bypass it. Keep normal safeguards: inspect the diff, run the repository’s own tests, verify the product behavior, and review commands before granting broad permissions. If a skill recommends the wrong command or produces an unsuitable result, correct the skill file or ask the agent to update it. That editable feedback loop is the main advantage of the skills.sh route.

The fastest successful setup is therefore not “install everything.” Pick one route, install a small useful set, configure the repository, invoke skills with concrete evidence and acceptance criteria, and expand only after the workflow earns your trust.