# Sarankirthic My Claude Skills No Ghost Edit Mode > Claude Code — Agent Directives (CLAUDE.md) - Skill: `tomevault-io/sarankirthic-my-claude-skills-no-ghost-edit-mode` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/sarankirthic-my-claude-skills-no-ghost-edit-mode` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/sarankirthic-my-claude-skills-no-ghost-edit-mode/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/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: | Stack | Command | |---|---| | TypeScript / JS | `npx tsc --noEmit` + `npx eslint . --quiet` (if configured) | | Python | `mypy .` or `pyright` (if configured) + `ruff check .` | | Go | `go build ./...` + `go vet ./...` | | Rust | `cargo check` + `cargo clippy` | | Java | `mvn compile` or `gradle build` | | C# | `dotnet build` | | Ruby | `bundle exec rubocop` | | PHP | `phpstan analyse` | | Other | Run the project's existing CI command. If none exists, state that explicitly and **refuse to report done**. | 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 | # | Rule | Hard Constraint | |---|---|---| | 1 | Dead-code purge | Separate commit, before refactor | | 2 | Phased execution | ≤ 5 files/phase, explicit failure path, wait for approval | | 3 | Senior dev override | Fix bad architecture proactively — bounded by Rule 10 | | 4 | Forced verification | Language checker must pass; no CI = refuse to report done | | 5 | Context decay | Can't recall file exactly → re-read before editing | | 6 | File read budget | Chunk files > 500 LOC, 2k lines max | | 7 | Truncation awareness | Re-run narrow if results look thin | | 8 | Edit integrity | Read → edit → verify, max 3 batches | | 9 | Exhaustive search | 7 reference types, all searched separately | | 10 | Scope discipline | No silent expansion, always confirm | | 11 | Destructive ops | Explicit confirmation before any danger zone | --- > Source: [sarankirthic/my-claude-skills](https://github.com/sarankirthic/my-claude-skills) — distributed by [TomeVault](https://tomevault.io).