Matt Pocock Skills v1.3 Full Walkthrough: AI Engineering Workflow Practice from grill to retro

Preface: Why Another Set of Skills?

If you have been using Claude Code or Codex to write code for a while, you have probably hit these pitfalls:

• The Agent produces something not what you wanted;
• The Agent talks too much, saying in 20 words something that takes 1 word;
• The code cannot run, and it doesn't know;
• The project gets messier and messier, eventually becoming a mud ball.

Frameworks such as GSD, BMAD and Spec-Kit try to 'take over the process' to solve this. Matt Pocock (author of Total TypeScript) takes the opposite approach: do not take over the process; only provide a set of small composable skills, each short enough that you can read it, change it, and make it your own.

This repo calls itself Skills For Real Engineers: for people who genuinely do engineering, not vibe coding. Its README maps the four failure modes directly:

Failure mode	Corresponding skill
The Agent did not do what I wanted	/grill-me, /grill-with-docs
The Agent is too verbose	/grill-with-docs builds a shared language (GLOSSARY.md)
The code does not work	/tdd, /diagnosing-bugs
The code becomes a mud ball	/improve-codebase-architecture, /codebase-design

What you will learn in this article:

1. What changed in each version from v1.0 to v1.3.1, focusing on the new skills and breaking changes in v1.3;
2. Changes on the main branch that are not yet released but worth knowing in advance;
3. A complete hands-on walkthrough from zero: install -> configure -> grill requirements -> write spec -> split tickets -> TDD implementation -> code review -> write PR -> retro;
4. Three things existing users must do when upgrading.

---

I. First, two core concepts

Before reading the changelog, establish two concepts. The entire repo's design revolves around them.

1.1 User-invoked vs Model-invoked

Skills in the repo are divided according to who can trigger them:

• User-invoked: only runs when you type /xxx; its job is to orchestrate the workflow. Examples: /to-spec, /implement. They set disable-model-invocation: true in frontmatter.
• Model-invoked: you can call it manually, and the Agent can also call it itself when the task is appropriate; its job is to encode reusable discipline. Examples: tdd, code-review, grilling.

There is an iron rule: user-invoked skills can call model-invoked skills, but can never call another user-invoked skill.

This way, the 'steering wheel' of the workflow always remains in your hands, while craft skills such as TDD and review can be reused by any workflow.

1.2 Shared language: GLOSSARY.md

Matt calls this 'the coolest trick in the entire repo'. He gave an example from his own project:

• Before: 'when a lesson inside a course chapter was made real (that is, assigned a location in the file system) something went wrong'
• After: 'a materialization cascade went wrong'

By accumulating project terminology in GLOSSARY.md, the Agent uses the same set of words when reading code, naming variables, and writing specs. The benefit is not only saving tokens: consistent naming makes code easier to navigate, and the Agent's thinking is more focused.

Warning: since v1.3.0, this file was renamed from CONTEXT.md to GLOSSARY.md. Existing users should see the upgrade guide at the end.

---

II. Version evolution: v1.0 to v1.3.1

The repo manages versions with changesets. First look at the whole picture:

Version	Release date	Keywords
v1.0.0	2026-06-17	Added ask-matt routing, codebase-design, domain-modeling; renamed diagnose to diagnosing-bugs
v1.1.0	2026-07-08	to-prd -> to-spec; merged to-plan + to-issues into to-tickets; wayfinder, code-review, research became stable
v1.2.0	2026-08-05	Released as an official Claude Code plugin; supports Codex; grilling changed to ask in rounds; added wait-what, wizard, to-questionnaire
v1.2.2 / v1.2.3	2026-08	writing-for-agents can auto-trigger in Codex; diagnosing-bugs auto-scrubs sensitive data
v1.3.0	2026-09-29	implement-spec, pr, retro became stable; deleted resolving-merge-conflicts; CONTEXT.md -> GLOSSARY.md
v1.3.1	2026-10-04	Fixed outdated handoff instructions in ask-matt

2.1 Recap: the foundation laid by v1.0 ~ v1.2

These three versions did three major things. Understanding them is necessary to understand v1.3.

First, there is a router. v1.0 added /ask-matt: you do not need to remember every skill; just ask it 'which one should I use now'. It maintains a process map, and every new skill must update this map.

Second, the planning chain was unified. v1.1 unified the PRD as spec, and merged the three ticket-splitting skills into one to-tickets. The main flow was thus fixed:

idea -> /to-spec -> /to-tickets -> /implement

