5 Engineer-Only Claude Skills Every Vibe Coder Needs

Module objectives

• Install the skills library and run its required configuration step.
• Understand the four failure modes these skills are built to fix.

The library installs through the skills CLI. Run this from your project root:

npx skills@latest add mattpocock/skills

Then run the one-time configuration skill inside your agent (Claude Code, Cursor, Codex — the skills are model-agnostic):

/setup-matt-pocock-skills

setup-matt-pocock-skills scaffolds per-repo configuration: where your issue tracker lives, your triage labels, and — importantly — the documentation paths the other skills lean on. Two artifacts come up again and again:

• CONTEXT.md — a living glossary of your project's domain vocabulary. Several skills read it first so they explain things in your app's language instead of generic terms.
• ADRs (Architecture Decision Records), typically under docs/adr/ — the record of decisions you have already made, so the agent does not relitigate settled choices.

The repository is MIT-licensed with no paywall.

The library targets four failure modes that show up the moment AI starts writing real code:

1. Misalignment — the agent does not actually understand the requirement, because nobody structured the questioning. (grill-me fixes this.)
2. Verbosity — shared domain language and terse communication cut the overhead and the token bill. (caveman, CONTEXT.md.)
3. Non-functional code — without fast feedback loops you are flying blind. (TDD, type checks, browser access.)
4. Architectural decay — fast coding accelerates entropy unless you deliberately invest in design. (improve-codebase-architecture.)

The design bet is that small, composable, model-agnostic skills beat heavyweight frameworks that take control away from you. As the repo quotes Kent Beck: "Invest in the design of the system every day."

---

Module objectives

• Surface the highest-leverage refactors in a messy codebase.
• Pressure-test a single decision until it becomes an implementable design.

What it does. The biggest downside of fast AI coding is drift: you make changes that quietly contradict what you already built, and the project gets convoluted until adding anything new is painful. improve-codebase-architecture dispatches an exploration agent across your codebase to find architectural friction and proposes deepening opportunities — places where a "shallow" module can be made "deep."

The skill defines its terms precisely:

• Module — anything with an interface plus an implementation.
• Depth — "leverage at the interface: a lot of behaviour behind a small interface." Deep modules are more testable and easier for an AI to navigate.
• Seam — where an interface lives; the point you alter.
• The deletion test — does deleting this module concentrate complexity, or just move it around?

It reads CONTEXT.md and your ADRs first, so the analysis speaks your domain's language and does not reopen decisions you already locked in. The output is a self-contained, timestamped HTML report (written to a temp directory) with a card per candidate — files involved, the fundamental problem, a concrete solution, the benefits, before/after Mermaid diagrams, and a recommendation strength — ending with a single top recommendation. Notably, it does not propose interfaces in that first report; it asks which candidate interests you before designing anything.

When to use it. Periodically on any project that has been growing fast — especially before you build a major new feature on top of an area that already feels tangled. Use your own judgment on which recommendations to act on; it surfaces options, it does not refactor for you. How to invoke it:

/improve-codebase-architecture

A typical finding reads like: "this quality-scoring module is a god-orchestrator tangled with unrelated concerns" — a clear signal that the next skill, grill-me, should drive the fix.

What it does. Most AI tools ask two or three clarifying questions, then let a pile of hidden assumptions slide straight into your project. grill-me does the opposite: it interviews you relentlessly about a plan or design until you reach shared understanding, resolving every branch of the decision tree.

The mechanic is what makes it valuable. Other tools ask five high-level questions and then resolve every downstream assumption themselves at code-writing time. grill-me instead goes deep: once you pick a direction, it walks down the rabbit hole created by that choice. Question 1 establishes the actual problem; the answer reshapes question 2 (what is the right shape of the solution?); that reshapes question 3 (how does this shape affect the functions that call this service?), and so on — each branch spawned by your last answer — until the whole tree is resolved. Questions come one at a time, each with a recommended answer, and it prioritizes exploring your codebase before asking.

A session is roughly seven or eight questions over about ten minutes, and you come out the other side with an actual implementable design instead of a vague direction. (A sibling skill, grill-with-docs, does the same but writes the resolved decisions into CONTEXT.md and your ADRs as you go.)

When to use it. Right after improve-codebase-architecture flags something worth fixing, or any time you are about to make a change whose ramifications you do not fully understand yet. It is the bridge from "this is a problem" to "here is exactly what we will build." How to invoke it:

/grill-me

Then describe the change you are considering and let it drive the questioning.

---

Module objectives

• Cut token spend on long sessions without losing technical accuracy.
• Build a mental model of unfamiliar code, then carry hard-won context into a fresh session.

What it does. caveman forces the model to reply tersely — like a "smart caveman" — to cut token usage. It drops articles (a/an/the), filler ("just," "really," "basically"), pleasantries, and hedging; fragments are fine; it abbreviates common terms (DB, auth, config, req, res, fn, impl) and uses arrows for causality (X → Y). The repo claims up to ~75% reduction; the point is that it keeps full technical accuracy — unlike naive "be brief" modes that drop the important technical language along with the fluff.

