My most-used agent skills: what I forked, what I pulled, what I wrote

A month of my own Claude Code sessions, counted skill by skill. Which skills I reach for, where each one came from, what I changed or wrote myself, and how to pick a starting set of your own.

TL;DR

  • Most of my skills are a fork of Matt Pocock's skills repo, and three came from elsewhere: two pulled repos and one Anthropic plugin.
  • My two most-used skills open and close a session: commit-session (45 sessions), which I wrote, and handoff (37), which I changed.
  • My changes to the forked skills are small: save the result to a file, list the assumptions, add a verify step. Some fixed something I kept correcting by hand; the rest came from comparing my skills with another repo.
  • Start with five skills, use them for two weeks, then count what you actually ran before adding more.

My skills came from three places

A skill is a folder with a SKILL.md file in it: instructions an agent reads when you call it by name, or when it decides the task fits. The format is an open one, so Claude Code, Codex and GitHub Copilot can all read the same folder. I keep one copy of my skills in a workspace repo and symlink each folder into ~/.claude/skills (Claude Code) and ~/.agents/skills (Codex, Copilot and the rest), so editing a skill changes it everywhere. A name written with a slash, like /handoff, is a skill only I can start by typing it; a bare name, like tdd, is one the agent may also load by itself when the task fits.

Most of that copy is a fork of Matt Pocock's skills repo, taken on 17 September 2026. His README says the skills are "designed to be small, easy to adapt, and composable", and that is why I forked instead of installing his plugin: a plugin is read-only and updates itself, a fork is mine to edit. The cost is that I port his later changes by hand.

Two skills I pulled from other repos and keep a note of the exact upstream commit for each: humanizer from Siqi Chen's repo, which rewrites prose that reads as AI-written, and playwright-cli from Microsoft, which lets an agent drive a real browser from the shell. frontend-design came to me through Anthropic's frontend-design plugin for Claude Code, which promises interfaces "that avoid generic AI aesthetics". The copy in my folder has drifted into a shorter rule set of its own, and it still lacks the source note the other two have.

I wrote the rest myself.

To see which of all these I really use, I counted. Claude Code keeps a transcript of every session, and between 15 September and 13 October 2026 I had 536 of them. For each skill I counted the sessions that called it. Codex sessions are not in that number, a session that called a skill five times counts once, and the first two days predate my fork.

The loop that runs every session

These four are the ones I would keep if I could keep nothing else. Three of them I wrote, and the fourth I changed.

/commit-session (45 sessions, mine). An agent session leaves edits in the working tree, often next to edits I made by hand. This skill works out which files the session itself touched, stages only those, and commits them with a one-line message. Anything else stays as I left it. Before it commits, it runs document-session.

/document-session (13 sessions on its own, plus inside every commit-session, mine). It finds the few things from a session that will not survive in the code or the git log (a decision, a new command, a gotcha) and writes each into the doc that owns it: the README, a runbook, an architecture note, an ADR. It shows me a table of proposed edits and waits for my approval. It is the reason my READMEs and runbooks still match the code after a month of agent work.

/handoff (37 sessions, forked and changed). It compresses the conversation into a document the next agent can pick up. Upstream saves it to the system's temp folder. I changed it to save inside the project, under docs/handoff/, dated. There are 40 of those files across my workspace now, and read in order they are a diary of each project. Because the state lives in a file, I can clear the context whenever it gets heavy without losing the thread.

/handoff-pickup (21 sessions, mine) is the other end of /handoff. It opens the newest handoff, turns it into a ticked task list, and walks the pending items one at a time. Before I wrote it, I ran /handoff, copied the path of the file it wrote, and pasted it into the next session with a prompt of my own asking the agent to pick up from there.

Thinking before any code

