name	update
description	Update an existing .claudeignore file by adding, removing, or revising entries based on current repository state.
argument-hint	Optional — what to add, remove, or change (e.g., "add data/", "remove debug/").
disable-model-invocation	true

Update .claudeignore

Modify an existing .claudeignore file based on the user's request or a fresh analysis of the repository.

Step 1: Read the current file

Read .claudeignore from the project root.

If the file does not exist, tell the user:

"No .claudeignore found in this project. Use claudeignore:create to generate one from scratch."

Do not fall through to creation logic.

Step 2: Determine what changed

There are three update modes:

Mode A: Explicit request

The user asks to add or remove specific entries (e.g., "add data/", "remove debug/", "stop ignoring reports/").

Parse the request into add/remove operations.
Skip the scan — the user knows what they want.

Mode B: Drift check

The user asks to "review" or "refresh" the claudeignore, or simply invokes claudeignore:update without specifics.

Scan the repository (same as create Step 1).
Compare the scan results against the current .claudeignore:
- Missing entries: directories that should be ignored but aren't. Apply the heuristic: large, generated, noisy, secret, or not useful for day-to-day coding decisions → should be ignored.
- Missing secrets: check for .env, .env.*, *.pem, *.key, or credential files that aren't ignored yet.
- Stale entries: directories in .claudeignore that no longer exist in the repo.
- Questionable entries: source directories, manifests (pyproject.toml, package.json), or key docs (README.md, CLAUDE.md) that are being ignored — likely a mistake.
- Over-ignored: files Claude needs to understand the project structure (core config, tooling config) that are currently ignored.
Present findings as a diff.

Mode C: From arguments

If arguments are provided, parse them as directives:

Bare directory names → add them (e.g., update data/ logs/)
Prefixed with - or ! → remove them (e.g., update -debug/ !reports/)
--refresh or --check → trigger drift check (Mode B)

Step 3: Present the changes

Show the user what will change using a before/after or diff format:

Changes to .claudeignore:

+ data/              # add — 450 MB data files, not source code
+ logs/              # add — log output, not useful for context
- debug/             # remove — user wants debug scripts indexed
~ stubs/ → stubs/py  # modify — narrow the scope

Ask:

"Here are the proposed changes. Apply them? (yes / edit / no)"

Step 4: Apply changes

After confirmation:

Read the current .claudeignore content.
Apply the additions, removals, and modifications.
Maintain the category comment structure — add new entries under the appropriate category header, or create a new category if needed.
Remove empty category sections (header with no entries below it).
Write the updated file.

Step 5: Report

After writing, report:

Summary of changes (N added, N removed, N modified)
Any stale entries that were cleaned up
Reminder about on-demand reading of ignored paths

Constraints

Never remove entries without confirmation. Even stale entries might be intentional (anticipating future directories).
Preserve existing comments and structure. Don't reformat the entire file just to add one entry.
Warn on source directory ignores. If the user asks to ignore src/, lib/, tests/, or scripts/, flag it:

"Warning: src/ contains source code. Ignoring it means I won't see your application code. Are you sure?"
Warn on manifest/config ignores. If the user asks to ignore pyproject.toml, package.json, tsconfig.json, or similar, flag it:

"Warning: this is a project manifest. Ignoring it means I won't understand your project's dependencies and tooling. Are you sure?"
Always recommend secrets. During drift checks, if .env, .env.*, *.pem, *.key, or credential files exist and aren't ignored, flag them as recommended additions — defense in depth against sensitive content entering context.
Validate entries exist. When adding directories, check that they actually exist. If they don't, warn the user but still add if they confirm — they may be anticipating future directories.
Read-only on error. If the file can't be parsed or written, report the error and stop. Do not silently create a new file.

Argument handling

Arguments are parsed as directives (see Mode C above). If no arguments are provided and the user's message doesn't specify what to change, default to Mode B (drift check).

Más de este repositorio

mismo repositorio

