Intro:
I started with the same lazy hope most of us have when we see a new agent workflow:
maybe this one makes the coding agent behave much much better!
Not Gonna Lie, Matt Pocock’s Skills For Real Engineers has been floating around developer circles for a good reason.
It is not another list of “10 prompts to make Claude a senior engineer.”
It is a set of Claude Code skills that package specific engineering habits into commands:
grilling, TDD, debugging, specs, tickets, handoffs, architecture reviews, and prototypes.
The pitch is simple enough.
Agents fail in predictable ways.
They misunderstand the task.
They talk too much.
They write code that looks fine but does not work.
They add complexity faster than humans can notice it.
So instead of asking the agent to “be careful,” Pocock turns those failure modes into repeatable workflows.
That idea sounded useful, but also a little suspicious.
Every agent workflow looks disciplined in a README.
The real test is what happens when it touches a messy project, a fuzzy idea, and a human who thinks they explained themselves better than they did.
So I treated the skills less like a magic toolkit and more like a stress test for my own workflow.
The setup is boring, which is good
The repository gives you two main ways in.
If you use Claude Code, you can install the managed plugin. Anthropic’s plugin docs describe plugins as bundles that can include skills, agents, hooks, MCP servers, and other capabilities. That managed path is the clean route if you want updates without thinking too much about the files.
The other route is npx skills@latest add mattpocock/skills, which copies editable skill files into your project.
I prefer this.
A skill is just text with a job. If it is wrong for your project, you should be able to read it, change it, and make it speak your team's language.
That distinction matters because the best version of these skills is not “install and obey.” It is “install, inspect, adapt.”
After setup, the workflow starts with /setup-matt-pocock-skills.
It asks practical questions: where issues live, which labels matter, and where generated docs should go.
Nothing glamorous. No cinematic AI moment. Just configuration so future commands do not have to guess (I like this, as expected)
Agents guess too much already. Any workflow that begins by removing a few guesses has my attention.
Alright, I’ll start with
/grill-with-docs that has made the biggest difference
The skill that immediately makes sense will be/grill-with-docs.
The idea is almost annoyingly simple:
before the agent writes code, it interviews you until the work is clear enough to build.
The plain /grill-me skill does this generally.
The docs version also builds shared vocabulary and records decisions into project documentation.
This sounds like process overhead until you watch it catch a bad assumption.
My normal instinct with an agent is to write a task description, add a few constraints, and trust the model to infer the rest.
That works for tiny changes.
It falls apart when the task has domain language, hidden acceptance criteria, or some “obvious” decision I forgot to say out loud.
The grilling step slows everything down at exactly the right moment.
It asks the questions I wanted the agent to ask before touching files.
What does this term mean in this codebase?
Which behavior matters first?
What should happen in the awkward edge case?
Should this be a temporary prototype or a committed path?
The docs part is the real trick.
Once the agent learns your domain language, it should not have to relearn it every session. A CONTEXT.md-style glossary and ADRs are boring artifacts, but they reduce the amount of translation you have to do later.
One person in a community had said they modified the grilling behavior into something more open-ended because the default loop felt too strict.
I get that now.
Sometimes the skill wants more certainty than the task deserves.
But the underlying habit is solid:
do not let the agent start building while the shape of the work is still foggy.
TDD felt less like ideology and more like seatbelts
I have mixed feelings about strict TDD in normal human work.
Sometimes it is perfect.
Sometimes it turns into theater.
With agents, though, the equation changes.
Agent-written code has a special problem:
it often looks right before it is right. The file structure is clean. The names are plausible. The comments sound confident. Then you run it and the behavior is wrong -.-
That is where /tdd earns its keep.
The skill pushes the agent into a red-green-refactor loop, one behavior at a time. Not a giant batch of imagined tests.
Not a whole feature dump followed by a panic pass.
One failing test, the minimum code to pass it, then the next slice.
This is not nostalgia for old engineering rituals. It is a way to give the agent a short feedback loop.
The same logic applies to /diagnosing-bugs. The skill makes the agent reproduce the bug, reduce the case, form hypotheses, add instrumentation, apply a fix, and leave behind a regression test. Again, none of this is new. That is why it works.
The more I used these workflows, the more obvious the pattern became: the useful skills are not clever because they are novel. They are useful because they make the obvious steps harder to skip.
And agents love skipping obvious steps.
Specs and tickets helped the session survive itself
The next part of the workflow is where the chat starts becoming a project.
After a grilling session, /to-spec turns the conversation into a structured spec. /to-tickets breaks the plan into smaller tickets. /implement is meant to build against that plan, using TDD and review along the way.
This is the part I expected to dislike.
I am allergic to fake process.
I do not want an agent turning every small task into a miniature enterprise ceremony.
But for work that spans more than one session, the artifact trail matters.
A chat feels full while you are inside it. It is terrible as a long-term source of truth. It gets compacted. It gets resumed days later. It gets interpreted by another agent with a slightly different view of the world. A spec is heavier, but at least it can be inspected.
Tickets are useful for the same reason.
They narrow the task.
They make dependencies visible.
They give the agent something smaller to finish and something clearer to review.
The review I read described a full path: /grill-with-docs, /to-spec, /to-tickets, then /implement.
NOTE: I would not use that whole chain for every change. For a small bug, it is still too much.
For a feature with real ambiguity, it is exactly the kind of friction that saves time later.
That is the main adjustment I have made:
Do not treat the pipeline as a religion. Treat it as a menu.
Use the smallest workflow that still protects you from the mistake you keep making.
My favourite and sleeper skill or the
The architecture skill is the one I would run periodically
/improve-codebase-architecture.
AI-assisted coding has a rot problem.
It does not create software entropy from scratch, but it speeds up the production of code enough that entropy arrives earlier.
A developer can now generate a lot of plausible structure in a short time. If nobody stops to ask whether the structure is still good, the codebase quietly gets harder to change.
That is why an architecture scan is useful.
The skill looks for candidates where the architecture can be improved and presents them as a report.
The important word there is “candidates.”
I do not want an agent wandering through a codebase and deciding to redesign half of it because the report looked exciting.
Architecture work needs taste, context, and restraint.
The best version of this skill is not an automatic cleanup button. It is a way to surface pressure points so the human can choose which one deserves attention.
Now, the biggest lesson from testing this workflow is that agent skills should not be treated like finished products.
They are closer to starting points.
As I’ve always thought and said,
The future of AI coding is probably not one perfect agent framework.
It is a layer of editable habits on top of increasingly capable models.
Some habits will be personal.
Some will be team-wide.
Some will become plugins.
Some will be a weird little SKILL.md file that only makes sense inside one company.That is fine.
The point is not to outsource judgment.
The point is to stop re-explaining the same judgment every session.
In case we are meeting for the first time, come over here, it’ll be worth the roller coaster of articles that are gonna come up in the next few weeks.
I run a bunch of apps at AIBucket.
I do not use AI in my writings and you shouldn’t either. So, How did I go from 0 to 1000 here ?
If you’re an established writer, here are the brands paying for sponsored articles.