The Agent Files Nobody Owns: Auditing Your Agentic Setup

I asked a coding agent to commit and push some work on a client codebase. A routine request; I make it several times a day. The agent staged the changes, wrote the commit messages, pushed the branch, and told me it was done.

At pull request review, one of the client’s lead developers noticed that the commit messages were written in a style the team had stopped using. Not wrong, exactly. Just old. A convention they had moved on from months earlier, reproduced faithfully across half a dozen commits by someone who had never worked there.

The agent had found a skill in the repository. That skill described how commit messages were written on the project, including the format the team no longer used, and the agent did precisely what it said. The behaviour was correct. The instruction was out of date.

Total damage: one mildly awkward comment on a pull request and a few commits to reword. As incidents go it barely qualifies, and I would have forgotten about it within the week if not for what happened when I asked around afterwards. Nobody could tell me who had written that skill. Nobody could tell me when. Nobody could tell me whether a single person had read it since the day it was committed. It had been sitting in the repository the whole time, and the only reason any of us knew it existed is that an agent found it before a person did.

In Part 1 of this series I covered the foundations: onboarding an agent to a project, briefing it within a conversation, and keeping that shared understanding honest. Part 2 covered the three workflows I use to get engineering work done, including GitHub’s spec-kit and the BMAD-Method. Part 3 covered what makes the whole arrangement safe, and ended a section on Model Context Protocol (MCP) servers with a sentence I have been meaning to come back to ever since: the same audit applies to skills and slash commands.

This post is that audit. It is about the half of agentic development nobody writes about, which is removal.

The Caller Is the Harness

Dead code is inert. An unused function sits in your codebase doing nothing; it can be quietly wrong for years and cost you no more than a moment’s confusion, because nothing calls it. Static analysis will usually tell you it is unreachable. The failure mode of dead code is that it wastes your attention when you eventually read it.

Files written for coding agents do not work that way, and the difference is the whole point of this post.

CLAUDE.md, AGENTS.md, .claude/skills/, .claude/commands/, .cursor/rules/, .github/prompts/: these are read because of where they sit. There is no import statement, no registration step, no call site you could grep for. The agent does not evaluate whether a file represents how the team works today; it has no way to. Sitting in the right directory is the entire qualification, and the harness reads what it finds.

Which gives us the rule I would like you to take from this post. Anything in an agent-discoverable location is a live instruction until somebody removes it. If your team does not use it, it should leave main, and the reason it left should be recorded somewhere an agent can be asked about, not somewhere it always reads.

The best case, when you leave that file in place, is that a new developer opens it and wastes twenty minutes working out whether the project really uses a methodology nobody has mentioned in stand-up. The worst case is that a coding harness finds it first, reasonably concludes that a file in that location describes how work is done here, and acts on it. My commit messages were the best case. I have been thinking about the worst one ever since.

Experiments That Were Right to Run and Wrong to Keep

Here is the shape of the problem, composited from several client repositories so that no single team is identifiable.

The main branch carries spec-kit. It also carries the BMAD-Method. Somewhere in there is Gastown, Steve Yegge’s multi-agent workspace manager, and a directory belonging to get-shit-done. Alongside those sit a pile of bespoke skills and slash commands written by individual developers over the preceding year, and, in one case, a second parallel set of rules for a completely different coding tool. None of the methodologies is in use. The team settled on one way of working months ago and has been working that way ever since.

Every one of those experiments was worth running. I said so in Part 2, where I recommended spec-kit for substantive features and BMAD for solo or underbacked work, and I stand by that; trying several is how you find the one that fits the shape of your work. What nobody warned anybody about is the other half of the experiment, which is retiring the ones that lost.

I ran an audit across the repositories of several current clients, and one of them tells the story better than any argument I could make. That repository contains 122 agent-discoverable items: one entry-point file, 70 skills, 22 slash commands, and 29 rules for a second coding tool the team also tried. Ninety-eight of those 122 items were committed once and never touched again. Sixty-eight of the seventy skills have exactly one commit in their history. They were written, they were merged, and in the months since, not one person has come back to any of them.

That is what abandonment actually looks like in a repository, and it is worth being precise about, because “old” is not the signal. Nothing in the repositories I scanned is more than about nine months old; the repository itself is not much older than that. The signal is the single commit. A file with one commit was never revised, never corrected, and, in all likelihood, never read again by a human being. It was, however, available to be read by every agent session anyone has run since.

