In one line
mattpocock/skills provides individual practices for requirement questions, project terminology, specifications, and testing that you can select for the task at hand.
Repository: mattpocock/skills
Fast code generation still leaves work to redo if the result misses the request. This repository from our weekly AI briefing focuses on alignment and development practices. Start with one recurring question or one term your team keeps interpreting differently.
What can you do with it?
The skills are small and adaptable. Some require an explicit user invocation; others can also be selected by the model. /grill-with-docs asks requirement questions while documenting terminology and design decisions. /to-spec turns the conversation into a specification. /tdd works through a failing test and minimal implementation at an agreed test boundary.
We suggest identifying whether a task needs clearer requirements, shared vocabulary, or a validation criterion before choosing a skill. Mark any overlap with the team's current process too.
Installation and setup
For the Claude Code plugin:
claude plugin install mattpocock-skills@claude-plugins-official
The README also covers Codex and other agents. Choose either the automatically updated plugin or the skills.sh route that copies editable files for manual updates. Installing both for one agent duplicates the skills.
Run setup once per repository to choose the issue tracker, triage labels, and document location. Check the destination project and visibility before connecting an external service.
/setup-matt-pocock-skills
Scenario 1: Turn a vague request into specific questions
“Let administrators manage users” leaves permissions, states, and failure behavior unresolved. Try starting with /grill-with-docs:
/grill-with-docs
I'm planning a feature for administrators to manage user status.
Ask about allowed transitions, approval permissions, and failure behavior.
Separate answers available in the code from decisions I need to make.
The official guide describes this skill as a way to settle a fuzzy change within one session. Terms are written to GLOSSARY.md; qualifying design decisions go under docs/adr/. Not every answer becomes an ADR, so check whether important requirements remain only in the conversation.
Scenario 2: Carry shared terminology into a specification
“Active user” might mean a recent visitor to one teammate and an enabled account to another. Settle the meaning, then continue in the same conversation with /to-spec. The official guide describes this handoff from requirement questions to specification.
/to-spec
Turn our agreed user states and permissions into a specification.
Separate normal behavior, requests to reject, and unresolved conditions.
Before publishing, confirm the destination issue tracker and project.
Compare the specification with your answers, paying particular attention to ordering, exceptions, and behavior that must remain unchanged. Since the skill can publish to an issue tracker, decide where private requirements belong before proceeding.
Scenario 3: Test one observable behavior
Once the behavior is clear, agree on what the test should observe. The official /tdd guide calls for agreeing on the test boundary before writing a failing test and the implementation needed to pass it.
/tdd
I want to reject empty input while preserving valid-input behavior.
Explain the observable inputs and outputs and the available test boundaries.
After we agree on a boundary, start with why one test fails.
When reviewing the result, check whether the test observes user-facing behavior rather than internal function names. Trace expected values to the specification instead of repeating the implementation's calculation. A useful test should make the requirement it covers understandable.
Enterprise adoption checks
Useful capability: Choose the relevant practice for requirement alignment, vocabulary, or validation. Compare the official requirement-question guide and testing guide with the team's actual problem.
Operating burden and security: Automatic updates can change reviewed instructions. Editable files require an owner for upstream changes. Inspect conflicts, connected tools, and publication destinations before installation. Keep instruction text separate from actual execution permissions.
License: The repository uses MIT. Check LICENSE for modifications and redistribution and assess the agent and issue service terms separately.
Original sources and further reading
- mattpocock/skills repository
- README and skill inventory snapshot
- LICENSE
- Read alongside OpenCode execution permissions and DeepSeek Harness plugin boundaries.
Wrapping up
The Hypemarc Builder Community will keep sharing the AI news and open source projects we explore each week. We'll continue gathering useful resources to share with fellow builders.
- Open chat: AI Builders
- Adoption advice and inquiries: Contact form
- Get the next post: Blog RSS · AI resource library