/grill-me and grilling (10 and 12 sessions, forked; grill-me changed). The agent interviews me in rounds, a numbered batch of questions with its recommended answer for each, until nothing is left unsettled. Upstream ends when the interview ends. My version saves every question and my final answer to a dated file in docs/brainstorm/, so the decisions outlive the chat. There are 10 of those so far.

domain-modeling (15 sessions, forked as is). It keeps a CONTEXT.md glossary and ADRs (short architecture decision records) for each project, and challenges me when I use a word two ways. Matt Pocock's README argues that agents left to guess a project's jargon "use 20 words where 1 will do", and this is the skill that keeps the glossary that fixes it.

/to-spec and /to-tickets (4 sessions each, forked and changed). The first turns a conversation into a spec, the second breaks a spec into small tickets, each naming the tickets it waits on. In October I compared them with the spec and planning skills in Addy Osmani's agent-skills repo on the same feature. Mine surfaced decisions his missed, and his had pieces mine lacked. I took three of them. to-spec now opens with a numbered list of every assumption it made, so I correct one line instead of rereading the spec. Every ticket from to-tickets carries a verify command. And every two or three tickets there is a checkpoint, where the tests must pass and I review the work so far.

Building and checking

frontend-design (31 sessions, from Anthropic's plugin, since adapted). It pushes for mobile-first layouts, a real brand palette, a display font paired with a body font, and layered shadows. This count is inflated: my website project's instructions load it at the start of every session there.

writing-for-agents (15 sessions, forked as is). How to write a SKILL.md or an AGENTS.md so an agent actually follows it. I load it whenever I write or edit a skill, which this month was often.

tdd (10 sessions, forked as is). A red, green, refactor loop, one small slice at a time. The agent writes a failing test first, so I know the code runs before I read it.

wizard (10 sessions, forked as is). Some steps only I can do: create an API key, click through a cloud console, sign in. This skill writes a small interactive bash script that walks me through them and checks each one.

/implement and code-review (3 and 6 sessions, forked as is). implement builds from a spec or tickets, driving tdd, and closes with code-review, which checks the diff against the repo's standards and against the spec in two separate agents so neither biases the other.

/new-page (9 sessions, mine, still in beta). It turns a YouTube video, an article or a document into a one-page A4 PDF brief with a thesis, the main ideas and what to do about them. I use it when I want what a video says without watching all of it.

Pick your own set

diagnosing-bugs, prototype and doc-coauthoring did not run once this month. research (a cited write-up from primary sources), teach (a lesson spread over several sessions), youtube-learn (a timestamped digest of a video) and linkedin-post ran one to three times each.

If you are starting out, this is the order I would go in:

  1. Install Matt Pocock's skills as a plugin, not a fork. You will not know what to change yet, and you can fork later.
claude plugin install mattpocock-skills@claude-plugins-official

In Codex it is codex plugin marketplace add mattpocock/skills then codex plugin add mattpocock-skills@mattpocock; in Copilot, copilot plugin marketplace add mattpocock/skills then copilot plugin install mattpocock-skills@mattpocock. The README has the details.

  1. Use five of them for two weeks: /grill-me, domain-modeling, tdd, /handoff and code-review. Upstream handoff saves to your temp folder, and that was the first thing I changed.
  2. Count what you ran. In Claude Code, every transcript is a file under ~/.claude/projects. This counts the sessions, across every transcript you have, that used tdd; swap in any skill name.
grep -rlE '"skill":"tdd"|<command-name>/tdd</command-name>' --include='*.jsonl' ~/.claude/projects | wc -l
  1. Fork only when a skill keeps doing something you correct by hand, or when another repo does one part better. Those two reasons cover every change in this post.
  2. Write your own skill for the thing you repeat at the start or end of every session. For me that was committing and handing off.

When you pull a skill from someone else's repo, record where it came from and which commit, next to the skill. I keep a SOURCE.md in each pulled folder with the upstream URL, the commit and the date I copied it, so I can diff against upstream later.

Sources

claude-codeagent-skillsworkflowproductivityai

All writing