The reason this accumulates unnoticed is worth naming, because it explains why the same teams have MCP servers under control. MCP servers live in a configuration file. Sooner or later somebody opens that file for an unrelated reason, sees thirty entries, and asks a question. I described exactly that audit in Part 3, including the developer who had accumulated thirty servers and could not work out why their context budget had evaporated. My own habit is to disable every MCP server on first clone of a client repository and re-enable them one at a time as each proves itself useful.

Skills and slash commands get none of that scrutiny, because they live in a directory. Nobody opens a directory. Files accumulate in it the way files accumulate in any folder anybody has ever owned, and the only thing that reliably reads all of them is the agent.

There is a further wrinkle, which is that the abandonment can happen above your head. get-shit-done was archived by its own author in June 2026 and now points visitors at a successor project; a separate Cursor adaptation continues under different maintenance. The methodology you standardised on last spring can be retired by somebody else entirely, while your copy of it sits in main looking exactly as current as it did the day you merged it.

I made a version of this argument about tools, not methodologies, in Stop Screening for AI Tools, where the point was that the harness named on an engineer’s curriculum vitae (CV) expires faster than the engineer does. Methodologies expire the same way. The difference is that a repository is a far stickier place to keep an expired one than a CV, because nobody ever rewrites a repository to make it look current.

The Cost I Expected to Find, and Didn’t

I went into this expecting the headline to be context. A hundred-odd dead files in a repository sounds expensive, and “your abandoned skills are eating your context window” is a satisfying sentence to write.

It is not true, and I would rather tell you that than let you find out from someone else.

Skills are loaded progressively. What sits in the model’s context at the start of a session is each skill’s name and description, a line or two apiece, because that is how the harness decides whether a skill is worth invoking. The body of the skill, which is the bulk of it, is read only when something actually calls for it. In that 122-item repository, everything resident at the start of a session amounts to 2,738 words, somewhere in the region of four thousand tokens. The dead ones are a rounding error on a modern context window.

So the context argument, in the form I expected to make it, does not survive measurement. What does survive is a different measurement entirely.

In a second client repository, the CLAUDE.md file runs to 2,039 words and links out to 30,548 words of supporting documentation. That is a ratio of about fifteen to one, and it is the discipline working rather than failing: the entry point stays small, the detail lives in docs/, and the agent reads the detail only when the work requires it. This is exactly the progressive discovery pattern I described in Part 1, and it is what a healthy repository looks like.

The interesting part is what the audit found next to it. That same docs/ directory holds roughly twenty thousand further words that the entry point does not link to at all. Not resident, not linked, not reachable by anything following a path from CLAUDE.md; documentation that neither an agent nor a developer will ever arrive at by ordinary means. It has not been deleted, so everyone assumes it counts. Nothing reads it.

Which is the same disease as the abandoned skill, presenting with the opposite symptom. One file is read by an agent nobody asked; the other is read by nobody at all. Both are in main, and in both cases the repository is making a claim about how this project works that stopped being true some time ago.

The restructure I run at the start of almost every client engagement addresses the first half of this directly, and it is the first thing I do on a new codebase. Simplify the entry-point file until it is an index rather than a manual. Move the changelog out of it, because history belongs in git and in a file of its own. Create an explicit set of documents covering architecture, commands, gotchas, and setup, put them in docs/ or claude-docs/, and link to them from the entry point. It takes an afternoon and it is the highest-leverage afternoon of the engagement.

Instructions Nobody Owns

The bounded cost is context. The unbounded one is that an unowned file is an unreviewed instruction surface.

Ask, of any skill in your repository: who last reviewed this? In most of the repositories I have looked at, the question has no answer. The file was committed once, possibly by somebody who has since left, and it has been eligible to shape the behaviour of every agent session run in that repository ever since.

Part 3 of this series covered AST03, over-privileged skills, from the OWASP Agentic Skills Top 10. The two items sitting above it on that list are the ones that matter here: AST01, malicious skills, and AST02, supply chain compromise. Both describe an instruction reaching your agent that nobody on your team intended. An abandoned skill is not malicious, but it occupies precisely the same position in your system: an instruction with automatic reach and no owner. The mechanism that would catch a malicious skill is a person reading the file. That mechanism is exactly what has not been happening.

