원클릭으로
create
Analyze a repository and generate a new .claudeignore file that excludes directories and files wasting context tokens.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Analyze a repository and generate a new .claudeignore file that excludes directories and files wasting context tokens.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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.
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.
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.
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.
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.
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.
| 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 |
Analyze the repository structure and generate a .claudeignore file that
excludes directories and files which waste context tokens without
providing useful source code.
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:
pyproject.toml, setup.py, requirements.txtpackage.jsonCargo.tomlgo.modpom.xml, build.gradleGemfileCheck what .gitignore already excludes (for reference, not copying):
cat .gitignore 2>/dev/null
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:
.gitignore keeps (e.g., data/, notebooks/, large media).Sort entries into these categories:
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 |
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 |
| 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 |
| Pattern | Why |
|---|---|
*.log | Log files |
logs/ | Log directories |
*.sqlite, *.db | Local databases |
Review these on a case-by-case basis:
notebooks/ — Jupyter notebooks with embedded outputsreports/ — Generated analysis reportsdocs/ — If dominated by generated API docs or large assetsstubs/ — Type stubsdebug/ — Ephemeral diagnostic scriptsdata/, datasets/ — Data files (unless small config/fixture data)assets/, static/, public/ — Media and static filesfixtures/ — Test fixtures if largesrc/, lib/, app/ — Application sourcetests/, test/, spec/ — Test sourcescripts/ — Build/utility scriptsconfig/ — Configuration filesprompts/ — Prompt templatestools/ — Developer toolsfrontend/ — Frontend source (but ignore frontend/node_modules/)README.md, CLAUDE.md, AGENTS.md — Project documentationpyproject.toml, package.json, Cargo.toml, go.mod — Manifeststsconfig.json, eslint.config.* — Core tooling configOver-ignoring these makes Claude guess incorrectly about app structure and tooling.
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?"
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/
After writing, report:
src/, lib/, tests/,
scripts/, etc.) unless the user explicitly asks.config/ — it almost always contains
important configuration.pyproject.toml, package.json,
Cargo.toml, go.mod, tsconfig.json) — Claude needs these to
understand the project stack.README.md or CLAUDE.md — these orient Claude..env, .env.*, private keys, and
credential files should always be in .claudeignore, even if not
in .gitignore — defense in depth against leaking into context..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.node_modules/ is better than
**/node_modules/** for readability.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.