Español

Delete Your Scaffolding For One Task

You have a rules file, some templates, a folder of carefully written skills. Here's an uncomfortable question: when did you last check whether any of it still helps? Not whether it exists, or whether it's tidy — whether removing it would change the output.

Setups are fossils

Scaffolding accretes. You add a rule because the agent got something wrong, a template because a task recurred, a skill because a workflow felt worth codifying. Each addition made sense on the day. Almost none of them get revisited.

The result is a setup shaped by problems you had months ago, against models that no longer behave the same way. And unlike code, this debt is charged continuously: an always-loaded rules file costs context on every session regardless of whether the task needs it, and long files measurably reduce how reliably instructions are followed.

So stale scaffolding isn't neutral. It's paying rent and, past a certain size, actively crowding out the rules you care about.

The experiment

There's a straightforward way to find out, and it takes one task:

• Pick a real task, not a toy — something representative of your actual work.
• Run it the normal way: full rules file, memory, templates, skills.
• Move the whole lot into a different folder so nothing loads.
• Run the same task again from a plain description of what you want.
• Compare the two outputs honestly.

The comparison is the point, and you should expect a split verdict rather than a clean win. Some scaffolding will obviously earn its place, and you'll keep it with actual confidence instead of assumption. Some will turn out to be answering a question nobody is asking, and you can delete it without the nagging feeling that you might need it.

What tends to survive, and what doesn't

Predicting the result is less useful than running it, but there's a pattern in what holds up.

Usually survives: the non-discoverable facts. This directory is generated, never hand-edit it. Tests need these two environment variables first. This service is deprecated, use that one. Nothing about the codebase reveals these, so they earn their permanent slot.

Often doesn't: conventions the codebase already broadcasts. If every file in the project uses one pattern, a rule stating that pattern is context spent telling the agent something it can see by looking. Directory layouts, dependency lists and architecture overviews fall in the same bucket — which is exactly what the built-in checkup targets when it proposes trims to a rules file.

There's a middle path worth knowing before you delete anything: material that only matters sometimes doesn't have to be all-or-nothing. Path-scoped rules load only when the agent touches matching files, and a skill's body loads only when used. Moving something there keeps it available at near-zero standing cost.

Make it a habit, not a one-off

The reason this works as a recurring practice is that the ground keeps moving. A rule that was load-bearing a year ago may be redundant now, and you will never notice through normal use, because normal use never removes the variable.

A reasonable cadence is once a quarter, or whenever you notice your setup has grown a lot. It costs one duplicated task and it's the only honest signal available.

The takeaway

Scaffolding isn't free just because you already built it. Run one real task with all of it moved aside, compare, and keep what earns its place. The parts that survive you'll trust properly; the parts that don't were costing you context on every single session.