mcpField
C
claude-settings-audit

claude-settings-audit

github.com/sickn33Agent workflows48.8k76 installsUpdated today
Repository

About claude-settings-audit

A Claude Code skill that inspects a repository and proposes evidence-based read-only permissions for `settings.json`. It emphasizes narrow command rules, preserving existing restrictions, and presenting changes for review rather than installing them.

Key features

  1. 01Detects repository stacks and services
  2. 02Reviews existing Claude settings
  3. 03Recommends narrowly scoped read-only permissions
  4. 04Suggests MCP configuration when relevant
  5. 05Preserves deny and ask rules
  6. 06Redacts secret values

Use cases

  1. 01Auditing a repository’s Claude Code permissions
  2. 02Creating a read-only command allowlist
  3. 03Reviewing permissions for a detected tech stack

MCP support

The skill can suggest Sentry or Linear MCP server configuration when the repository indicates those services. MCP configuration belongs in `.mcp.json`, separate from `settings.json`.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill claude-settings-audit

After installing, type/claude-settings-auditin Claude Code to confirm it loaded.

Details

From the project README

Claude Settings Audit

Analyze this repository and generate recommended Claude Code settings.json permissions for read-only commands.

When to Use

  • You are setting up or auditing Claude Code settings.json permissions for a repository.
  • You need to infer a safe read-only allow list from the repo's tech stack, tooling, and monorepo structure.
  • You want to review or replace an existing Claude permissions baseline with something evidence-based.

The broad prefixes in legacy examples are not a read-only sandbox: find can execute/delete, gh api can POST/PATCH/DELETE, and git branch/remote/tag have mutating forms. Recommend narrow reviewed commands or purpose-built read tools; never auto-allow arbitrary arguments merely because a command is usually observational. Build tools (make -n, Gradle, Maven, package managers) may evaluate project code or download/write caches. Redact settings/MCP secret values before displaying them, preserve existing deny/ask rules, and produce a proposal rather than silently installing permissions or servers. Skill invocation permissions can authorize mutating workflows and are not read-only by name.

Phase 1: Detect Tech Stack

Run these commands to detect the repository structure:

ls -la
find . -maxdepth 2 \( -name "*.toml" -o -name "*.json" -o -name "*.lock" -o -name "*.yaml" -o -name "*.yml" -o -name "Makefile" -o -name "Dockerfile" -o -name "*.tf" \) 2>/dev/null | head -50

Check for these indicator files:

CategoryFiles to Check
Pythonpyproject.toml, setup.py, requirements.txt, Pipfile, poetry.lock, uv.lock
Node.jspackage.json, package-lock.json, yarn.lock, pnpm-lock.yaml
Gogo.mod, go.sum
RustCargo.toml, Cargo.lock
RubyGemfile, Gemfile.lock
Javapom.xml, build.gradle, build.gradle.kts
BuildMakefile, Dockerfile, docker-compose.yml
Infra*.tf files, kubernetes/, helm/
Monorepolerna.json, nx.json, turbo.json, pnpm-workspace.yaml

Phase 2: Detect Services

Check for service integrations:

