Zombie Process Sweep
Skill1 starsChanged 4 months agoMITView on GitHub
Find and safely kill orphaned dev servers/watchers left running at session end, enforcing a 'stop what you started' rule automatically instead of relying on memory. Use at the end of any session that started a background dev server, watcher, or long-running process, and whenever a dev server seems to be hanging mid-session.
In this repository25 other files it gives its agents.
- templates/AGENTS.mdAGENTS.md
- braindump-autoSkill
- braindumpSkill
- Capability Claim GroundingSkill
- Derived Figure AuditSkill
- design-review-loopSkill
- Dictation Garble CatcherSkill
- Discord Todo OpsSkill
- Full Account Security AuditSkill
- Large Task Session SplitSkill
- Personal Dashboard StyleSkill
- Pre-Push Secret ScanSkill
- Project Design DocSkill
- Public Repo Leak RetractionSkill
- repo-hygieneSkill
- Repo Index Drift CheckSkill
- Safe Section DeletionSkill
- Session HandoffSkill
- Skill Overlap AuditSkill
- superbraindumpSkill
- ui-change-visual-verifySkill
- Verify, Don't TrustSkill
- Windows Process Restart (Safe)Skill
- Windows Shell Tool SelectionSkill
- Worktree Task-Pack VerificationSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are 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.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Every background process started during a session should be stopped when its task is done, unless it was explicitly asked to persist.
≈ “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
Zombie Process Sweep
Every background process started during a session should be stopped when its task is done, unless it was explicitly asked to persist. This automates checking for the ones that got left behind.
Why this exists
The same "dev server hanging" failure has recurred multiple times in real sessions: a next dev or Vite process left running, or wedged, from an earlier turn, silently eating a port or CPU until someone notices something's wrong.
Procedure
1. Find the real processes, don't guess:
Get-CimInstance Win32_Process -Filter "Name='node.exe'" | Select-Object ProcessId, ParentProcessId, CommandLineMatch on CommandLine, not on process name alone. node.exe alone doesn't tell you what's actually running.
2. Identify supervisor vs. child for anything running under a watcher/supervisor pattern (e.g. run.js spawning index.js). Only kill the child if a live reload is the goal. Killing the supervisor takes the whole thing down and it won't respawn.
3. Kill only processes you can positively tie to this session's own launches, or that are unambiguously orphaned (parent PID no longer exists, and the process matches a known dev-server/watcher command shape: next dev, vite, npm run dev, tauri dev, etc.). Confirm with the user before killing anything that might be serving live/production traffic.
4. Never build this around a broad heuristic ("kill anything that looks old or unused"). A dead-parent-PID heuristic alone has produced false positives against live processes before. Only act on the specific, verified signature: known dev-command pattern + confirmed-dead or confirmed-orphaned parent. Flag anything less certain instead of killing it.
5. Verify the kill actually worked and nothing needed it:
Get-Process -Id <pid> -ErrorAction SilentlyContinue # should return nothing after Stop-ProcessThen check the port is actually free if the goal was freeing a port, not just that the PID is gone.
Relationship to windows-shell-tool-selection
Both are Windows-environment operational skills; this one is about what's running, that one is about which tool to type the commands into. They're commonly needed in the same session.
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.