TL;DR
- The solo signature skill pack is becoming the standard unit of distribution. 2026-04-15 forrestchang/andrej-karpathy-skills, 2026-04-29 addyosmani/agent-skills, 2026-04-30 mattpocock/skills all hit the top of GitHub trending — within two weeks, a moment converged in which a well-known engineer packages their entire way of working into a SKILL.md.
- The character of the three packs is precisely different:
- Karpathy: 1 skill, 67 lines, a behavioral contract. Pins down only the 4 stances a model should take before it goes off to write code.
- Matt Pocock: 28 skills, 6 categories, a collection of workflow slash commands. One slash per input stage, from PRD → issues → diagnose → refactor.
- Addy Osmani: 22 skills, flat, a methodology catalogue unified under X-driven development / X engineering noun phrases.
- Install them together and you get name collisions (
tddvs.test-driven-development,diagnosevs.debugging-and-error-recovery) and discipline overlap (spec/TDD/debugging present in two or three places at once). §4 sorts out how to untangle them. - Recommended combo: if you'll install just one, Addy. If you need slash workflows, cherry-pick Matt. Karpathy layers on top of any combination without friction — it's the lightest.
Overview — Why Look at All Three Together
The overview of the Agent Skill series laid out that "the skill is the design unit after prompts and context." The Superpowers piece looked at framework-style meta-skill bundles. This piece covers signature packs where an individual has packaged their entire way of working into a SKILL.md.
The three packs bundle together because the author is themselves a domain authority. Karpathy is an OpenAI founding member, former Tesla AI director, and former mentor in the Microsoft AI Residency; Matt Pocock is one of the most influential TypeScript instructors; Addy Osmani is an engineering leader in Google Chrome DevRel. All three made the decision to move their workflow into a single SKILL.md bundle at nearly the same time.
| Pack | Skill count | Structure | Character |
|---|---|---|---|
forrestchang/andrej-karpathy-skills |
1 | single SKILL.md | behavioral contract |
mattpocock/skills |
28 | 6 categories | workflow slash commands |
addyosmani/agent-skills |
22 | flat | methodology catalogue |
The body runs Karpathy → Matt → Addy. Each section's shape is matched to the pack's character — Karpathy has only one skill, so signatures and tables would feel awkward; we substitute quotes of the core guidelines instead. For Matt and Addy, 5–6 signatures plus a full-table toggle.
1. Karpathy — Shaping Model Behavior With a Single Sheet of Guidelines
forrestchang/andrej-karpathy-skills is a repackaging of Andrej Karpathy's LLM-coding-pitfalls memo posted to X into a single SKILL.md. Precisely 1 skill, 67 lines. It isn't Karpathy's own repo — forrestchang (community) ported it — but after entering GitHub trending at #2 on April 15, it has effectively settled in as the Karpathy signature.
1.1. The Four Core Guidelines (quoted)
The body of the SKILL.md ends in just four sections:
- Think Before Coding — Don't assume. Don't hide confusion. Surface tradeoffs. State your assumptions; stop and ask when uncertain; when multiple interpretations exist, don't pick — present them.
- Simplicity First — Minimum code that solves the problem. Nothing speculative. No features beyond the request, no abstraction for single-use code; if 200 lines can be 50, rewrite it.
- Surgical Changes — Touch only what you must. Clean up only your own mess. Don't tamper with surrounding code, formatting, or comments; clean up only the orphan imports you created; existing dead code gets mentioned, not deleted.
- Goal-Driven Execution — Define success criteria. Loop until verified. Convert "fix the bug" into "write a test that reproduces the bug, then make it pass." With a strong success criterion, the model loops on its own.
1.2. When to Use It
- When you want to stop the model from rushing straight into writing code. All four guidelines share the trunk of "stop before writing."
- As a base discipline to install on any project. Pin 67 lines at the tail of your system prompt and it conflicts with no other skill or CLAUDE.md — it's a behavioral contract, not a workflow, so it has no slash commands, priorities, or self-invocation.
- Conversely, it falls short when you need a workflow. The Karpathy pack only pins down "stances before writing code"; it doesn't touch "how to build a PRD, how to slice issues, how to debug" — that's Matt and Addy territory.
2. Matt Pocock — 28 Workflow Slash Commands
mattpocock/skills. Hit GitHub trending on April 30 at +7.2k stars/day. Bundles 28 skills into 6 categories (deprecated · engineering · in-progress · misc · personal · productivity) — the distinctive move being to separate current operational, experimental, domain-specific, and personal by directory.
2.1. Six Signatures
grill-with-docs (engineering)
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise.
The signature of Matt's signatures. It doesn't just listen to your plan — it interrogates it against the project's CONTEXT.md and ADRs. Every time a decision crystallizes, it updates the ADR right there. When: before a new feature or architecture decision, when you want to forcibly align with the domain model.
grill-me (productivity)
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree.
The domain-free version of grill-with-docs. You toss your design out briefly and the model questions every branch of the tree in reverse, forcing you to crystallize the entire decision tree. When: when you want to stress-test a design you've only been turning over hazily in your head.
caveman (productivity)
Ultra-compressed communication mode. Cuts token usage ~75% by dropping filler, articles, and pleasantries while keeping full technical accuracy.
His trademark. Keeps full technical accuracy but drops articles, euphemisms, hedges, and conjunctions wholesale to cut tokens to a quarter. Drop: articles (a/an/the), filler (just/really/basically), pleasantries (sure/certainly/of course), hedging. When: when a long session starts eating context, or when you have to force down output token cost.
zoom-out (engineering)
Tell the agent to zoom out and give broader context or a higher-level perspective.
Matt uses this so often that "auto-trigger zoom-out when Claude is judged to be buried in details" is pinned into his own global CLAUDE.md. When: when the model gets trapped in a narrow file or function and why this work is happening starts to drop out.
to-prd / to-issues (engineering, a pair)
Turn the current conversation context into a PRD and publish it to the project issue tracker. / Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices.
Finishes brainstorm → PRD → issue-slicing in two slashes. Forces tracer-bullet vertical slices (where the first issue cuts thinly through the entire system) as the default. When: the moment a Slack conversation or meeting notes need to crystallize into a PRD, and the moment a PRD needs to decompose into issues an AFK agent picks up on its own.
diagnose (engineering)
Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test.
A slash that forces a 6-step debugging loop. Very close to Superpowers' systematic-debugging, but it stresses reproduce and minimize more — the contract is to compress the bug to the smallest unit of code before forming a hypothesis. When: vague "something somewhere is broken" bugs and performance regressions.
2.2. When to Use It (overall)
- Teams working on top of a PRD/issue tracker. The
to-prd·to-issues·triagetrio is the real main of this pack. It fits best in workflows where GitHub Issues is a first-class citizen. - Solo operators who want to handle writing with the same tool.
in-progress/writing-*·personal/edit-articleand other writer's slashes are bundled in. - Conversely, it's weak if you expect a full-stack discipline package. The forced gates for TDD, debugging, and verification are thicker on the Superpowers/Addy side. Matt's strength is the ritual of the input stage, and he treats code-writing discipline only lightly.
2.3. Full Table of All 28
Expand the full table of mattpocock/skills (28)
| Category | Skill | One-liner |
|---|---|---|
| engineering | diagnose |
6-step diagnosis loop for debugging / perf regressions (reproduce → minimize → hypothesize → instrument → fix → regression-test) |
| engineering | grill-with-docs |
interrogate the plan against CONTEXT.md / ADRs, updating docs inline as decisions crystallize |
| engineering | improve-codebase-architecture |
hunt refactor / deepening opportunities based on CONTEXT.md / ADRs |
| engineering | prototype |
throwaway prototype before design is locked (terminal-runnable build vs. simple code tree) |
| engineering | setup-matt-pocock-skills |
scaffold a ## Agent skills block in AGENTS.md/CLAUDE.md and a docs/agents/ tree |
| engineering | tdd |
force the red-green-refactor loop |
| engineering | to-issues |
decompose a plan/PRD into tracer-bullet vertical-slice issues |
| engineering | to-prd |
turn the current conversation context into a PRD and publish it to the issue tracker |
| engineering | triage |
process incoming issues through a triage-role state machine |
| engineering | zoom-out |
pull a detail-buried model up to broader context |
| productivity | caveman |
~75% token compression (drop articles/filler/hedges, keep technical accuracy) |
| productivity | grill-me |
interrogate the user's plan down every branch of the decision tree |
| productivity | handoff |
compress the current conversation into a handoff doc another agent can pick up |
| productivity | write-a-skill |
author a new skill in progressive-disclosure structure |
| in-progress | review |
review changes since a fixed anchor (commit/branch) along two axes: Standards/Behaviour |
| in-progress | writing-beats |
decompose writing into beats and reassemble as choose-your-own-adventure |
| in-progress | writing-fragments |
mine writing fragments (claims, vignettes, sentences) from the user |
| in-progress | writing-shape |
refine raw markdown into an article through conversation |
| misc | git-guardrails-claude-code |
block dangerous git commands (push, reset --hard, branch -D) via Claude Code hooks |
| misc | migrate-to-shoehorn |
migrate as assertions in TS tests to @total-typescript/shoehorn |
| misc | scaffold-exercises |
scaffold an exercise directory in section/problem/solution/explainer structure |
| misc | setup-pre-commit |
set up Husky pre-commit + lint-staged (Prettier, typecheck, test) |
| personal | edit-article |
improve a piece's structure, clarity, and concision |
| personal | obsidian-vault |
search, create, and manage notes in an Obsidian vault |
| deprecated | design-an-interface |
generate many module interface designs via parallel subagents |
| deprecated | qa |
interactive QA with the user → auto-create GitHub issues |
| deprecated | request-refactor-plan |
interview the user to write a small-commit refactor plan, then file issues |
| deprecated | ubiquitous-language |
extract a DDD-style ubiquitous-language glossary from the current conversation |
3. Addy Osmani — A 22-Skill X-driven development Catalogue
addyosmani/agent-skills. Hit +3k stars/day the day after its April 29 appearance, two consecutive days at the top of trending. No category directories — 22 skills laid out flat, almost all named with X-driven development or X engineering noun phrases. Closer to a methodology catalogue.
3.1. Six Signatures
using-agent-skills (meta)
Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.
The bootstrap of Addy's pack. Same role as Superpowers' using-superpowers — it lays down the discovery and invocation contract for the other 21 skills first. When: bundle it to auto-inject at SessionStart right after installing the pack, and the self-invocation rate of the rest goes up.
spec-driven-development
Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet.
Exactly the same grain as a spec-first principle. It turns "no spec means no code" into a discipline. When: a new project or feature, or when requirements exist only as a hazy idea.
doubt-driven-development
Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when correctness matters more than speed, when stakes are high (production, security-sensitive logic, irreversible operations).
Addy's signature. Forces a fresh-context adversarial review (asking a model in a separate context to argue against it) for every non-trivial decision. When: where correctness matters more than speed — production changes, security logic, irreversible operations. In a word, adversary as a service.
source-driven-development
Grounds every implementation decision in official documentation. Use when you want authoritative, source-cited code free from outdated patterns.
Requires a citation to official docs for every implementation decision. The goal is to stop the LLM from reproducing the outdated patterns from its training cutoff. When: working with a new framework or a new library version where the model's training data may be stale.
context-engineering
Optimizes agent context setup. Use when starting a new session, when agent output quality degrades, when switching between tasks, or when you need to configure rules files and context for a project.
Standardizes the rules-file and context setup at session start and task switches. The backbone is guidelines for managing CLAUDE.md, AGENTS.md, and rule files. When: when output quality starts dropping (usually caused by context contamination).
incremental-implementation
Delivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.
Forces a model trying to bulldoze multiple files at once to cut into incremental commit units. When: when the model tries to attempt a 200-line change in one response — this skill cuts the chunk into small pieces.
3.2. When to Use It (overall)
- As a full-stack discipline bundle. Nearly half of the 22 are X-driven development (spec/test/doubt/source) — the closest full package to the Superpowers gates.
- People who work primarily on the frontend. Because Addy is Chrome DevRel, there are frontend-specific skills like
frontend-ui-engineering·browser-testing-with-devtools— a spot the Matt pack lacks. - Conversely, making PRDs/issues in one slash is weak. Addy is closer to discipline noun phrases and Matt is closer to workflow verb phrases — install both and they're complementary (§4).
3.3. Full Table of All 22
Expand the full table of addyosmani/agent-skills (22)
| Class | Skill | One-liner |
|---|---|---|
| meta | using-agent-skills |
bootstrap that lays down the discovery/invocation contract for other skills |
| methodology (driven) | spec-driven-development |
write a spec before coding |
| methodology (driven) | test-driven-development |
prove behavior with tests |
| methodology (driven) | doubt-driven-development |
fresh-context adversarial review on every decision |
| methodology (driven) | source-driven-development |
cite official docs on every decision |
| workflow | planning-and-task-breakdown |
decompose work into ordered tasks |
| workflow | incremental-implementation |
split multi-file changes into incremental commit units |
| workflow | idea-refine |
refine an idea via divergent → convergent thinking |
| workflow | context-engineering |
context / rules-file setup at session start and switches |
| code quality | code-review-and-quality |
multi-axis code review before merge |
| code quality | code-simplification |
simplify code to be clearer |
| code quality | debugging-and-error-recovery |
root-cause debugging guide |
| code quality | security-and-hardening |
harden code against vulnerabilities |
| code quality | performance-optimization |
optimize application performance |
| domain | frontend-ui-engineering |
implement production-grade UI |
| domain | browser-testing-with-devtools |
test in a real browser |
| domain | api-and-interface-design |
design stable APIs / interfaces |
| ops | git-workflow-and-versioning |
standardize the git workflow |
| ops | ci-cd-and-automation |
automate the CI/CD pipeline |
| ops | documentation-and-adrs |
decision records and documentation |
| ops | deprecation-and-migration |
manage deprecation / migration |
| ops | shipping-and-launch |
prepare for production launch |
The class column is assigned for this piece's organization — the original repo is flat.
4. Collision Potential — Where It Breaks When You Install All Three
The points below aren't observed from running them together — they're read off each one's SessionStart hooks, README, definition files, and filed issues, listing only collisions that are structurally inevitable.
4.1. Name Collisions and Discipline Overlap
Each of the three packs has skills that do the same job, two apiece:
| Job | Karpathy | Matt | Addy |
|---|---|---|---|
| TDD | (guideline §4 Goal-Driven) | engineering/tdd |
test-driven-development |
| debugging | (none) | engineering/diagnose |
debugging-and-error-recovery |
| skill authoring | (none) | productivity/write-a-skill |
(can substitute Superpowers' writing-skills) |
| code review | (none) | in-progress/review |
code-review-and-quality |
| architecture improvement | (none) | engineering/improve-codebase-architecture |
(none) |
With all three installed at once, which one self-invokes hinges on subtle differences in the description. Claude Code doesn't show the user the description-matching result, so if you suspect a collision, compare them and remove one — that's faster.
4.2. Installed Alongside Superpowers
These three packs are exactly what the Superpowers review §4 covers under mixing with other meta-frameworks. The spots that collide most often:
- Superpowers
test-driven-developmentvs. Matttddvs. Addytest-driven-development— all three become self-invocation candidates at once. - Superpowers
systematic-debuggingvs. Mattdiagnosevs. Addydebugging-and-error-recovery— same. - Superpowers
writing-skillsvs. Mattwrite-a-skill— same.
→ The effectively only fix is to pin into your global CLAUDE.md, in one line, which pack owns which domain — e.g. specifying that debugging is systematic-debugging, TDD is test-driven-development, skill authoring is writing-skills.
4.3. Karpathy Doesn't Collide
The single karpathy-guidelines is a behavioral contract, so it has no slashes, self-invocation, or discipline gates. It just layers on top of any combination — working only as a 67-line behavioral baseline.
5. Conclusion — Whose Should You Install
The decision tree across the three packs is simple:
- If you'll install just one: Addy. The 22 X-driven development skills are effectively a full-stack discipline bundle, with frontend-specific skills thrown in. Its discipline-gate thickness is the most balanced of the three.
- If you need slash workflows: cherry-pick Matt. You don't need all 28 — just
engineering/{grill-with-docs,to-prd,to-issues,diagnose,zoom-out}+productivity/{caveman,handoff,grill-me}or so. It's most worth its weight on teams where the PRD/issue tracker is a first-class citizen. - Baseline: Karpathy. Layer it on top of any combination as a 67-line behavioral contract. No collision risk.
- Layered on top of Superpowers: Addy's methodology noun phrases are complementary to Superpowers' process gates (the former is why you should build it this way, the latter is when and in what stage to build it). For Matt, pick only the slash-ritual domain — about 5:
to-prd·to-issues·triage·grill-with-docs·caveman— which don't overlap with Superpowers and complement it.