audit-agent-settings
Skill142 starsChanged 22 days agoMITView on GitHub
Use when auditing Claude Code or Codex settings and env vars against the latest docs to suggest tailored changes
In this repository14 other files it gives its agents.
- AGENTS.mdAGENTS.md
- publish-pluginsSkill
- upgrade-playbooksSkill
- best-practicesSkill
- blindspotSkill
- commitSkill
- differenceSkill
- fuck-over-engineeringSkill
- prSkill
- refactor-agents-mdSkill
- refactor-memorySkill
- refactor-skillSkill
- simple-englishSkill
- write-like-meSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 10
Use AskUserQuestion in Claude Code or request_user_input in Codex when available.
- Distinctive: line 14
Use targets already specified by the user.
- Distinctive: line 25
Follow the reference's notes on how keys and variables are laid out in those files, and grep them for the full lists.
- Distinctive: line 29
Read every config scope the reference lists, where it exists.
- Distinctive: line 31
Read the platform's instruction files, rules, and memory the reference lists.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Audit Agent Settings
Scan the platform's docs exhaustively, cross-reference them against the user's real config, deliver a ranked report, and apply what the user picks. Tie every suggestion to a named user fact — tailored, not generic.
Use AskUserQuestion in Claude Code or request_user_input in Codex when available. Use plain text when the tool is unavailable.
1. Pick the targets
Use targets already specified by the user. Otherwise, offer the existing targets with this session's platform first: Claude Code settings, Codex config, or both. Read one reference per target:
- references/claude-code.md for Claude Code's docs mirrors, settings scopes, validator, dead-key probe, and gotchas.
- references/codex.md for the same on Codex.
Done when every target has its reference loaded.
2. Fetch ground truth
Curl each raw markdown mirror the reference lists into <scratchpad>. <scratchpad> is your session's scratchpad directory, or /tmp when the harness provides none. -f makes a missing page a failed command instead of a silently saved 404 body. These files are the only acceptable source for the scan; the reference's installed-CLI probes verify behavior, they do not replace the files.
Follow the reference's notes on how keys and variables are laid out in those files, and grep them for the full lists. Read the full entry of every key the user sets, since the entries carry the defaults, deprecations, and precedence the index omits.
3. Collect the user's real config
Read every config scope the reference lists, where it exists. When a dotfiles repo is the source of truth, read the repo copy and run git diff on it — uncommitted drift matters in step 6.
Read the platform's instruction files, rules, and memory the reference lists. These carry the workflow signals that make suggestions tailored: plugins, hooks, shell aliases, permission style, model choice, terminal, background-agent habits.
Done when you hold one list of every key and env var the user sets, plus a short profile of how they work.
4. Cross-reference
Two passes, both exhaustive:
- Validate (set → docs). Check every user key against the fetched files. Treat absent, removed, deprecated, or no-effect keys as candidates for the reference's dead-key probe; confirm their installed behavior before proposing removal or migration. Named a live legacy alias → propose the migration. Default or semantics changed → flag it. No key skipped.
- Discover (docs → unset). Walk every documented key and variable once, applying the reference's scope restrictions and skipping administrator-only settings unless the user manages that scope. Keep a candidate only when a specific user fact argues for it, and name that fact in the item.
5. Report
Open with problems in the current config, ranked by impact. Then grouped suggestions: security, workflow, small ideas. Close with leave-alone items — attractive switches that break something the user relies on (the reference has an example).
Each item carries the key, what it does in one line, and the user fact that makes it relevant.
6. Apply
Apply picks already authorized by the user; otherwise, collect picks grouped like the report using the selection method above. Before editing a tracked settings file with uncommitted changes, distinguish user-authored edits from CLI-written changes, following the reference's drift guidance where provided. Commit only identified user-authored edits first as their own commit, honoring explicit commit exclusions; leave automatic or uncertain changes uncommitted.
Apply the picks and validate with the reference's validator after edits. Say which picks land later, per the reference.
Gotchas
- WebFetch and similar fetch tools answer through a separate model call, not the raw page, and read a long page 100,000 characters per call. The scan greps every key and reads whole entries, which needs the raw text in a file, and a "continue the list" prompt has fabricated plausible keys (observed:
rubyCrimsionPath). Fetch the raw markdown mirror with curl and read it yourself. - Undocumented is not the same as dead. A key can live on a different docs page than the fetched files. Grep all the fetched files, then check the platform's other docs pages the reference points to and run its dead-key probe before you call a key dead.
- Docs churn fast. Results from a previous audit go stale; fetch fresh files every run, and treat remembered page content as expired.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