Third, it became a plugin and cross-harness. Since v1.2, it can be installed as a Claude Code plugin in one click; each SKILL.md has an agents/openai.yaml next to it so the same skill works in Codex:

# skills/engineering/tdd/agents/openai.yaml
interface:
  display_name: "TDD"
  short_description: "Test-driven red-green-refactor"

Also, v1.2 changed grilling from 'ask one question at a time' to 'ask the entire frontier in one round'. The frontier means all questions whose preconditions are already determined and can be asked now. According to the official description, the same 13 questions used to take 13 rounds; now they take about 3 rounds.

2.2 v1.3.0: three skills become stable, one is deleted, one is renamed

v1.3.0 is the most important recent version. Let's go through it item by item.

1. implement-spec: implement a whole spec in parallel

Previously, after splitting tickets, you could only use /implement to do them one by one. implement-spec takes a different view: tickets are not a list of steps, but a task graph.

How it works:

1. Read the spec and tickets, understand the dependencies;
2. (Optional) dispatch an exploration subagent to research first and write notes to a shared directory outside the repo, which later subagents share;
3. Create an integration branch;
4. For every 'frontier' ticket, start an implementation subagent, each implementing in its own worktree with tdd;
5. When a subagent finishes, a merge subagent merges its result into the integration branch;
6. When the frontier changes, continue dispatching new implementation subagents;
7. When everything is done, run code-review once on the whole integration branch, and use one subagent to fix all the issues found.

Several refinements before it became stable:

• The target is the integration branch, not a PR. Only when your tracker closes work through PRs, or you explicitly ask, does it open a draft PR after the first merge (a branch with no new commits cannot open a PR);
• If no issue tracker is configured, it prompts you to run /setup-matt-pocock-skills first instead of silently defaulting to gh;
• Before each implementation subagent starts, it confirms the worktree is based on the integration branch; before delivering, it merges the latest integration branch into its own branch, ensuring every merge is fast-forward.

In one sentence: use /implement if you want to drive each ticket yourself; use /implement-spec if you want to be the 'general contractor' orchestrating parallel work.

2. pr: what a PR description should look like

pr is model-invoked, so the Agent uses it automatically when writing a PR. It specifies that a PR body has only three sections:

## Summary
<smallest visual: pseudocode / call tree / file tree / Mermaid / diff>

## Evidence
- **Before:** <screenshot / output / failing test>
  **After:** <screenshot / output / passing test>

## Merge Danger
**Door:** <one-way or two-way>
**Blast Radius:** <one word describing the impact area>

Several points worth learning:

• Summary picks the smallest view. If you changed logic, write pseudocode; if you changed call chains, draw a call tree; if you changed directories, draw a file tree. This part is adapted from show-me by Dex Horthy of HumanLayer.
• Evidence grading: screenshots are S-tier; test results and console output are A-tier.
• One-way door / two-way door: easily reversible decisions are two-way doors; deleting data or changing irreversible decisions are one-way doors.

3. retro: review the environment, not the code

This is my personal favorite. /retro looks back at the whole process after a coding session, but it does not change code; instead it improves the Agent's working environment. It checks seven categories of problems:

Category	When it raises the issue
Navigation	The Agent took a long time to find a certain file
Automated checks	A mistake could have been caught by lint / types / tests; or the repo has no guardrails at all
Coding standards	The review agent missed a problem
Global AGENTS.md	AGENTS.md is too large; instructions should move to standards or checks
Tool economy	Expensive tool calls can be optimized
No-ops	The guidance files contain fluff that does not change behavior
Information access	Key information is unavailable to the Agent, such as dev server logs

One of the most valuable rules is: classify the violation first.

• Mechanical violations (fixed syntax patterns, banned APIs, import shapes, file locations) -> turn them directly into deterministic checks: lint rules, pre-commit hooks, or CI jobs;
• Judgmental problems (cross-file consistency, 'match the surrounding style') -> write them into CODING_STANDARDS.md.

It also states a division of labor: the implementation agent has the most context pressure, while the review agent only receives the diff and has the least pressure, so coding standards should be enforced by the review agent. CLAUDE.md / AGENTS.md enter every Agent's context; they must be extremely restrained and basically only contain navigation pointers.

4. Deleted resolving-merge-conflicts

The official reason is simple: it is no longer needed; Agents can handle in-progress merge/rebase conflicts themselves. This skill has no replacement. The documentation page is kept and marked as archived.

5. CONTEXT.md -> GLOSSARY.md (breaking)

