Matt Pocock Core Skill - Grill, Context, TDD, Refactor

What this skill teaches

This Matt Pocock-inspired skill treats agent work as an engineering conversation before it treats it as a coding shortcut. The distilled pattern is simple: close the alignment gap first, write down the language of the project, use red-green-refactor as the default implementation loop, zoom out when the agent is staring too closely at one file, and reserve time for design repair before entropy becomes the new architecture. The live source repo frames these ideas as small, composable skills for real software teams. This page turns the cross-cutting ideas into one agent-agnostic baseline that can sit beside your other local skills.

The point is not to imitate another developer’s workflow line by line. It is to preserve the useful pressure points. Agents drift when requirements stay vague, when project terms live only in chat, when tests come after the code has already been rationalized, and when local edits accumulate without any system-level review. This skill gives the agent a compact ritual for catching those failures while the session is still cheap to redirect.

The skill body

# Matt Pocock core - agent engineering loop

A compact engineering loop for coding agents, distilled from the public
Matt Pocock skills repository. Use it with Claude Code, Codex, Cursor,
or any agent that can read local project instructions.

## Core stance

Do not start by typing code. Start by removing ambiguity. The agent's
speed only helps after it shares the user's goal, vocabulary, feedback
loop, and design constraints.

## 1. Grill before build

Before implementation, ask pointed questions until the decision tree is
small enough to execute. Challenge vague nouns, missing users, hidden
states, edge cases, and success criteria. Stop grilling only when the
next patch can be judged from observable behavior.

When the user asks for a plan, stress-test it. When the user asks for
code, spend a short first pass finding the unclear parts. Alignment is
part of the work, not a preface.

## 2. Write shared language into CONTEXT.md

If the project has local terms, write them down. Prefer one durable
`CONTEXT.md` or equivalent project note over re-explaining the same
domain in every session. Capture:

- domain nouns and what they mean here
- overloaded terms that differ from common usage
- decisions the team no longer wants reopened
- phrases the codebase already uses for core workflows

Use the shared language in file names, function names, tests, comments,
and status reports. Shorter vocabulary is useful only when it is precise.

## 3. Use red-green-refactor for code changes

For behavior changes, start with a failing test or failing reproduction.
Then make the smallest patch that turns it green. Only after that,
refactor. Keep the three states visible:

- RED: the failing test or reproduction proves the gap exists
- GREEN: the smallest implementation closes the gap
- REFACTOR: the design gets improved while behavior stays locked

Do not skip RED because the change feels obvious. The agent is most
likely to invent success when no feedback loop contradicts it.

## 4. Zoom out before drilling deeper

When the agent gets stuck inside one function, step back. Explain the
module boundary, the neighboring abstractions, the data flow, and the
reason this code exists. A narrow local fix can damage the system when
the agent cannot see the shape around it.

Use zoom-out moments before large refactors, after surprising test
failures, and whenever two plausible designs compete.

## 5. Invest in design every session

Agent speed accelerates entropy. Reserve time in each meaningful change
for design repair: remove a bad branch, tighten an interface, rename a
concept to match the shared language, or split a module whose surface
has become too wide.

This is not polish after the feature. It is part of keeping the system
changeable while the agent is producing code faster than a human could.

## Done signal

A task is done only when alignment has been checked, shared terms have
been updated when needed, the feedback loop has run, the agent has
zoomed out over the affected design, and any design debt created by the
patch has been named or paid down.

Why this matters

Agent sessions fail in patterns that look familiar to senior engineers. The agent builds the thing it thought you meant, not the thing you meant. It invents vocabulary because the project did not hand it one. It writes plausible code before a failing test exists. It keeps drilling into a bad local abstraction because nobody asked it to describe the surrounding system. It ships several fast patches in a row, and then the next patch becomes hard because the shape of the code quietly worsened.

The Matt Pocock skills repository is useful because it turns those familiar engineering failures into small repeatable interventions. A grilling pass turns unclear intent into decisions. A shared-language file turns domain knowledge into project infrastructure. Red-green-refactor gives the agent a feedback loop it cannot fake. Zooming out breaks fixation on the current file. A daily design investment keeps the codebase from becoming a transcript of every short-term compromise the agent made while moving quickly.

This ViteCode skill is deliberately agent-agnostic. It does not depend on a Claude-only command, a Cursor-only rule format, or a Codex-only workflow. It is a portable baseline for any coding agent that can read a local Markdown instruction.

Where it fits in the loop

Use this skill before medium or large changes, especially when the request still has fuzzy nouns, domain-specific terms, or a risk of architectural sprawl. It pairs well with Karpathy coding, which keeps the agent honest by running real code, and GSD core, which gives multi-phase work a written outer loop. The difference is emphasis: this skill is about keeping the agent aligned with the human and the codebase while the work is underway.

For one-file edits, the full ritual can be compressed into a short alignment question, one failing test, and a final design pass. For phase-sized work, run the full loop and capture the durable terms in CONTEXT.md before implementation starts. The agent-rules generator linked below can wire this skill into a reusable rules file so the reminder appears at the start of future sessions instead of relying on memory.