mcpField
Z
zero-tech-debt

zero-tech-debt

github.com/jnsahajDevelopment106545 installsUpdated 3w ago
Repository

About zero-tech-debt

zero-tech-debt is a coding skill for shaping changes around their intended end state. It guides developers to remove unused compatibility paths, centralize shared rules, and verify the resulting flow.

Key features

  1. 01Define the intended end state
  2. 02Find callers before keeping compatibility
  3. 03Shape code around the product surface
  4. 04Centralize shared rules
  5. 05Verify behavior and removed assumptions

Use cases

  1. 01Refactoring a patch into the intended design
  2. 02Removing unused modes and fallback paths
  3. 03Consolidating duplicated permissions or route rules

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/jnsahaj/skills --skill zero-tech-debt

After installing, type/zero-tech-debtin Claude Code to confirm it loaded.

Details

From the project README

Zero Tech Debt

Rework the change from the intended end state, not from the historical path that produced the current patch.

Steps

  1. State the intended end state in one or two sentences.

  2. Search for real callers before preserving compatibility. If a mode, prop, wrapper, route alias, or fallback has no current caller, delete it.

  3. Reshape around the final product surface. Prefer one clear component or flow over mode flags. Split only when it creates an obvious boundary such as state, layout, controls, or domain commands.

  4. Move shared rules to one place. Feature flags, permissions, route gating, URL state, and command naming should not be duplicated across pages or hidden in view components.

  5. Verify the intended flow. Test the new behavior and any deleted assumptions that affect navigation, permissions, or persisted state.

Rules

  • Optimize for the code that should exist, not the smallest diff from the old shape.
  • Delete dead compatibility paths instead of making them better.
  • Do not invent a generic framework for one feature.
  • Keep the refactor scoped to what makes the final shape coherent.
  • Prefer names that describe product intent over implementation history.

Comments

Markdown supported