# Matt Pocock Skills: the Agent Needs an Engineering Routine Date: 2026-10-14 "Add role-based access to our application." Six words. That request could mean a permissions system with eight roles and a database migration, or a single middleware guard built in two hours. Before a line of code is written, the developer is trusting the agent to resolve the ambiguity—or shipping something that answers the wrong question. Matt Pocock Skills is a collection of composable engineering practices—installable skill files for Claude Code, Codex, Cursor, and other agents. The skills are small, designed to be modified, and leave composition to the user. There is no mandatory sequence—the collection addresses specific failure modes, and the developer chooses which ones apply. Four documented skills cover the path from ambiguous request to reviewed result. ## `/grill-with-docs`: the questions before the code Running `/grill-with-docs` opens a structured interview. The skill models the conversation as a design tree—every decision branches into decisions that depend on it. The agent identifies the frontier: the questions whose prerequisites are already settled and can be asked now without guessing. It presents the whole frontier in one round, each question with a recommended answer, then waits before continuing. Alongside the interview, it builds shared vocabulary: terms are challenged against `GLOSSARY.md` as they crystallize, and significant decisions are recorded as Architecture Decision Records. For "Add role-based access," the first frontier surfaces: What roles exist—fixed or user-defined? What can each role do? Where is authorization enforced—middleware, service layer, or query level? What happens to existing users? What does a correct result look like, and where is it verified? These are not edge cases. They are the feature. ## `/to-spec`: from conversation to testable document After the interview, `/to-spec` synthesizes what was discussed—without opening another interview—into a structured specification: problem statement, user stories, implementation decisions, testing decisions, and an explicit out-of-scope section. It publishes to the project issue tracker. The implementation decisions section captures architectural choices without locking down specific file paths that will be outdated before the work is done. ## `/tdd`: vertical slices, confirmed seams The TDD skill enforces vertical slices: one failing test, one minimal implementation, repeat. It explicitly prohibits horizontal slicing—writing all tests first, then all the code—which the documentation identifies as producing tests for imagined behavior rather than user-facing behavior. Before any test, the skill requires agreement on which seams to test: the public boundaries where behavior is observable without reaching into implementation. Refactoring belongs to the review stage, not the red-green loop. ## `/code-review`: two axes, kept separate The review skill runs two parallel sub-agents with no shared context. One checks whether the code follows the repository's documented standards plus a baseline of Fowler code smells. The other checks whether the implementation matches the originating spec. The separation is intentional: "A change can pass one axis and fail the other." A conformant implementation of the wrong spec, or a correct implementation written in the wrong style, both produce findings—but from different axes, on different evidence. Keeping them apart prevents one from masking the other. --- ## The limit of a good process A well-structured workflow narrows the space for failure. It does not eliminate it. If the grilling session produces wrong answers, the spec encodes them, the tests verify the wrong behavior, and code review checks against a wrong spec. The process is only as sound as the requirements feeding it—the skill maps what is unresolved but cannot supply missing domain knowledge. ## Who benefits, and who does not Software engineers who have learned that "just tell the agent what you want" produces misaligned results at scale. Engineering leads treating agent-generated pull requests as a distinct review category. Product managers may find the interview useful independently: surfacing unanswered questions before implementation has value regardless of tool. This collection presupposes a codebase, an issue tracker, and a specification as working materials. It is not a workflow for drafting communications. ## The next problem Even a structured agent can generate technically correct output that buries the key next action in paragraph four. That is a different failure mode—and the subject of the next post. --- *Source: github.com/mattpocock/skills — SKILL.md files for grill-with-docs, to-spec, tdd, code-review, grilling, and domain-modeling. Retrieved 8 October 2026.* #SoftwareEngineering #AgentSkills #DeveloperTools