Superpowers 系列（二）：入口门禁
很多流程规则失败，不是规则写得不好，而是规则加载得太晚。Agent 已经读了文件、形成判断、开始修改，之后再提醒它“要先设计”“要先调试”“要先测试”，效果会差很多。
Superpowers 的入口控制解决的就是这个时机问题：在 Agent 做任何事情之前，先让它判断是否存在适用 Skill。
入口控制要解决的不是技能缺失，而是技能绕过
如果把 Skills 当工具箱，Agent 会在自己觉得需要时才取工具。这个模型有一个前提：Agent 能稳定判断自己什么时候需要流程。但很多事故正好发生在 Agent 觉得“不需要流程”的地方。
比如：
- “我先看一眼文件”会变成未受控的代码调查。
- “我先问个澄清问题”会跳过设计类 Skill 的提问顺序。
- “这只是小改动”会跳过用户批准。
- “我知道 TDD 是什么”会替代真正读取当前 TDD Skill。
所以 Superpowers 没有把 using-superpowers 设计成普通帮助文档，而是通过 session-start hook 把它注入会话上下文。这个 hook 读取 skills/using-superpowers/SKILL.md，再把内容作为额外上下文传给运行环境。入口规则因此比普通 Skill 更早出现。
触发条件只回答“该不该读”，不回答“怎么做”
using-superpowers 要求：如果有哪怕很小概率存在适用 Skill，就必须调用。它的 Rule 还明确把 Skill 调用放在任何响应或行动之前，包括澄清问题、读文件和探索代码。这个规则的重点不是“多用 Skill”，而是把“技能发现”从主观判断变成默认动作。
它还有一个更隐蔽的设计点：Skill 的 description 只应该描述触发条件，而不应该摘要完整流程。writing-skills 对这一点讲得更清楚：如果 description 写成流程摘要，Agent 可能只读 description 就开始执行，从而跳过正文里的关键门禁。
这说明 Superpowers 把 Skill 分成两个阶段：
description -> 发现入口
SKILL.md -> 执行契约description 的任务是让 Agent 找到 Skill；正文的任务才是控制行为。两者混在一起，入口会变快，但行为控制会变浅。
过程类 Skill 优先于实现类 Skill
入口控制还有一个优先级规则：多个 Skill 同时适用时，过程类 Skill 先执行。
这个规则解决的是“实现能力覆盖过程能力”的问题。一个前端任务可能触发 UI Skill，一个 bug 任务可能触发框架 Skill，但如果先进入实现类 Skill，Agent 会把问题直接放进技术栈里解决。Superpowers 希望先确定方法，再调用领域能力。
可以把它理解成两层路由：
过程类 Skill 先定义“应该怎样接近问题”；实现类 Skill 再处理具体技术动作。
为什么入口门禁必须很硬
入口门禁的价值在于阻止第一步错位。Agent 的第一步会决定后续上下文结构：先读代码，它会围绕现状解释目标；先写代码，它会围绕实现解释测试；先调试症状，它会围绕猜测组织证据。
Superpowers 把技能检查放在澄清问题、读文件、探索代码之前，是为了让方法先于材料进入上下文。这样后面的读文件、问问题、写计划都在方法框架里发生。
代价也存在：入口门禁会让简单任务看起来多一步。但 Superpowers 的取舍很明确，宁愿让简单任务多一次短检查，也不让复杂任务从一开始就无约束滑出去。
入口门禁的边界
入口门禁并不替 Agent 完成任务，也不替后续 Skill 做判断。它只保证一件事：Agent 开始行动前，先进入合适的方法上下文。
这个边界很重要。using-superpowers 不负责设计方案，也不负责调试 bug，更不负责判断代码是否完成。它负责把请求导向可能适用的过程 Skill。后续行为仍由具体 Skill 控制。
因此，Superpowers 的入口设计不是把所有规则塞进一个总提示，而是让入口只做发现和分派。小入口配合强 Skill，比一个超长总提示更容易维护。
参考资料：
系列导航：