Weekly repo cleanup for AI-heavy teams in 30 minutes

Why AI repos get messy fast

AI work creates clutter faster than regular product work. A coding assistant can generate ten files in minutes, and half of them exist only to test one idea. If nobody cleans them up, the repo fills with draft prompts, one-off scripts, copied configs, and files that made sense for a day.

Prompt work makes this worse because people often test outside the normal flow. They save scraps in random markdown files, text files, notebooks, or folders called "temp" and "misc". That feels harmless at the time. A week later, nobody knows which prompt still matters and which one failed on the first try.

Branches pile up for the same reason. AI makes it cheap to try five approaches before lunch, so teams create more short-lived branches than they used to. Many of those branches never turn into real features. They just sit there with old commits and old assumptions.

Names drift when people move fast. A file starts as "draft_prompt.md," becomes "draft_prompt_v2.md," then turns into "final_prompt_new.md." The same thing happens with folders, feature flags, and experiment branches. After a while, the repo stops telling a clear story.

Most of this mess does not come from one big mistake. It comes from leftovers: test files nobody removed, prompt variants nobody merged or archived, branches nobody closed, and docs nobody updated after the experiment changed.

A short cleanup every week fixes that before it turns into friction. In AI-heavy repos, entropy is normal. The problem starts when stale files look just as real as the files the team still uses every day.

What fits in 30 minutes

A weekly cleanup works only if the scope stays small. Pick one repo and stay in it. If you try to tidy every service, notebook, prompt folder, and doc at once, the half hour disappears.

Use the time on the mess people trip over every day. Focus on names that make teammates pause, branches nobody will merge, prompt files that helped during one test and were forgotten, and docs that still describe last month's setup.

The pass is simple:

• rename files, folders, or scripts that make people guess
• delete or archive branches tied to finished tests
• remove prompt scraps, copied model output, and throwaway notes
• fix the docs people actually open

Leave deeper work for another block of time. If a module needs a redesign, a prompt set needs a full rewrite, or the docs need a new structure, turn that into a separate task. One messy folder should not eat the whole afternoon.

The time limit matters as much as the checklist. Thirty minutes is enough to cut obvious clutter and restore some order. It is not enough to solve every old problem, and that is fine.

When the timer ends, stop. If you found three more things worth fixing next week, the routine is doing its job.

The weekly routine

Set a 30-minute timer and treat this as maintenance, not a mini refactor. One person should move fast, make obvious fixes, and leave bigger questions for later.

Spend the first five minutes scanning recent commits, open pull requests, and top-level folders. Look for fresh junk first: copied prompts, test exports, mystery scripts, and files with names that made sense only on Tuesday.

Use the next ten minutes on names. Rename folders, prompt files, and helper scripts with vague labels like test3, new-prompt, or tmp-run. If the name does not tell a teammate what it does, fix it now.

Take five minutes to remove dead branches. Delete anything already merged and flag abandoned experiments nobody has touched in a while. If you are unsure, leave a short note and close it later that day.

Use another five minutes to sort prompt scraps and notes. Keep reusable prompts, archive anything with real context, and delete throwaway drafts that only add noise.

Finish with five minutes on the docs people open first. Update setup steps, common commands, file paths, and model notes if the repo changed during the week.

This rhythm works because the bar stays low. If a fix takes less than five minutes, do it. If it needs a discussion, open an issue and move on. Perfect cleanup is not the goal. Keeping entropy low is.

Fix names first

If you only have time for one thing, start with names. Bad names spread confusion into every other task. People open the wrong file, edit the wrong prompt, or keep old work around because they cannot tell what is current.

Names like test2, final, new, or prompt_latest age badly within days. A clear name should tell a teammate what the file is and what it does. lead_scoring_prompt_v3.md is not beautiful, but it is much better than newprompt.md.

Folder names matter just as much. If a folder is called misc, it will become a junk drawer. If it holds eval scripts, call it evals. If it stores archived experiments, use something plain like archive/2025-04. Boring clarity beats clever naming every time.

Use one naming pattern for prompts, scripts, and support files. Teams often mix styles without noticing: fixBug.py, prompt-final.md, run_eval_NEW.ts, stuff/. That slows everybody down.

A simple pattern is enough:

