ai-analyze-permissions
$
npx mdskill add arcasilesgroup/ai-engineering/ai-analyze-permissionsAnalyze accumulated permissions in `settings.local.json` and suggest smart wildcard patterns to consolidate into shared configuration. Reduces permission sprawl by replacing specific entries with safe wildcard patterns.
SKILL.md
.github/skills/ai-analyze-permissionsView on GitHub ↗
--- name: ai-analyze-permissions description: "Use when Claude Code keeps asking to approve commands you have already approved, when settings.local.json has grown large, or when you want to consolidate permission grants into wildcard patterns. Trigger for 'too many permission prompts', 'clean up permissions', 'audit my settings', 'consolidate allow rules'. Claude Code only — not available in GitHub Copilot, Antigravity, or Codex." effort: high model_tier: opus argument-hint: "[analyze|apply|cleanup]" disable-model-invocation: true applies_to_surfaces: [claude-code] copilot_compatible: false codex_compatible: false --- # Analyze Permissions ## Purpose Analyze accumulated permissions in `settings.local.json` and suggest smart wildcard patterns to consolidate into shared configuration. Reduces permission sprawl by replacing specific entries with safe wildcard patterns. ## Arguments (parsed from user input) - **action**: What to do - `analyze` (default), `apply`, or `cleanup` Example invocations: - `/ai-analyze-permissions` → analyze and suggest patterns - `/ai-analyze-permissions apply` → apply suggested patterns to shared config - `/ai-analyze-permissions cleanup` → just run the cleanup script ## Process ### Step 1: Read Current Permissions Read these files: 1. **Project-local**: `<project-root>/.claude/settings.local.json` - accumulated "Always allow" permissions (per-project) 2. **Global**: `~/.claude/settings.json` - shared/base permissions across all projects Note: `settings.local.json` is project-specific. Each repo has its own at `<repo>/.claude/settings.local.json`. The global `~/.claude/settings.json` is shared across all projects. ### Step 2: Analyze Patterns For each entry in `settings.local.json`: 1. **Check if already covered** - Is there a wildcard in `settings.json` that covers this? - `Bash(git commit -m "Fix bug")` is covered by `Bash(git commit:*)` - `Bash(curl https://api.example.com)` is covered by `Bash(curl:*)` 2. **Identify pattern opportunities** - Group similar commands: - Multiple `kubectl` commands → suggest `Bash(kubectl:*)` - Multiple `docker` commands → suggest `Bash(docker:*)` - Multiple WebFetch for same domain → suggest `WebFetch(https://example.com/*)` 3. **Decide global vs local** - Where should the pattern live? - **Global (`~/.claude/settings.json`)**: General-purpose tools used across projects (`npx`, `python`, `docker compose`, etc.) - **Local (`settings.local.json`)**: Project-specific commands, or write operations you only want for that project (e.g., `git push` for a personal repo) 4. **Assess safety** - Consider if the pattern is safe for auto-approval: - Read-only commands: Generally safe - Commands with side effects: Flag for review - Overly broad patterns: Warn about security implications ### Step 3: Present Analysis Output a structured report: ```markdown ## Permission Analysis ### Settings Overview - settings.local.json: X entries - settings.json: Y entries (Z wildcards) ### Already Covered (can be removed) These entries in settings.local.json are redundant: | Entry | Covered by | | ------------------------- | ------------------- | | Bash(git commit -m "...") | Bash(git commit:\*) | ### Suggested New Patterns These patterns would consolidate multiple specific entries: | Pattern | Covers | Scope | Safety | | -------------------- | --------- | ------ | ------------------- | | Bash(kubectl:\*) | 4 entries | global | Safe (read-heavy) | | Bash(docker exec:\*) | 3 entries | local | Review (can modify) | ### Uncategorized These entries don't fit a pattern (one-offs): - Bash(some-specific-command) ``` ### Step 4: Handle Actions Based on the action argument: **analyze (default):** - Present the report - Ask if user wants to apply suggestions **apply:** - For each suggested pattern, ask for confirmation - Add approved global patterns to `~/.claude/settings.json` by editing the `permissions.allow` array - Add approved local patterns to `<project-root>/.claude/settings.json` (project-level, not local) - Run the cleanup script to remove now-redundant entries from `settings.local.json` **cleanup:** - Run `<project-root>/.claude/skills/ai-analyze-permissions/scripts/cleanup-settings-local.sh` ### Step 5: Apply Patterns (if applying) When adding patterns: 1. Before writing updated permissions, re-read the target file to ensure no concurrent modifications since the analysis step. If the file has changed, re-run analysis. 2. Read the target settings file (`~/.claude/settings.json` for global, `<project-root>/.claude/settings.json` for project) 3. Add new entries to the `permissions.allow` JSON array 4. Write the updated JSON back (preserving all other fields) 5. Run cleanup to remove now-redundant entries: `<project-root>/.claude/skills/ai-analyze-permissions/scripts/cleanup-settings-local.sh` **Important**: Adding patterns to `settings.json` never removes existing entries. The cleanup script only cleans `settings.local.json`. To clean `settings.json` itself, manually remove redundant entries. When adding patterns to project-level `settings.json` (committed to git), warn the user that these patterns will apply to all team members who pull the change. Confirm before writing. See `references/pattern-safety.md` for pattern safety classifications. $ARGUMENTS
More from arcasilesgroup/ai-engineering
- ai-adviseProactive governance advisor — checks standards, decisions, and quality trends during development. Always advisory, NEVER blocks. Three modes: `advise` (post-edit), `gate` (pre-dispatch), `drift` (on-demand decision audit). Trigger for 'governance check', 'advise on this change', 'check for drift', 'is this aligned with active decisions', 'shift-left advisory'. Not for blocking gates — use /ai-verify. Not for narrative code review — use /ai-review.
- ai-animationDesigns motion, transitions, and micro-interactions for UI components: spring animations, gestures, easing, staggers — taste-driven detail compounding. Trigger for 'animate this', 'add transitions', 'micro-interactions for', 'gesture design', 'swipe to dismiss', 'easing for this', 'stagger the'. Not for design systems; use /ai-design instead. Not for visual art; use /ai-visual instead. Not for testing animation code; use /ai-test instead.
- ai-autopilotDelivers large multi-concern specs and backlog runs autonomously: decomposes specs into sub-specs (or normalizes work items into a backlog DAG), deep-plans with parallel agents, builds a dependency DAG, implements in waves, runs a single final quality loop with one bounded quality-remediation pass (verify+guard+review on full changeset), delivers via PR. Trigger for 'implement spec-NNN end to end', 'autopilot this', 'autonomous delivery', 'decompose and ship', 'run the backlog', 'execute these GitHub issues', 'process the sprint backlog'. Invocation is the approval gate. Not for small or single-concern tasks; use /ai-build instead. Not for ambiguous requirements; use /ai-brainstorm first.
- ai-boardOperates the project board (GitHub Projects v2 or Azure DevOps): discovers configuration after install (fields, state mappings, process templates) and syncs work-item state at lifecycle transitions. Trigger for 'set up the board', 'configure our ADO board', 'discover board fields', 'move this issue to in-review', 'update the board', 'mark as in progress', 'sync the work item state'. Two subcommands: `discover` (post-install configuration write) and `sync` (lifecycle state transitions). Auto-invoked via `sync` by /ai-brainstorm, /ai-build, and /ai-pr; fail-open. Not for backlog execution; use /ai-autopilot --backlog instead.
- ai-brainstormForces rigorous design interrogation BEFORE any code: explores approaches, surfaces ambiguity, gathers evidence, produces an approved spec that becomes the contract for /ai-plan. Trigger for 'lets add X', 'how should we handle Y', 'whats the best approach', 'I am thinking about', 'what should we build for'. Not for existing approved specs; use /ai-plan instead. Not for execution; use /ai-build instead.
- ai-branch-cleanupCleans branches safely: switches to the default branch, prunes merged and squash-merged branches, syncs to remote, sweeps stale specs, rotates `.ai-engineering/runtime/` per retention policy. Trigger for 'tidy up', 'tidy branches', 'sync to main', 'delete old branches', 'start fresh', 'rotate runtime'. Auto-invoked by /ai-pr after merge. Not for committing changes; use /ai-commit instead. Not for code-level dead-code removal; use /ai-simplify instead.
- ai-buildCanonical implementation gateway: reads approved plan.md, resolves stack from manifest, deterministic-routes each task to its adapter, dispatches the build agent in an isolated worktree, runs TDD self-validation per task, then a single final quality loop with one bounded quality-remediation pass on the full changeset before /ai-pr. Trigger for 'go', 'start building', 'execute the plan', 'implement it', 'lets do this', 'build the plan', 'resume', 'continue'. Not without an approved plan; run /ai-plan first. Not for multi-concern specs needing decomposition; use /ai-autopilot instead. Not for a single function or subcomponent; use /ai-code.
- ai-codeWrites production code that satisfies stack-context standards on the first pass: interface-first design, backward-compatibility checks, lightweight self-review. Trigger for 'implement this', 'write the code for', 'add X to Y', 'build this function', 'make this work'. Not for tests; use /ai-test instead. Not for debugging; use /ai-debug instead. Not for refactoring; use /ai-simplify instead. Not for executing an approved plan end-to-end; use /ai-build (the gateway).
- ai-commitRuns the governed commit pipeline: auto-branches from protected, stages selectively, formats and lints, scans for secrets, gates docs, composes a conventional message, pushes. Trigger for 'commit my changes', 'save my work', 'push this to remote', 'stage these files', 'ship it'. Not for opening a PR; use /ai-pr instead. Not for branch hygiene; use /ai-branch-cleanup instead.
- ai-constitutionInterviews the operator to produce a project-identity CONSTITUTION.md (Mission / Stakeholders / Vocabulary / Prohibitions / Compliance gates / Anti-goals / Boundaries / Escalation / Language / Lifecycle phase). Trigger for 'set up the constitution', 'define project identity', 'who is this project for', 'what does this project never do', 'amend the constitution'. Not for AI-behaviour rules — those live in CANONICAL.md / AGENTS.md. Not for spec governance; use /ai-governance instead.