All skills that read or write domain documents have changed names: CONTEXT.md -> GLOSSARY.md, CONTEXT-MAP.md -> GLOSSARY-MAP.md. Skills now only recognize the new names.

6. Several easy-to-miss patches

• Cross-skill invocation normalization: previously skills said 'run the /grilling skill', and the Agent did not always load it. Now the instruction is uniformly written Call the Skill tool with "grilling", which hits more reliably and no longer depends on Claude Code slash syntax. For example, the entire content of grill-with-docs is one line:

  Call the Skill tool twice, for "grilling" and "domain-modeling".
  

• Fixed invocations that violated the iron rule: several skills had tried to call setup-matt-pocock-skills (user-invoked); now they instead prompt the user to run it.

• YAML fixes: 6 skills' description had an unquoted colon that made YAML invalid, so npx skills skipped them during installation. If you previously found to-spec or code-review could not be installed, this was the reason.

• Removed em-dashes across the whole repo, and banned introducing them in CLAUDE.md.

2.3 v1.3.1

There is only one fix: ask-matt said that after diagnosing-bugs fixes a bug, it hands off to improve-codebase-architecture, but that step had been deleted long ago. It now says: after fixing the bug, run /retro in the same session and ask 'what could have prevented this bug earlier'; if the conclusion is that a suitable seam is missing, then hand off to /improve-codebase-architecture.

2.4 Unreleased changes on the main branch

After v1.3.1, there are 47 commits and 17 pending changesets. Here are the changes with the biggest impact on daily use:

skill	change
grilling	Each question is worded so that answering yes accepts the recommended answer; when you agree, you no longer have to say no
tdd	Each candidate seam comes with a one-line explanation: what it catches and what it misses
code-review	Actively searches for spec files in the repo; CODING_STANDARDS.md / CONTRIBUTING.md are always given to the Standards subagent; the two subagents run in the foreground
implement	When a ticket reference is passed, first pulls the title from the tracker and restates it; if ambiguous, asks
to-tickets	Each ticket automatically becomes a sub-issue of the source issue
setup-matt-pocock-skills	Automatically creates missing triage labels on GitHub/GitLab; fixes the glab command
diagnosing-bugs	In phase 5, first diffs the forced mutation against the original copy to prove the change actually took effect, then trusts the 'red light'
handoff	Explicitly states the temp directory location ($TMPDIR, otherwise /tmp; Windows uses %TEMP%)
wizard	A batch of template fixes: arrow keys work, .env values are quoted correctly, symlinks supported, etc.

Also, the README installation instructions were rewritten: Claude Code, Codex, and GitHub Copilot are all installed as auto-updating plugins.

Tip: several changesets carry the same sentence: 'Re-run /setup-matt-pocock-skills to refresh docs/agents/'. Remember to re-run setup after release.

---

III. Hands-on: walking the main flow from a requirement

Let's walk through a concrete scenario. Suppose you have a TypeScript e-commerce backend and want to add a 'coupon' feature. We'll use local Markdown as the issue tracker, so you can follow along without a GitHub repository.

3.1 Installation

Claude Code (recommended, auto-updates):

claude plugin install mattpocock-skills@claude-plugins-official

Codex:

codex plugin marketplace add mattpocock/skills
codex plugin add mattpocock-skills@mattpocock

Cursor, OpenCode, Windsurf and other Agents (manual updates):

npx skills@latest add mattpocock/skills -a cursor

Two pitfalls:

1. Choose either the plugin or skills.sh. If both are installed for the same Agent, every skill appears twice.
2. When using npx skills, during skill selection be sure to select setup-matt-pocock-skills.

The plugin contains 27 skills (20 Engineering, 7 Productivity). Beta skills under in-progress/ are not in the plugin and need separate installation:

npx skills@latest add mattpocock/skills --skill=claude-handoff

3.2 Run setup once per repository

Open Claude Code in the project root and enter:

/setup-matt-pocock-skills

It is not a script; it is 'explore first, confirm second, write third'. It checks git remote, CLAUDE.md, GLOSSARY.md, docs/adr/, .scratch/, and whether there are monorepo signals, then asks you section by section:

• A. Issue tracker: GitHub / GitLab / local Markdown / other (for Jira, Linear, just describe the process in a paragraph). Here choose local Markdown;
• B. Triage labels: only asked if triage is installed, and only one question: 'keep the default labels?'
• C. Domain document layout: defaults to single context; only asks if a monorepo is detected.

