Matt Pocock Skills Selection Guide: Match Your Workflow Gaps First

The article analyzes how to choose skills from Matt Pocock's collection for AI-assisted development (Claude Code, Codex, and other agents via skills.sh). It is based on source code v1.2.3 (HEAD c55ee46) and installer output Found 38 skills from sandbox testing with skills.sh 1.7.0 ( npx skills@latest add mattpocock/skills).

Skill Categories: 38 Total, 25 "Regulars" in the Plugin

The repository organizes skills into five buckets:

engineering/ (18) – daily coding skills, promoted in the plugin.

productivity/ (7) – general workflow skills, also promoted.

misc/ (4) – README states "not promoted in the plugin".

in-progress/ (9) – beta, README: "excluded from the plugin…can change or disappear without warning".

deprecated/ (0) – empty.

The Claude Code plugin ( claude plugins install mattpocock-skills) bundles exactly the first two buckets (25 skills). The skills.sh copy method ( npx skills@latest add mattpocock/skills) lets you pick any subset; files live in your repo and you control updates via npx skills update. The installer requires setup-matt-pocock-skills to be selected – it is the prerequisite for all engineering skills.

Dimension 1: Who Invokes – User-Invoked vs Model-Invoked

README Reference splits skills on one axis: who can invoke them .

User-invoked : only triggered when you explicitly type its name (e.g., /grill-with-docs). Role: "orchestrate". Frontmatter sets disable-model-invocation: true (Codex: policy.allow_implicit_invocation: false).

Model-invoked : model may call automatically when a task matches. Role: "hold the reusable discipline". No disable flag; description written with trigger phrasing.

Invariant from .agents/invocation.md: User-invoked may call Model-invoked, but never another User-invoked.

Dependency graph extracted from SKILL.md files: grill-with-docs calls grilling and domain-modeling. implement drives tdd (red-green slices) then code-review (dual-axis, parallel sub-agents) then commits. improve-codebase-architecture calls codebase-design for vocabulary. tdd may call codebase-design when interface shape is uncertain.

README: grilling is "the reusable interview primitive behind grill-me, grill-with-docs, triage, wayfinder and improve-codebase-architecture ".

Consequence: installing a User entry without its Model dependencies yields a hollow shell (e.g., /grill-with-docs without grilling + domain-modeling produces an interview that writes nothing; /implement without tdd + code-review is just raw generation).

Dimension 2: Fill Your R&D Workflow – The Main Line and On-Ramps

ask-matt

(engineering User entry) acts as the official router. The main idea → ship line: /grill-with-docs: interrogate & write CONTEXT.md + ADRs (stateful, same context window).

If a question needs running code: branch via /handoff (productivity User skill) to compress context, then /prototype in a fresh session.

Multi-session large work: /to-spec → issue tracker → /to-tickets (tracer-bullet tickets with declared blockers) → per-ticket /implement.

Single-session small work: direct /implement.

Every /implement runs /tdd (one red-green slice at a time), finishes with /code-review (standard axis + spec axis, parallel sub-agents), then commits.

Three on-ramps into the main line:

External issue pile: /triage – runs issues through a triage state machine, outputs agent-ready briefs.

Hard failure: /diagnosing-bugs – discipline: first create a tight feedback loop with a command that makes the bug red, then fix, then add regression test.

Vague engineering too big for one session: /wayfinder – map decision tickets on tracker, resolve one by one, output decisions not deliverables, then return to /to-spec.

Two vocabulary layers (not standalone flows): /domain-modeling maintains domain language ( CONTEXT.md /ADR); /codebase-design supplies deep-module design vocabulary (module, interface, depth, seam).

Context hygiene rule: steps 1-3 keep the same context window (≈150k token "smart zone" for state-of-the-art models); each /implement cold-starts from its ticket.

Dimension 3: Setup Configuration Is Derived From Your Selection

setup-matt-pocock-skills

is a prompt-driven per-repo configurator. It runs three sections, writing into docs/agents/:

A – Issue tracker : asks where you track tickets (GitHub gh, GitLab glab, local markdown .scratch/<feature>/, or free-text for Jira/Linear). Writes docs/agents/issue-tracker.md.

B – Triage labels : five canonical roles needs-triage / needs-info / ready-for-agent / ready-for-human / wontfix; asks to accept defaults. Writes docs/agents/triage-labels.md. Skipped entirely if triage skill is not installed (SKILL.md: "Skip this section entirely if the triage skill isn't installed… since an uninstalled skill needs no labels").

