Matt Pocock's Skills

npx skills@latest add mattpocock/skills

What it does

A bundle of small, composable engineering skills that Matt Pocock uses in his own daily work, packaged so you can install the ones you want. They are deliberately not a process framework that takes over the wheel. They are sharp, single-purpose tools you compose yourself, and they are built to work with any model.

The notable ones:

• Grilling (grill-me, recently renamed grilling, plus the docs-aware grill-with-docs): the agent interrogates you about what you actually want before it writes anything, closing the gap that causes most wrong builds. These are the most-used skills in the set.
• Domain modeling: build and sharpen a project's ubiquitous language, recording decisions as ADRs and keeping a CONTEXT.md current as the model changes.
• Codebase design: a shared vocabulary for designing deep modules, small interfaces over meaningful behavior, with clean seams that stay testable.
• TDD: a disciplined red-green-refactor loop that tests behavior through public interfaces.
• Diagnosing bugs: a reproduce, minimise, hypothesise, instrument, fix, regression-test loop for the hard ones.
• Workflow skills: implement, prototype, to-issues, to-prd, and triage, for turning intent into shippable, well-scoped work.

Install the whole set with the skills.sh installer, or cherry-pick individual skills, and choose which agents to install them on. Run the included setup skill once per repo to wire in your issue tracker and docs layout.

VeryCreatives' take

This is the rare skill set that encodes engineering judgment, not just prompts. The thesis is right: the most common failure is not bad code, it is misalignment, and a grilling session that forces the agent to interrogate your intent before it builds fixes more problems than any amount of clever generation. Starting any non-trivial task with a grilling pass changes the quality of everything that follows.

What earns it a top pick for us is the discipline underneath. ADRs, a ubiquitous domain language, deep modules with small interfaces, behavior-first tests: these are the habits the VeryCreatives engineering team already leans on, so we recognize senior practice when we see it, and this is senior practice written down. It also respects your control. Unlike the process frameworks that own your workflow end to end, these stay small and composable, so you adapt them instead of surrendering to them.

It is also one of the most installed and starred skill sets out there, and skills.sh shows it passing Socket and Snyk security checks, which is reassuring for something you drop straight into your own repository.

The honest part: this is discipline, not magic. The grilling skills only pay off if you actually engage with the questions, and the value is the engineering thinking baked in, not autopilot. A few skills are user-invoked slash commands built around Claude Code conventions, so on other agents you trigger them a little differently.

Bottom line: if you do real engineering with an agent and you care about getting it right rather than getting it fast, this is a top pick, and a genuinely good model for what a serious skill set looks like.

How VeryCreatives uses it

Of this set, the skill we actually lean on is grilling, and we use it for planning, not code generation. The way one of our engineers frames it: an axe-sharpener, not a code generator. You reach for it at the start of any non-trivial design decision, when there are real tradeoffs to settle, before a line of code is written.

A recent example: centralising cashback-rate logic on a client project. The rules had grown custom and scattered across views, with edge cases and conditions spread through the codebase, and the change touched almost every part of the app, so getting the approach right mattered more than getting started fast. Running a grilling pass over the design, cross-referenced against the client's own spec document, did three things that reading the code or the document alone would not have:

• It killed a false constraint. Performance turned out to be neutral between the approaches we were weighing, so we almost optimised for a reason that did not exist.
• It caught a live bug. Cross-referencing the spec against the code revealed that production was capping the rate using the wrong setting, a discrepancy that only surfaced because we were comparing the document's claims to what the code actually did.
• It prevented a wrong approach. The question of whether to pick the highest rate or follow the hierarchy turned out to be a business decision, and the client's answer was a hybrid that neither of our assumed approaches would have handled.

The output was not code. It was a sharper specification, a confirmed production bug, and a recalibration with the client on the intended business logic. For work where building the wrong thing is expensive, that is exactly the point.

One honest note from our use: when you hand it a document as context, it can treat that document as the law. Some claims in a client spec are assumptions or simplifications rather than engineering truth, so you still have to tell the agent which parts to trust. We run it in Cursor with Claude, installed manually.

When to use it

• You build real software with an agent and want alignment and design discipline, not vibe coding.
• Your team values ADRs, domain language, and testable architecture, or wants to start.
• You want composable tools you can adapt, not a framework that owns your process.

When not to

• You want a hands-off "build it for me" button. These skills ask you to think and to answer.
• You only make small, well-understood changes where a full grilling and design loop is overkill.

Cross-agent note

This set is built to be multi-agent. The author states plainly that the skills work with any model, and the skills.sh installer targets a long list of agents: Claude Code, Codex, Cursor, GitHub Copilot, Windsurf, Gemini, Cline, and more. That is a stronger cross-agent stance than most skills offer.

Two nuances. First, OpenCode is not on the installer list today, which is worth knowing if it is your main agent. The skills still work in OpenCode because it reads the shared .claude/skills and .agents/skills directories, so you install into one of those or copy the folders in. Second, invocation: some skills are user-invoked via Claude Code style slash commands, and agents that ignore that flag will expose them as model-invocable instead. We have not hand-verified every agent yet, so the flags are AI-inferred.