shunk031-codex-worker-prompting

说明

阅读此 SKILL.md 后，请说：🤖 I read shunk031-codex-worker-prompting.

Codex Worker 提示词编写

编写提示词，明确说明 Worker 的决策和停止条件。

前提。 Codex 系列 Worker 往往会把涉及多个方面的编辑过度工程化为批量机械转换，例如使用 sed、正则表达式或脚本重写，即使每处都需要单独判断。分派需要判断的跨领域编辑时，请明确禁止批量查找并替换，并要求一次编辑一处，逐个审查每个差异块后再提交。

技能路径。 分派任务依赖技能时，请注明每项所需技能及其可读路径；如果不打算调用技能，请说明“读取该文件”。不要依赖 Worker 猜测适用哪些技能，也不要在分派任务中加入无关技能。

前提。 用户提供字面内容（格式示例、确切措辞、表格或名称）时，请将其原样粘贴到分派内容中，并标记为 verbatim；绝不要改述。改述会悄然丢失行内代码格式、标点和大小写等关键属性，而 Worker 会忠实地实现这个劣化版本。请在视觉上区分用户的原始措辞与协调者的解读，以便 Worker 对照源内容进行检查。

对于公共/私有点文件或 Codex 配置相关工作，请告知 Worker 使用 shunk031-manage-public-private-dotfiles 技能。该技能要求在可读取时阅读 ~/.agents/AGENTS-private.md，以及两个点文件仓库根目录中的 AGENTS.md 文件。请使用这个稳定的私有指令路径，而不要自行编造 Codex 专用的私有 AGENTS.md。

八项原则

1. 写清契约，而非凭感觉。 任务需要时，说明可由机器检查的验收条件和停止条件。对于有状态或高风险工作，使用精确的 SHA、命令和通过／失败门槛；轻量任务则保持轻量。要求执行者根据门槛自行检查，并在门槛无法满足时停止。如果某个门槛的衡量范围会影响决策，还要说明它无法衡量什么。
2. 假定内容会被逐字执行。 预期每项断言都会按原文执行，包括错误内容。加入读取回查、ls-remote 比较和前置条件检查等验证条款，让执行者在事实过时或错误时停止。明确说明不变量，包括数字、主张力度、归属、文件范围和章节顺序；逐字执行者会把所有未说明的属性视为可变项。
3. 限制循环次数，而非任务数量。 一次派发可以涵盖完整生命周期，但每个可重试步骤都必须明确重试预算、等待时长和终止报告状态。对于筛选或审查等判断类任务，说明决策规则、不确定情况的默认处理方式，以及支撑该默认方式的成本不对称性。将授权边界（包括用户拥有的合并操作和破坏性操作）写入提示词中的 STOP 条件。
4. 相关时列出已验证的环境事实。 只列出任务可能涉及的事实，例如代理、推送 URL 陷阱、API 字段、沙盒变量或身份验证回退方案。将未经验证的判断写成待验证的假设，并附上用于检查的命令。在每次可能涉及既有授权的派发中，重复说明该授权。
5. 派发需求和验收标准，而非实现方案。 如果认为某种工具或方法不合适，应将此判断写成待执行者验证的假设；选择工具时，要求先做调研再实施。执行者会逐字落实解决方案框架，因此可能把错误的东西做得非常出色。
6. 让派发内容符合交付物的目标语体。 执行者会将派发中的用语和约束映射到交付物中。对于面向读者的交付物，不要在提示词正文中写入内部代号和审计约束，并说明合规性证据应放在 PR 正文中，而非文档中。 对于交付物为面向读者的报告的任务，要求执行者先阅读 shunk031-writing-kosshi 技能，再阅读 shunk031-writing-telegraph 技能，并将两者应用于报告正文。此要求仅适用于报告，不适用于派发内容或常规进度／最终回复，除非用户要求采用该风格。
7. 修复缺陷类别，并证明已全面排查。 审查者指出具体缺陷实例时，要求执行者消除整个缺陷类别。要求提供全面排查证据：列出并分类所有候选项的表格，或一个能在修复前复现已知错误状态、修复后报告零错误的检测器。
8. 根据角色和输出退化情况轮换，然后根据上下文轮换。 每个独立的审查结论都应启动新会话；如果会话输出退化或固守失败方案，应结束该会话；长期运行的执行者则应在自然边界处轮换，不要等到上下文耗尽；固定的剩余上下文百分比并非可靠的触发条件。发生崩溃或轮换后重新派发时，应列出磁盘上的状态，包括路径以及每项产物是否为最终版，并说明哪些内容不得重新计算。在仓库政策允许的情况下，将交接状态记录到交接文档和 PR 评论中；PR 正文应面向读者，而不是充当状态台账。

派发内容的传送、报告格式和对账等传输机制，属于 shunk031-herdr-orchestrate-workers 技能的范畴。本技能仅负责提示词编写指导。