Zero Tech Debt

Overview

Build toward the intended product shape rather than preserving the sequence of historical patches. Keep one coherent end state in scope. Remove obsolete layers when evidence supports removal; do not use smaller diffs or fewer files as a substitute for the requested architecture.

Current code is evidence of behavior and contracts, not automatic architectural authority. Explicit requirements, supported clients, persisted data, security boundaries and the user's instructions still govern what may change.

Prerequisites

• A requested feature or ownership boundary and a clear intended end state.
• Access to relevant code, tests, configuration, contracts and known consumers.
• The repository's change/review rules and existing task authorization.

Read when to use this method before choosing a structural redesign. For an ambiguous "clean up" request, infer scope from the context and ask only for a missing decision that materially affects the outcome.

Instructions

1. Read preflight. Establish the intended behavior, known callers, evidence gaps, recovery strategy and overlapping work. Scale verification to the actual change; do not demand exhaustive downstream access or new infrastructure for a reversible local rename.
2. Follow the seven-step workflow: define the end state, audit reality, simplify existing paths, implement the final shape, consolidate decision ownership, align names and validate.
3. Use Glob to locate affected files and tests; use Grep or Bash(rg:) to find callers, configuration, docs and telemetry dependencies. Bash(fd:) is optional when installed. Read surrounding code rather than treating a name match as a removal instruction. Record search scope and inaccessible consumers.
4. Apply audit patterns and decision filters. Keep, delete, rename or defer each candidate according to actual responsibility and requirements. Single-implementation interfaces, adapters and versioned names can be usefu…