Axiomantic Spellbook Finding Dead Code

You never assume code is used because it "looks important." You never skip verification because "it seems needed." Professional reputation depends on accurate verdicts backed by concrete evidence. Are you sure this is all used?

Operate with skepticism: all code is dead until proven alive.

You MUST:

1. Check git safety FIRST (Phase 0) - status, offer commit, offer worktree isolation
2. Ask user to select scope before extracting items
3. Present ALL extracted items before verification begins
4. Verify each item by searching for callers with concrete evidence
5. Detect write-only dead code (setters called but getters never called)
6. Identify transitive dead code (used only by other dead code)
7. Offer "remove and test" verification for high-confidence dead code
8. Re-scan iteratively after identifying dead code to find newly orphaned code
9. Generate report that doubles as removal implementation plan
10. Ask user if they want to implement removals

NEVER mark code as "used" without concrete evidence of callers. This is very important to my career.

Invariant Principles

1. Dead Until Proven Alive - Every code item assumes dead status. Evidence of live callers required. No assumptions based on appearance.
2. Full-Graph Verification - Search entire codebase for each item. Check transitive callers. Re-scan after removals until fixed-point.
3. Data Flow Completeness - Track write->read pairs. Setter without getter = write-only dead. Iterator without consumer = dead storage.
4. Git Safety First - Check status, offer commit, offer worktree BEFORE any analysis or deletion. Never modify without explicit approval.
5. Evidence Over Confidence - Never claim test results without running tests. Never claim "unused" without grep proof. Paste actual output.

Inputs

Outputs

BEFORE_RESPONDING Checklist

Step 0: Have I completed Phase 0 (Git Safety) via /dead-code-setup? If not, run it now.

• Did I check git status --porcelain?
• Did I offer to commit uncommitted changes?
• Did I offer worktree isolation (ALWAYS, even if no uncommitted changes)?

Step 1: What phase am I in? (setup=Phase 0-1, analyze=Phase 2-5, report=Phase 6, implement=Phase 7)

Step 2: For verification - what EXACTLY am I checking usage of?

Step 3: What evidence would PROVE this item is used?

Step 4: What evidence would PROVE this item is dead?

Step 5: Could this be write-only dead code (setter called but getter never used)?

Step 6: Could this be transitive dead code (only used by dead code)?

Step 7: Have I checked ALL files for callers, not just nearby files?

Step 8: If claiming test results, have I ACTUALLY run the tests?

Step 9: If about to delete code, am I in a worktree or did I get explicit user permission?

Now proceed with confidence following this checklist.

Workflow Execution

This skill orchestrates dead code analysis through 4 sequential commands.

Command Sequence

Execution Protocol

1. Setup: Run /dead-code-setup for git safety and scope
2. Analyze: Run /dead-code-analyze to find dead code
3. Report: Run /dead-code-report to document findings
4. Implement: Run /dead-code-implement to apply deletions (optional)

Standalone Usage

Each sub-command can be run independently:

• /dead-code-setup - Just prepare environment
• /dead-code-analyze - Re-analyze after changes
• /dead-code-report - Regenerate report
• /dead-code-implement - Apply from existing report

Detection Patterns (Shared Reference)

Pattern 1: Asymmetric Symmetric API

IF getFoo exists AND setFoo exists AND clearFoo exists:
  Check usage of each independently
  IF any has zero callers -> flag as dead
  EVEN IF others in group are used

Pattern 2: Convenience Wrapper

IF proc foo() only calls bar() with minor transform:
  Check if foo has callers
  IF zero callers -> dead wrapper
  EVEN IF bar() is heavily used

Pattern 3: Transitive Dead Code

WHILE changes detected:
  FOR each item with callers:
    IF ALL callers are marked dead:
      Mark item as transitive dead

NOTE: "Has callers" is not sufficient for alive status. Callers must themselves be alive. Direct caller check and transitive check are separate steps.

Pattern 4: Field + Accessors

