This skill should be used when the user asks to "check clean code", "review code cleanliness", "find code smells", "is this function too long", "are these names clear", "review my error handling", "check my tests", or "clean up this code". Also triggers when the user mentions Clean Code, Uncle Bob, Robert Martin, meaningful names, function length, comment rot, F.I.R.S.T. tests, or names a dimension directly ("naming", "boundaries", "concurrency"). Supports auditing all nine dimensions at once or focusing on a single dimension.

2026-07-2312

agent-guardrails-analyze

florianbuetow/claude-code

Scan Claude Code chat session logs for recurring agent anti-patterns (hedging, stalling, skipping, false completions, preference-asking, dismissing, cosmetic, caveats, flagging) and produce a ranked report with frequency counts, example excerpts, and suggested guardrail rules. Use when user asks to "analyze sessions for anti-patterns", "find bad patterns in logs", "what anti-patterns am I seeing", "agent-guardrails analyze", or wants data-driven guardrail recommendations.

2026-07-1912

agent-guardrails-install

florianbuetow/claude-code

Install agent behavioral guardrail rules into a project's .claude/ directory. Generates a Stop hook bash script and configures settings.local.json. Includes nine battle-tested rules (no-guessing, no-stalling, no-preference-asking, no-false-completion, no-skipping, no-dismissing, no-cosmetic, no-caveats, no-flagging). Use when user asks to "install guardrails", "set up agent guardrails", "add behavioral hooks", "agent-guardrails install", or wants to enforce assistant discipline.

2026-07-1912

agent-guardrails-test

florianbuetow/claude-code

Test installed agent guardrail hooks by sending trigger phrases through the stop hook script. Checks hook installation first, then runs two test phrases per rule. Use when user asks to "test guardrails", "verify hooks", "check guardrail patterns", "agent-guardrails test", or wants to confirm hooks are working.

2026-07-1912

agent-guardrails-update

florianbuetow/claude-code

Re-analyze Claude Code session logs against existing agent guardrail rules to measure effectiveness, catch false positives, identify missed anti-patterns, and refine regex patterns. Use when user asks to "update guardrails", "refine guardrail rules", "check guardrail effectiveness", "agent-guardrails update", "tune guardrails", or wants to improve existing behavioral rules based on real usage data.

2026-07-1912

product-spec

florianbuetow/claude-code

Use when the user wants to write a "product spec" or "product specification", frame a "product bet", or define a falsifiable hypothesis before building. Also triggers on "replace the PRD", "retire the PRD", "the PRD is too long / too vague", "tighten this spec for an engineer or agent", "what's the bet", "what problem are we solving", "acceptance criteria", "success criteria", "kill / scale / graduate thresholds", "measurement plan", or when scoping a feature's problem, bet, success behaviors, and evaluation before any behavioral spec. Part of the spec-dd workflow; precedes /spec-dd:spec.

2026-06-2912

name	create
description	Analyze a repository and generate a new .claudeignore file that excludes directories and files wasting context tokens.
argument-hint	Optional — specific directories or patterns to include.
disable-model-invocation	true

Create .claudeignore

Analyze the repository structure and generate a .claudeignore file that excludes directories and files which waste context tokens without providing useful source code.

Step 1: Scan the repository

Run these commands to understand the project structure:

List all top-level directories:
```
find . -maxdepth 1 -type d | sort
```
Measure directory sizes to identify large non-source content:
```
du -sh */ .*/ 2>/dev/null | sort -rh | head -30
```
Detect the project type from manifest files:
- Python: pyproject.toml, setup.py, requirements.txt
- Node/JS: package.json
- Rust: Cargo.toml
- Go: go.mod
- Java/Kotlin: pom.xml, build.gradle
- Ruby: Gemfile
- Mixed: multiple of the above
Check what .gitignore already excludes (for reference, not copying):
```
cat .gitignore 2>/dev/null
```

Step 2: Classify directories and files

Apply this heuristic to every entry: "Would I ever want Claude to edit or inspect this for normal coding tasks?" If no, it belongs in .claudeignore.

Things that are large, generated, noisy, secret, or not useful for day-to-day coding decisions should be ignored. Source code, key configs, and docs should stay visible.

Start from .gitignore as a baseline, then:

Remove anything Claude still needs for reasoning (manifests, core config, docs).
Add anything generated or irrelevant to code changes that .gitignore keeps (e.g., data/, notebooks/, large media).

Sort entries into these categories:

Always ignore (caches, build artifacts, dependencies)

These never contain useful source code for Claude:

