Claude Settings Audit

Claude Settings Audit

Selective Reading Rule

Start with:

• references/senior-master-standard.md
• references/usage-routing.md
• references/quality-checklist.md

Then load only the inherited docs, scripts, assets, or examples that match the user's actual task.

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.

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:

Phase 2: Detect Services

Check for service integrations:

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:

Baseline Commands (Always Include)

[
  "Bash(ls:*)",
  "Bash(pwd:*)",
  "Bash(find:*)",
  "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:*)",
  "Bash(git remote:*)",
  "Bash(git tag:*)",
  "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 api:*)"
]

Stack-Specific Commands

Only include commands for tools actually detected in the project.

Python (if any Python files or config detected)

Node.js (if package.json detected)

Other Languages

Build Tools

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

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: Never suggest GitHub MCP. Always use gh CLI commands for GitHub.

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": [
// ... grouped by category with comments
],
"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 allows any arguments to the base command

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 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.