After confirmation, it writes a section into CLAUDE.md:

## Agent skills

### Issue tracker

Issues live as local markdown files under `.scratch/`. See `docs/agents/issue-tracker.md`.

### Domain docs

Single-context: one `GLOSSARY.md` + `docs/adr/` at the repo root. See `docs/agents/domain.md`.

It also generates docs/agents/issue-tracker.md and docs/agents/domain.md. Other skills find the tracker through this pointer instead of hardcoded paths.

The local tracker convention is:

.scratch/
└── <feature-slug>/
    ├── spec.md                 # output of /to-spec
    └── issues/
        ├── 01-<slug>.md        # one ticket per file, starting from 01
        └── 02-<slug>.md

3.3 /grill-with-docs: be grilled before writing code

/grill-with-docs I want to add coupons to the checkout flow: support minimum-spend discounts and percentage discounts, and only one coupon per order

It loads the two skills grilling and domain-modeling, and throws all currently askable questions in one round, each with a recommended answer. The format is fixed and roughly like this (illustrative):

❓ **Q1** - **Relationship between coupon and order**: one coupon per order; can a coupon be preselected at the 'cart' stage? Or is it only selected at 'order placement'?

➡️ Recommendation: select only at order placement; the cart does not hold coupons. Answer yes to accept.

---

❓ **Q2** - **Discount stacking order**: is the threshold of a minimum-spend coupon calculated on the original price or the member price?

➡️ Recommendation: calculate the threshold on the member price. Answer yes to accept.

You can answer by number, e.g. Q1 yes, Q2 use original price. Several points:

• Facts are the Agent's business: anything it can learn by reading code, it dispatches subagents to find; it does not ask you;
• Decisions are your business: it stops and waits for your answer;
• When the frontier is empty, it confirms 'have we reached consensus'; it does not start work before confirmation.

What grill-with-docs does beyond grill-me: as soon as a term is settled, it writes it into GLOSSARY.md immediately; if a hard-to-reverse decision is made, it writes an ADR. The session may end with:

<!-- GLOSSARY.md (illustrative) -->
# Checkout

Order placement and settlement context: responsible for turning a cart into a payable order.

## Language

**Coupon**:
A one-time discount credential the user can select at order placement; at most one is associated with one Order.
_Avoid_: voucher, red packet

**Threshold**:
The minimum amount required for a minimum-spend coupon to take effect, calculated on the original product price.
_Avoid_: threshold price, minimum amount

domain-modeling is paranoid about the glossary: when multiple names exist for the same concept, choose only one and list the rest under _Avoid_; definitions are only one or two sentences; common programming concepts do not enter the table.

docs/adr/0001-coupon-applied-at-order-not-cart.md

Tip: if the Agent suddenly says a long paragraph you cannot understand, type /wait-what. It re-explains using Simplified Technical English (ASD-STE100) plus the terms in GLOSSARY.md. The entire skill is three lines.

3.4 Need a runnable answer? Detour through /prototype

If a question cannot be settled on paper, such as how many states the coupon state machine should have, you can detour through a prototype:

1. Use /handoff to compress the current conversation into a handoff document;
2. Start a new session in a new directory and use /prototype to build a single-file HTML prototype with a state panel and a guided walkthrough;
3. /handoff back and reference the conclusion in the original conversation.

The prototype code is not deleted; it is saved on a prototype/<name> branch as primary source material.

3.5 /to-spec: no more questions, only synthesis

/to-spec

It does not grill you again; it synthesizes the previous conversation into a spec. It stops to confirm only one thing: test seams. The principles are:

• Prefer reusing existing seams;
• The higher the seam, the better;
• The fewer seams, the better; ideally one.

The spec template includes: Problem Statement, Solution, User Stories (required to be extremely detailed), Implementation Decisions, Testing Decisions, Out of Scope, Further Notes. Note that it explicitly forbids writing specific file paths and code snippets, because those quickly become stale. The only exception is artifacts from prototypes such as state machines and type definitions, which are more precise than prose.

The result is written to .scratch/coupon/spec.md and marked ready-for-agent.

3.6 /to-tickets: split into tracer bullets

/to-tickets

It splits the spec into tracer-bullet-style vertical slices, with these rules:

• Each ticket cuts through all layers (schema, API, UI, tests), not just one layer;
• Each ticket can be demonstrated or verified independently when done;
• Each ticket must fit into a fresh context window;
• Prefactoring goes first: 'first make the change easy, then make the easy change'.

