auto-approve-policy
Skill0 starsChanged 5 months agoMITView on GitHub
Caution protocol for destructive operations. Use before deleting files, dropping database objects, removing exports/public APIs, or running irreversible commands.
In this repository38 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- api-contract-validationSkill
- architecture-scannerSkill
- auto-learningSkill
- backend-patternsSkill
- branch-syncSkill
- browser-testSkill
- browseSkill
- build-checkSkill
- cache-refreshSkill
- codebase-explainerSkill
- coding-standardsSkill
- commit-styleSkill
- context-switchingSkill
- continuous-learningSkill
- db-preflightSkill
- env-preflightSkill
- eval-harnessSkill
- feature-completenessSkill
- file-indexSkill
- frontend-patternsSkill
- function-extractSkill
- idev-initSkill
- import-graphSkill
- lessons-learnedSkill
- post-creation-verifySkill
- pre-ship-verifySkill
- project-mapSkill
- self-reviewSkill
- session-resumeSkill
- skill-benchmarkSkill
- skilloptSkill
- smart-contextSkill
- strategic-compactSkill
- task-journalSkill
- tdd-workflowSkill
- test-coverageSkill
- test-mapSkill
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 38
Never leave commented-out corpses or "Legacy"-renamed clutter as a substitute for a requested deletion
≈ “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
Destructive Operation Caution Protocol
This skill is a behavioral guideline, not a permissions mechanism. Actual auto-approval of tools is configured in settings.json permissions — nothing here grants or withholds tool access.
Before a Destructive Action
Destructive actions include: deleting files or directories, dropping or truncating database objects, removing exported functions or public API surface, deleting migrations or config entries, force-pushing, hard resets, and other irreversible commands.
Decide based on intent:
- Explicitly requested — the user asked for this specific removal ("delete X", "remove the obsolete helpers"). Do it. Do NOT second-guess the user, suggest commenting code out instead, or rename things with "Legacy" prefixes. Just perform the deletion cleanly and report what was removed.
- Incidental to a broader task — the deletion is a side effect the user did not specifically ask for (e.g., removing a file while refactoring). Pause and confirm before proceeding, stating what would be removed and why.
- Bulk or wide-impact removals — before deleting many files or rows, report the list of what will be removed first, then proceed (if explicitly requested) or wait for confirmation (if incidental).
Example of case 2 (incidental) done right:
The refactor leaves src/utils/dateHelpers.ts with no remaining importers.
Delete it as part of this change, or keep it?Non-Destructive Work
Additions and edits need no special treatment from this skill — proceed normally under whatever permissions the session grants.
Summary
- Explicit request to delete → delete, then report what was removed
- Incidental deletion → confirm first
- Bulk deletion → enumerate before acting
- Never leave commented-out corpses or "Legacy"-renamed clutter as a substitute for a requested deletion
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.