Pattern	Ecosystem	Why
`.venv/`, `venv/`, `env/`	Python	Virtual environment packages
`node_modules/`	Node.js	npm/yarn packages
`__pycache__/`	Python	Bytecode cache
`*.pyc`	Python	Compiled bytecode files
`.mypy_cache/`	Python	Type checker cache
`.ruff_cache/`	Python	Linter cache
`.pytest_cache/`	Python	Test runner cache
`.cache/`	General	Generic caches
`target/`	Rust/Java	Build artifacts
`build/`, `dist/`	General	Build output
`.gradle/`	Java/Kotlin	Gradle cache
`.next/`	Next.js	Build output
`.nuxt/`	Nuxt.js	Build output
`.turbo/`	Turborepo	Build cache
`vendor/`	Go/PHP	Vendored dependencies
`coverage/`, `htmlcov/`	General	Coverage reports
`.tox/`, `.nox/`	Python	Test environment tools
`.cargo/`	Rust	Cargo cache

Always ignore (secrets and credentials)

These reduce the chance sensitive content enters context:

Pattern	Why
`.env`	Environment secrets
`.env.*`	Per-environment secrets
`.pem`, `.key`	Private certificates and keys
`*-credentials.json`	Service account credentials
`.secrets/`	Secret stores

Always ignore (tool/IDE config)

Pattern	Why
`.cursor/`	Cursor IDE state
`.idea/`	JetBrains IDE config
`.vscode/`	VS Code config (unless project-shared)
`.playwright-mcp/`	Playwright MCP temp files
`.dolt/`, `.doltcfg/`	Dolt/beads database internals

Always ignore (logs and noise)

Pattern	Why
`*.log`	Log files
`logs/`	Log directories
`.sqlite`, `.db`	Local databases

Ignore if large (> 1 MB) and not source code

Review these on a case-by-case basis:

notebooks/ — Jupyter notebooks with embedded outputs
reports/ — Generated analysis reports
docs/ — If dominated by generated API docs or large assets
stubs/ — Type stubs
debug/ — Ephemeral diagnostic scripts
data/, datasets/ — Data files (unless small config/fixture data)
assets/, static/, public/ — Media and static files
fixtures/ — Test fixtures if large

Never ignore (source code and key files — keep readable)

src/, lib/, app/ — Application source
tests/, test/, spec/ — Test source
scripts/ — Build/utility scripts
config/ — Configuration files
prompts/ — Prompt templates
tools/ — Developer tools
frontend/ — Frontend source (but ignore frontend/node_modules/)
README.md, CLAUDE.md, AGENTS.md — Project documentation
pyproject.toml, package.json, Cargo.toml, go.mod — Manifests
tsconfig.json, eslint.config.* — Core tooling config

Over-ignoring these makes Claude guess incorrectly about app structure and tooling.

Step 3: Present the plan

Show the user a table of what will be ignored and why:

| Directory | Size | Category | Reason |
|-----------|------|----------|--------|
| .venv/ | 1.7 GB | dependency cache | Python packages |
| ...       | ...  | ...      | ...    |

Also note any borderline decisions where the user might disagree.

Ask:

"Here's what I'd ignore. Want me to add or remove anything before I write the file?"

Step 4: Write the file

After confirmation, write .claudeignore in the project root.

Group entries by category with comment headers. Use trailing slashes for directories. Example:

# Python caches
.venv/
__pycache__/
.mypy_cache/
.ruff_cache/
.pytest_cache/

# Build artifacts
build/
dist/

# IDE/tool config
.cursor/
.idea/

# Large non-source directories
notebooks/
data/

Step 5: Report

After writing, report:

Number of entries added
Estimated context savings (rough, based on directory sizes)
Reminder that specific files from ignored directories can still be read on demand via explicit path

Constraints

Never ignore source code directories (src/, lib/, tests/, scripts/, etc.) unless the user explicitly asks.
Never silently ignore config/ — it almost always contains important configuration.
Never ignore project manifests (pyproject.toml, package.json, Cargo.toml, go.mod, tsconfig.json) — Claude needs these to understand the project stack.
Never ignore README.md or CLAUDE.md — these orient Claude.
Always include secrets. .env, .env.*, private keys, and credential files should always be in .claudeignore, even if not in .gitignore — defense in depth against leaking into context.
Present the plan before writing. Do not write without user confirmation.
Use .gitignore as starting point, not as copy source. .claudeignore serves a different purpose — .gitignore excludes from version control, .claudeignore excludes from AI context. They often overlap but are not the same. Start from .gitignore, remove what Claude needs, add what Claude doesn't.
Prefer directories over globs. node_modules/ is better than **/node_modules/** for readability.

Argument handling

If the user passes arguments (e.g., create data/ logs/), treat them as additional directories to include in the ignore list. Still run the full scan — the arguments are additions, not the complete list.