My commit message skill was benign. That is the argument, not a caveat to it. The system behaved exactly as designed; a file in a discoverable location was discovered, read, and acted upon, without anyone in the loop knowing it was there. The content of that particular file was a stale convention. There is no property of the arrangement that guarantees the next one will be equally harmless, and no review step standing between the two cases.

There is one further turn of this screw, and it is the reason I have moved from mildly irritated about stale skills to something closer to concerned. Agents increasingly run in continuous integration (CI): triaging issues, reviewing pull requests, applying labels, sometimes pushing commits. When an agent runs there, the lead developer who spotted my commit messages is not in the room. Nobody is.

The industry has already found out what that costs, although so far through a different door. In February 2026, a crafted issue title was enough to make the automated triage workflow in Cline, a coding tool with a user base in the millions, run an install script from an attacker-controlled repository and exfiltrate its API key; the attacker needed nothing beyond the ability to open an issue. A cluster of related prompt-injection disclosures followed in June 2026 against Claude Code’s GitHub Action, Gemini CLI, and GitHub Copilot’s agent, all turning on the same property: an agent cannot reliably distinguish the instructions its owner wrote from text an attacker placed in front of it.

Those attacks arrived through user-submitted content rather than through committed files, and I am not aware of a published case where a stale skill in a repository was the vector. I would not lean on that distinction. A committed file starts inside the trust boundary, which is a considerably better starting position than an issue title, and the control that would catch a bad one is a person reading it. That is the control this entire post is about, and it is the one that demonstrably has not been running.

Delete It, and Write Down Why

Deleting the file is the easy half. The half people get wrong is what happens to the reasoning.

Somebody on that team chose spec-kit, ran it for six weeks, and concluded it was too heavy for the work in front of them. That conclusion is genuinely valuable; it is the return on the experiment. Lose it and, in eighteen months, a well-meaning engineer proposes spec-kit at a planning session and the team spends another six weeks finding out the same thing.

The obvious move is to write a note in CLAUDE.md explaining that the team tried spec-kit and stopped. Please do not do this. A paragraph in your entry-point file describing a methodology you do not use is a paragraph resident in context, on every session, describing a methodology in enough detail for an agent to have a view about it. You have replaced a dead file with a smaller dead file in a more expensive location.

Architecture decision records (ADRs) solve this properly, and the reason they do is a property I described in Part 2 without noticing it was the general case. Writing about spec-kit’s specifications, I said they work because they live next to the code in a standard location the agent knows how to find, and are not automatically loaded into context, so they do not burn always-on budget, but they are discoverable by explicit prompt. That is the exact shape a retirement decision needs.

Look at the two categories side by side. An abandoned skill is resident in the agent’s context and invisible to the team. An ADR is absent from the agent’s context and available to the team, and to the agent, on request. You want your decisions in the second category and nothing whatsoever in the first.

An architecture decision record for a retired methodology needs four things: what we adopted, when, why we stopped, and what we do instead. Write it as a closed decision rather than a description of a system, because the distinction matters more here than it does for a normal ADR; a document that explains how spec-kit works reads, to an agent, uncomfortably like an instruction, whereas one that records that spec-kit was assessed and rejected in March does not.

I ask clients to keep these in an adrs/ directory, and the payoff is that the history becomes queryable by the same tooling that caused the problem:

“Did we ever use spec-kit on this project? If we did, is there a reason we stopped? There is an adrs directory; the answer may be in there.”

Which brings up the objection I hear most often, usually phrased as a worry about losing the work. You are not losing it. Git remembers every version of every file you have ever committed, in full, permanently; that is what it is for. The whole reason main does not have to carry your abandoned experiments is that the history already does. Deleting a skill from main and recording why in an ADR keeps every part of the experiment that has value and removes the only part that can misfire.

The Audit, and How Often

This is a practice, not a project. It has two halves, and the second is the one that makes the first survive contact with a real team.

Retiring

The first audit is the expensive one, and I run it at the start of a client engagement alongside the entry-point restructure described above. Everything in an agent-discoverable location gets looked at once: what is it, who wrote it, does anyone here use it. Finding the unused agent skills in a repository that has been accumulating for a year takes a morning.

After that it is a standing item at the retrospective, every three or four sprints, which works out at roughly every two months. Three questions:

