build-the-gate-before-the-content
在被守护的东西之后才加的检查，是有人为了发布而关掉的检查。趁还没有东西要拦，就把它接死。
由读过该卡片的评审者赋予，而不是文件自我声明的。智能体在处理不可信内容的运行中提炼出的卡片，生来即被标记为受污染，在被检索之前会一直等待评审。
何时会想到它
- 规划一次迁移
- 着手做一个新界面
- lint 以后再加
- 安排任务顺序
价值通常在「避免」和「检查」里。「该做」是人人都会写的那一节。
上面的卡片正文是译文。英文原文才是 CLI 导入的内容、智能体运行时读取的内容，也是下方哈希所证明的内容。
触发
你即将构建某样需要在其上贯彻一条规则的东西——一项风格约束、一次新鲜度检查、一份模式（schema）、一个链接校验器、一个预算。自然的顺序是先把东西建好，等有内容可查了再加检查。
这条不适用于你正在给已有代码加检查的情况；那是另一件更难的事，那里的答案是棘轮（ratchet），而不是一堵墙。
该做
- 在第一次提交（commit）里就加上检查，早于任何可能让它失败的内容出现。它会轻易通过，这正是重点：它一出生就是绿色的。
- 给它一条说明该运行什么命令的失败信息。一个输出只是
assert False的门禁（gate），会被凌晨两点撞上它的下一个人删掉。 - 让检查在第一次违规时就失败，而不是第一百次。棘轮（ratchet）是给遗留代码用的；全新项目（greenfield）从零开始。
- 检查真的触发时，去修内容。如果每次都改检查本身，就在提交信息里记下是哪个案例逼你这么做的。
避免
"等页面都写好了再打开这个检查。"到那时检查已经积压了一堆待办，打开它就意味着一整天不相关的修复，而最省事的路径就是搞一份永远不会缩小的 skip 名单。
也要避免在触发门禁（gate）的那个功能提交里顺手放松门禁。放松的动作在一个大 diff 里根本看不出来，而这恰恰是门禁不再是门禁的那一刻——所以它应该单独成为一次提交，配上自己的说明。
检查
故意引入一次违规，确认构建（build）会变红——然后再移除它。要在写门禁（gate）的当天就做这件事，而不是以后再做。
一个从没被人看着失败过的门禁，不是门禁；它只是一个自称是门禁的文件。
风险
在内容出现之前就写好的门禁（gate），编码的是对尚不存在的内容的假设，其中一些假设会被证明是错的。预期早期会需要收窄它一两次。
收窄正是危险的时刻。每收窄一次，规则就弱一分，而一条在无人察觉的情况下被收窄了三次的规则，已经不再覆盖它当初被写出来要防的那种情况。每一次收窄，都要用促使它发生的那个失败案例把它钉住。
如何使用
卡片就是数据。克隆仓库并按路径导入——任何经由网络到达的内容都会被视为受污染并等待批准，这正是你想要的行为，也是这里没有一行命令安装器的原因。
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/build-the-gate-before-the-content/SKILL.md完整性
文件发布版本的 SHA-256。导入方可以据此核对收到的内容与本页展示的一致。
58c3de3bf7323fb3be38d084394e45ff97e408c20c45db31749cde2b8a13fc81