• prompts: task_audience_goal.md
• scripts: verb_object.py
• folders: prompts, evals, scripts, docs
• dated archives: archive/YYYY-MM

Rename in small batches, not in one giant sweep. Change a few files, run the project, and make sure imports, references, and docs still point to the right place. Then do the next batch.

This matters even more in repos full of Claude or GPT experiments. One clean rename can save ten minutes of hunting next week. A handful of clean renames can stop a team from living with three different "final" files forever.

Cut old branches and experiments

Most repo clutter does not come from shipping work. It comes from side paths nobody owns anymore: test-rag-v4, agent-prompt-fix-final, new-eval-maybe. In AI-heavy repos, these branches pile up fast because people run more small tests and drop them as soon as one path looks good enough.

Start with merged branches. If the work already landed, close the branch right away. Old merged branches make the list noisy, and people waste time checking whether an old thread still matters.

Then look at branches nobody touched in a few weeks. Ask a plain question: "Will someone open this again next Monday?" If the answer is no, delete it. You are not erasing history. Git still has the commits, and anything useful should already live in main, a tag, or a short note.

Before you remove an experiment, keep only the part that earned its place:

• what you tested
• what happened
• why it failed or looked promising
• what someone should try next

That note does not need to be long. Four lines is usually enough. If the idea still has real value, move it into an issue or a doc where people can actually find it later.

This is especially important with prompt work. Teams leave behind branch after branch full of prompt scraps, eval files, and half-finished agent flows. Six weeks later, nobody knows which version improved the output and which one just made it longer.

Treat experiments like lab notes, not permanent code. Save the result, keep the lesson, and delete the branch.

Trim prompt scraps and throwaway files

Prompt clutter spreads faster than code clutter. AI-heavy repos collect copied prompt files, raw model exports, scratch notes, and logs from one afternoon of testing. A week later, nobody knows which prompt still drives the workflow.

Keep reusable prompts in one clear place and treat that folder like source code. If the team runs a prompt in production, in a shared script, or in a repeatable internal task, store it there with a plain name. If a file is only a rough draft or a thinking note, move it somewhere separate or delete it.

A simple split works well:

• keep team-used prompts in one folder
• keep notes and research in a separate notes folder
• delete copied prompt versions you no longer run
• remove exports, temp files, and one-off logs

This saves time quickly. When someone opens prompts/, they should see current files only, not prompt-final.md, prompt-final-v2.md, and prompt-final-use-this.md. Pick one file, give it a clear name, and let Git handle the history.

Be strict with generated leftovers. JSON exports, CSV dumps, screenshots, debug logs, and model output samples often slip into commits because they sit next to real work. If a file does not support a test, a review, or a real workflow, it should not stay in the repo.

This part of the cleanup usually takes less than ten minutes. Open the prompt folders, sort by recent changes, and ask one question for each file: does anyone still use this? If the answer is no, delete it.

Update the docs people still use

Start with the README. If someone opens the repo for the first time, that file shapes their first ten minutes. Fixing it usually gives the biggest return for the least effort.

Look for steps that no longer match the code. Old setup commands, renamed folders, dead scripts, and outdated model notes waste time fast. One wrong command in the README can send a teammate into a 20-minute detour.

A simple test helps: follow the docs like a new hire would. If a command fails, fix it now or delete it. If the repo no longer uses a folder, branch pattern, or prompt file path, remove that text instead of leaving a half-true note behind.

If the team changed naming rules, add one short note where people will actually see it. Keep it plain. Use feature names for prompt files. Keep experiment folders dated. Avoid names like final_v2_real. One short rule people read is better than a style guide nobody opens.

You do not need perfect docs every week. You need docs people can trust. If a section is unfinished, mark it clearly with a short warning such as "Draft - steps may change" or "Not updated for the new eval flow yet." That stops people from treating old text as current process.

If time is tight, focus on the docs tied to work happening this week:

• README
• local setup notes
• prompt and eval conventions
• deployment or release steps
• onboarding notes for the current workflow

Old reference pages can wait. The README usually cannot.

A small team example

A three-person startup can make a repo messy in one week. The founder tests prompts in chat, pastes a few into a shared doc, then drops another version into code comments so nothing gets lost. By Friday, nobody knows which prompt actually made it into the product.