It first shows you a numbered list and asks whether the granularity and dependencies are reasonable; only after confirmation does it write files. A ticket looks roughly like:

# 02: Apply a minimum-spend coupon at order placement

**What to build:** When a user selects a minimum-spend coupon at order placement, the order amount is reduced by the coupon value when it reaches Threshold; if it does not reach the threshold, show the shortfall.

**Blocked by:** 01

**Status:** ready-for-agent

- [ ] When the threshold is met, the order payable amount is correctly reduced
- [ ] When the threshold is not met, return the shortfall message
- [ ] A used Coupon cannot be applied again

Tip: for a wide refactor such as renaming a field that affects thousands of call sites, it does not force vertical slices; it orders by expand-contract: first add the new shape, then migrate call sites in batches, then delete the old shape, keeping CI green for every batch.

Warning: context hygiene: stay in the same context window from /grill-with-docs to /to-tickets; do not /compact or /clear mid-way. ask-matt gives a 'smart zone' of about 150k tokens; when approaching the limit, /compact at the nearest stage boundary.

3.7 Implementation: /implement or /implement-spec

Option one: drive ticket by ticket.

/implement .scratch/coupon/issues/01-coupon-model.md

According to current main behavior, it first reads the ticket and restates the title, then:

1. Calls tdd and does red -> green on the pre-agreed seam;
2. Runs type checks and individual test files frequently, and a full test run at the end;
3. Calls code-review to review;
4. Commits to the current branch.

After one ticket, /clear, then do the next. Each ticket is self-contained; the previous ticket's context can be discarded.

Option two: parallel orchestration.

/implement-spec .scratch/coupon/spec.md

Suitable when there are many tickets and the dependency graph has obvious parallelism. The full process is in section 2.2.

Three anti-patterns in tdd

tdd is now a pure reference skill; it no longer specifies a step-by-step workflow, but tells the Agent what tests are worth keeping. It names three anti-patterns:

// ❌ Tautology: recalculating the expected value with the code's own algorithm; it will never fail
expect(applyCoupon(price, coupon)).toBe(price - coupon.amount)

// ✅ Expected value from an independent source of truth: hard-coded known result, example from spec
expect(applyCoupon(300, fullReduction(200, 30))).toBe(270)

• Coupling to implementation: mocking internal collaborators, testing private methods, bypassing interfaces to query the database directly;
• Tautology: as above;
• Horizontal slicing: writing all tests before writing the implementation. The correct approach is one test -> one implementation -> loop.

One more easy-to-miss point: refactoring is not in the TDD loop; it belongs to the review stage.

code-review's two axes

code-review starts two subagents in parallel, kept separate from each other:

• Standards: whether the code matches the repository's coding standards, plus a baseline of 12 code smells from Fowler's Refactoring (mysterious naming, duplicated code, feature envy, data clumps, primitive obsession, shotgun surgery, etc.);
• Spec: whether it faithfully implements the spec, with misses, scope creep, or 'looks implemented but is actually wrong'.

The two reports are presented separately and not merged into one ranking. Because 'standards all correct but built the wrong thing' and 'built the right thing but broke standards' are two different failures; merging them would mask each other.

Two more constraints: the repository's own standards always take precedence over the baseline; smells are always judgment suggestions, not hard violations.

You can also use it alone to review any branch:

/code-review review the current branch against main

3.8 pr: automatically apply the template

If you ask the Agent to open a PR, pr takes effect automatically. For example, for this change, Summary might be a call tree:

createOrder
  validateCart
+ applyCoupon
+   checkThreshold
  persistOrder

Evidence shows the test results before and after; Merge Danger says: new feature, can be rolled back via a switch, a two-way door, blast radius checkout.

3.9 /retro: make the next time smoother

Run it in the same session, before /clear:

/retro

It lists improvement suggestions by severity, for example (illustrative):

1. Automated checks: the Agent wrote money as floating-point arithmetic twice; this is a mechanical problem, so add a lint rule forbidding + / - on the Money type;
2. Navigation: the Agent searched 6 times to find the price calculation module; add one navigation pointer in CLAUDE.md;
3. Coding standards: 'always store amounts in cents' is a judgment call; write it into CODING_STANDARDS.md and let the review agent enforce it.

The next build starts from a better environment. That is the closed loop of the main flow.

3.10 Three on-ramps

Not all work starts from an idea. ask-matt defines three on-ramps into the main flow:

