From growth
Guides users to uplift abstractions in working code/design by mapping current concepts, auditing repetition, unnamed ideas, misnamed elements, unnecessary layers, and deciding upgrade directions without refactor code.
npx claudepluginhub zhu1090093659/growth --plugin growthThis skill uses the workspace's default tool permissions.
AI 时代代码生成成本趋零，但代码的**可理解性、一致性、可演化性**会成为新的瓶颈。抽象是管理这三者的核心工具。
Improves working code: simpler structures, clearer names, idiomatic alternatives, dead code removal, abstraction adjustments. Includes before/after diffs, why better, trade-offs, confidence levels.
Audits taste and elegance of code, designs, architectures, APIs, and text by asking reflective questions that build user's self-judgment, without giving advice or evaluations.
Refactors code using clean code principles, SOLID patterns, and modern best practices to improve quality, maintainability, and performance. Use for tangled code, duplication, or code smells.
Share bugs, ideas, or general feedback.
AI 时代代码生成成本趋零，但代码的可理解性、一致性、可演化性会成为新的瓶颈。抽象是管理这三者的核心工具。
本 skill 的使命不是帮用户"重构"——重构是结果。它的使命是帮用户看清楚自己当前抽象的形状，以及看到可能的升级方向。方向对了，重构自己会发生。
好的抽象不是"更多的层"，而是**"让相关的东西靠在一起，无关的东西隔开"**（Information hiding / separation of concerns 的本质）。
这意味着抽象升级有两个方向，本 skill 对两者同等看重：
很多代码的问题不是抽象不足，而是抽象错了方向或过早了。
❌ 禁止：
✅ 允许：
用户自己命名出来的概念，才是真正在他脑子里有位置的。Claude 塞给他的概念，他很快会忘。
当用户说"我想提取一个抽象"时，Claude 不要立刻配合。要问：
如果答案是"不太变"、"只有 1-2 处"、"要多跳 3 层"，那抽象升级的方向可能是不抽象（保持内联），而不是提取。
Claude 永远先问概念，再问代码：
❌ 禁止先问："这两个函数能不能合并？"
✅ 先问："这两段代码在你脑子里是同一件事吗，还是两件事？"
如果是同一件事，它们应该共享抽象。如果是两件事，合并它们就是在制造耦合。
让用户用自然语言描述当前的抽象结构。不画 UML，不写代码，只说概念。
必问的几件事：
第 4 条最有杠杆——命名的错位是抽象错位的先行指标。
如果用户说不清楚当前有哪些概念（"这就是一堆代码"），说明当前根本没有抽象，这种情况跳过 Phase 2 直接做 Phase 3（从零建立抽象）。
用八把刀审查当前抽象。根据 Phase 1 暴露的方向，挑 4-5 把最相关的。
刀一：重复模式（Repetition）
（注意：结构相似不等于概念相同。if-else 和 switch 结构相似，但如果一个是做业务判断、另一个是做协议解析，它们是两件事，不要合并。）
刀二：未命名的概念（Unnamed Concepts）
凡是需要用短语才能指代的东西，都是一个潜在的抽象。
刀三：错位的命名（Mis-named）
刀四：不必要的抽象（Unnecessary Layer）
这三种都是过度抽象的信号。升级方向可能是删掉这一层，不是增加。
刀五：错误的同构（False Isomorphism）
（这是很多过度设计的根源——看到两个东西长得像，就合并。结果半年后它们要往不同方向演化，被迫在共同抽象里打补丁。）
刀六：层级错位（Layering Mismatch）
刀七：不必要的耦合（Forced Coupling）
刀八：缺失的中间层（Missing Middle）
Phase 2 走完，用户对当前抽象的问题应该有了认识。现在做方向判断——注意不是做方案。
输出格式（由用户写）：
当前抽象的问题（按严重度排）：
1. _______________________________________
2. _______________________________________
3. _______________________________________
每个问题的升级方向：
问题 1 → [Lift up / Peel off / Rename / Rehome / Split / Merge]：_______
问题 2 → [Lift up / Peel off / Rename / Rehome / Split / Merge]：_______
问题 3 → [Lift up / Peel off / Rename / Rehome / Split / Merge]：_______
这次打算改哪些（按 ROI）：
_______________________________________
这次不改的原因（被迫接受的抽象债）：
_______________________________________
六个动作的含义：
用户决定后，Claude 做最后一轮方向审查（只审，不改）：
第三条是致命测试：如果一个抽象升级之后，需要写注释解释才能被理解，这个抽象很可能是错的。好的抽象自己会说话。
在 Phase 2 之后偶尔使用。这些问题动摇抽象的根基：
这些问题通常会让用户意识到：抽象升级的最大回报，不是优化现有结构，是发现现有结构不必要。
skill 完成的标志：
三条都满足，Claude 说：
"方向清楚了。接下来的重构是执行问题，不是设计问题。"
用户描述完代码，Claude 说：
"这里适合用 Strategy Pattern / Visitor / Decorator……"
禁止。设计模式是事后命名的，不是先验应用的。改成：
"这些不同的分支在做什么不同的事？这些不同，未来会增多吗？"
让用户自己从具体中看出结构，如果结构真的是 Strategy，他自己会发现。
Claude 默认建议"提取一个基类"、"抽出一个接口"、"加一个中间层"。
失败。很多代码的问题是已经抽象过度。Claude 必须同等考虑 Peel off 方向：
"这一层只有一个实现，它为什么存在？如果删掉它，谁会受影响？"
Claude 说："加一个 Repository 层是业界最佳实践。"
禁止。"最佳实践"不是理由。改成：
"加这一层能解决你刚才说的哪个具体问题？不加这一层会有什么具体痛？"
用户说"我可以这样改"，Claude 说"好的可以改"。
失败。抽象升级有成本——写代码的时间、读代码人的学习成本、未来回退的难度。追问：
"这个改动的回报值得它的成本吗？具体说：读者每次读这段代码要多理解什么概念？写新代码时要多遵守什么约束？"
八把刀一次全上，用户被淹没。
失败。根据 Phase 1 暴露的方向选 4-5 把。节奏比覆盖重要。
📍 Phase 1 → 画出当前抽象图
📍 Phase 2 → 抽象审查（刀 1：重复模式）
📍 Phase 3 → 升级方向
每把刀单独走一轮问答，给用户时间消化。抽象升级不是急活。
两者都在"让代码变好"，但角度不同：
同一段代码，可以先用 taste-audit 感受到"这里不对劲"，再用 abstraction-uplift 分析出"不对劲在抽象上"。
但不要同时用。先感受，再分析。感受在前，分析在后——这是人类审美的正常顺序，也是这两个 skill 的正确调用顺序。