IF field X detected:
  Search for getter getX or X
  Search for setter setX or `X=`
  IF all three have zero usage -> dead feature

Pattern 5: Test-Only Usage

IF all callers are in test files:
  ASK user if test-only code should be kept
  Don't auto-mark as dead

Pattern 6: Write-Only Dead Code

FOR each setter/store S with corresponding getter/read G:
  IF S has callers AND G has zero callers:
    Mark BOTH S and G as write-only dead
    Mark data is "stored but never read"

Pattern 7: Iterator Without Consumers

IF iterator I defined:
  Search for "for .* in I" or "items(I)" patterns
  IF zero consumers found:
    Mark iterator as dead
    Check if backing storage is also write-only dead

Pattern 2: Incomplete Search

• Only searching nearby files
• Only searching same directory
• Not checking test directories
• Not checking if it's exported Reality: Search the ENTIRE codebase, including tests.

Pattern 3: Ignoring Transitive Dead Code

• Marking code as "used" because something calls it, without checking if the caller is itself dead
• Stopping after first-level verification Reality: Build the call graph, check transitivity. A live caller chain must terminate in code with external callers, not other dead code.

Pattern 4: Deleting Without User Approval

• Auto-removing code without showing the plan
• Batch-deleting without per-item verification
• Not offering user choice in implementation Reality: Present report, get approval, then implement.

Pattern 5: Claiming Test Results Without Running Tests

• Stating "tests fail" without actually running the test command
• Claiming code "doesn't work" without execution evidence
• Saying "tests pass" after removal without running them Reality: Run the actual command. Paste the actual output.

Pattern 6: Missing Write-Only Dead Code

• Only checking if code is called, not if stored data is read
• Not verifying iterator/getter counterparts exist for setter/store
• Assuming "something calls it" means "code is used" Reality: Check the full data flow. Code that stores without reading is dead.

Pattern 7: Single-Pass Verification

• Marking code as "alive" or "dead" in one pass
• Not re-scanning after identifying dead code
• Missing cascade effects where removal orphans other code Reality: Re-scan iteratively until no new dead code found.

Pattern 8: Deleting Code Without Git Safety

• Running "remove and test" without checking git status first
• Deleting code without worktree isolation
• Not offering to commit uncommitted changes
• Skipping worktree recommendation Reality: ALWAYS check git status in Phase 0. ALWAYS offer worktree isolation.

Self-Check

Git Safety (/dead-code-setup):

• Did I check git status before starting?
• Did I offer worktree isolation?
• Did I ask user to select scope?

Analysis (/dead-code-analyze):

• Did I present ALL extracted items for triage?
• For each item: did I search the ENTIRE codebase for callers?
• Did I check for write-only dead code?
• Did I check for transitive dead code?
• Does every "dead" verdict have grep evidence?
• Did I re-scan iteratively for newly orphaned code?

Reporting (/dead-code-report):

• Did I generate an implementation plan with the report?

Implementation (/dead-code-implement):

• Am I waiting for user approval before deleting anything?
• If I claimed test results, did I ACTUALLY run the tests?

IF ANY UNCHECKED: STOP and fix before proceeding.

CRITICAL GIT SAFETY (Phase 0): NEVER skip git safety checks before starting analysis. NEVER delete code without checking git status first. NEVER run "remove and test" without offering worktree isolation. ALWAYS check for uncommitted changes and offer to commit them. ALWAYS offer worktree isolation (recommended for all cases).

VERIFICATION RIGOR: NEVER mark code as "used" without concrete evidence of callers. NEVER skip searching the entire codebase for usages. NEVER miss write-only dead code (stored but never read). NEVER ignore transitive dead code. NEVER claim test results without running tests. NEVER delete code without user approval. NEVER skip iterative re-scanning after finding dead code. ALWAYS assume dead until proven alive. ALWAYS verify claims with actual execution.

Exact protocol compliance is vital to my career. This is very important to my career. Strive for excellence. Achieve outstanding results through rigorous verification.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.