Don't delete your setup blind. Audit it first.

Audit my Claude Code instruction files. Do not edit anything yet.

Read ./CLAUDE.md, ./.claude/CLAUDE.md, ./CLAUDE.local.md, any CLAUDE.md files in subfolders, ./.claude/rules/, and ~/.claude/CLAUDE.md (skip any that don't exist). Then explore this codebase enough to check every claim in them.

Sort every instruction into one of these groups and show it as a table with the file, the line, the group and a one-line reason:

1. KILL: things you would already do without being told, generic advice ("be careful", "think step by step", "write clean code"), role-play ("you are a senior engineer"), rules written for older models, and anything that references files, commands or tools that no longer exist.
2. CONTRADICTS: pairs of instructions that conflict with each other, across all files.
3. REWRITE: rules that matter but are vague. Give the exact new wording, specific and checkable (for example "Use pnpm, never npm" instead of "use the right package manager").
4. KEEP: things you could not figure out from the code alone, such as build, test and deploy commands, project conventions, and hard safety rules.
5. MISSING: important facts you discovered in the codebase that are not written anywhere, such as the real test command, environment variables, folders that must not be touched, or recurring gotchas.

Then:
- Count the lines before and after, and aim for under 200 lines per file.
- Suggest which rules should move to a path-scoped file in .claude/rules/ because they only matter for part of the codebase.
- Show the proposed new CLAUDE.md in full.

Wait for my approval before changing any file.

Audit my Claude Code skills. Do not edit or delete anything yet.

Read every SKILL.md (and its supporting files) in ./.claude/skills/ and ~/.claude/skills/. Also list any plugin skills that are enabled.

For each skill, report: name, location, what its description says it does, when it would actually trigger, and the last time its files were modified.

Then group them:

1. MERGE: skills that overlap or do nearly the same job (for example deploy, deploy-v2 and deploy-final). Propose one merged skill with a single clear description and combined instructions, and say which originals it replaces.
2. DELETE: skills that are dead. They reference tools, frameworks, files or commands that no longer exist in my projects, they only repeat things the current model already does well without help, or they were one-off experiments.
3. FIX: skills worth keeping whose description is too vague to trigger reliably, or whose instructions are outdated or contradict my CLAUDE.md. Give the new description and the specific edits.
4. KEEP: skills that are specific, still accurate and clearly useful.
5. MISSING: workflows I repeat often in this codebase or in my git history that would deserve a skill. Suggest at most three, each with a name and description.

Finish with a table of every skill and its verdict, plus the exact file operations you would run. Wait for my approval before changing anything.

Audit my Claude Code hooks. Do not edit anything yet.

Read the "hooks" section of ~/.claude/settings.json, ./.claude/settings.json and ./.claude/settings.local.json (skip any that don't exist), plus every script those hooks call.

For each hook, report: the event (PreToolUse, PostToolUse, Stop, SessionStart and so on), the matcher, the command, and what it actually does.

Then check each one and group it:

1. BROKEN: the script or command doesn't exist, isn't executable, depends on a missing tool, has a wrong path, or would fail on this machine. Show the evidence.
2. NOISY or SLOW: runs on every tool call when it only needs to run on some, blocks for a long time, or produces output nobody reads. Suggest a tighter matcher or a better event.
3. RISKY: anything that could push, delete, deploy or leak secrets without me noticing.
4. DUPLICATE or CONFLICTING: hooks across user and project settings that do the same thing or fight each other.
5. KEEP: hooks that are working and earning their place.
6. MISSING: hooks I should build, based on this codebase and the mistakes that keep happening. Examples are blocking edits to protected files, running the formatter after edits, or running tests before Claude says it is done. Suggest at most three, with the exact JSON and script for each.

Finish with the full proposed "hooks" JSON for each settings file. Wait for my approval before changing anything.