Matt Pocock's AI Hero Skills: The Good Parts, the Hype, and What to Steal

Matt Pocock’s work on AI Hero is easy to misread as another attempt to turn prompt files into a software methodology. It is more interesting than that, but it is also less magical than its marketing can imply.

The durable idea is simple: coding agents do not remove the need for engineering. They increase the cost of unclear requirements, weak feedback loops, and poor architectural decisions. An agent can produce a lot of plausible code before a human notices it is solving the wrong problem.

AI Hero’s response is a workflow: clarify the work, preserve the important decisions, make the task small and testable, then use the agent inside a feedback loop. The free skills repository makes that workflow concrete.

This is my practical, slightly adversarial review of the approach.

The part he gets exactly right

The best thing about AI Hero is that it treats AI coding as an engineering-control problem, not a prompting competition.

The course and skills consistently push the same sequence:

1. Clarify the outcome and constraints.
2. Research or prototype when there is genuine uncertainty.
3. Write down a behavioural target.
4. Break it into work small enough to verify.
5. Implement with real feedback.
6. Review the result separately from the implementation pass.

That is a good sequence with or without an LLM. The agent changes the speed and scale, not the underlying need for judgment.

Pocock calls this the seven phases of AI development: idea, research, prototype, PRD, implementation planning, execution, and QA. There is nothing proprietary about the phases. Their value is that they are explicit enough to stop the common failure mode of jumping from a vague idea to a giant agent prompt.

The paid course appears strongest as an organised apprenticeship in this judgment: when to gather context, when to stop exploring, how to hand work over, how to keep an agent on a bounded task, and how to inspect what comes back. It is not a source of secret prompts or an AI engineering credential.

The key distinction: workflow versus magic

Pocock’s skills are Markdown instruction packages. They can make an agent more consistent, but they cannot create:

• product taste;
• domain knowledge;
• a useful acceptance criterion;
• a meaningful test suite;
• security judgment; or
• an architectural decision that nobody has actually made.

That limitation matters. A polished PRD.md built from unresolved assumptions is still unresolved assumptions. An autonomous loop that only runs weak checks is just a faster way to create false confidence.

The skills work best as constraints on a capable engineer’s process. They work worst when they become a substitute for thinking.

The free skills worth understanding

The repository contains more than a dozen skills. These are the ones that form the useful core.

grill-me: force ambiguity into the open

Use grill-me before research, a build, or a decision when the desired result is clear enough to describe but not clear enough to implement.

It works as a guided interview. Instead of immediately producing a plan, the agent asks focused questions, exposes assumptions, compares alternatives, and helps settle the brief. That is valuable because an agent’s default response to ambiguity is to silently invent the missing details.

This is a good skill for questions such as:

• What exactly should this feature do at its boundary cases?
• Who is allowed to change this state?
• What behaviour would make this migration safe?
• Is this a product requirement or an implementation preference?

Do not use it for a one-line fix or an already-settled task. It can easily turn five minutes of work into an elaborate interview.

grill-with-docs: clarify and retain the decisions

grill-with-docs is the more interesting version. It combines the interview with domain modelling and writes down decisions as they are made. The intended outputs include a shared glossary (CONTEXT.md) and Architecture Decision Records (ADRs).

Its strongest idea is ubiquitous language. If a codebase repeatedly describes “the process by which a lesson gets a place on disk”, that phrase should become one agreed term. The human, the code, and the agent can then use the same short name. This reduces prompt repetition, improves naming, and makes handoffs more reliable.

Use it when decisions will recur across sessions, contributors, or agents. It pays off most in long-lived systems with real domain language.

The failure mode is ADR inflation. A decision record for every endpoint, database field, or CSS choice is process theatre. Record consequential and hard-to-reconstruct decisions; leave the rest in code and tests.

Domain modelling: give the agent the project’s vocabulary

The domain-modelling skill is the documentation half of the previous idea. It establishes what the important concepts mean, what they do not mean, and which decisions have already been made.

This is unusually useful in enterprise systems, integrations, compliance-heavy work, and any product whose nouns have business meaning. It is less useful for a small standalone utility, where a glossary merely adds another file to ignore.

The practical benefit is not token reduction, though concise context is nice. It is that future agents stop inventing inconsistent concepts and names. A system gets easier to navigate when its types, files, tickets, and prompts all use the same vocabulary.

to-spec: make the result testable before making it real

Earlier versions of the workflow talked about a PRD; the current skill is called to-spec. Use it after discovery, before a significant implementation.

The goal is to write a build contract: expected behaviours, scope boundaries, constraints, acceptance criteria, and the agreed places where behaviour will be tested. It should describe the destination, not narrate every implementation step.

The test-seam idea is particularly good. Before writing tests, agree the public boundary that matters: an API, an integration boundary, a command, or a user-visible behaviour. That steers agents away from brittle internal mocks and tests that only verify their own implementation details.

The caveat is obvious but important: do not write a specification before the problem is understood. A structured document can make uncertainty look resolved.

to-tickets: convert a spec into bounded work

Use to-tickets when the spec is genuinely larger than one focused session or has work that can safely proceed independently. It slices the work into tickets with dependencies, acceptance criteria, and an agent-ready state.

This is useful because “implement the whole spec” is exactly the kind of prompt that causes drift. Good tickets give an agent a stopping point and give a human a reviewable increment.

The trap is false parallelism. If two tasks are coupled through the same data model, abstraction, or user flow, sending them to separate agents often produces merge conflicts and incompatible assumptions. The dependency graph needs engineering judgment; a ticket generator cannot supply it.

implement: a deliberately boring execution loop

