用途：在开始长时间运行的自主工作前，先建立一份具体到位的目标契约，使进度无需反复人工引导即可持续推进。适用对象是那些比单次提示大、但比整个任务清单小的任务。
主要能力：契约要求在动手前写明——目标（单一持久成果）、停止条件（确切停止状态）、需先读取的上下文（文件、文档、工单、日志、计划、截图或示例）、约束（非目标、安全边界、风格规则、架构限制、需审批事项）、验证循环（证明进展的命令、检查、产物或行为）、检查点（带预期证据的小里程碑）、进度日志（简洁的状态格式）、暂停条件（何时停下并请求用户输入）。若某个必填项缺失且无法自行发现，就问一个阻塞性问题，并给出推荐答案。
使用方式：以固定提示结构组织——Goal 写明完成单一目标；Context 说明先读什么、要保留什么；Constraints 列出不要改的非目标、限定编辑范围、风险操作前需询问；Validation 规定每个检查点后运行什么命令或检查、查看什么产物与预期信号；Checkpoints 逐条写明里程碑及其完成证据；Progress 报告当前检查点、已完成工作、验证结果、剩余工作与阻塞；Stop when 给出可验证的结束状态；Pause when 给出应停下并请求输入的情形。状态更新采用固定格式：Checkpoint、Done、Verified、Remaining、Blocked。若状态变模糊，应收紧下一个检查点，而不是增加宽泛指令。
适用场景：包括迁移（如将旧路径迁移到目标技术栈，并要求契约测试、并行校验与回滚文档）、原型（按 PLAN.md 实现可运行的首版并核对参考界面或行为列表）、提示词优化（在指定路径改进提示词直至达到评测目标，每次改动后运行评测命令，编辑保持最小且针对性）。
限制与写作规则：目标要大于一次提示、小于整个任务清单；只命名一个主要成果；使用具体名词，如文件路径、命令、指标、截图、issue 编号、产物名；开始前就定义完成；范围要窄到可以独立推进；迁移需包含回滚或并行校验，原型与游戏需包含视觉或行为检查，提示词优化需包含评测命令、目标分数与编辑上限；避免“改进、打磨、清理、处理”等模糊动词，除非附带证据。关于收费、价格、平台等未在资料中说明的事项，暂未提供。