multi-agent-filesystem-governance
Govern filesystem organization and file-operation decisions in multi-agent environments. Use when deciding where files should live across agent-private workspaces, shared resources, archives, downloads, scripts, notes, knowledge vaults, and code project folders; when defining directory conventions; when triaging downloads; when preventing cross-agent overwrites; or when standardizing file placement and lifecycle rules for reusable agent setups.
Install via CLI (Recommended)
clawhub install openclaw/skills/skills/darinrowe/multi-agent-filesystem-governanceMulti-Agent Filesystem Governance
Use this skill to make safe, consistent filesystem decisions in environments where multiple agents may create, edit, move, download, organize, or archive files.
This skill governs ownership, placement, lifecycle, and write boundaries. It is not tied to a specific product, path layout, operating system, or note-taking tool.
Core objective
Ensure that every file has:
- a clear ownership scope
- a clear storage location
- a clear lifecycle state
- a clear modification rule
When uncertain, choose the narrowest safe scope and the least shared location.
Scope model
Classify every file, folder, and file operation into exactly one of these scopes:
- agent-private: used by one agent only
- shared: intentionally reusable or accessible by multiple agents
- archive: inactive, historical, completed, frozen, or retained for reference
If scope is unclear, default to agent-private.
Storage model
Use three top-level storage categories conceptually, even if local directory names differ:
- agent areas: private per-agent working locations
- shared areas: common reusable resources
- archive areas: inactive or historical materials
Do not depend on any single hard-coded path. Preserve conceptual boundaries even when adapting to local layouts.
Required decision order
Before creating, editing, moving, renaming, or deleting files, determine the following in order:
- What is the artifact?
- Is it temporary, active, reusable, frozen, or historical?
- Is it private to one agent or shared by multiple agents?
- What is the narrowest valid location?
- Will this action affect other agents or shared workflows?
If any answer is unclear, choose a private non-destructive location first.
Default rules
Prefer private over shared
If a file does not clearly require cross-agent reuse, place it in an agent-private location.
Do not write across agent boundaries by default
Do not create, edit, move, or overwrite files belonging to another agent unless the task explicitly requires it.
Treat shared locations as high-impact
Writing to a shared location is a wider-scope action. Use shared locations only when reuse, collaboration, or standardization is intended.
Keep archive separate from active work
Archived material is not an active workspace. Do not continue editing files in archive locations. Restore or copy them into an active or private area first.
Treat temporary locations as disposable
Do not keep the only important copy of a file in a temp or scratch location.
Content-type placement guidance
Apply these rules regardless of exact local path names.
Skills
- Put reusable multi-agent skills in a shared skills location.
- Put experimental, agent-specific, or override skills in an agent-private skills location.
- If the same skill exists in both shared and private locations, prefer the more specific private version for that agent.
Metadata
Not sure this is the right skill?
Describe what you want to build — we'll match you to the best skill from 16,000+ options.
Find the right skillPaste this into your clawhub.json to enable this plugin.
{
"plugins": {
"official-darinrowe-multi-agent-filesystem-governance": {
"enabled": true,
"auto_update": true
}
}
}Related Skills
obsidian-official-cli-headless
Install and adapt the official Obsidian CLI for headless Linux servers by using a non-root user, Xvfb virtual display, ACL-based vault access, and an obs wrapper command. Use when the user wants the official Obsidian CLI (not notesmd-cli) on a Debian/Ubuntu-like machine without a normal desktop session, or when root/GUI/display constraints break native CLI use.
openclaw-backup-restore
Backup and restore OpenClaw configuration, agents, sessions, and workspace to/from a private Git repository. Use when the user wants to manually trigger a backup, migrate to a new machine, or restore from a previous state.
git-backed-obsidian-cli-workflows
Use the official Obsidian CLI for note workflows in a Git-backed vault, including search, read, links/backlinks-style queries, daily-note operations, and lightweight note writes that auto-sync after successful write operations. Use when the official Obsidian CLI is already installed and usable on any supported environment, and the task is about querying or updating notes in an Obsidian vault with Git-backed backup behavior.
git-workflows-pro
Handle advanced git workflows and recovery tasks. Use when the user needs help with interactive rebase, commit cleanup, conflict resolution, reflog recovery, cherry-pick, stash, worktree, bisect, submodule vs subtree decisions, sparse checkout, branch archaeology, or undoing dangerous history mistakes in real repositories.
github-private-repo-ssh-routing
Diagnose and manage SSH keys, host aliases, and Git remotes for GitHub private repositories in multi-repo environments. Use when deploy keys collide, a machine manages multiple private repos, automation or backup scripts push to GitHub, or errors like "Permission denied (publickey)" / "Repository not found" appear despite the repo existing.