Feature work gets tangled in the same way. One branch is called agent-memory-test, another is memory-v2, and both try to solve the same problem. The engineer keeps one alive for safety. The founder keeps the other because it has a prompt tweak that seemed better on Tuesday. Neither branch has a clear owner, and both look half-finished.

Then the README adds one more layer of confusion. It still mentions an older model, old setup steps, and environment variables the team no longer uses. A new teammate opens the repo on Monday, follows the wrong setup, and hits errors before they even find the current code.

One short cleanup can fix more than people expect. The team picks one branch to keep and closes the other. They move the surviving prompts into one folder with plain names like support-reply-draft.md instead of leaving them in chats and comments. They delete the prompt scraps that never shipped. Then they spend five minutes rewriting the README so it matches the current model and setup.

Nothing dramatic happens, but the repo feels different next Monday. People open fewer dead ends. They stop guessing which experiment won. They spend their first 20 minutes building instead of digging through leftovers.

Mistakes that waste the half hour

The fastest way to lose 30 minutes is to treat cleanup like a refactor. You open the repo to tidy a few things, then start reworking folders, rewriting prompts, and touching code that still works. Now the cleanup is a side project.

Another common mistake is turning naming into a debate. Teams spend ten minutes arguing about which pattern is better, then rename nothing. In AI-heavy repos, obvious names beat perfect rules. If test2_final_v3 confuses people, rename it and keep moving.

Teams also keep too many experiments "just in case." Old branches, abandoned eval scripts, prompt scraps, and one-off notebooks pile up fast. After a month, nobody knows what is current. Search gets noisy. New people open the wrong file and lose time.

A simple rule helps: if nobody plans to use it this week and nobody wants to own it, remove it or archive it outside the active repo.

Docs create a quieter version of the same problem. People polish pages nobody reads because it feels productive. Meanwhile, the setup note, prompt guide, or release checklist the team actually uses stays stale. Update the docs that affect daily work. Leave the rest for a bigger doc pass.

The last mistake is weak ownership. When everyone can do the cleanup, nobody makes the small calls. One person should own the pass each week, rename the obvious mess, cut dead branches, and flag anything that needs a real decision.

If an item needs a meeting, a rewrite, or approval from three people, it does not belong in this half hour.

Quick checks before you stop

A clean finish matters more than it seems. Small leftovers turn into slow confusion by Monday: the wrong prompt folder, a branch name from an abandoned test, a README that still describes last month's setup.

Before you close the repo, do one last pass:

• can a new teammate tell which folder holds the current prompts without guessing?
• do the remaining branch names still match the work they contain?
• does the README reflect the current setup, models, and local commands?
• are there files with no clear job, such as old exports or random test scripts?
• did you leave one short note for next week?

That final check should feel a little strict. If you hesitate over a file and cannot explain why it stays, move it out or delete it. Mystery files waste more time than most teams admit.

A short note at the end helps too. One sentence in the repo, issue tracker, or team notes gives the next session a starting point, so you do not spend the first ten minutes trying to remember what past-you meant.

Make it a habit

Cleanup works only when it stops feeling optional. Put it on the calendar at the same time every week, right after planning or the last merge window if that fits your team better. The routine gets easier when nobody has to ask when it happens.

Keep one shared note for the small rules people forget. Use it for naming patterns, docs that need a refresh, and folders that keep collecting junk. When someone finds a bad file name or an old prompt, they should know exactly where to look and what to do.

A short list is enough:

• naming rules for branches, prompts, and experiment files
• docs that need a quick update
• cleanup items that did not fit into the 30 minutes

Give the weekly pass to one person. You can rotate the owner each month, but each pass needs a clear owner.

This matters even more in AI-heavy repos. Prompt scraps, dead branches, and stale docs pile up quietly, then slow down simple work. Someone opens the repo to ship a small change and loses ten minutes asking which prompt is real and which branch is safe to delete.

If repo sprawl keeps coming back, an outside technical lead can help set the rules and keep them practical. Oleg Sotnikov at oleg.is works with startups and small teams as a Fractional CTO, and this kind of lightweight cleanup process fits naturally into broader AI development and automation work.

The payoff is simple: people open the repo and know what is current. That alone saves time every week.