领域编写指南
领域告诉代理何时值班、下一步做什么，以及如何知道工作已完成。为该纪律赋予一个令人难忘的派系风格。
编写之前
阅读目标指南和宪章的触发器表。保留已商定的派系分配，并使其与邻近领域有所区别。基于用户希望处理的实际开发场景进行工作。命名可识别的技术：“模拟对象、桩对象和伪造对象”比单独使用“受控替身”更易于发现。
将选择逻辑放在主技能中
主 realms-of-code SKILL.md 拥有 何时使用每个领域。其表格必须让代理在加载指南之前进行选择。使用具体场景：测试文件删除、选择 API 标准，或保护查询计数改进。将触发器保留在那里，而不是在每个指南中重复。
将最佳实践放在领域指南中
- 名称、纪律、格言： 一个标题、一行具体范围描述和格言。
- 传说： 一段简短生动的段落，将派系与其工程角色联系起来。让隐喻解释工作。
- 公理： 几个简洁的原则，指导决策。修改现有领域时，保留已建立的承诺。
- 怎么做： 以动词开头的实际步骤。确定要检查或更改的内容，如何选择方法，以及要验证的内容。使用明确的技术名称并重用项目的工具。解释有意义的替代方案和陷阱。
- 证据： 支持完成的可观察结果或产物，外加该证据所能证明的任何重要限制。
公理解释判断；步骤使其可执行。避免在两者中重复相同的建议。保持每个部分尽可能简短。领域参考文件为纯 Markdown：无 ID、重复的 YAML 字段、格言来源标签或署名说明。只有可发现的 SKILL.md 需要技能前置元数据。
已修正的示例
对于“无面者”，"控制依赖" 过于抽象。一个有用的触发器是“测试一个删除文件或调用外部支付服务的作业”。下一步是隔离该边界，选择模拟对象/桩对象/伪造对象，并测试成功、失败和重试行为，而不会产生意外的实时影响。证据包括预期目标和结果状态，以及在真实契约重要时的集成证明。仍然调用实时服务的间谍是一个值得命名的陷阱。
当配套的 realms-of-code 技能可用时，其 references/realms/faceless-men.md 是完整的示例。
对于“艾林”，"选择协议" 属于主触发器表。其指南必须说明要查找现有标准和技术，验证当前维护和弃用状态，评估可行性，重用已实现的实现并测试互操作性。
在实现过程中进行保护：将重要规则编码为护栏，将已验证的改进编码为棘轮。棘轮记录可重现的基线，拒绝回归并在改进后收紧。学城构建保护；铁金库强制执行。决不要通过悄悄削弱检查来解决失败的检查。
发布前审查
尝试两个真实的匹配任务和一个属于另一个领域的附近任务。从主表中选择领域，然后从其指南中识别出第一个具体操作和所需证据。如果任一步骤仍然模糊，则修改负责的文件。避免与任务无关的通用门控。
通过格言、传说和偶尔使用的工作短语（如“我们对虫子说什么？今天不行。”）保持风味鲜活。将其与有用的工程指导配对。删除既不增加决策也不增加角色的词语。遵循仓库的发布工作流程，并在受影响时验证相对链接和技能发现。