agent-safety
Skill0 starsChanged 5 months agoMITView on GitHub
Lightweight safety workflow for AI coding agents. Use when the user explicitly asks for Agent Safety Skill, AI coding agent guardrails, a safety gate before code changes, L3/high-risk confirmation cards, or repository-level AGENTS.md/CLAUDE.md safety templates.
- Reads credentials
3 other projects use a version of this.
Adopted by
Most recently taken up by
- poorvith-mp/skills-agentstheir own version, first seen Sep 6, 2026
- zyphr-labs/bounty-harnesstheir own version, first seen Aug 26, 2026
- compass-soul/agent-safety-skilltheir own version, first seen Feb 9, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- zyphr-labs/bounty-harness★ 1same name
- compass-soul/agent-safety-skill★ 0same name
- poorvith-mp/skills-agents★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository2 other files it gives its agents.
- templates/AGENTS.mdAGENTS.md
- templates/CLAUDE.mdCLAUDE.md
The file
Show its rules and text
We split this skill into the rules it gives an agent
18 rules. 0 are common, 15 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
15
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Use this skill to add a minimal safety gate before AI coding agents read, edit, delete, configure, publish, or hand off work.
- Distinctive: line 10
Keep the workflow lightweight.
- Distinctive: line 17
Stop before high-risk actions.
- Distinctive: line 35
If the request has multiple intents, use the highest-risk intent.
- Distinctive: line 46
Use L3 when unsure whether an action is safe.
- Distinctive: line 70
Use this before any high-risk action:
- Distinctive: line 83
Do not proceed until the user explicitly confirms the exact high-risk action.
- Distinctive: line 87
Treat these as L3 by default:
- Distinctive: line 117
Keep the summary factual. Mention failed or skipped validation.
- Distinctive: line 121
Keep only this minimal workflow in active context.
- Very specific: line 123
Read docs/risk-levels.md when adapting the risk model to a new project or team.
- Very specific: line 124
Read docs/scenario-examples.md when testing whether the workflow classifies common risky tasks correctly.
- Very specific: line 125
Use templates/AGENTS.md or templates/CLAUDE.md only when generating a repository-level rules file.
- Distinctive: line 129
Do not replace project-specific rules.
- Distinctive: line 130
Do not add broad process unless the task risk requires it.
- Distinctive: line 131
Do not claim automated hooks exist unless they are actually installed.
- Distinctive: line 132
Do not store secret values in logs, reports, examples, or handoff notes.
- Distinctive: line 133
Do not keep the full skill body in final output.
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Agent Safety
Use this skill to add a minimal safety gate before AI coding agents read, edit, delete, configure, publish, or hand off work.
Keep the workflow lightweight. Do not turn every task into a full governance process.
Core Workflow
- Classify the user intent.
- Classify the risk level.
- Check authorization.
- Stop before high-risk actions.
- Deliver evidence before handoff.
Intent Classification
Classify the request as one primary intent:
| Intent | Meaning | Default action |
| discuss | Brainstorm, compare, name, evaluate, or explain | Answer only |
| read | Inspect files, review code, summarize state | Read only |
| edit | Modify normal files within a clear scope | Proceed after scope is clear |
| create | Add new files or artifacts | Proceed after target is clear |
| configure | Change settings, permissions, credentials, remotes, hooks, CI, deploy config | Treat as high risk |
| delete | Remove, overwrite, reset, clean, or migrate files | Treat as high risk |
| publish | Push, upload, deploy, send, post, or call external systems | Treat as high risk |
| handoff | Summarize, compress, or prepare continuation context | Preserve minimal state |
If the request has multiple intents, use the highest-risk intent.
Risk Levels
| Level | Typical scope | Required behavior |
| L0 | General advice, explanation, naming, planning | Do not modify files |
| L1 | Read-only review, audit, comparison, feasibility analysis | Read only; do not modify files |
| L2 | Local reversible edits, new docs, scoped code changes, local validation | State scope, make focused changes, verify |
| L3 | Delete, overwrite, configure, change permissions, touch secrets, push, deploy, call external APIs, affect production data | Stop and ask for explicit confirmation |
Use L3 when unsure whether an action is safe.
Authorization Check
Before acting, determine:
Task type:
Risk level:
Authorization: confirmed / missing / blocked
Will modify files: yes / no
Will leave local machine or repo: yes / no
Sensitive content involved: yes / no
Decision: proceed / ask confirmation / blockFor L0 and L1, keep this internal unless the user asks for the reasoning.
For L2, mention the scope before making changes when the scope is not obvious.
For L3, stop and show the confirmation card.
L3 Confirmation Card
Use this before any high-risk action:
High-risk action confirmation
- Action:
- Why it is high risk:
- Affected files/systems:
- Sensitive data involved:
- Reversibility:
- Safer alternative:
- Exact confirmation needed:Do not proceed until the user explicitly confirms the exact high-risk action.
Protected Operations
Treat these as L3 by default:
- Reading or modifying
.env, credentials, cookies, tokens, SSH keys, storage state, or secret files. - Deleting, overwriting, resetting, cleaning, force pushing, or changing remotes.
- Installing dependencies, changing hooks, changing CI, changing permissions, or changing deployment configuration.
- Sending emails, posting publicly, uploading, deploying, pushing, or calling external write APIs.
- Touching production data, customer data, payment flows, account access, or legal/medical/financial decisions.
Prefer safer alternatives:
| Risky action | Safer alternative |
| Delete files | Move to trash or propose deletion list first |
| Force push | Use normal push or --force-with-lease only after confirmation |
| Edit secrets | Ask the user to edit manually or provide a placeholder |
| Run broad cleanup | Produce a candidate cleanup report first |
| Deploy/publish | Run local validation and request explicit approval |
Delivery Evidence
End L2 and L3 work with a short evidence summary:
Changed:
Verified:
Not done:
Risks:
Next:Keep the summary factual. Mention failed or skipped validation.
Progressive Disclosure
Keep only this minimal workflow in active context. Load supporting docs only when needed:
- Read
docs/risk-levels.mdwhen adapting the risk model to a new project or team. - Read
docs/scenario-examples.mdwhen testing whether the workflow classifies common risky tasks correctly. - Use
templates/AGENTS.mdortemplates/CLAUDE.mdonly when generating a repository-level rules file.
Boundaries
- Do not replace project-specific rules.
- Do not add broad process unless the task risk requires it.
- Do not claim automated hooks exist unless they are actually installed.
- Do not store secret values in logs, reports, examples, or handoff notes.
- Do not keep the full skill body in final output; keep only decisions, evidence, and links to generated artifacts.
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.