clean-code

florianbuetow/claude-code

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	update
description	Update an existing .claudeignore file by adding, removing, or revising entries based on current repository state.
argument-hint	Optional — what to add, remove, or change (e.g., "add data/", "remove debug/").
disable-model-invocation	true

Update .claudeignore

Modify an existing .claudeignore file based on the user's request or a fresh analysis of the repository.

Step 1: Read the current file

Read .claudeignore from the project root.

If the file does not exist, tell the user:

"No .claudeignore found in this project. Use claudeignore:create to generate one from scratch."

Do not fall through to creation logic.

Step 2: Determine what changed

There are three update modes:

Mode A: Explicit request

The user asks to add or remove specific entries (e.g., "add data/", "remove debug/", "stop ignoring reports/").

Parse the request into add/remove operations.
Skip the scan — the user knows what they want.

Mode B: Drift check

The user asks to "review" or "refresh" the claudeignore, or simply invokes claudeignore:update without specifics.

Scan the repository (same as create Step 1).
Compare the scan results against the current .claudeignore:
- Missing entries: directories that should be ignored but aren't. Apply the heuristic: large, generated, noisy, secret, or not useful for day-to-day coding decisions → should be ignored.
- Missing secrets: check for .env, .env.*, *.pem, *.key, or credential files that aren't ignored yet.
- Stale entries: directories in .claudeignore that no longer exist in the repo.
- Questionable entries: source directories, manifests (pyproject.toml, package.json), or key docs (README.md, CLAUDE.md) that are being ignored — likely a mistake.
- Over-ignored: files Claude needs to understand the project structure (core config, tooling config) that are currently ignored.
Present findings as a diff.

Mode C: From arguments

If arguments are provided, parse them as directives:

Bare directory names → add them (e.g., update data/ logs/)
Prefixed with - or ! → remove them (e.g., update -debug/ !reports/)
--refresh or --check → trigger drift check (Mode B)

Step 3: Present the changes

Show the user what will change using a before/after or diff format:

Changes to .claudeignore:

+ data/              # add — 450 MB data files, not source code
+ logs/              # add — log output, not useful for context
- debug/             # remove — user wants debug scripts indexed
~ stubs/ → stubs/py  # modify — narrow the scope

Ask:

"Here are the proposed changes. Apply them? (yes / edit / no)"

Step 4: Apply changes

After confirmation:

Read the current .claudeignore content.
Apply the additions, removals, and modifications.
Maintain the category comment structure — add new entries under the appropriate category header, or create a new category if needed.
Remove empty category sections (header with no entries below it).
Write the updated file.

Step 5: Report

After writing, report:

Summary of changes (N added, N removed, N modified)
Any stale entries that were cleaned up
Reminder about on-demand reading of ignored paths

Constraints

Never remove entries without confirmation. Even stale entries might be intentional (anticipating future directories).
Preserve existing comments and structure. Don't reformat the entire file just to add one entry.
Warn on source directory ignores. If the user asks to ignore src/, lib/, tests/, or scripts/, flag it:

"Warning: src/ contains source code. Ignoring it means I won't see your application code. Are you sure?"
Warn on manifest/config ignores. If the user asks to ignore pyproject.toml, package.json, tsconfig.json, or similar, flag it:

"Warning: this is a project manifest. Ignoring it means I won't understand your project's dependencies and tooling. Are you sure?"
Always recommend secrets. During drift checks, if .env, .env.*, *.pem, *.key, or credential files exist and aren't ignored, flag them as recommended additions — defense in depth against sensitive content entering context.
Validate entries exist. When adding directories, check that they actually exist. If they don't, warn the user but still add if they confirm — they may be anticipating future directories.
Read-only on error. If the file can't be parsed or written, report the error and stop. Do not silently create a new file.

Argument handling

Arguments are parsed as directives (see Mode C above). If no arguments are provided and the user's message doesn't specify what to change, default to Mode B (drift check).