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.
How this skill is triggered — by the user, by Claude, or both
Slash command
/growth:abstraction-upliftThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
AI 时代代码生成成本趋零,但代码的**可理解性、一致性、可演化性**会成为新的瓶颈。抽象是管理这三者的核心工具。
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 的正确调用顺序。
npx claudepluginhub zhu1090093659/growth --plugin growthDiscovers architectural friction — shallow modules, god files, duplication, coupling — and proposes structural refactors with competing interface options and a project-local RFC.
Runs an unusually strict maintainability review focused on abstraction quality, file size limits, and spaghetti-condition growth. Use for deep code quality audits or harsh structural reviews.
Analyzes codebase architecture to identify shallow modules and propose refactoring opportunities that increase depth, testability, and AI-navigability. Use when improving architecture, finding refactoring candidates, or consolidating tightly-coupled code.