• Did we experiment with any skills, commands, or methodologies this cycle?
• Does anything need retiring?
• Who last reviewed the skills we are actually using?

On a healthy repository this takes minutes, and most cycles the answer to all three is short. The point of the cadence is not the time it consumes; it is that the question gets asked at all, by a group of people, on a schedule, instead of never.

Promoting

Everything above is loss-framed, and teams resist deletion for a reason that has nothing to do with discipline. Somebody wrote that skill in their own time because they were curious. Deleting it reads as a judgement on them.

So run the other half in the same meeting. Ask who has built a skill or a slash command they would like to share with the team. Have them demo it, talk through what it does and why they built it, and take questions; the questions are where the value is, because that is when somebody points out the edge case, or the simpler approach, or the fact that two people have now built the same thing twice. Then it gets shared properly, and it goes on the list to be revisited at a later retrospective, so promoted tooling sits on the same review cadence as everything else, instead of becoming next year’s abandoned file.

The effect of running both halves together is that the work gets harvested before the file gets deleted. Once the team has seen the skill, understood what it does, and improved it, deleting the copy in main costs nobody anything, because the file was never the valuable part. The learning was, and the learning now sits with the people who have it, not in a directory waiting for an agent to find it.

What to Do This Week

Two ways to find the unused Claude skills in your own repository, depending on how much time you have.

The thirty-second version: list your agent-discoverable directories, sort by the date of the last commit that touched each file, and take the five oldest to your next retrospective. Sort by commit date rather than by file modification time; a fresh clone resets every timestamp on disk, so a repository you pulled this morning will report that all of your abandoned skills were modified today.

The longer version is to build yourself an audit tool, and this is a genuinely good use of a coding agent, because the tool is small, single-purpose, and disposable. I built one while writing this post. Rather than publishing it as something else for you to install and forget, here is a handoff document in the sense that Josh Morony describes: pass it to your own agent, let it build the version that fits your environment, then throw the document away.

Build a read-only command-line tool that audits the agent-discoverable files in a
repository and reports which ones look abandoned.

Detect: entry points (CLAUDE.md, AGENTS.md, .cursorrules, and equivalents), skills
and slash commands, editor rule directories, MCP configuration, and the footprints
of methodology frameworks such as spec-kit and BMAD. Make detection a data table
rather than code, because you will be adding to it.

For each item report: size in bytes and words, first and last commit dates, number
of commits, and whether it has exactly one commit.

Gotchas that will cost you a day each if you miss them:

- Take dates from git commit history, never from filesystem mtime. A fresh clone
  makes every file look new, which silently inverts the entire result.
- Use author date rather than committer date; a rebase rewrites the latter.
- Skill descriptions are resident in context; skill bodies are not. Report those
  two totals separately, or the headline number will be wrong by an order of
  magnitude.
- Frontmatter descriptions are often YAML block scalars. A naive parser reads the
  value as "|" and reports two words instead of a hundred and thirty.
- Deduplicate by real path; skill directories are sometimes symlinks.
- Report token counts as a labelled range, not a figure. You have not run a
  tokeniser.

The single strongest abandonment signal is an item with exactly one commit in its
history. Rank on that, not on age.

Make the report say, in its own output, that it cannot tell you whether a skill is
actually used, because a repository does not record skill invocations. It produces
candidates for a conversation, not a delete list.

That last paragraph is the one I care about most. The audit is a conversation between people who know what the team actually does; a tool can only tell you where to point the conversation. Nothing in your repository records whether a skill was ever invoked, and any evidence that does exist is scattered across individual developers’ local session histories.

Almost twenty years in this industry, across more than fifty organisations, has left me with a low opinion of process for its own sake and a high one for the small number of habits that stop problems compounding. This is one of the cheap ones. An hour at the start, three questions every couple of months, and a directory of short documents explaining what you tried and why you stopped.

The alternative is a repository that quietly disagrees with itself about how the work is done, in files nobody has read, available to something that reads everything.

If you would like help getting a team to this point, the work I do with clients includes exactly this: the initial audit, the entry-point restructure, and the slower business of turning it into a habit the team keeps after I have gone. Fractional Chief Technology Officer (CTO) engagements often start here, because it is the fastest way to find out what a codebase actually believes. Get in touch.