| name | gatekeeper-zh |
| description | 中文版守门员 skill。用于复杂、高风险、多人接力、多步骤、跨文件、规则变更、方案决策、创建新资料或推进下一阶段之前，先做行动前检查：澄清目标、确认依据、识别风险、避免重复建设、限定范围、确定唯一下一步和停止点。适用于需要节省 token、提高项目效率、保证项目质量，并防止范围漂移、重复劳动、无依据假设或过早宣布完成的任务。 |
守门员（中文版）
用途
在下一步不够确定、不够安全，或可能影响多个对象之前，先使用这个 skill。
守门员只回答三件事：
- 当前到底要做什么。
- 凭什么可以做这一步。
- 最小且安全的下一步是什么。
适用与不适用
适合使用守门员：
- 任务会影响多个文件、多人接力或后续阶段。
- 用户要求继续、完成、发布、创建新资料、改规则或推进下一步。
- 当前依据不清、范围容易扩大、存在重复建设风险。
- 一次错误会造成明显返工、质量风险或后续误判。
不必完整使用守门员：
- 用户只要求执行一个明确的小命令。
- 单文件小改且目标、依据、范围都很明确。
- 只是在回答一个普通解释性问题，不产生持久改动。
轻量模式与完整模式
低风险任务使用轻量检查即可：
目标：
依据：
下一步：
高风险、跨对象、创建新资料或推进阶段时，使用完整模板。
守门员不是审批官。它的目标是让任务安全继续推进，不是制造停滞。能根据当前依据判断的，就直接判断；只有依据不足、范围失控或风险过高时才停止。
为什么能省 token
- 先锁定目标，避免把旧上下文、相似材料和无关资料全部读进来。
- 先列最小必读依据，只读取当前行动真正需要的证据。
- 先判定范围外内容，减少无关解释、无效搜索和重复讨论。
- 先判重再新建，避免生成多个近似文件、规则或模板，减少后续维护成本。
- 遇到依据不足时立即停下，不用在错误方向上继续产出大段内容。
为什么能提高项目效率
- 把“先做什么、不能做什么、做到哪里停”提前说清，减少来回返工。
- 每次只选择一个最小安全下一步，让复杂任务可以连续推进而不失控。
- 新建对象前先判断能否合并，避免资料膨胀和团队认知负担增加。
- 交接时保留已完成、未完成、阻断项和下一步，让下一位执行者快速接上。
- 当发现方向变化时及时回到守门检查，避免把小偏差拖成大返工。
为什么能保证项目质量
- 每个行动都要有依据，降低凭记忆、猜测或旧信息推进的风险。
- 明确范围内和范围外，防止越权修改、跨层处理和责任混淆。
- 把“禁止动作”和“停止点”写出来，避免过早发布、过早标记完成或跳过必要检查。
- 将症状和根因分开判断，避免用表面修补掩盖真正问题。
- 收口时直接检查交付物，保留下一步和阻断项，保证质量问题不会只停留在口头提醒里。
与脚本的关系
守门员本身不是脚本，而是一套行动前检查流程。
但在守门员机制下，可以搭建必要脚本。适合搭建脚本的情况包括：
- 同一类检查会反复出现，人工判断容易漏项。
- 需要稳定读取、比对、扫描、校验或生成结果。
- 需要减少重复复制、重复搜索或重复格式化带来的 token 消耗。
- 需要把质量检查固定成可复跑、可验证的步骤。
- 需要让多人接力时使用同一套检查口径。
搭建脚本前仍要先守门：
- 明确脚本要解决的单一问题。
- 判断是否已有工具、脚本或流程可以复用。
- 限定输入、输出和使用边界。
- 不要为了每个检查都写脚本；只有重复、稳定、可验证、人工易漏时才脚本化。
- 验证脚本结果，不把“脚本运行成功”直接等同于任务质量通过。
如何用到自己的项目中
-
选择版本。
- 中文团队优先使用
gatekeeper-zh。
- 英文或双语团队可使用
gatekeeper。
-
放到可加载的位置。
- 如果你的工具支持 skill 目录，把整个 skill 文件夹放入该工具指定的 skills 目录。
- 如果你的工具没有 skill 机制，把
SKILL.md 作为团队的行动前检查说明，放入项目的协作规范或 agent 使用说明中。
- 保留
SKILL.md 和 agents/openai.yaml 的相对结构，不要只复制一半。
-
约定触发方式。
- 明确告诉团队：遇到复杂、高风险、跨对象、创建新资料或推进阶段的任务时，先使用守门员。
- 可直接说：“使用守门员检查一下再做”。
- 支持 skill 调用的工具中，可用
$gatekeeper-zh 触发中文版。
-
做本地化适配。
- 写清你们项目里哪些资料算“当前依据”。
- 写清哪些对象属于“持久对象”，例如规范、模板、配置、发布材料、流程说明。
- 写清哪些动作必须先判重，例如新建文件、新建规则、新建模板、新增脚本。
- 写清哪些动作必须停止等待确认，例如依据缺失、范围扩大、质量风险过高。
-
从高风险场景开始使用。
- 不要一开始要求所有小任务都完整套模板。
- 先用于容易返工的场景：新建资料、改规则、跨文件修改、多人交接、发布前检查。
- 低风险任务只用轻量模式，避免把守门员用成形式主义。
-
逐步脚本化。
- 先人工使用守门员，观察哪些检查反复出现。
- 对重复、稳定、可验证、人工易漏的检查，再补脚本。
- 脚本只负责固定检查，不替代人的判断和最终质量确认。
-
复盘并微调。
- 如果守门员经常误停，说明停止条件过重，应改轻。
- 如果守门员经常放过错误，说明依据、判重或停止点写得不清。
- 每次只改一小处，让团队容易理解和继续使用。
执行流程
-
复述任务。
- 用一句话说清用户当前请求。
- 写明本轮要交付什么。
- 区分当前请求和旧上下文，不把旧目标自动带入本轮。
-
核对依据。
- 列出直接支持下一步行动的资料、文件、用户指令或当前事实。
- 标出还没有确认的假设。
- 优先使用明确的用户指令和当前资料；不要优先依赖记忆、旧笔记、示例或相似对象。
-
划定边界。
- 写明本轮范围内的动作。
- 写明本轮范围外的动作。
- 写明现在不能做的动作。
-
新增前判重。
- 新建规则、文档、模板、流程或 skill 前，先判断是否可以并入已有对象。
- 只有当新对象承担独立、可复用、不可合并的职责时，才允许新建。
- 如果只是小修、小补充或重复表达，应合并到已有对象。
-
选择下一步。
- 只选择一个最小有用动作。
- 如果依据不足，下一步就是补证据或问一个聚焦问题。
- 如果风险过高，停止并说明阻断点。
-
按边界执行。
- 只做守门结果允许的动作。
- 执行中发现边界变化时，暂停并重新守门。
- 不要把计划、草稿、试跑、部分结果说成完成。
-
收口交接。
- 直接检查已改或已交付的对象。
- 说明已完成什么、还剩什么、下一人应先看什么或先做什么。
输出模板
行动前使用：
【守门员检查】
1. 当前请求：
2. 交付物：
3. 已确认依据：
4. 未确认假设：
5. 范围内：
6. 范围外：
7. 禁止动作：
8. 唯一下一步：
9. 停止点：
新建对象前使用：
【新增前判重】
1. 拟新增对象：
2. 已有可复用对象：
3. 是否必须新建：
4. 新建理由：
5. 不得重复的内容：
6. 下一步：
交接时使用：
【交接摘要】
1. 已完成：
2. 未完成：
3. 阻断项：
4. 下一步：
5. 先读 / 先看：
简短示例
用户请求：新增一个团队协作规范文件。
【守门员检查】
1. 当前请求：判断是否需要新增协作规范文件。
2. 交付物：若必须新增，产出一个规范文件；若不必须，合并到已有资料。
3. 已确认依据：用户要求新增；已有资料尚未确认。
4. 未确认假设：是否已经存在同类规范。
5. 范围内：查找现有同类资料，判断新增或合并。
6. 范围外：直接编写完整新规范。
7. 禁止动作：未判重前新建文件。
8. 唯一下一步：检查现有资料是否可复用。
9. 停止点：找到可复用对象或确认必须新建。
停止规则
出现以下情况时，先停下，不要继续执行：
- 目标是凭记忆猜出来的，不是由当前依据支持的。
- 用户要求继续、完成、发布或标记完成，但现有依据只支持规划、草稿或部分结果。
- 拟新增对象会重复已有对象。
- 任务依赖缺失资料。
- 拟采取的修复只处理表面症状，真正原因属于另一层。
- 请求动作超出用户给定范围。
- 工具输出不可读、不完整、过宽，或不足以作为依据。
表达要求
- 简短、具体。
- 优先给出一个安全下一步，不写很长的猜测计划。
- 不确定就写“不确定”，不要补脑。
- 保留有效成果，但不要保护错误方向。
- 先守门，再执行；不要把守门结论当成交付结果。
