How I use skills for everything

When agent skills first came out, I thought they were silly. We are just casting magic spells now are we? Is that where we are?

But over time, I bought into the whole "context engineering" thing (as much as I fought the hype initially) and started using them more. Today, almost every interaction I have with an agent on any surface loads at least one skill from the PostHog skills store.

No really, my agent looked it up. Over the last 28 days, 78% of my 578 chats loaded a skill and 47% updated one (shoutout AI observability for making this easy as all my Claude Code sessions go there).

I have about 139 skills in the store. About 100 of them are custom scouts, which are skills that run themselves on a schedule. The other 39 are for how I actually work, and those are what this post is about.

Jake gets it.

To be clear, this isn't a "try my magic skill bro" pitch. There's a little cottage industry of skills that promise to fix your agent, and I find it a bit cringe. I'm not taking a dependency on your skill, bro. Skills can turn into tech debt (agent debt?), so the bar for adopting someone else's should be very high.

What I'm evangelical about is the ways you use them.

Skills are magic context bombs

Most people think of skills as better prompts. Something that teaches the agent a trick. They aren't.

You should think of skills as little portable agentic memory systems. They are the perfect abstraction for tagging a bundle of context, so an agent (or I) can pull that context in exactly when it's needed and nowhere else.

The body is typically a thin index. The bundled files hold the detail. The agent reads them and pulls only the files the current task touches. That's progressive disclosure, and it's mostly the point.

A lot of the time skills are used to provide the agent with instructions, but this will likely go away as models get better. They will just use their built in memory and tools to get what they need.

What won't go away is the need to manage context. This means telling agents what's true right now, what happened last session, what's in-flight, and what bit us before. That's the part I'm skills-pilled on, and the part that's changed my work the most. Here are some examples.

Every meaningful piece of work I do is documented and maintained by my agents in one of two skills: self-driving-work and scouts-work (these are the two things I work on the most).

They're siblings with identical conventions: a numbered issues/ backlog with an index, an ideas/ folder, open-prs.md, a rolling 14-day CHANGELOG.md, environment-notes.md for durable gotchas, and a HANDOVER.md that each session overwrites its own section of.

At the time I'm writing this, the self-driving-work skill is on version 433 with 126 bundled files, including 55 numbered issues, 17 ideas, and 39 pain points. I didn't write most of those. My agents did, at the end of sessions, because the skill tells them to.

The loop looks like this:

• I start a session on any surface (local Claude Code, a cloud task, Slack, PostHog AI, Codex) and say "let's check in on /phs self-driving work".
• The agent uses my local /phs bridge skill, loads the remote skill, reads HANDOVER.md, scans the backlog index, and knows where we left off. We do the work in the repo and the product, not in the skill.
• At the end of the session, the agent logs any new issue or idea, records any PR that opened or merged, adds one changelog line, and overwrites its handover section.

This is the lowest friction and most chill way I have ever found to deliver complex features over long horizons. The skill is the memory, and it's memory I get my agents to intentionally control and maintain.

I don't rely on a model's hidden memory feature that I can't read. The skill in PostHog shows exactly what my agents think is true. If it gets messy, I tell the agent to clean up, or better yet, it knows to follow certain protocols like trimming the changelog after 14 days (all skill edits are version tracked so it's recoverable if I need it).

I liked this pattern enough that I turned it into a template. project-template is in the community skills store. Install it once per area of work, bind the project name and the changelog window, and you have a living hub that any agent on your team can read and write.

My favorite part of the template is a small table the agent has to consult before writing anything down:

The table is there to stop the most common way these skills go wrong: the agent writes durable detail into the changelog, because the changelog is the file it was already editing. I watched that happen many times before I added the table.

You don't need all this structure on day one, though. For a new, messy project, just start a skill and tell your agent to keep its context there. Don't worry much about the layout. Agents do something sensible on their own, and in my experience, a skill only starts to get messy at around version 50. The important part is that the context is in a skill you can see, version, and load from anywhere.

Filter our skills store to self-driving- and you get a map of how self-driving works inside PostHog: the alerts, the dashboards, the data warehouse layer, the Temporal workers, the debugging runbook, and the support rotation. Eleven skills, written by several people on the team. A new teammate, or a fresh agent session, can read that list and know where everything lives.

