leave-no-mess
Skill98 starsChanged 2 months agoMITView on GitHub
Clean up a session's side effects — background processes and ports, temp files, debug scaffolding, seeded test data, stashes, config and env changes — and name what has to stay. Use before the final report on any task that started servers or watchers, wrote scratch or repro files, added logging or debug output, seeded databases, registered webhooks or test accounts, or changed configs, env vars, or branches. Not for reviewing the intended diff itself.
- Reads credentials
In this repository38 other files it gives its agents.
- ambiguity-commitSkill
- api-surface-careSkill
- calibrated-recommendationSkill
- codebase-orientationSkill
- concurrency-reasoningSkill
- config-and-flagsSkill
- context-checkpointSkill
- cross-platform-careSkill
- data-loss-guardSkill
- data-migration-safetySkill
- dependency-changesSkill
- docs-as-contractSkill
- edge-case-sweepSkill
- environment-firstSkill
- error-message-qualitySkill
- escalate-vs-decideSkill
- estimation-and-scopingSkill
- explain-at-the-right-levelSkill
- generalize-the-correctionSkill
- git-hygieneSkill
- incident-diagnosisSkill
- llm-app-codeSkill
- numerical-careSkill
- performance-investigationSkill
- perf-sanitySkill
- question-vs-taskSkill
- resource-lifecycleSkill
- reviewing-a-changeSkill
- root-cause-debuggingSkill
- security-reflexesSkill
- stop-thrashingSkill
- subagent-fanoutSkill
- surgical-refactoringSkill
- task-decompositionSkill
- test-designSkill
- untrusted-content-guardSkill
- verify-ui-visuallySkill
- workmanshipSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 13
Scaffolding in the diff: Read git diff hunk by hunk (see workmanship): debug prints, log-level flips, hardcoded test values, commented-out …
- Distinctive: line 25
Before the final report: git status shows only intended changes.
≈ “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
leave-no-mess
Weak cleanup looks like: reporting "done" with a dev server still holding :3000, a repro.py in the repo root, and console.log('HERE') in three files. Strong cleanup leaves the workspace as you found it plus the intended diff, and names anything that had to stay. The task isn't the diff alone; it's the diff plus a workspace in the state you found it.
Sweep, in this order
- Processes and ports. List background tasks you started this session (the harness's task list, plus
ps/Get-Processfor anything a script spawned) and stop each one — dev servers, watchers, containers, tunnels. Confirm the port is free afterwards (lsof -i :<port>/netstat -ano | findstr :<port>). A zombie from your session is the "port already in use" mystery in the user's next one. - Scaffolding in the diff. Read
git diffhunk by hunk (see workmanship): debug prints, log-level flips, hardcoded test values, commented-out experiments,TODO(remove), skipped or.onlytests, timeouts you shortened. Everything left should be the change, not the process of finding it. - Files you created.
git status --porcelain: every untracked path is yours to classify — deliberate artifact (keep) or repro script / downloaded sample / generated fixture (delete, or move to the scratchpad). Also check ignored locations you wrote to (git status --ignored: build dirs, caches,.env.local). - State you changed outside the repo. Undo: seeded or mutated rows in a shared database, edited local or global configs, env vars exported for one run, git stashes you created, feature flags toggled, test users / webhooks / sandbox records registered against real services. External artifacts especially — nobody else knows they exist.
- Working-tree position. Same branch you started on unless moving it was the task; nothing of the user's left stashed; no half-applied migration.
What stays, and how to say so
- Deliberate artifacts are not mess — the new fixture, the added script, the updated lockfile. The test is intent: did the task need this to exist afterward, or did you need it during?
- What you can't or shouldn't clean, report explicitly, one "Left in place:" line each:
dev server on :3000 for your review (stop with ...),migration 0042 applied to local db,cache in .next/ will rebuild. A named leftover is a handoff; an unnamed one is a mess.
Exit check
Before the final report: git status shows only intended changes; every process you spawned is stopped or listed under "Left in place"; every external test artifact is deleted or listed. If any item is unverified, say so rather than assume.
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.