implement is the default work loop for one agent-ready ticket. The agent reads the ticket and relevant context, makes a small change, runs the relevant checks, updates the work state, and stops.

Its value is restraint. Small, observable increments are easier to validate, revert, resume, and review. That makes it a better default than open-ended “keep working until it is done” delegation.

The skill is not itself a quality guarantee. If the ticket is wrong, the agent can efficiently implement the wrong thing. Quality comes from the spec, the feedback loop, and the review after the loop.

tdd: constrain the agent with behavioural tests

Use tdd when behaviour is clear, independently testable, and has an agreed public seam.

Pocock’s version is deliberately narrow:

1. Agree the seam to test.
2. Write one failing capability-level test.
3. Add the minimum implementation to pass it.
4. Repeat in vertical slices.

It warns against three agent-friendly anti-patterns:

• implementation-coupled tests that break during harmless refactors;
• tautological tests whose expected value is calculated the same way as the code; and
• horizontal slicing, where an agent writes a batch of imagined tests before it understands the implementation.

That is sound advice. Agents are very good at generating test volume and very bad at knowing whether the tests prove anything.

There are limits. Do not force test-first development onto a UI spike, an exploratory integration, or trivial glue code. The skill also intentionally separates refactoring into a later review pass, which is pragmatic for agents but is not classical red-green-refactor TDD.

code-review: make improvement a separate job

Use code-review after a feature works. It shifts the agent’s objective from “make checks pass” to “protect and simplify the codebase.” The review looks for correctness gaps, test value, unnecessary complexity, naming problems, architectural mismatch, and refactoring opportunities.

Separating implementation and review is a smart design choice. Agents rarely perform a serious refactor while they are still trying to complete the task in front of them. A distinct pass creates room to question whether the first working solution is also the right one.

The risk is generic LLM approval: “looks good” with no evidence. A useful review needs the diff, the spec, the relevant project conventions, and permission to report no findings when that is the honest conclusion.

prototype: learn before committing

Use prototype when the uncertainty is the point: an unfamiliar API, a risky integration, a competing architecture, or a user interface where taste matters.

The skill makes a throwaway experiment, compares alternatives, and distinguishes what was learned from what deserves a production implementation. This is the opposite of letting a convincing first demo become accidental architecture.

It is especially useful with agents because they can create a plausible first version so quickly that it feels more validated than it is. A prototype is an experiment, not a shortcut around design.

The discipline required is simple: do not quietly promote prototype code into production. Rebuild or review it intentionally.

diagnosing-bugs: prove cause before patching

Use this for a real bug whose cause is not already obvious. It drives evidence collection: reproduce the issue, narrow the responsible boundary, form competing hypotheses, test them, and only then propose a fix.

That is much safer than “fix this error”, especially in legacy systems and integrations. A fast patch often hides the symptom while making the actual problem harder to find later.

For an unambiguous stack trace and a one-line correction, this is excessive. Its value rises with uncertainty.

triage: prepare incoming work, not your own plan

triage is for externally filed issues and pull requests. It verifies whether a report is reproducible, checks whether the request already exists or was previously rejected, asks for missing information, and leaves behind either an agent-ready brief, a human-required task, or a documented closure.

It uses a small state model: needs information, ready for an agent, ready for a human, or will not fix. That is valuable for an open-source project or a team receiving unstructured requests.

It is not useful for tickets you generated from your own spec. Those should already be ready for implementation. The state model is also intentionally limited: blocked and deferred work need a local convention.

handoff: turn session state into an artifact

Use handoff before stopping a meaningful session or transferring work to another person or agent. It records the current state, decisions, changes, validation, open risks, and the next concrete step.

This is boring and extremely useful. It replaces “read the repository and reconstruct what happened” with a small, explicit continuation point. In long agentic work, that saves time and avoids the quiet loss of context that causes repeated investigation.

Where the framework breaks down

The workflow is strongest for substantial work in a durable codebase. It becomes counterproductive when applied indiscriminately.

• A tiny fix does not need a grilling session, spec, tickets, and ADRs.
• A one-person prototype does not need a tracker state machine.
• A weak test suite does not make autonomous loops safe.
• An agent cannot responsibly own a decision that requires product taste, production access, legal approval, or security accountability.
• A CONTEXT.md that grows without pruning becomes another source of stale instructions.

The same warning applies to Ralph loops, his approach for repeatedly running an agent against a task list. The loop is simple and can be useful: take one small task, run checks, commit progress, repeat. But it amplifies the quality of the task list and checks it receives. Good inputs create useful progress; weak inputs automate drift.

Is the paid AI Hero course worth it?

Matt Pocock is a credible educator, and the material is more concrete than generic AI-coding content. The course is likely useful for developers who need a curated path, cohort accountability, or a shared operating language for a team moving to coding agents.

For an experienced engineer already using agents, skills, durable context, delegation, code mapping, and review loops, the value proposition is weaker. Most of the practical techniques are available for free in the skills repository, the skills documentation, and the AI Engineer Roadmap.

The course does not need to be bad for it to be a poor purchase. Premium education should offer something beyond information: feedback on your work, a high-quality peer group, accountability, or a process you will actually adopt. If those are not the reason for buying, use the free material first.

What I would adopt

I would start small:

grill-with-docs → prototype (when uncertain) → to-spec → implement → code-review

Add to-tickets only when the work needs multiple sessions or real parallelism. Add triage only when outside reports are a meaningful part of the project. Use tdd for behaviour with a clear seam, not as a ritual.

The test is not whether this produces more Markdown. The test is whether it produces clearer decisions, smaller mistakes, and code that remains understandable after the agent has moved on.

That is the real promise of AI Hero’s best ideas. Not that agents can replace engineering, but that a good engineering process can keep agents useful.