fstack-simplify

/fstack-simplify

审计不必要的复杂度并提出删除建议。只删除——绝不新增。适用于任何范围：一个计划、一个 diff、一个文件或整个代码库。未经批准不会应用任何改动。

何时使用

• 用户对一个计划、diff、文件、文件夹或整个项目调用 /fstack-simplify。
• /fstack-check 发现了复杂度并建议运行此技能。
• 某处感觉臃肿、过度设计或草率——无论是单个文件还是整个项目。

步骤

1. 阅读目标。如果整个代码库，先摸清全貌——文件树、入口点、依赖、实际被用到的部分。
2. 寻找以下坏味道：
   • 死代码——未使用的文件、导出、函数、导入
   • 只有一个调用者的抽象，或只传递数据的层
   • 没人要求的配置选项
   • 用来替代几行代码的依赖
   • 为不可能发生的情况写的错误处理
   • 只是复述代码的注释，或“为将来准备”但将来从未用到的代码
   • 没有共享而是各自漂移的复制粘贴块
   • 文档或注释中初学者看不懂的词汇
3. 生成一份提议的删除与精简列表。每项一行：删除什么，以及你会失去什么（通常：什么都没有）。对于整个代码库的审计，将它们排序并按区域分组，安全高价值的删减优先。
4. 停下来询问要应用哪些。
5. 应用已批准的项。对于大规模审计，一次应用一批，并在批次之间运行测试或构建。如果出现问题，停下来报告后再继续。

禁止

• 提议新增。此技能只做删除和精简。
• 把可运行的代码改写成另一种风格。要更简单，而不是不同。
• 仅仅因为不熟悉就删除某物。如果不确定它是否未被使用，就保留并说明。
• 触碰生成的文件、vendored 代码或 lockfile。
• 未经批准就应用任何改动，或在检查上一批通过之前就应用整批。

示例输出

可以更少（已排序）：

1. 删除 src/utils/legacy/ —— 4 个文件，零导入。失去：无。
2. 删除 ThemeProvider 抽象 —— 只有一个消费者，一个 hook 就能做到。失去：无。
3. 移除 theme-config.json —— 两个值，内联即可。失去：无。
4. 去掉 clsx 依赖 —— 只用了一次，模板字面量就够了。失去：无。

我应该应用哪些？对于大扫除，我一次一批并在批次之间运行测试。