AI Skills for Real Engineers

Install the full skill set globally:

npx skills add mattpocock/skills -y -g

Browse the source on GitHub: mattpocock/skills

This repo is Matt Pocock's working set of agent skills for everyday software engineering. They are the skills he uses to plan, design, build, refactor, and ship with AI without turning the process into vibe coding.

The set currently includes 24 skills with more than 173,000 total installs on skills.sh. The most installed skills include grill-me, tdd, improve-codebase-architecture, write-a-prd, and prd-to-issues, though Matt now generally recommends domain-model over grill-me for planning workflows.

The skills are intentionally small. You can read them, edit them, and understand what they are asking the agent to do. That is the point. The workflow stays observable.

The core idea

The repo has nearly 30,000 stars because the individual skills are useful on their own.

But the real value is in how they compose.

domain-model is the recommended starting point for most planning workflows. It resolves the design tree while sharpening the plan against the language and decisions already present in your codebase. to-prd turns the resulting context into a product requirements document. to-issues breaks that PRD into independently grabbable vertical slices. tdd implements those slices one behavior at a time.

That is a software practice, not a pile of prompts.

Skill docs

I started breaking the core workflow into individual skill docs:

• domain-model, the recommended starting point for planning workflows
• grill-me, an older, narrower skill for stress-testing a plan before you build
• to-prd, turn resolved context into a PRD
• to-issues, break a PRD into vertical-slice GitHub issues
• tdd, implement one behavior at a time with red, green, refactor

A workflow for real engineering

1. Sharpen the domain with domain-model

domain-model takes the plan and checks it against your project's existing language and documented decisions.

It looks for:

• CONTEXT.md, the domain glossary for a bounded context
• CONTEXT-MAP.md, when a repo has multiple bounded contexts
• docs/adr/, where architectural decisions live

During the session, it challenges overloaded language. If you say "account," it asks whether you mean Customer, User, Organization, Workspace, or something else. If your glossary defines a term one way and your plan uses it another way, it stops and resolves the conflict.

When a term is resolved, it updates CONTEXT.md immediately. When a decision is hard to reverse, surprising without context, and the result of a real trade-off, it offers to write an ADR.

2. Turn context into a PRD with to-prd

to-prd does not run another interview. It synthesizes the current conversation and codebase understanding into a PRD.

The PRD includes:

• problem statement
• solution
• extensive user stories
• implementation decisions
• testing decisions
• out-of-scope items
• further notes

It also looks for deep modules, which are modules that hide meaningful complexity behind a small, stable, testable interface.

3. Break the PRD into issues with to-issues

to-issues converts a plan, spec, or PRD into GitHub issues using tracer-bullet vertical slices.

Each issue should deliver a narrow but complete path through the system. Not "build the schema," then "build the API," then "build the UI." That is horizontal slicing.

A good issue cuts through the stack and produces something demoable or verifiable on its own.

Each slice is marked as:

• AFK, the agent can implement it without more human input
• HITL, human interaction is needed for a design review, architectural decision, or similar checkpoint

The skill proposes the issue breakdown first, checks granularity and dependencies with you, then creates the GitHub issues in dependency order.

4. Implement with tdd

tdd uses a red, green, refactor loop, one behavior at a time.

The rule is simple: tests verify behavior through public interfaces, not implementation details.

The skill explicitly rejects horizontal TDD, where you write all tests first and all implementation later. That produces tests for imagined behavior. Instead, it works vertically:

RED: write one failing behavior test
GREEN: write the minimal implementation
REPEAT: add the next behavior
REFACTOR: clean up once everything is green

This keeps the agent close to the actual implementation and prevents it from outrunning its headlights.

What is in the repo

The full collection is listed on skills.sh/mattpocock/skills, including install counts for each skill.

Planning and design

• domain-model, challenge a plan against the codebase's domain language and ADRs
• grill-me, older, narrower interview skill for stress-testing a plan
• to-prd, synthesize the current context into a PRD and submit it as a GitHub issue
• to-issues, break a plan or PRD into vertical-slice GitHub issues
• design-an-interface, generate multiple interface designs for a module using parallel sub-agents
• request-refactor-plan, create a small-commit refactor plan through user interview

Development

• tdd, build features or fix bugs through red, green, refactor
• triage-issue, investigate a bug, identify root cause, and file a TDD-based fix plan
• improve-codebase-architecture, find architectural deepening opportunities using CONTEXT.md and ADRs
• migrate-to-shoehorn, migrate tests from as assertions to @total-typescript/shoehorn
• scaffold-exercises, create exercise structures with problems, solutions, and explainers

Tooling and setup

• setup-pre-commit, set up Husky, lint-staged, Prettier, type checking, and tests
• git-guardrails-claude-code, block dangerous git commands before Claude Code runs them

Writing and knowledge

• write-a-skill, create new skills with structure, progressive disclosure, and bundled references
• edit-article, restructure and tighten articles
• ubiquitous-language, extract a DDD-style glossary from a conversation
• obsidian-vault, search, create, and manage notes in an Obsidian vault

Why tiny skills matter

Large frameworks can hide too much. They burn context, obscure the instructions, and make it harder to understand why the agent did what it did.

These skills stay small enough to inspect.

That means you can adapt the workflow to your codebase instead of adopting a giant process wholesale. You can keep the parts that improve your engineering judgment and edit the parts that do not match how your team works.

Start here

Install the full set:

npx skills add mattpocock/skills -y -g

Then try the planning workflow on a real feature:

domain-model → to-prd → to-issues → tdd

Watch the video above for the walkthrough, then read the source in mattpocock/skills.