The detail that makes it safe to leave on: it automatically exits caveman mode when terseness would be dangerous —

• security warnings,
• irreversible-action confirmations,
• multi-step sequences where fragment order could be misread,
• or any time you ask it to clarify or repeat.

After the clear explanation, it resumes compressing. It stays active across turns until you say "stop caveman" or "normal mode."

A measured example. In the source video, the same clarifying response cost 768 tokens in normal mode and 502 tokens in caveman mode — about a 30% cut on that single message. Compounded across a long session, even 30% is real money; 75% is the best case when there is more filler to strip. When to use it. Long planning or review sessions where you are exchanging many messages and the prose does not need to be polished — exactly the kind of high-volume back-and-forth that grill-me and improve-codebase-architecture generate. How to invoke it:

/caveman

Or just tell the agent "caveman mode" / "talk like caveman" / "less tokens." To turn it off: "stop caveman" or "normal mode."

What it does. When a section of code is over your head, zoom-out tells the agent to go up a layer of abstraction and explain how the pieces fit the bigger picture, rather than drowning you in implementation detail. It looks at your domain vocabulary first (the project's glossary) so the explanation is grounded in your app's language, then maps the relevant modules and their relationships — which files are read, which are written, and where a given claim actually sits in that structure.

This matters because in an unfamiliar domain you tend to defer to whatever the model recommends. zoom-out gives you enough of a mental model to actually evaluate a recommendation instead of rubber-stamping it. In the demo, it took a refactor that improve-codebase-architecture had flagged as a concern and showed it was, on closer inspection, a non-issue — the "problem" was a misread of what the logging code was doing versus what the ranking code was doing.

When to use it. Any time an earlier skill (or a teammate, or the model) raises a point that is "a little higher than your understanding of things," and you need broader context before you act. It pairs naturally with caveman — run both and you get a terse, high-level map. How to invoke it:

/zoom-out

Then point it at the file, module, or claim you want explained from above. (Note: this skill is set to be user-invoked, not auto-triggered by the model.)

What it does. handoff compacts your current conversation into a portable markdown document so a fresh agent — or a fresh context window — can pick up exactly where you left off. Think of it as a deliberate alternative to auto-compacting: you keep all the accumulated understanding, but as a clean document you control rather than a lossy summary.

The handoff document includes a summary of the conversation and its context, references to existing artifacts (PRDs, plans, ADRs, issues, commits, diffs) by path or URL rather than re-pasting them, a "suggested skills" section telling the next agent what to invoke, and it redacts sensitive data (API keys, passwords, PII). It writes to your OS temp directory, not your workspace. Crucially, it tailors the document to what you tell it the next session is for.

Two everyday use cases:

1. Planning → implementing. After you have used improve-codebase-architecture and grill-me to reach a plan, handoff distills it into a concrete brief you can feed to a spec-driven implementation tool (OpenSpec, Compound Engineering, BMAD, etc.). Clear the window, hand the document to the implementer, and it starts building with full context.
2. Tangent without pollution. You are mid-task and need to chase a side question in a separate window, but everything accumulated so far is valuable context you do not want to muddy with the detour. Hand off first, branch in a clean window, come back.

When to use it. At the seam between two phases of work, or any time you need a fresh context window but cannot afford to lose what you have built up. How to invoke it (the argument tells it what the next session needs):

/handoff This is getting passed to a spec-driven development tool for implementation. Include the problem framing, the solution we landed on, the key decisions, and any specifics we resolved.

---

Module objectives

• Chain the five skills into one coherent loop.

None of these skills is a framework that takes over. They are small and to the point, so you can drop them into whatever process you already run and make it a little better. A representative loop:

1. /improve-codebase-architecture   → surface the highest-leverage refactor
2. /grill-me                         → resolve the chosen change into a real design
3. /zoom-out                         → sanity-check anything above your understanding
4. /caveman                          → keep the long back-and-forth cheap
5. /handoff "for implementation"     → ship the plan to a spec-driven tool, clean window

The first four get you to a decision you trust; handoff carries that decision forward so a spec-driven tool can implement it systematically. That hand-off between deciding and doing is the whole point of "vibe engineering": move fast, but keep a human in the loop on the decisions that matter.

---

Summary

| Skill | Use it to… | Invoke |

|---|---|---|

| improve-codebase-architecture | Find high-leverage refactors (deepening opportunities) | /improve-codebase-architecture |

| grill-me | Resolve a design's full decision tree before coding | /grill-me |

| caveman | Cut token spend on long sessions, accuracy intact | /caveman |

| zoom-out | Build a mental model of unfamiliar code | /zoom-out |

| handoff | Carry context into a fresh session/agent | /handoff |

Install once with npx skills@latest add mattpocock/skills, run /setup-matt-pocock-skills, and these five are available everywhere you code. They will not turn a vibe coder into a staff engineer overnight — but they will make you a more systematic one, which is the entire point.

---

Source: the mattpocock/skills repository (github.com/mattpocock/skills) and a video walkthrough demoing these five skills in a real project. Skill mechanics quoted from each skill's SKILL.md. Token and star figures noted inline with their provenance.