Matt Pocock’s skills: the specification before the code

On 3 February 2026, Matt Pocock, the trainer known for his Total TypeScript courses, opened a GitHub repository of “skills”: instruction sheets that coding agents load on demand. His motto: “real engineering”, not “vibe coding”, the habit of accepting generated code without reading it. As of 29 October 2026, the repository has more than 306,000 stars, GitHub’s equivalent of a bookmark, and more than 25,700 forks. According to the Star History curve, it passed roughly 200,000 stars in early August, six months after it was created.

This success does not come from skills that write code faster. The most popular ones are for talking with the agent before it codes. In agentic development, the bottleneck is no longer writing the code, but expressing the need. For leaders who steer software projects, it is a return to the fundamentals of business ownership.

What the repository contains

• A modest start (international · GitHub): on the day it was created, the repository held 7 skills, including drafting a requirements document (“write-a-prd”) and test-driven development (“tdd”). It is published under the MIT licence.
• A diagnosis (United Kingdom · AI Hero): rewritten on 28 April 2026, the repository’s introduction names misalignment as the most common failure: you think you have been understood, then you see what was built. The proposed fix is a questioning session; the skills that run it are, according to the author, his most popular.
• A workflow (international · GitHub): the questioning session (“grill-me” or “grill-with-docs”), then the specification (“to-spec”), the split into tickets (“to-tickets”), test-driven implementation (“implement”), code review (“code-review”) and, finally, a session review (“retro”).
• Names settled over the summer (international · GitHub): version 1.0 on 17 June 2026; since version 1.1 on 8 July, “to-spec” and “to-tickets” have replaced the earlier names. Package 1.3.2, released on 29 October, ships 27 skills.
• Several agents (international · GitHub): installation documented for Claude Code (United States · Anthropic), Codex (United States · OpenAI), GitHub Copilot and Gemini CLI (United States · Google).
• Strict curation (international · GitHub): no proposals for new skills are accepted, and a change request must describe a failure observed in a real session.

What remains to be proven

• Real-world use: a star is not a deployment. As far as we know, no public measurement links these skills to gains in quality or lead time.
• Stability: the repository reflects one person’s practice and changes often; skills are renamed or removed. A team that adopts it inherits that pace.
• Comparison with rival frameworks: as far as we know, no independent evaluation compares these skills with Spec Kit (international · GitHub).

The real issue: the specification becomes the deliverable again

The central skill, “grilling”, describes an interview method. The agent asks its questions in rounds, offers its recommended answer for each, and acts only once a shared understanding is confirmed. It looks up facts in the code and environment itself, rather than asking the user. The rule is explicit: facts are the agent’s job, decisions remain the human’s. This is the classic split between the delivery team and the business owner.

The “to-spec” template asks for the problem statement from the user’s point of view, a long list of user stories (“as a…, I want…, so that…”), implementation and testing decisions, and what is out of scope. Code review then judges the result on two separate axes: compliance with the repository’s standards, and faithfulness to the specification. The first is about quality; the second looks very much like acceptance testing.

The repository’s introduction contrasts these skills with approaches that “own the process” and names three: GSD, BMAD and Spec Kit, the toolkit GitHub opened in August 2025, which has more than 143,000 stars. Matt Pocock argues for small, editable building blocks; yet both approaches converge: the specification comes before the code. In September 2026, an interview (international · The Pragmatic Engineer) raised the idea of “strategic programming”, a notion borrowed from computer scientist John Ousterhout, as the future of developers’ work.

Three points of vigilance

1. A specification is only as good as the person answering. The questioning session interviews whoever sits in front of the agent. If a developer answers on behalf of the business, the specification records assumptions. The repository even provides a skill, “to-questionnaire”, to send the questions to the person who holds the answer.

2. Speed shifts the risk to acceptance testing. When code arrives faster, verification becomes the bottleneck. A review by one agent of another agent’s work does not replace functional acceptance by the business, on real cases.

3. A third-party skill is still third-party code. Installed as a plugin, the package updates itself: your development process can change without any decision on your part. Pin the version and review changes, as for any dependency.

What leaders of software projects should require

1. A written specification before any code is generated: problem, solution, user stories, out of scope, versioned in the ticketing tool.
2. The business in the questioning session: the decision-maker answers; the developer settles the technical points.
3. Short, ordered tickets: each delivers a slice that can be checked end to end and declares what blocks it.
4. A project glossary: business terms, defined once and shared by the team and the agent alike, with a log of architecture decisions.
5. Two-level acceptance: a review of conformity with the specification, then validation by the business on real cases.
6. A lead-time indicator: the time between an approved specification and an accepted delivery, rather than the volume of code produced.
7. Skills managed as dependencies: pinned version, review before updating, a named owner.

An agent codes what it is told; the business owner decides what it is told.

The question to ask on Monday morning

To your project manager: “For the last ticket handed to an agent, who wrote the need, who answered its questions, and who accepted the result?”