Matt Pocock's Engineering Skills: A Practical Guide

A coding agent can produce plausible code while following a weak process. Matt Pocock’s engineering skills address that gap by giving agents repeatable ways to plan, create tickets, implement changes, test behavior, and review work.

The goal isn’t more automation for its own sake. It’s tighter control over how an agent reaches an engineering decision.

Prerequisites and installation choices

Before installing anything, confirm these requirements:

• An existing repository or a newly initialized repository
• Claude Code, Cursor, Codex, GitHub Copilot, or Amp
• Permission to add agent instruction files
• A clean Git working tree, or changes safely committed or stashed
• An issue tracker choice, such as GitHub Issues or local Markdown files

A skill is a small instruction package that teaches an agent a repeatable method for one job. Skills compose well because one skill’s output can become another skill’s input.

1. Install the skills through one route

Claude Code users who want managed, read-only skills can install the official plugin:

bashCopy
/plugin install mattpocock-skills

This route receives updates through Claude Code’s plugin system. The files are managed rather than edited directly, which fits teams that want a consistent shared installation.

The Claude Code plugin documentation explains how plugin discovery, installation, and management work.

For Codex, Cursor, GitHub Copilot, Amp, or an editable Claude Code installation, use the skills.sh CLI:

bashCopy
npx skills@latest add mattpocock/skills

Select the required skills during installation. Include setup-matt-pocock-skills, since it connects the general skill set to the repository’s actual conventions.

The CLI installs ordinary files that developers can inspect, version, and edit. The skills.sh documentation covers supported agents and package management, while Cursor’s Agent Skills documentation explains how Cursor discovers and applies skill files.

Updates are explicit rather than automatic:

bashCopy
npx skills update

That separation matters in regulated or tightly reviewed repositories. Your team can inspect upstream changes before bringing them into active engineering workflows.

Why it matters: One installation route prevents duplicate skills while preserving a clear update and review policy.

Configure the skills in an existing repository

An existing project doesn’t need to restart its architecture, backlog, tests, or documentation. Setup reads what’s already present and records repository-specific decisions around it.

2. Protect the current repository state

Check the working tree before asking an agent to change project instructions:

bashCopy
git status

If the tree contains intentional work, either commit it or stash it:

bashCopy
git add.
git commit -m "Save work before agent skills setup"

Or:

bashCopy
git stash push -m "Before Matt Pocock skills setup"

This creates a clean comparison point. Setup may propose changes to CLAUDE.md, AGENTS.md, or files under docs/agents/, so a clean diff makes every addition visible.

3. Run repository setup once

Open the repository in the chosen coding agent, then run:

bashCopy
/setup-matt-pocock-skills

The setup skill reads the Git remote and checks existing CLAUDE.md and CONTEXT.md files. It then proposes repository-specific instructions instead of assuming a blank project.

Review each proposed change before accepting it. The setup can record decisions under docs/agents/ and add an Agent skills section to CLAUDE.md or AGENTS.md.

This is where human control shows up most clearly. The skill can detect context and propose conventions, but the developer confirms what becomes repository policy.

4. Choose one issue-tracking model

For GitHub, the workflow uses the gh CLI. GitLab uses glab, while local mode works without a remote. Linear, Jira, Azure DevOps, Beads, Gitea, and other trackers can also work. Their programmatic workflow must be described in docs/agents/issue-tracker.md so the agent knows how to create, read, link, and update work items.

GitHub Issues and local Markdown are alternatives, not layers. Choosing both creates two possible sources of truth and makes completion state unreliable.

Setup also establishes:

• Where issues live
• Which triage labels the repository uses
• Where domain documents live
• Which command-line interface controls the tracker
• How the agent records dependency relationships

That boundary is useful. The repository owns its engineering conventions, while the installed skills supply repeatable procedures.

Why it matters: Existing repositories gain a controlled agent workflow without discarding their architecture or current delivery system.

Set up the skills in a new project

The new-project path is shorter because there are fewer existing conventions to reconcile. It still benefits from explicit domain language and issue-tracker rules before the first large feature.

5. Establish repository instructions early

Create the repository and its first agent instruction file:

bashCopy
git init
touch AGENTS.md

Install the skills through the selected route, then run:

bashCopy
/setup-matt-pocock-skills

Choose the issue tracker and establish domain vocabulary before planning a large feature. Domain vocabulary gives agents stable names for entities, boundaries, states, and business operations.

A new repository can define these rules before code creates conflicting terminology. An existing repository instead asks setup to discover and document the terminology already embedded in code and documentation.

The setup is safe at either stage. The difference is whether the skill records established decisions or helps formalize early ones.

For teams monitoring broader changes in coding agents, AI Developer Trends: Agents, Local Models & Code Safety gives related context on agent control and code safety.

Why it matters: Early vocabulary and tracker decisions reduce ambiguity before multiple agent sessions begin producing code.

Understand the 25 skills by moment of use

The skill set is easier to understand as an engineering lifecycle than as a command list. Start with the current problem, then choose the smallest skill that produces the next required artifact.

6. Match each skill to an engineering moment

When the correct entry point is unclear, use:

bashCopy
/ask-matt

This avoids starting with implementation when the real gap is an unsettled requirement, missing research, or an undefined repository convention.

7. Follow the normal artifact handoff

Start by testing the idea through structured questioning:

bashCopy
/grill-with-docs

The result is a recorded set of decisions. Once those decisions are stable, convert them into a specification:

bashCopy
/to-spec

The specification becomes the input for ticket design:

bashCopy
/to-tickets

Each approved ticket can then enter a fresh implementation context:

bashCopy
/implement

After implementation, review the result against the specification and repository standards:

