De-slop Exposed: One Skill Is Actually 27 — Matt Pocock Open-Sourced His .agents Directory
First, an account not mentioned in the video: Matt Pocock — author of the "one skill that cleans up an AI-messed codebase" video, and also the author of Sandcastle, last week's 226-line software factory — open-sourced his entire .agents directory this past February. The repository is simply named skills, with a blunt subtitle: "Skills for Real Engineers. Straight from my .agents directory." In eight months: 284,215 stars, 23,000 forks, MIT licensed. It may be one of the fastest-growing repositories of 2026, and it sells exactly one thing: turning software engineering's old disciplines into agent-executable workflows.
The "one skill" in the video
The skill featured in the video maps to improve-codebase-architecture. What it does: scans the codebase, identifies "deepening opportunities," generates a visualized HTML report, then walks through them with you one by one. "Deepening" comes from John Ousterhout's *A Philosophy of Software Design* — a shallow module has a large interface but holds little; a deep module has a small interface but holds a lot. Refactoring means grinding shallow modules deeper. A line from the README is worth quoting: "Run it every few days. It's a survey, not a rescue." It finds candidates; it does not untangle your mud for you.
Three design details in 71 lines
The real design density is in the skill file itself. Three spots are worth unpacking:
1. The objective function. The refactor's stated goals are testability and AI-navigability — structures an agent can read are treated as a first-class citizen alongside testability. The list of a codebase's readers now includes a non-human.
2. Vocabulary discipline. The skill forces the agent to invoke a separate codebase-design skill to obtain the shared vocabulary (module, interface, depth, seam, adapter, leverage, locality), and explicitly forbids drift — "don't drift to words like component, service, API, boundary." Terminological consistency is a hard constraint, because if the agent's suggested wording drifts, your judgment has to re-align.
3. Memory integration. Every new concept named during refactoring goes into GLOSSARY.md (created lazily). When you reject a candidate, the skill asks: "Want to record this reason as an ADR, so future architecture reviews won't recommend the same option again?" Reasons for rejection are assets too — but filtered: weighty reasons deserve recording; offhand "not worth it now" and self-evident reasons don't.
One entry point, a skill network
"One skill" is really "one entry point." The frontmatter of improve-codebase-architecture references two other skills — codebase-design (architecture vocabulary) and domain-modeling — while grilling, an interview primitive that keeps asking questions until every branch of the design tree is resolved, is a shared component used by five skills. The repository writes the network's relationships into architectural rules:
- Skills come in two layers. User-invoked skills may only be triggered manually and orchestrate the process; model-invoked skills can be picked up automatically by the agent when a task matches, carrying reusable discipline.
- Orchestrating skills may call discipline skills; discipline skills don't call each other; orchestrating skills don't call each other either.
- Dependency direction is fixed. It's a small software architecture — except the modules are workflows.
- tdd skill: hard-codes red-green-refactor.
- diagnosing-bugs skill: hard-codes "build a feedback loop that can go red first, then hypothesize, then fix."
- code-review skill: runs two parallel sub-agents checking "does it follow repo conventions?" and "does it faithfully implement the requirement?" — explicitly kept separate so they don't contaminate each other. Review independence is treated as an architecture problem.
One more detail: improve-codebase-architecture's frontmatter sets disable-model-invocation: true — a major refactoring move may only have its trigger pulled by a human; the agent has no authority to act on its own.
The overall narrative
The repository's README states it bluntly: "agents can dramatically speed up writing code while simultaneously accelerating software entropy at an unprecedented rate." The Ball of Mud section quotes Kent Beck: "invest in the system's design every day." The answer isn't using AI less — it's externalizing design discipline:
Fact-check notes
Cross-checking the video summary against the repository: everything matches. "First understand the whole codebase, then form a refactor strategy, and gradually clean it up" corresponds to the scan–report–grill three-stage structure — no inflation. Background not mentioned in the material: this skill suite is offered on aihero.dev under "See all 27 skills"; the repository and the site share the same origin. A separate same-named concept repo called slopwatch has a one-line README — the author's unfinished experiment; don't confuse them. Attribution is clear: personal open source, funneling to an education site, with the free/paid boundary at the courses, not the skills.
Closing
The previous post on Sandcastle concluded that "a software factory is made of if/for." This one supplies the second half: the software factory's process specifications are written as skills. Methodology moves out of books and blogs, cut into steps an agent can execute, outfitted with vocabulary files, memory files, and layered invocation rights. Twenty years ago these things were called team conventions — written into a wiki, nobody read them. Now they've grown into executable files, downloaded by 280,000 people in eight months. Ousterhout's book is still the same book; what changed is that the reader is no longer only human.