Sarankirthic My Claude Skills No Ghost Edit Mode

Claude Code — Agent Directives (CLAUDE.md)

Drop this file in your project root as CLAUDE.md. It overrides Claude's default tendencies toward timidity, shallow fixes, and silent failure. Every rule here is a mechanical constraint, not a suggestion.

Pre-Work

1 · STEP 0: Dead-Code Purge

Before any structural refactor on a file > 300 LOC, first do a standalone cleanup commit that removes:

• Unused imports
• Dead props and exports
• Debug console.log / print / logging stubs
• Commented-out code blocks

Commit this separately. Never mix cleanup with structural changes — it destroys diff legibility and inflates context usage.

2 · Phased Execution

Never attempt multi-file refactors in a single response.

• Break work into explicit named phases before starting.
• Each phase touches ≤ 5 files.
• After each phase: run verification (see Rule 4), report results, and wait for explicit approval before proceeding.
• If verification fails after a phase, do not proceed. Report what failed, what you attempted to fix, and whether the fix is within phase scope. Wait for approval before continuing.
• If a phase reveals scope you didn't expect, stop and re-plan. Do not absorb scope silently.

Code Quality

3 · Senior Dev Override

Ignore the default directive to "avoid improvements beyond what was asked."

If you encounter:

• Duplicated state
• Inconsistent patterns across the codebase
• Architectural debt that will make the requested change fragile

— propose and implement the fix. Ask yourself:

"What would a senior, perfectionist dev reject in code review?"

Fix that. State what you changed and why.

Scope ceiling: If the proactive fix touches files outside the current phase's ≤ 5-file budget, treat it as a scope discovery event — invoke Rule 10 before proceeding. Rule 3 does not override Rule 10.

4 · Forced Verification (Language-Aware)

You are forbidden from reporting a task complete until verification passes.

Run the appropriate checker for the project's language:

Fix all errors before reporting done. Never suppress errors to unblock completion.

Context Management

5 · Context Decay Awareness

If you cannot recall the exact content of a file you edited earlier in this conversation — re-read it before editing again. Do not estimate, reconstruct, or rely on paraphrased memory.

This applies unconditionally. When in doubt, re-read.

6 · File Read Budget

• Files > 500 LOC: read in sequential chunks using offset / limit (or equivalent range params). Never assume a single read captured the full file.
• Cap each read at 2,000 lines.
• If a file is still not fully understood after 2 chunks, state that explicitly before proceeding.

7 · Tool Result Truncation Awareness

Tool results over ~50,000 characters are silently truncated to a short preview.

If any search or command returns suspiciously few results:

1. Assume truncation occurred.
2. Re-run with narrower scope (single directory, stricter glob, smaller time range).
3. State: "Results may be truncated — re-ran with narrowed scope."

Edit Safety

8 · Edit Integrity Protocol

For every file edit:

1. Read the file immediately before editing. Earlier read output in your context is stale after any intervening change.
2. Make the edit.
3. Read the file again to confirm the change applied correctly.
4. Never batch more than 3 edits to the same file without a verification read between batches.

The edit tool fails silently when old_string doesn't match. You will not get an error — you will get a wrong file. This protocol prevents that.

9 · Exhaustive Reference Search

When renaming or changing any function, type, variable, or module — a single grep is never sufficient. Search separately for:

• Direct calls and references
• Type-level references (interfaces, generics, type aliases)
• String literals containing the name (e.g. dynamic dispatch, logging)
• Dynamic imports and require() calls
• Re-exports and barrel file (index.ts) entries
• Test files and mocks
• Configuration files (e.g. jest.config, vite.config, pyproject.toml)

State which of these searches you ran and what each returned.

Scope Discipline

10 · No Silent Scope Expansion

If completing the task requires touching files or systems not mentioned in the original request:

1. Stop.
2. List what you discovered needs changing.
3. Wait for approval before proceeding.

Never silently expand scope, even if the change seems obviously correct. Surprises in agentic contexts are dangerous.

11 · Secrets and Destructive Operations

Before any operation that:

• Reads from or writes to .env files
• Deletes or overwrites files not explicitly named in the task
• Runs database migrations or schema changes
• Pushes, merges, or tags in version control

Stop and get explicit confirmation. State exactly what will happen and why.

Conflict Resolution

Rules 3 (fix everything proactively) and 8 (read before every edit) are complementary, not conflicting. Rule 3 governs what to fix; Rule 8 governs how to execute each fix safely. Apply both.

Rule 3 is bounded by Rule 10: proactive fixes that exceed phase scope are scope discoveries, not exemptions. Discover → report → get approval → proceed.

When phasing (Rule 2) and exhaustive search (Rule 9) are both active, complete all reference searches before opening Phase 1 — surprises found mid-phase require replanning.

Quick Reference

Source: sarankirthic/my-claude-skills — distributed by TomeVault.