The most detailed part of the map is self-driving-dwh. It's the blueprint for the data warehouse views behind our internal self-driving analytics: an entity diagram of how scout runs, signals, reports, tasks, and PRs join, the keys that stitch them together, and a recipes/ folder of SQL that actually works.

The entity diagram in self-driving-dwh. Any agent that loads the skill gets the same picture I have in my head. Also, no one likes making ERDs but agents love it! (or have no choice)

When I say "use the /self-driving-dwh skill to help here", the agent knows how everything joins before it writes a query. The skill is on version 458, and I didn't write most of it. A scout, signals-scout-self-driving-dwh, checks that the views still sync, catches drift when a source table changes, and updates the skill when it fixes something. A skill maintained by a skill.

Another favorite example is self-driving-alerts. It's the single store for all 178 of our anomaly alerts: what each one watches, which dashboard tile it hangs off, which Slack channel it posts to, and why it exists. When we want a new alert, the agent reads the skill to see if we already have one, then adds the new one to the inventory as part of creating it.

Each skill is version tracked and we have an optional description string on all changes so you can easily see how the skill changed and by whom. Very useful for team level skills like this.

This also means we can compare any two versions of a skill body. Here, v61 against v73: the alert counts go up as new alerts get added. Remember, this is mostly text for agents to read.

Stuff like this used to be really annoying to maintain somewhere – now you get it for practically free if you just put it in a skill and let your agents maintain it.

The alerts skill above records what exists. A runbook records what went wrong and how we fixed it, so it gets better every time something breaks.

self-driving-debugging is our runbook for when self-driving misbehaves in production and users have some issues we need to dig into.

The whole thing hangs off one line in the skill body: add or extend a reference every time we run down a new class of issue. When a support ticket turns into a real investigation, the agent writes what it found as a dated file in investigations/, then extends the matching reference so the next agent doesn't start from zero. Seven investigations in, it covers duplicate reports, competing PRs for one fix, oversold report titles, unaddressed review comments, and a data import source that emitted nothing.

Its sibling, scouts-debugging, does the same job for the scout fleet. Between them, "debug self-driving for team N" is a sentence I can say to an agent on any surface and get a real answer.

The andy-inbox skill is how I start most days. It pulls every report in the self-driving inbox where I'm a suggested reviewer, maps each one to its GitHub PR and issues, and renders one plain line per report: priority, age, review state, CI, and one next action.

The skill bundles Python scripts to do the boring parts: render_table.py builds the table from the API and gh, pr_candidates.py ranks reports that are ready for a Create PR press, merge_intent.py finds PRs I've approved that need agent work to get merged, and draft_task.py writes the payload to launch a PostHog task for a stalled row. So "get these three PRs green on CI" turns into three async tasks I can check on later.

It also has a working-set.md that records only what I've personally chosen to own, with four rules to guide it:

• Check the live state first, the file second.
• The API is the truth.
• The file is a list of my commitments.
• Never report status from the file alone.

There's a whole family of daily driver skills like these:

• my-github is what needs my attention across GitHub: open PRs, review requests, assigned issues, recent merges.
• andy-prs is every PR I opened, with its size, the issues it closes, the inbox report it came from, and its checks.
• andy-issues is every issue I filed, mapped to the inbox report that picked it up and the PR that came out of it, so I can see which of my specs turned into code.
• andy-approvals is the bot-authored PRs I approved or sent /trunk merge on, and whether the bot has pushed since, because approving an agent's PR and then losing track of it is a real failure mode.

A scout called signals-scout-andy-github runs the GitHub one every hour and keeps a single living report current in my inbox, so most mornings the answer is already waiting for me. A generic version, my-inbox, is in the community store.

Before I went on holiday recently, I posted a state-of-the-world message to my team's Slack channel. It was long. It had a section on current state, a section on operational stuff, and a section on where to dig when something breaks.

Almost every bullet was a link to a skill.

Every bullet was a skill, so a teammate or their agent can pick it up:

• scouts-dogfooding for the project log and open issues.
• scouts-debugging for symptom-driven runbooks, including a playbook for digging into one team's experience.
• scouts-dashboard for the dashboard I look at.
• signals-alerts for what pages us. And the line I'm least sorry about: "if you have complex questions and analysis, say 'use the signals-dwh skill in PostHog MCP to help here'."

