我给 Claude Code 装了两套技能系统，然后花了一下午让它们别打架

起因：两套系统打架了

我先后装了两套 Claude Code 的技能（skills）系统：

• Superpowers（obra 出品，14 个工程方法论技能）：管"把代码写对"——需求澄清、写计划、TDD、调试、完成前校验。
• gstack（Garry Tan 出品，53 个角色和工具型技能）：像一支虚拟工程团队，CEO、设计师、工程经理、QA、安全官都有，还带真浏览器、部署、抓取这些能碰到真实世界的工具。

麻烦在于，两套技能的自我描述里都写着"主动触发"。同一个请求进来，它们抢着应。调试一个 bug 该用谁？写计划又该用谁？两边都喊"我来"。

我这才反应过来：装了不等于会用。能力一重叠又不定规矩，剩下的就是内耗。

第一刀：一句话切开边界

跟 Claude 来回聊了几轮，我定了个核心原则，一句话能说完：

Superpowers 管"把代码写对"的内循环；gstack 管内循环之外的一切，以及碰真实世界的工具。

写代码的内循环——规格、计划、TDD、执行、校验——归 Superpowers。产品策略、设计、真浏览器 QA、部署、安全审计、文档这些外循环和真实世界工具，归 gstack。

有了这把尺，大部分情况一秒就能选。

第二刀：模糊地带逐条拍板

剩下的就是边界不清的灰色地带，我一条条单独定：

• 调试：涉及前端、页面表现的，走 gstack，开真浏览器看；纯内部代码逻辑的，走 Superpowers 的系统化调试。
• 代码评审：统一走 Superpowers。两套评审标准并行只会互相打架。
• 想清楚做什么：值不值得做、做多大这种产品策略层的问题归 gstack；单纯的功能需求澄清归 Superpowers。
• 写计划：计划骨架归 Superpowers；要多角色评审再过 gstack。

只有一条是红线：同一个功能，绝不让两套系统都做"实现规划"。二选一，否则就是白干两遍。

关键发现：光写文档压不住

这点最出乎我意料。

我本来以为，在 CLAUDE.md（Claude Code 的项目说明文件）里把规矩写清楚就完事了。结果发现，纯文字的"建议"会被技能那套强势的自我描述悄悄绕过。技能描述里写着 "MUST invoke"、"proactively"，AI 就照着它走，把我的文档当耳旁风。

真正让规矩落地，靠两步：

第一，关掉抢活的自动触发。gstack-config set proactive false，把 gstack 的主动自荐停掉。第二，把 CLAUDE.md 的措辞从"建议"升级成"显式用户指令"，开头就写明：本节优先级高于任何技能的自我描述。

还有个意外收获。Superpowers 自己的机制里就声明了优先级——用户的 CLAUDE.md 大于技能，技能大于默认行为。所以它根本不用我去压，它本来就认 CLAUDE.md 当老大。我要是硬改它，反而会被插件升级覆盖掉，还把它的核心机制给废了。

教训是：编排 AI 不是写愿望清单，是改它的优先级机制。文字是软的，配置和优先级声明才是硬的。

加料：把两套设计技能也编进来

光有工程还不够，我还想要好看的 UI。手上正好有两套设计技能：

• frontend-design：擅长新颖、有创意、有品牌感的视觉，专门反"AI 味"，会避开烂大街的 Inter 字体和紫色渐变。
• ui-ux-pro-max：擅长标准化、显专业的设计，67 种风格、96 套配色、57 组字体搭配，还自带一套客观的无障碍（a11y）规则。

它俩怎么配合，我定的规矩是这样：

方向层只出方案、不写代码，按意图二选一主导。要创意、品牌、营销落地页，frontend-design 出视觉稿；要后台、SaaS、dashboard，ui-ux-pro-max 出标准设计系统。两者不能同时主导，创意和标准凑一起会互相拧。但有个例外：ui-ux-pro-max 那套 a11y 客观规则（对比度、触控尺寸、aria），不管谁主导都得叠上。

方案出来人审一遍，过了就当下一步的输入。到构建层，交给 Superpowers 独占落地，写计划再 TDD。设计技能从这一步起就不碰产品代码了——代码库只留一个 owner，省得多套系统改同一个文件撞车。

评审层有两道，看着重叠其实不是。ui-ux-pro-max 做渲染前的代码级静态检查（a11y 只有它管），gstack 做真浏览器渲染后的视觉 QA。一前一后，时机不同，所以都得跑。最后发布走 gstack 的 /ship。

心法就一句：方案层可以百花齐放，落地层必须单一 owner。