bashCopy
/code-review

The sequence isn’t mandatory ceremony for every change. If a complete change fits inside one context window and has clear acceptance criteria, /implement can handle it directly without creating tickets.

For larger changes, the artifacts protect information between agent sessions. Conversation becomes a specification, the specification becomes tickets, and each ticket becomes a reviewable implementation.

Why it matters: Explicit artifact handoffs prevent decisions from disappearing when an agent’s context changes.

Design tickets that fresh agents can complete

A ticket is a self-contained unit that a fresh agent session can understand and finish. It needs observable acceptance criteria, explicit blockers, and one narrow behavior that can be demonstrated.

8. Create vertical slices instead of technical layers

A useful ticket cuts through the schema, API, interface, and tests needed for one small behavior. It does not place all database work in one ticket and all interface work in another.

The skill author documented a 26-ticket case organized into corpus, producer, aggregator, and selector layers. It required roughly 20 agent runs per closed ticket, with about three quarters of those runs spent on rework.

The lesson isn’t that 26 tickets is inherently excessive. It’s that a technically neat decomposition can create expensive coordination when individual tickets don’t produce independently demonstrable behavior.

After reviewing a proposed ticket, ask what can be demonstrated when it closes. If the answer depends on several unfinished tickets, the slice is probably too horizontal.

Wide renames and shared-symbol migrations are an exception. Those changes can follow an expand, migrate, contract sequence: introduce compatibility, move callers, then remove the old symbol.

9. Review the dependency graph before publishing

Read a dependency as a directed blocking edge. If ticket B says Blocked by A, B can’t start until A closes.

Tickets with no open blockers form the current frontier. Those are the tickets that independent agent sessions can safely begin.

/to-tickets publishes blockers first. Before publication, it shows a numbered breakdown and asks the user to merge, split, or correct tickets.

The human approves this graph. The skill proposes sequencing, but it doesn’t own scope or architecture.

10. Store tickets in GitHub or local files

On GitHub, create an issue with native blockers:

bashCopy
gh issue create --blocked-by 12,15

Create a child issue under a parent:

bashCopy
gh issue create --parent <number>

Or attach an existing issue as a sub-issue:

bashCopy
gh issue edit <parent> --add-sub-issue <number>

Native relationships are preferable to plain body text because GitHub can expose blockers and sub-issues as structured data. The GitHub issue dependencies documentation explains the supported relationships.

The skill may still write Blocked by in the issue body or omit a parent sub-issue link. Inspect published issues and repair native relationships when necessary.

In local mode, each ticket lives in a separate file:

.scratch/<feature-slug>/issues/<NN>-<slug>.md

Implement a numbered local ticket with:

bashCopy
/implement 03

Local files remove tracker setup and work well for isolated repository work. GitHub and Linear are better suited to displaying a dependency frontier across several fresh agent sessions.

The skill creates the ticket graph, but it isn’t an orchestration platform. It doesn’t dispatch agents, reliably close every completed ticket, or update every external tracker state.

Why it matters: A visible dependency frontier permits parallel work without pretending that ticket creation also manages execution.

Testing, troubleshooting, and safe operation

Agent workflows fail most often at the boundaries between artifacts. Testing should verify the acceptance criteria, the implementation, and the tracker state.

Testing Your Implementation

Before implementation, confirm that the acceptance criteria fail. A passing test at this point may not test the requested behavior.

Run the repository’s existing test command rather than inventing a new testing path. Then use:

bashCopy
/implement <ticket-number>

After implementation, verify four things:

1. The new acceptance criteria pass.
2. Existing tests remain green.
3. The requested behavior can be demonstrated.
4. The issue tracker reflects the actual completion state.

Finish with:

bashCopy
/code-review

The review should compare code against the specification, not merely check style. This catches implementations that are technically valid but solve a different problem.

Common setup and workflow problems

Use one fresh context per ticket. This tests whether the ticket is genuinely self-contained and prevents hidden conversational knowledge from influencing implementation.

For more coverage of agent reliability risks, see AI Weekly News: Mystery Models and Screen Watching.

Why it matters: Tests prove behavior, while tracker checks preserve operational truth between sessions.

Hands-On Steps

Start here (your first step)

Run git status, commit or stash current work, then install the skills through exactly one supported route.

Quick wins (immediate impact)

• Run /setup-matt-pocock-skills once and review every proposed repository change before accepting it.
• Run /ask-matt on one current engineering task and record which workflow entry point it selects.

Deep dive (for those who want more)

• Take one settled specification through /to-tickets, then verify that every ticket has observable acceptance criteria and explicit blockers.
• Implement one frontier ticket in a fresh context, run the repository tests, and update the tracker manually after completion.

Useful Resources

• skills.sh Documentation - Installation, supported agents, skill discovery, and update behavior.
• Claude Code Plugin Documentation - Official guidance for discovering and managing Claude Code plugins.
• Cursor Agent Skills Documentation - How Cursor loads and applies agent skills.
• GitHub Issue Dependencies Documentation - Native blocked-by, blocking, and sub-issue relationships.

Key Takeaways

Matt Pocock’s engineering skills are process instructions, not autonomous engineering management. They turn uncertain ideas into specifications, specifications into dependency-aware tickets, and tickets into tested implementations.

Install them through one route. Configure them around the repository rather than replacing existing practices. Use vertical slices for ordinary product work. Reserve expand, migrate, contract sequencing for broad symbol migrations and compatibility changes.

Keep humans responsible for scope, ticket breakdowns, architecture, demonstrations, and tracker state.

The strongest workflow isn’t the one with the most agent runs. It’s the one where every run starts with a clear artifact and ends with verifiable evidence.