skills/permissions/SKILL.md
Configures Claude Code permissions for safe agent autonomy. Creates settings.json with allow/deny rules and a path-restriction hook. Use after /optimus:init to enable autonomous agent workflows, or standalone to lock down a project's permission boundaries.
npx skillsauth add oprogramadorreal/optimus-claude skills/permissionsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Configure safe permission rules and a path-restriction hook so Claude Code agents can work autonomously inside the project without constant permission prompts, while blocking destructive operations outside the project.
| Operation | Inside Project | Outside Project | |-----------|---------------|-----------------| | Read/Search | Allow | Allow | | Write/Edit | Allow | Ask user | | Write/Edit precious unversioned file | Ask user | Ask user | | Delete (rm/rmdir) | Allow | BLOCKED | | Delete precious unversioned file | BLOCKED | BLOCKED | | Git on feature branch | Allow | — | | Git on protected branch | BLOCKED | — |
.claude/settings.json exists. If so, read its full content — it will be preserved during merge..claude/hooks/restrict-paths.sh (or restrict-paths.*) already exists. Note whether this is a fresh install or an update — report this to the user in Step 5..mcp.json exists at the project root. If so, extract all MCP server names (top-level keys) for Step 4.Print a brief detection summary to the user: what exists, what will be created/updated.
mkdir -p .claude/hooks
Copy the hook template to the project (overwrites any existing version):
$CLAUDE_PLUGIN_ROOT/skills/permissions/templates/hooks/restrict-paths.sh.claude/hooks/restrict-paths.shCopy the file contents exactly — do not modify the template.
Use the template from $CLAUDE_PLUGIN_ROOT/skills/permissions/templates/settings.json as the base configuration.
.claude/settings.json does NOT existCreate it from the template. If .mcp.json was found in Step 1, add mcp__<server-name> entries to the permissions.allow list for each server.
.claude/settings.json already existsMerge the template into the existing file:
permissions.allow — add any entries from the template that are not already present. If .mcp.json was found, also add mcp__<server-name> entries. Never remove existing entries.
permissions.deny — add any entries from the template that are not already present. Then check for extra git deny patterns: collect all deny entries containing the word git (as a command, not as part of words like github) from both the existing settings and the template. If the existing settings have git deny entries not present in the template, list them and use AskUserQuestion — header "Git patterns", question "Your settings have extra git deny patterns that may block feature-branch workflow (commit/push) needed by /optimus:tdd: [list patterns]. Replace with the template's set?":
If Replace: remove all existing git deny entries, add the template's git deny set. Non-git deny entries are untouched. If Keep all: no changes.
hooks.PreToolUse — add the hook entry from the template. If a PreToolUse array already exists, append to it (avoid duplicates if an entry already references restrict-paths.sh).
Preserve everything else — existing hooks.PostToolUse, custom sections, and any other configuration must remain untouched.
Run through this checklist. Fix any issues before reporting.
.claude/hooks/restrict-paths.sh exists and contains the hook logic.claude/settings.json exists and contains:
permissions.allow with at least the 13 tool entries from the templatepermissions.deny with at least the 30 deny patterns from the templatehooks.PreToolUse with an entry referencing restrict-paths.shReport to the user:
PROTECTED_BRANCHES array in .claude/hooks/restrict-paths.sh.env, *.key, *.pem, *.sqlite, etc.) that are not tracked by gitfind . -maxdepth 4 \( -name ".env*" -o -name "local.settings.json" -o -name "credentials.*" -o -name "secrets.*" -o -name "docker-compose.override.yml" -o -name "appsettings.*.json" -o -name "*keyfile*.json" -o -name "newrelic.config" -o -name "*.key" -o -name "*.pem" -o -name "*.pfx" -o -name "*.p12" -o -name "*.cert" -o -name "*.crt" -o -name "*.jks" -o -name "*.sqlite" -o -name "*.sqlite3" -o -name "*.db" -o -name "*.db-shm" -o -name "*.db-wal" -o -name "*.db-journal" -o -name "*.mdf" -o -name "*.ldf" -o -name "*.ndf" -o -name "*.bak" -o -name "*.dump" -o -name "*.sql.gz" -o -name "*.suo" -o -name "*.user" \) -not -path "./.git/*" -not -path "*/node_modules/*" -not -path "*/obj/*" -not -path "*/bin/*" 2>/dev/null
config.local.yaml), ask the user if they want to add custom patterns to the is_precious() function in .claude/hooks/restrict-paths.sh. Note: custom edits to this file will be replaced if the user re-runs /optimus:permissions. For persistent customizations, edit the template in the plugin source instead.Recommend the next step based on project state:
.claude/CLAUDE.md does not exist → /optimus:init to set up coding guidelines and project structure/optimus:unit-test to establish test coverage, or /optimus:tdd to start developing with test-driven workflowTell the user: Tip: for best results, start a fresh conversation for the next skill — each skill gathers its own context from scratch.
development
Use when starting a new project or product and you want a docs-first plan before writing code — scaffolds an empty, product-neutral spec-driven-development cascade (product vision, MVP PRD, target tech-stack) for a human to fill, then hands off to brainstorm. Emits skeletons only; it never authors product content and never overwrites existing docs.
tools
Compacts the current conversation into a single self-contained handoff document under docs/handoffs/ so a fresh agent — a new session, a different AI tool, or another developer on a different machine — can resume the work by reading only that file. References committed artifacts (PRDs, plans, ADRs, issues, commits) by path or URL and inlines anything not yet pushed. Redacts secrets and PII. Re-running on an existing handoff lets you enhance the shared doc or overwrite it. Use when pausing work that someone else or a future session will pick up, or when a long conversation needs a durable summary.
development
Improves unit test coverage on demand — discovers testing gaps and generates tests that follow project conventions. Requires /optimus:init to have set up test infrastructure first. Conservative — only adds new test files, never refactors existing source code. Supports `deep` mode for iterative in-conversation test generation and `deep harness` mode for an automated multi-cycle unit-test + testability-refactor loop with fresh context per phase. Use when test coverage is low, after adding new code that lacks tests, or when you want an automated coverage-improvement harness.
development
Guides test-driven development — decompose a feature or bug fix into behaviors, then cycle through Red (failing test) → Green (minimal implementation) → Refactor for each one. Requires /optimus:init and working test infrastructure. Use when starting a new feature or bug fix with test-first discipline.