ServiceDetection
Sentrysentry-sdk in deps, @sentry/* packages, .sentryclirc, sentry.properties
LinearLinear config files, .linear/ directory

Read dependency files to identify frameworks:

  • package.json → check dependencies and devDependencies
  • pyproject.toml → check [project.dependencies] or [tool.poetry.dependencies]
  • Gemfile → check gem names
  • Cargo.toml → check [dependencies]

Phase 3: Check Existing Settings

cat .claude/settings.json 2>/dev/null || echo "No existing settings"

Phase 4: Generate Recommendations

Build the allow list by combining:

Candidate Baseline (Review Each Permission)
[
  "Bash(ls:*)",
  "Bash(pwd:*)",
  "Bash(file:*)",
  "Bash(stat:*)",
  "Bash(wc:*)",
  "Bash(head:*)",
  "Bash(tail:*)",
  "Bash(cat:*)",
  "Bash(tree:*)",
  "Bash(git status:*)",
  "Bash(git log:*)",
  "Bash(git diff:*)",
  "Bash(git show:*)",
  "Bash(git branch --list)",
  "Bash(git remote -v)",
  "Bash(git tag --list)",
  "Bash(git stash list:*)",
  "Bash(git rev-parse:*)",
  "Bash(gh pr view:*)",
  "Bash(gh pr list:*)",
  "Bash(gh pr checks:*)",
  "Bash(gh pr diff:*)",
  "Bash(gh issue view:*)",
  "Bash(gh issue list:*)",
  "Bash(gh run view:*)",
  "Bash(gh run list:*)",
  "Bash(gh run logs:*)",
  "Bash(gh repo view:*)",
  "Bash(gh repo view --json nameWithOwner)"
]
Stack-Specific Commands

Only include commands for tools actually detected in the project.

Python (if any Python files or config detected)
If DetectedAdd These Commands
Any Pythonpython --version, python3 --version
poetry.lockpoetry show, poetry env info
uv.lockuv pip list, uv tree
Pipfile.lockpipenv graph
requirements.txt (no other lock)pip list, pip show, pip freeze
Node.js (if package.json detected)
If DetectedAdd These Commands
Any Node.jsnode --version
pnpm-lock.yamlpnpm list, pnpm why
yarn.lockyarn list, yarn info, yarn why
package-lock.jsonnpm list, npm view, npm outdated
TypeScript (tsconfig.json)tsc --version
Other Languages
If DetectedAdd These Commands
go.modgo version, go list, go mod graph, go env
Cargo.tomlrustc --version, cargo --version, cargo tree, cargo metadata
Gemfileruby --version, bundle list, bundle show
pom.xmljava --version, mvn --version, mvn dependency:tree
build.gradlejava --version, gradle --version, gradle dependencies
Build Tools
If DetectedAdd These Commands
Dockerfiledocker --version, docker ps, docker images
docker-compose.ymldocker-compose ps, docker-compose config
*.tf filesterraform --version, terraform providers, terraform state list
Makefilemake --version, make -n
Skills (for Sentry Projects)

If this is a Sentry project (or sentry-skills plugin is installed), include:

[
  "Skill(sentry-skills:agents-md)",
  "Skill(sentry-skills:blog-writing-guide)",
  "Skill(sentry-skills:brand-guidelines)",
  "Skill(sentry-skills:claude-settings-audit)",
  "Skill(sentry-skills:code-review)",
  "Skill(sentry-skills:code-simplifier)",
  "Skill(sentry-skills:commit)",
  "Skill(sentry-skills:create-branch)",
  "Skill(sentry-skills:create-pr)",
  "Skill(sentry-skills:django-access-review)",
  "Skill(sentry-skills:django-perf-review)",
  "Skill(sentry-skills:doc-coauthoring)",
  "Skill(sentry-skills:find-bugs)",
  "Skill(sentry-skills:gh-review-requests)",
  "Skill(sentry-skills:gha-security-review)",
  "Skill(sentry-skills:iterate-pr)",
  "Skill(sentry-skills:pr-writer)",
  "Skill(sentry-skills:security-review)",
  "Skill(sentry-skills:skill-creator)",
  "Skill(sentry-skills:skill-scanner)",
  "Skill(sentry-skills:skill-writer)",
  "Skill(sentry-skills:sred-project-organizer)",
  "Skill(sentry-skills:sred-work-summary)"
]
WebFetch Domains
Always Include (Sentry Projects)
[
  "WebFetch(domain:docs.sentry.io)",
  "WebFetch(domain:develop.sentry.dev)",
  "WebFetch(domain:docs.github.com)",
  "WebFetch(domain:cli.github.com)"
]
Framework-Specific
If DetectedAdd Domains
Djangodocs.djangoproject.com
Flaskflask.palletsprojects.com
FastAPIfastapi.tiangolo.com
Reactreact.dev
Next.jsnextjs.org
Vuevuejs.org
Expressexpressjs.com
Railsguides.rubyonrails.org, api.rubyonrails.org
Gopkg.go.dev
Rustdocs.rs, doc.rust-lang.org
Dockerdocs.docker.com
Kuberneteskubernetes.io
Terraformregistry.terraform.io
MCP Server Suggestions

MCP servers are configured in .mcp.json (not settings.json). Check for existing config:

cat .mcp.json 2>/dev/null || echo "No existing .mcp.json"
Sentry MCP (if Sentry SDK detected)

Add to .mcp.json (replace {org-slug} and {project-slug} with your Sentry organization and project slugs):

{
  "mcpServers": {
    "sentry": {
      "type": "http",
      "url": "https://mcp.sentry.dev/mcp/{org-slug}/{project-slug}"
    }
  }
}
Linear MCP (if Linear usage detected)

Add to .mcp.json:

{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": ["-y", "@linear/mcp-server"],
      "env": {
        "LINEAR_API_KEY": "${LINEAR_API_KEY}"
      }
    }
  }
}

Note: Use the client’s approved GitHub connector or narrowly scoped CLI commands according to user preference.

Output Format

Present your findings as:

  1. Summary Table - What was detected
  2. Recommended settings.json - Complete JSON ready to copy
  3. MCP Suggestions - If applicable
  4. Merge Instructions - If existing settings found

Example output structure:

## Detected Tech Stack

| Category        | Found          |
| --------------- | -------------- |
| Languages       | Python 3.x     |
| Package Manager | poetry         |
| Frameworks      | Django, Celery |
| Services        | Sentry         |
| Build Tools     | Docker, Make   |

## Recommended .claude/settings.json

\`\`\`json
{
"permissions": {
"allow": [
"Bash(pwd)"
],
"deny": []
}
}
\`\`\`

## Recommended .mcp.json (if applicable)

If you use Sentry or Linear, add the MCP config to `.mcp.json`...

Important Rules

What to Include
  • Only READ-ONLY commands that cannot modify state
  • Only tools that are actually used by the project (detected via lock files)
  • Standard system commands (ls, cat, find, etc.)
  • The :* suffix is broad; verify current host matching semantics and all allowed argument effects
What to NEVER Include
  • Absolute paths - Never include user-specific paths like /home/user/scripts/foo or /Users/name/bin/bar
  • Custom scripts - Never include project scripts that may have side effects (e.g., ./scripts/deploy.sh)
  • Alternative package managers - If the project uses pnpm, do NOT include npm/yarn commands
  • Commands that modify state - No install, build, run, write, or delete commands
Package Manager Rules

Only include the package manager actually used by the project:

If DetectedIncludeDo NOT Include
pnpm-lock.yamlpnpm commandsnpm, yarn
yarn.lockyarn commandsnpm, pnpm
package-lock.jsonnpm commandsyarn, pnpm
poetry.lockpoetry commandspip (unless also has requirements.txt)
uv.lockuv commandspip, poetry
Pipfile.lockpipenv commandspip, poetry

If multiple lock files exist, include only the commands for each detected manager.

Limitations

  • Use this skill only when the task clearly matches the scope described above.
  • Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
  • Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

Comments

Markdown supported