The .claude directory is the new dotfiles

What happened

Matt Pocock — known to most TypeScript developers as the guy who explained generics without making you cry — quietly pushed a repo called `skills` to GitHub with a one-line README: *"Skills for Real Engineers. Straight from my .claude directory."* No marketing thread, no launch post, no Product Hunt page. It's just his working Claude Code configuration, lifted directly out of the directory where he actually does his job.

The repo is now sitting on GitHub trending next to the usual immovable objects: `sindresorhus/awesome` (444k stars, a decade of curated lists), and `freeCodeCamp/freeCodeCamp` (437.9k stars, the largest free programming curriculum on the planet). Those two haven't budged from the top of the trending pile in years — they're the cosmic background radiation of GitHub. What's new is the third name on the list: a one-developer dump of AI agent configurations, treated by the community with the same gravity as a decade-old educational nonprofit.

The content itself is unglamorous. Skill definitions. Prompts. Agent recipes for refactoring, code review, test generation. The kinds of things that until eighteen months ago lived in your private notes app, or your team's wiki, or — more likely — entirely in your head.

Why it matters

There's a recognizable arc here, and developers have lived through it before. In the 2010s, dotfiles repos became a quiet credentialing signal: showing your `.vimrc`, your `.zshrc`, your tmux config was a way of saying *this is how I actually work*, not how I claim to work on a resume. People recruited from dotfile repos. They starred them. They forked them and replaced fragments. The artifact was small, personal, and load-bearing.

The `.claude/` (and equivalent `.cursor/`, `.continue/`, `.aider/`) directory is the same artifact for a different decade. It encodes how you decompose problems for an LLM, which sub-agents you delegate to, what skills you've found worth investing in, and — implicitly — what you've concluded *doesn't* work after burning evenings on prompts that misfired.

Compare the three repos on trending right now and the genre split becomes obvious:

- `sindresorhus/awesome` is curation: links to other people's tools, organized taxonomically. - `freeCodeCamp` is curriculum: a structured path from zero to employable. - `mattpocock/skills` is something newer: a working configuration. Not links, not lessons — the actual machine-readable artifact someone uses to ship code on a Tuesday afternoon.

The community reaction to this kind of repo has been telling. The HN and Reddit dunks that used to greet any "here's my AI workflow" post a year ago have softened considerably. The asymmetry the discourse keeps circling — that an LLM can generate generic prompts but not *your specific* hard-won prompts — is the same asymmetry that made dotfiles repos valuable. Nobody needs another `.vimrc` in the abstract. Everyone wants to see how a senior engineer they respect actually configured theirs.

There's a secondary signal worth naming. Pocock is, by training and trade, a teacher. He sells TypeScript courses. The fact that he's publishing skill files rather than recording a course on "how to use Claude Code" suggests something about where the leverage is moving. A YouTube tutorial ages in months; a `.claude/skills/` directory that survives contact with real codebases is a forkable artifact other engineers can run against their own repos tonight.

What this means for your stack

Three concrete implications if you're a practitioner.

First: if your team has been treating prompt engineering as a private craft, you're now leaving recruiting and reputation value on the table. The same way an open dotfiles repo became a hiring signal — *this person actually knows what they want from their environment* — an open skills directory will signal taste, rigor, and accumulated judgment about LLM workflows. Sanitize the secrets and ship it.

Second: there's a real architectural question buried here that nobody's answering well yet. Skills, agents, sub-agents, MCP servers, custom slash commands — every vendor has invented overlapping primitives. Pocock's repo is interesting partly because he's made opinionated choices about which abstractions to lean on. The right move for most teams isn't to invent your own taxonomy; it's to fork someone else's working configuration and bend it to your codebase. Treating this as greenfield work is how you spend six weeks rebuilding what a senior engineer already debugged in public.

Third: the package-management problem is going to arrive faster than people expect. Right now you copy-paste skill definitions out of someone's repo. In twelve months you'll want a `skills.json` lockfile, versioned dependencies between agents, and a way to update a downstream skill without breaking your local overrides. The first project to ship `npm` for AI skills will accrue the same network effect npm did — and the seed corpus for that ecosystem is being deposited on GitHub trending right now.

Looking ahead

Expect the genre to fragment before it consolidates. There will be a year of personal `skills`/`agents`/`workflows` repos, then a shakeout into one or two canonical registries, then a long tail of opinionated forks. The interesting question isn't whether AI-workflow-as-content becomes a category — it already has — but whether the artifact stays human-readable, or gets swallowed by a vendor's proprietary format the moment one of them notices the leverage. If you've been waiting for the right moment to publish your own setup, the trending page just told you what time it is.