agentleFS
RedSe7enZRedSe7enZ/agent-safety-skill/SKILL.md

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

  • Other versions3 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 3

    1. zyphr-labs/bounty-harness★ 1same name
    2. compass-soul/agent-safety-skill★ 0same name
    3. 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.

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
  1. Distinctive:

    Use this skill to add a minimal safety gate before AI coding agents read, edit, delete, configure, publish, or hand off work.

    line 8
  2. Distinctive:

    Keep the workflow lightweight.

    line 10
  3. Distinctive:

    Stop before high-risk actions.

    line 17
  4. Distinctive:

    If the request has multiple intents, use the highest-risk intent.

    line 35
  5. Distinctive:

    Use L3 when unsure whether an action is safe.

    line 46
  6. Distinctive:

    Use this before any high-risk action:

    line 70
  7. Distinctive:

    Do not proceed until the user explicitly confirms the exact high-risk action.

    line 83
  8. Distinctive:

    Treat these as L3 by default:

    line 87
  9. Distinctive:

    Keep the summary factual. Mention failed or skipped validation.

    line 117
  10. Distinctive:

    Keep only this minimal workflow in active context.

    line 121
  11. Very specific:

    Read docs/risk-levels.md when adapting the risk model to a new project or team.

    line 123
  12. Very specific:

    Read docs/scenario-examples.md when testing whether the workflow classifies common risky tasks correctly.

    line 124
  13. Very specific:

    Use templates/AGENTS.md or templates/CLAUDE.md only when generating a repository-level rules file.

    line 125
  14. Distinctive:

    Do not replace project-specific rules.

    line 129
  15. Distinctive:

    Do not add broad process unless the task risk requires it.

    line 130
  16. Distinctive:

    Do not claim automated hooks exist unless they are actually installed.

    line 131
  17. Distinctive:

    Do not store secret values in logs, reports, examples, or handoff notes.

    line 132
  18. Distinctive:

    Do not keep the full skill body in final output.

    line 133

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  1. Classify the user intent.
  2. Classify the risk level.
  3. Check authorization.
  4. Stop before high-risk actions.
  5. Deliver evidence before handoff.

Intent Classification

Classify the request as one primary intent:

IntentMeaningDefault action
discussBrainstorm, compare, name, evaluate, or explainAnswer only
readInspect files, review code, summarize stateRead only
editModify normal files within a clear scopeProceed after scope is clear
createAdd new files or artifactsProceed after target is clear
configureChange settings, permissions, credentials, remotes, hooks, CI, deploy configTreat as high risk
deleteRemove, overwrite, reset, clean, or migrate filesTreat as high risk
publishPush, upload, deploy, send, post, or call external systemsTreat as high risk
handoffSummarize, compress, or prepare continuation contextPreserve minimal state

If the request has multiple intents, use the highest-risk intent.

Risk Levels

LevelTypical scopeRequired behavior
L0General advice, explanation, naming, planningDo not modify files
L1Read-only review, audit, comparison, feasibility analysisRead only; do not modify files
L2Local reversible edits, new docs, scoped code changes, local validationState scope, make focused changes, verify
L3Delete, overwrite, configure, change permissions, touch secrets, push, deploy, call external APIs, affect production dataStop 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 / block

For 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 actionSafer alternative
Delete filesMove to trash or propose deletion list first
Force pushUse normal push or --force-with-lease only after confirmation
Edit secretsAsk the user to edit manually or provide a placeholder
Run broad cleanupProduce a candidate cleanup report first
Deploy/publishRun 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.md when adapting the risk model to a new project or team.
  • Read docs/scenario-examples.md when testing whether the workflow classifies common risky tasks correctly.
  • Use templates/AGENTS.md or templates/CLAUDE.md only 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.