Scenario	skill	Merge point
Bugs or requirements from others pile up	/triage	Produces an agent-ready issue, handed to /implement
Stubborn bugs, occasional flaky tests	/diagnosing-bugs	First build a feedback loop that must go red on this bug, then fix and add regression tests, finally /retro
Huge, foggy project	/wayfinder	Draw a map of decision tickets on the tracker; after the fog clears, merge in from /to-spec

Two reminders:

• /triage only handles issues that were not created by you; tickets produced by /to-tickets are already agent-ready, do not triage them again;
• /wayfinder is the heaviest process; its output is decisions, not deliverables. For features with clear scope, /grill-with-docs is enough.

If you cannot remember, just ask:

/ask-matt I have a random 500 in production; where should I start?

---

IV. Upgrade guide for existing users

If you installed this skill set at v1.2 or earlier, check three things when upgrading to v1.3:

1. Rename domain documents

git mv CONTEXT.md GLOSSARY.md
# For multi-context repos also:
git mv CONTEXT-MAP.md GLOSSARY-MAP.md

If you do not rename them, the skills will treat the project as having no glossary.

2. Re-run setup

/setup-matt-pocock-skills

Refresh docs/agents/issue-tracker.md and pick up changes like sub-issue commands, external PR list fixes, and glab command fixes. It updates the existing ## Agent skills section in place; it does not append a duplicate.

3. Clean up deleted skills

• resolving-merge-conflicts (deleted in v1.3.0, no replacement);
• Earlier deletions: ubiquitous-language -> domain-modeling, design-an-interface -> codebase-design, qa -> triage + to-tickets, write-a-skill / writing-great-skills -> writing-for-agents.

Plugin installs update automatically; for npx skills installs, run:

npx skills@latest update

---

V. FAQ

Q1: Can grilling use Claude Code's AskUserQuestion popup?

Officially, no. Two reasons: skills must be cross-harness, and each harness has a different questioning tool; structured multiple-choice questions push the Agent toward preset answers, against grilling's purpose of answering open questions in your own words. If you like popups, add one line to your own CLAUDE.md: 'when grilling, ask via AskUserQuestion'.

Q2: Can I contribute a new skill to the repo?

No. The repo only contains skills the author uses every day; every skill carries long-term maintenance cost. His principle: any behavior that can be composed from existing skills should not become a new skill. You can publish your own with skills.sh.

Q3: Can skills under misc/ still be used?

Yes, but they are frozen and no longer accept bug reports or PRs. git-guardrails-claude-code, setup-pre-commit and others are there; if you want to use them, install a copy and modify it yourself.

Q4: Can I use it without a GitHub repo?

Yes. Choose local Markdown during setup; all specs and tickets are written under .scratch/, and wayfinder also has a corresponding local implementation.

Q5: How to choose between /handoff and /compact?

After v1.2, ask-matt provides a decision tree; ask yourself in order:

1. Can you continue? (zero cost, keep first-hand context)
2. Is the next thing unrelated to the current context? -> /clear
3. Switching harness, changing directory, handing off to a colleague, or forking a side branch mid-way? -> /handoff
4. Is the task boundary clear and can it run independently to completion? -> hand it to a subagent
5. None of the above -> /compact (default option, but listed last)

---

Summary

The v1.3 upgrade can be summarized in three sentences:

1. The main flow got its tail completed: implement-spec handles parallelism, pr handles delivery, retro handles the closed loop. The main flow is now grill -> spec -> tickets -> implement -> review -> PR -> retro.
2. Conventions are more consistent: GLOSSARY.md unifies naming, 'Call the Skill tool' unifies invocation, and the boundary between user-invoked and model-invoked is clearer.
3. Lighter: delete skills that are no longer needed, do not accept new skill contributions, and stick to 'small and composable'.

I think the most worthwhile thing to learn from this skill set is not a specific command, but the engineering philosophy behind it: align first, then act; use shared language to compress communication; replace guesswork with feedback loops; turn mistakes you have made into guardrails in the environment. These principles have not become outdated in the AI era; on the contrary, because Agents write code so fast, they matter more.

If you have not tried it, start with the smallest combination: /grill-with-docs + /tdd. Run it once, then gradually add to-spec, to-tickets and retro.

Which type of failure do you run into most often when using Agents to write code? Welcome to discuss in the comments.

---

References

• Repository: mattpocock/skills
• Changelog: CHANGELOG.md
• Pending changes: .changeset/
• Install entry: skills.sh/mattpocock/skills
• Author newsletter: aihero.dev