Skills for Real Engineers: Subscribe or Fork Your Agent Workflow

A repository called skills from Matt Pocock reached GitHub's daily trending list this week, with a framing that lands directly against the current direction of agent tooling.

Its opening line: agent skills for real engineering, not vibe coding.

The argument

Pocock's critique targets process-owning frameworks, naming GSD, BMAD and Spec-Kit, and it is specific rather than dismissive. His claim is that in taking ownership of the development process, those approaches take away the engineer's control and make bugs in the process itself hard to resolve.

Anyone who has debugged a multi-agent workflow will recognise the failure. When the framework decides the sequence, a wrong output leaves you unsure whether the model failed, the prompt failed, or the framework's own state machine failed — and you cannot inspect the third one.

The alternative on offer is deliberately less ambitious: skills that are small, easy to adapt, composable, and model-agnostic. Hack around with them, make them your own.

The failure mode it names

The repo organises itself around specific failure modes rather than capabilities. The first one is the honest one: the agent didn't do what I want.

Pocock attributes it to misalignment and quotes The Pragmatic Programmer on the underlying problem — that nobody knows exactly what they want. You think the developer understands the requirement, then you see the output.

This is a better diagnosis than most agent tooling starts from. The common assumption is that agents fail because they lack context or tools. The competing claim here is that they fail for the same reason human delegation fails, and that no amount of context window solves an underspecified request.

Two distribution models, deliberately different

The installation section is unusually clear about the trade-off, and it maps onto a real organisational decision.

The Claude Code plugin (claude plugins install mattpocock-skills) installs the set as a managed, read-only bundle that updates when the author ships. You subscribe rather than fork. It's in the official marketplace, so updates arrive automatically.

npx skills@latest add mattpocock/skills copies editable skill files into your repo as ordinary files you own. Nothing updates behind your back; you pull changes when you choose.

The README is blunt that you should pick one — installing both leaves every skill duplicated. There's a one-time /setup-matt-pocock-skills step that asks which issue tracker you use, what triage labels you apply, and where docs should be saved.

Why the distribution choice is the interesting part

Subscribe-versus-fork is exactly the question every organisation building internal agent workflows has to answer, usually without noticing they're answering it.

Managed bundles give you consistency and free maintenance, at the cost of behaviour changing under you. Forked files give you control and stability, at the cost of owning the drift forever.

Most teams default into the second by accident — copying a prompt, editing it, and inheriting maintenance they never budgeted for. Naming the two paths explicitly, and warning against taking both, is a more useful contribution than the individual skills.

The repository is MIT licensed.

Source: GitHub — mattpocock/skills