C – Domain doc layout : default single-context ( CONTEXT.md + docs/adr/), auto-written. Only offers multi-context when monorepo signals detected ( pnpm-workspace.yaml, package.json workspaces, src/packages/*). Writes docs/agents/domain.md.

Consumers ( to-spec, to-tickets, code-review) all assume setup has run; missing config redirects you to /setup-matt-pocock-skills rather than self-healing.

Therefore the true selection order:

Define workflow (which main-line segments / on-ramps you need).

Pick User entries + their required Model disciplines together.

Run setup – it configures only for what you installed (B section appears only with triage, C multi-context only with monorepo signals).

Reversing order (install all → run setup → later add triage) leaves triage-labels.md ungenerated; you must re-run setup to add it.

Scenario-Based Skills – Install When You Hit the Scenario

/prototype

– Validate state model, UI look, or design question with a throwaway prototype. /research – Dispatch a background agent to fetch high-trust primary sources; output cited Markdown. /diagnosing-bugs – Hard bugs, intermittent flakes, performance regressions – a dedicated battle. /wizard – Steps only a human can do: provision infra, configure credentials, navigate unfamiliar console, one-off migration. /wayfinder – Work too large for one session; need a decision-ticket map. /resolving-merge-conflicts – Actively in a merge/rebase conflict; resolve chunk-by-chunk by intent, never --abort.

misc four: git-guardrails-claude-code (prevent dangerous git commands), setup-pre-commit (auto format/lint/test), migrate-to-shoehorn (TS as assertions → shoehorn), scaffold-exercises (course exercise structure).

These live in misc/ (not promoted) or in-progress/ (beta) – install on demand, no pre-emptive slot reservation.

Security Risk Assessments – Three Columns, Don't Be Scared Off

The installer shows a "Security Risk Assessments" table with three columns from skills.sh audit page: "Combined security audit results from Gen Agent Trust Hub, Socket, and Snyk".

Gen (Gen Agent Trust Hub) : content layer – what capabilities the prompt declares (run commands, write files, call APIs, read network).

Socket : supply-chain layer – malicious behavior in dependencies. All visible entries show 0 alerts (some skill pages show Pass).

Snyk : vulnerability layer – known vulns or dangerous patterns in code/commands. Mostly Low Risk, a few Med Risk.

Three skills flagged (verified against audit page & skill pages): triage – Gen: Med Risk, Socket: 0 alerts, Snyk: Med Risk code-review – Gen: Warn, Socket: Pass, Snyk: Fail to-tickets – Gen: Pass, Socket: Pass, Snyk: Warn

Why these? triage reads/writes issue tracker (setup A section: gh / glab /local markdown) and transitions ticket states. code-review reads git diff and spawns two parallel sub-agents. to-tickets writes tickets to tracker or local files. Snyk's "Fail" on code-review aligns with its declared actions (read diff, spawn sub-processes) – not a vulnerability in the skill itself. Skills are SKILL.md prompt documents; they execute nothing. The real safety boundary is the agent platform's permission prompts (allow/ask/deny). Official docs: "review skills before installing and use your own judgment". Risk levels tell you where to look; permission prompts are the security boundary.

Pre-Install Checklist (Self-Test Each Item)

[ ] Choose install route: Claude Code plugin (subscription, read-only, auto-update) or skills.sh (copy, editable, manual update) – pick one.

[ ] Decide your workflow: interrogation start? spec+tickets? direct implement+review? Map to User entries.

[ ] Check User entry's Model dependencies together ( grill-with-docs → grilling + domain-modeling; implement → tdd + code-review).

[ ] Always check setup-matt-pocock-skills.

[ ] Run /setup-matt-pocock-skills; expect prompts for issue tracker, triage labels (only if triage installed), domain layout (multi-context only if monorepo detected).

[ ] Read security columns as "capability declaration list": Socket all 0 alerts, Snyk mostly Low Risk; inspect flagged skills' declarations, don't auto-uninstall.

[ ] Install scenario skills ( prototype, diagnosing-bugs, etc.) when the scenario actually appears; ignore misc/ and in-progress/ until needed.

Decision path in one sentence: workflow gap → User entry → matching Model discipline → setup writes config for what you chose → rest on demand.

Boundaries & Next Steps

Analysis based on v1.2.3 / HEAD c55ee46; installer output from sandbox test; rest per documented expectations. Actual experience may vary – run it yourself. CHANGELOG shows active patches on 1.2.3 ( diagnosing-bugs secret redaction, cross-harness tool naming, wizard revamp) – watch for updates after install.

Next articles will deep-dive two practical paths: (1) /grill-with-docs → CONTEXT.md + ADR persistence; (2) /implement → /tdd → /code-review integration in real development and where it stalls.