This is the bit I think people miss about a shared skills store: the handover doesn't go to a human who then has to load it into their own agent. It goes to the human and their agent at the same time, because the skill already lives where both of them can read it.

Every scout in PostHog is a skill. Same format, same store, same version history. The only difference is a schedule and a harness that runs it. Which means when I've built a skill for how I do a job, turning it into a job that does itself is a small step, not a new project.

signals-scout-agent-feedback watches what agents complain about in our MCP, signals-scout-self-driving-logs watches our production logs, and signals-scout-canonical-drift checks the canonical scout fleet against the current harness once a week for any drift and inconsistencies as code evolves.

A few are about skills themselves. signals-scout-skills-best-practices checks recently-changed skills in our repo against the Agent Skills spec. signals-scout-skills-maintenance catches merged PRs that make an in-repo skill stale. Both lean on skills-best-practices, which gets its own section below.

Yes, I have skills that maintain skills. I did warn you.

I even used a skill to write this blog. The andy-blogs skill has one file per post with the argument, sources, a dated log of every decision, a list of what I cut for being too sensitive, and the open TODOs.

When I start a new session on the post, the agent already knows which branch the draft is on, which numbers it still has to re-check, and which Slack screenshot I already rejected (it was about scouts, not skills). It's well past 20 versions by now, and this paragraph is in its changelog. It helps with all the annoying stuff about writing blog posts like adding the screenshots. And I also use it to tell the agent how I write blog posts: I need to fire up VS Code to eyeball every diff before we commit, as agents are too eager to add stuff I don't want in the final post.

This isn't just a set of instructions. The skill is a document I'm iterating on with an agent, over weeks, across surfaces. A skill turned out to be a better home for that than a Google Doc, because the agent can read it, edit it with the smallest possible change, and every edit is a version I can diff.

You could do all of this with a local .claude/skills/ or .agents/skills/ folder, but that's just crazy. Vibing your own plumbing and CI to get your skills to every agent is also totally possible but crazy. Using a skill store gives you benefits like:

• It's on every surface. The same skill loads in Claude Code on my laptop, in a cloud task, in Slack, in Codex, in Cursor, and in PostHog AI.
• Agents can write to it. The skill-update tool takes incremental edits and file_edits with a base_version check, so two sessions can maintain the same skill without clobbering each other.
• It's versioned. 433 versions of self-driving-work means 433 diffs I can read when something looks off. A file on disk gives me one, unless I remember to commit it.
• It's shared. A teammate, or their agent, or a scout, reads the same thing I do.
• Progressive disclosure is built in. skill-list returns names and descriptions. skill-get returns the body and a file manifest. skill-file-get pulls one file.

It's not just me, either. Here's every skill created in our internal project since late April:

If you're already using the PostHog MCP, you have this today. Install the PostHog AI plugin and your agent already knows the skills-store skill. I keep a tiny local bridge called /phs that just loads it; the docs show how.

There's a catch with all of this. Leave an agent to maintain a skill and it will grow it: a paragraph every session, a changelog line for every fix, until loading the skill costs more than it saves. A mono-skill of slop.

So I wrote skills-best-practices. I tell the agent to use it to clean up if needed and also, when I'm making a new project tracker type skill, I tell the agent to follow it. It's in the community store if you want it. The short version:

• Give every skill a convention. Tell the agent exactly where an issue, a handover, or an investigation goes. If you don't, it makes something up, and it's different every time.
• Keep the body small. About one screen: what this is, the gotchas, and a map of the files. Detail goes in the files.
• Stop things growing forever. The changelog keeps 14 days. The handover gets overwritten, not appended to.
• Link, don't copy. One skill per area, with links to its siblings.
• Dogfood them. Use the skill for its actual job, notice where the agent stumbled, and fix the skill in the same session.
• Read the skills docs and connect the PostHog MCP to whatever agent you use.
• Then just ask your agent about the PostHog skills store. With the PostHog AI plugin installed, it already has the skills-store skill and knows how to list, load, and edit your skills.
• Install from the community store for one area of work you're tired of re-explaining to your agent.
• Install next to it, and tell your agent to load it before it creates or edits any skill.
• When you have a skill for how you do a job, turn it into a scout and let it do the job for you.

And if you build a skill for something in your life that has no business being a skill, tell me. I have a hedgehog joke scout. I'm not going to judge.