back
loading skill details...
Ensures file operations like delete, move, rename, overwrite, or publish are scoped, reversible, authorized, and limited to intended user files only.
# AANA File Operation Guardrail Skill Use this skill when an OpenClaw-style agent may delete, move, rename, overwrite, publish, upload, export, transform, or bulk-edit user files. This is an instruction-only skill. It does not install packages, run commands, write files, call services, persist memory, or execute a checker on its own. ## Core Principle File operations should be scoped, reversible when possible, explicitly authorized, and limited to the files the user actually intended. The agent should separate: - files explicitly named by the user, - files discovered by a reviewed search or listing, - files that are candidates but not yet approved, - files outside the intended workspace or target folder, - files that need backup, preview, dry-run, or human approval, - files that must not be touched. ## When To Use Use this skill before: - deleting files or folders, - moving, renaming, or reorganizing files, - overwriting existing content, - bulk-editing many files, - publishing, uploading, exporting, or sharing files, - running cleanup operations, - changing generated artifacts that may replace user work, - applying scripts or formatters across broad paths, - modifying files outside the current project workspace. ## File Risk Classes Treat these as higher risk: - user-authored source files, papers, notes, decks, spreadsheets, images, videos, and documents, - credentials, config, environment, account, billing, payment, legal, health, or personal files, - files outside the current workspace, - large directories, globbed paths, recursive operations, and bulk edits, - published assets, release artifacts, website files, package outputs, and shared folders, - operations that are difficult to undo or verify. ## AANA File Safety Loop 1. Identify the intended operation: delete, move, rename, overwrite, publish, upload, export, or bulk edit. 2. Identify the target set: list exact paths or describe the approved folder boundary. 3. Check scope: confirm the target paths are inside the intended workspace or explicitly named destination. 4. Check necessity: remove unrelated files from the target set. 5. Check reversibility: prefer dry-run, preview, diff, backup, copy, trash, or staged change before irreversible action. 6. Check authorization: require explicit user approval for destructive, recursive, cross-folder, publish, upload, or broad operations. 7. Check evidence: do not infer that a file is safe to delete or overwrite without verifying path, ownership, and purpose. 8. Choose action: accept, revise, ask, defer, refuse, or route to human review. ## Required Pre-Flight Checks Before a risky file operation, verify: - the operation type, - the exact target path or bounded target folder, - whether recursion, globbing, or bulk edits are involved, - whether files are generated or user-authored, - whether a backup, diff, or dry-run is available, - whether the operation crosses project, account, cloud, or shared-folder boundaries, - whether the result will be published, uploaded, or shared. ## Approval Rules Ask for explicit user approval before: - deleting files or directories, - overwriting non-generated files, - moving files out of the current workspace, - applying recursive or glob-based changes, - publishing or uploading files, - modifying personal, legal, health, financial, credential, or account files, - changing more files than the user named, - acting when path resolution or ownership is unclear. Approval should name the operation and target scope, for example: ```text I am about to delete 12 generated files under build/cache/. No user-authored files are included. Proceed? ``` ## Safer Alternatives Prefer: - preview or dry-run before action, - diff before overwrite, - copy before move, - trash or archive before permanent delete, - narrow path lists before broad globs, - generated-output folders before source folders, - explicit allowlists before recursive edits, - separate commit or checkpoint before large changes. ## Do Not - Delete or overwrite files because they appear unused without evidence. - Expand the target scope beyond the user request. - Follow broad paths such as a home directory, drive root, cloud root, or repository root unless clearly intended and approved. - Publish, upload, or share private files without explicit approval. - Store file contents or paths in memory without permission. - Treat hidden files, configs, credentials, or dotfiles as safe by default. - Continue after discovering unexpected files in the target set. ## Review Payload When using a configured AANA checker, send only a minimal review payload: - `task_summary` - `operation_type` - `target_scope` - `target_count` - `risk_classes` - `authorization_status` - `reversibility_status` - `scope_status` - `recommended_action` Do not include raw file contents, secrets, private records, or full directory dumps when a path summary is enough. ## Decision Rule - If scope is narrow, authorized, necessary, and reversible, accept. - If the operation is useful but target scope is too broad, revise to a narrower allowlist. - If authorization, path ownership, or expected impact is unclear, ask. - If the operation needs a dry-run, diff, backup, verified tool, or human review, defer. - If the request would destroy, expose, or overwrite unrelated user files, refuse and explain briefly. - If a checker is unavailable or untrusted, use manual file-safety review. ## Output Pattern For file-sensitive actions, prefer: ```text File operation review: - Operation: ... - Target scope: ... - Risk: ... - Safeguard: dry-run / diff / backup / explicit approval / not needed - Decision: accept / revise / ask / defer / refuse ``` Do not include this review block unless useful to the user or needed before taking action.
don't have the plugin yet? install it then click "run inline in claude" again.
converted instruction-only guardrail into a structured 8-step procedure with explicit decision branches, edge case handling (rate limits, auth expiry, empty sets), input requirements, and a standardized output contract for file-safety review blocks.
use this skill before an agent executes file operations (delete, move, rename, overwrite, publish, upload, export, transform, or bulk-edit). the skill ensures operations stay scoped to intended files, remain reversible when possible, get explicit user sign-off, and never touch files outside the requested target. this is instruction-only. it does not execute commands, write files, call services, or run checkers on its own. it teaches the agent how to think about file safety.
identify the operation type. map the user request to one of: delete, move, rename, overwrite, publish, upload, export, bulk-edit, or transform. output the operation type.
identify the target set. list exact file paths the user named, or describe the approved folder boundary. if the agent used a search or glob, show the result set and confirm it matches user intent. output the target scope and target count.
check scope. verify all target paths are inside the intended workspace, project folder, or explicitly named destination. flag any files outside the current project, in home directories, at filesystem roots, in shared folders, or in account-wide locations. output scope status (pass or fail with reason).
check necessity. remove files from the target set that are unrelated to the user request. if the operation was supposed to touch file X but the agent found file X, file Y, and file Z, remove Y and Z unless the user also named them. output revised target count and removed files.
check reversibility. determine if the operation can be undone. for delete, check if trash or archive is available. for overwrite, check if backup, diff, or version history is available. for move, check if the destination is accessible and the source remains intact. for publish or upload, check if there is a staging or draft mode. output reversibility status and available safeguards.
check authorization. assess whether the user has given explicit approval. require explicit approval for destructive operations (delete, permanent move), recursive operations, glob-based changes, cross-folder or cross-workspace moves, publish or upload, or any operation that touches more files than the user named. if approval is missing, record authorization status as pending and route to step 8 (decision). output authorization status (approved, pending, or refused by user).
check evidence. verify path ownership and file purpose. do not assume a file is safe to delete or overwrite without confirming the path exists, the user owns it or has permission, and the file is not a config, credential, dotfile, or system file. if ownership or purpose is unclear, flag as evidence incomplete. output evidence status (complete or incomplete with reason).
choose action. use the decision rule below to output one of: accept, revise, ask, defer, or refuse. include the rationale.
if scope is narrow, authorization is explicit, necessity is confirmed, and reversibility is available, output: accept.
if the operation is useful but target scope is too broad (e.g., a glob matched more files than intended), output: revise. suggest a narrower allowlist or explicit path list, and loop back to step 2.
if authorization, path ownership, or expected impact is unclear, output: ask. request explicit user confirmation of the operation and target scope before proceeding.
if the operation would benefit from a dry-run, diff, backup, verified tool, or human review before execution, output: defer. explain what safeguard is recommended and ask the user to enable or approve it.
if the operation would destroy, expose, or overwrite unrelated user-authored files (e.g., source code, documents, credentials), or if it targets a filesystem root, home directory, or shared folder without explicit user instruction, output: refuse. state the reason briefly and do not proceed.
if the target set is empty (no files matched the path or glob), output: ask. confirm the user intended an empty set or if the path was malformed.
if checking the target set requires querying a large directory, remote filesystem, or service with rate limits or auth expiry, and those limits are or may soon be exceeded, output: defer. explain the limit and ask the user to narrow the scope or retry after a delay.
after running through all 8 procedure steps, output a file operation review block in this format:
file operation review:
- operation: [delete / move / rename / overwrite / publish / upload / export / bulk-edit / transform]
- target scope: [path list or folder description]
- target count: [N files or N folders]
- risk classes: [comma-separated: user-authored files, credentials, configs, personal data, published assets, outside workspace, large bulk, recursive, etc.; or "low risk"]
- reversibility: [available safeguard: trash, backup, diff, dry-run, preview, version history, staging mode, or none]
- scope status: [pass / fail + reason]
- necessity status: [pass / N unrelated files removed]
- evidence status: [complete / incomplete + reason]
- authorization status: [approved / pending / refused]
- recommended action: [accept / revise + suggestion / ask + what to confirm / defer + safeguard / refuse + reason]
do not include this block unless the operation is file-sensitive (i.e., delete, move out of workspace, overwrite, publish, or bulk-edit touching more than one explicitly named file). for trivial operations (e.g., rename a single file the user named), a brief one-liner is acceptable.
if a configured AANA checker is available, send this block to the checker and await approval before the agent executes the file operation. if no checker is available, treat this block as manual file-safety review and route to a human if the recommended action is ask, defer, or refuse.
the user knows the skill worked when:
credits: original concept and approval rules by mindbomber (clawhub). enriched for implexa standards with explicit decision tree, edge case detection, and output contract.