Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/shanraisshan/claude-code-best-practice/workflow-claude-settingsgit clone --depth 1 https://github.com/shanraisshan/claude-code-best-practiceWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00011 | $0.03490 |
| Opus 5 | $0.00005 | $0.01745 |
| Sonnet 5 | $0.00002 | $0.00698 |
| Haiku 4.5 | $0.00001 | $0.00349 |
Grade A, and why
workflow-claude-settings scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
Copies of this mod
1 near-identical copy found in the catalogue:
- workflow-claude-settings — 100% identical, 0 lines differ
How it starts
The opening of the file, as written. The whole thing — 244 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Workflow Changelog — Settings Report
You are a coordinator for the claude-code-best-practice project. Your job is to launch two research agents in parallel, wait for their results, merge findings, and present a unified report about drift in the Settings Reference report (best-practice/claude-settings.md).
Versions to check: $ARGUMENTS (default: 10 if empty or not a number)
This is a read-then-report workflow. Launch agents, merge results, and produce a report. Only take action if the user approves.
Phase 0: Launch Both Agents in Parallel
Immediately spawn both agents using the Task tool in the same message (parallel launch):
Agent 1: workflow-claude-settings-agent
Spawn using subagent_type: "workflow-claude-settings-agent". Give it this prompt:
Research the claude-code-best-practice project for settings report drift. Check the last $ARGUMENTS versions (default: 10).
Fetch these 3 external sources:
- Settings Documentation: https://code.claude.com/docs/en/settings
- CLI Reference: https://code.claude.com/docs/en/cli-reference
- Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
Then read the local report file (
best-practice/claude-settings.md) and the CLAUDE.md file. Analyze differences between what the official docs say about settings keys, permission syntax, hook events, MCP configuration, sandbox options, plugin settings, model aliases, display settings, and environment variables versus what our report documents. Return a structured findings report covering missing settings, changed types/defaults, new settings additions, deprecated settings, permission syntax changes, hook event changes, MCP setting changes, sandbox setting changes, environment variable completeness, example accuracy, settings hierarchy accuracy, and sources validity.
Agent 2: claude-code-guide
Spawn using subagent_type: "claude-code-guide". Give it this prompt:
Research the latest Claude Code settings system. I need you to find:
- The complete list of all currently supported settings.json keys with their types, defaults, and descriptions
- Any new settings keys introduced in recent Claude Code versions
- Changes to existing settings behavior (e.g. new permission modes, new hook events, new sandbox options)
- Changes to the settings hierarchy (new priority levels, new file locations)
- Changes to permission syntax (new tool patterns, new wildcard behavior)
- New hook events or changes to hook configuration structure
- Changes to MCP server configuration (new matching fields, new settings)
- Changes to sandbox settings (new network options, new commands)
- Changes to plugin configuration (new fields, new marketplace options)
- Changes to environment variables (new vars, deprecated vars, changed behavior)
- Changes to model aliases or model configuration
- Changes to display/UX settings (status line, spinners, progress bars)
- Any deprecations or removals of settings keys
Be thorough — search the web, fetch docs, and provide concrete version numbers and details for everything you find.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 244 lines · 11 tokens per session scan A 818e5e1661cf
workflow-claude-settings is a command published in the GitHub repository shanraisshan/claude-code-best-practice (65,460 stars, last pushed today), licensed MIT. It adds 11 tokens to every session and 3,490 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
workflow-changelog
Track Claude Code changelog and find what needs updating in this repo.
commit
Commit changes with auto-generated message showing command context, timestamp, and change count.
workflow-add-hook
Add a new Claude Code hook event with sounds, config, settings, scripts, and docs.
release-update
(dev-only) release-update maintainer harness — Claude Code upstream change tracker (release-notes version-delta sweep + docs sync). NOT distributed to user projects.
github
(dev-only) github maintainer harness — GitHub issue-fix and PR-review via gh CLI. NOT distributed to user projects.
harness
Manage harness learning subsystem (status/apply/rollback/disable) OR create a harness via natural-language analysis (Context-First Discovery + name derivation + approval gate).