‹ 首页

zero-tech-debt

@darkroomengineering · 收录于 昨天 · 上游提交 昨天

Rework a patch from its intended end-state, not from the historical path that produced it — delete compat cruft, mode flags, fallbacks, and wrappers no one calls anymore. Triggers "zero tech debt", "rewrite as if from scratch", "delete the compat layer", "kill the legacy path", "this has too many flags", or when a feature has accreted mode props and shims over multiple iterations and you want the shape it should have shipped with.

适合你,如果你的项目积累了大量兼容性代码和废弃标志

/ 通过 npx 安装 校验哈希
npx oh-my-skill add darkroomengineering/cc-settings/zero-tech-debt
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- darkroomengineering/cc-settings/zero-tech-debt
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify darkroomengineering/cc-settings/zero-tech-debt
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
40GitHub stars
~627上下文体积 · 单文件
索引托管

怎么用

商店整理自技能原文 · 版本 fa04efc · 表述以原文为准
它做什么

Claude会以最终目标为起点重构代码,删除兼容层、模式标志和无人调用的回退代码,只保留真正需要的部分。

什么时候触发

当你提到“zero tech debt”“删除兼容层”等关键词,或某个功能在多次迭代中积累了过多模式标志、别名或兼容包装时触发。

装好后可以这样说
Claude会搜索调用者并删除无用兼容层。
Claude会从最终状态出发重构,忽略历史路径。
Claude会删除无调用者的分支并重塑代码。
技能原文 SKILL.md作者撰写 · MIT · fa04efc

Zero Tech Debt

Rework the change from the intended end-state, not from the historical path that produced the current patch. The principles (no compat hacks, no abstractions you don't need, no dead branches) are in AGENTS.md — this skill is the workflow for applying them to a specific patch.

When to invoke
  • A feature has accreted mode props, route aliases, or fallbacks across iterations
  • A migration left behind a compatibility shim that no current caller uses
  • You catch yourself preserving an old shape "just in case" with no concrete caller in mind
  • The diff is bigger than the change it represents because it's making the old structure better instead of removing it

For restructuring code outside the current diff use /refactor. This skill is for the patch in front of you. (Claude Code 2.1.147 renamed /simplify to /code-review and removed the old cleanup-and-fix behavior; the native command is now a correctness reporter, not a code tightener.)

Steps
  1. State the intended end-state. One or two sentences. If you can't name it, stop and ask the user — you'll otherwise optimize toward the current shape.
  2. Search for real callers before preserving compatibility. For each mode prop, route alias, fallback branch, or wrapper: grep for current callers. No caller → delete it, don't improve it.
  3. Reshape around the final product surface. Prefer one clear component or flow over mode flags. Split only when there's an obvious boundary — 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 inside 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.
  • Don't invent a generic framework for one feature.
  • Keep the rework scoped to what makes the final shape coherent — don't drag in unrelated cleanup.
  • Prefer names that describe product intent over implementation history (AdminDashboard over LegacyDashboardV2).
按 MIT 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。