housekeeper
Skill5 starsChanged 11 days agoMITView on GitHub
Run a conservative code-project housekeeping pass: one proven low-risk cleanup at a time.
In this repository57 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- architecture-satisfactionSkill
- autopilotSkill
- browser-testSkill
- chatter-scoutSkill
- closeoutSkill
- codebase-designSkill
- code-reviewSkill
- code-smells-auditSkill
- commitSkill
- dependency-auditSkill
- diagnosing-bugsSkill
- domain-modelingSkill
- fix-ci-failuresSkill
- fix-github-issuesSkill
- fix-nightwatch-issuesSkill
- fix-posthog-issuesSkill
- grillingSkill
- grill-meSkill
- grill-with-docsSkill
- handoffSkill
- harness-toolsSkill
- implementSkill
- implement-specSkill
- improve-codebase-architectureSkill
- laravel-herd-worktreesSkill
- panelSkill
- prototypeSkill
- prSkill
- prune-testsSkill
- releaseSkill
- repository-cleanupSkill
- researchSkill
- resolve-review-commentsSkill
- resolving-merge-conflictsSkill
- retroSkill
- run-afterSkill
- scratch-cleanupSkill
- scratch-statusSkill
- setupSkill
- sweepSkill
- tddSkill
- teachSkill
- to-questionnaireSkill
- to-specSkill
- to-ticketsSkill
- triage-github-prSkill
- triageSkill
- ui-designSkill
- upgrade-planSkill
- verifySkill
- wait-whatSkill
- wayfinderSkill
- which-skillSkill
- wizardSkill
- writing-for-agentsSkill
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 10 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 19
Stop when no confirmed low-risk cleanup remains and existing behavior still passes.
- Distinctive: line 23
Use this when a code project has accumulated small maintenance problems, such as unused code, stale files, duplicated logic, broken links, …
- Distinctive: line 34
Run the relevant existing checks: build, tests, lint/type checks, runtime smoke checks, link checks, or project-specific verification.
- Distinctive: line 51
Treat generated files, unclear files, active work, and user changes as protected until there is direct evidence and approval.
- Distinctive: line 64
Start each item that needs the user (a risk, a deferral, an approval) with ⚠️, and each failed check with ❌.
- Distinctive: line 68
Do not delete code merely because its purpose is not immediately obvious.
- Distinctive: line 69
Do not touch unrelated, active, uncommitted, generated, or uncertain work.
- Distinctive: line 70
Do not combine unrelated cleanups into one large change.
- Distinctive: line 71
Do not keep a cleanup if checks fail or behavior cannot be verified.
- Distinctive: line 72
Ask for approval before removing dependencies, deleting broad file sets, or changing public interfaces when risk is unclear (workflow step …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Housekeeper
Goal
Find and apply one proven, low-risk cleanup at a time while preserving existing behavior and protecting unrelated work.
Loop Prompt
Review [repository or code project] for dead code, meaning unreachable or unused code; stale files or comments; unused dependencies; duplication; broken links; inconsistent names; and confusing structure. Protect unrelated, active, uncommitted, generated, and uncertain work. Prove one low-risk cleanup, make the smallest coherent change, then rerun the build, tests, runtime checks, and diff review. Keep only verified improvements. Stop when none remain, progress stalls, verification is unavailable, or approval is required. Return changes, evidence, and deferred candidates.Stop when no confirmed low-risk cleanup remains and existing behavior still passes.
When To Use
Use this when a code project has accumulated small maintenance problems, such as unused code, stale files, duplicated logic, broken links, old comments, inconsistent names, or confusing organization, but broad deletion would be risky.
This loop cleans source and project structure. It is not a Git branch, pull request, commit, or worktree cleanup workflow.
Workflow
- Inspect the current project state before changing anything.
- Identify active branches, uncommitted edits, generated files, configuration, build artifacts, and other work that must not be disturbed.
- Collect possible cleanup candidates.
- Pick one candidate that can be proven low risk from code references, configuration, documentation, tests, or runtime behavior.
- Make the smallest coherent change that removes or improves that candidate.
- Run the relevant existing checks: build, tests, lint/type checks, runtime smoke checks, link checks, or project-specific verification.
- Review the diff and keep the change only if behavior stays intact and unrelated work is untouched.
- Repeat until no proven low-risk cleanup remains, progress stalls, verification is unavailable, or the next candidate needs approval.
- When stopping on candidates that need approval, ask the user to pick which to apply, in one question (a structured question (harness-tools):
multiSelect: true, one option per deferred candidate, at most 4 per question and further questions for the rest; otherwise a numbered list in chat). Continue the loop in the same run on every approved candidate, one at a time.
Candidate Types
Look for:
- Unreachable or unused code.
- Stale files or stale comments.
- Unused dependencies.
- Duplicated logic.
- Broken links.
- Inconsistent names.
- Confusing project structure.
Treat generated files, unclear files, active work, and user changes as protected until there is direct evidence and approval.
Report
End with:
- Cleanup candidates reviewed.
- Changes made.
- Evidence supporting each retained cleanup.
- Verification commands run and their results.
- Deferred candidates and why they were not changed.
- Any approval still needed, and the candidates the user declined.
Start each item that needs the user (a risk, a deferral, an approval) with ⚠️, and each failed check with ❌. No other marks.
Guardrails
- Do not delete code merely because its purpose is not immediately obvious.
- Do not touch unrelated, active, uncommitted, generated, or uncertain work.
- Do not combine unrelated cleanups into one large change.
- Do not keep a cleanup if checks fail or behavior cannot be verified.
- Ask for approval before removing dependencies, deleting broad file sets, or changing public interfaces when risk is unclear (workflow step 9).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

