Kirrito-k423 Goal 定义
把 Goal 当作用户与执行者之间的任务合同，不要把它写成一句愿望或“持续尝试直到成功”的循环指令。先收敛成功定义和工程边界，再允许进入执行。
基本原则
- 先复述已知信息，再提问。 不重复询问用户已经给出的内容，也不询问可通过只读检查直接获得的事实。
- 每轮只问 1–3 个会改变方案的问题。 同时给出推荐默认值、影响和不回答时的处理方式。
- 尽早展示草案。 从第一轮起维护
DRAFT，让用户修改具体条款，而不是接受连续审问。 - 区分事实、假设、未知量和决策。 不把推测写成事实，不用虚假的精确数字掩盖不确定性。
- 验收必须可举证。 “跑通”“效果好”“问题解决”不是完整标准；必须写明可观察条件和证据位置。
- 持续交付。 最终目标未达成时，仍应能交付已完成代码、最小复现、日志、调查结论、文档和决策包。
- 不替用户扩大权限。 外部发信、推送代码、创建 PR、变更生产环境、删除数据或产生显著费用等动作必须在 Goal 中明确授权。
- 不擅自缩小成功标准。 任何范围、指标或交付期限变化都作为变更请求交给用户确认。
交互流程
1. 建立任务画像
从用户上下文和只读环境中提取：
- 业务背景、期望终态和截止时间；
- 仓库、基线提交、环境、硬件和数据；
- 已完成工作、现有证据、已知故障和未知量；
- 预期交付件、汇报对象与频率；
- 时间、算力、费用、重试和版本切换预算；
- 允许与禁止的动作、需要审批的边界。
将缺口分成两类：
- 关键缺口：不同答案会改变目标、验收、风险、权限或成本，必须由用户确认。
- 非阻塞缺口：可以给出保守默认值，但必须列在“待确认假设”中。
2. 分轮澄清
优先按以下顺序提问：
- 终态与证据：什么结果才算完成，谁来验收，用什么证据证明？
- 范围与交付：哪些必须做、明确不做，代码、脚本、文档、报告分别交付到哪里？
- 时限与预算：截止时间、算力、费用、高成本实验次数和重试上限是什么？
- 环境与基线：仓库/提交、机器、软件栈、数据、凭证和已知成功基线是什么？
- 权限与升级：是否允许提交/推送/建 PR/改远端环境，阻塞时谁能做资源或范围决策？
- 汇报节奏：多久同步一次，领导最关心哪些信息，何时必须生成交接包？
当用户明确授权“按最佳判断补全”时，采用推荐默认值并明确标注，不要继续追问非关键问题。涉及不可逆动作、外部影响或明显费用的关键缺口不得自行假设。
3. 生成 Goal 草案
生成最终合同前，必须读取 Goal 合同模板。在仓库任务中，默认将合同保存为：
goal_process/<goal-id>/GOAL.md
若用户只要求聊天内草案，则在回复中完整给出，不擅自写文件。
草案至少包含：
- 元数据、目标陈述、成功后的业务价值；
- 范围、非目标、环境基线；
- 已知事实、待验证假设和关键未知量；
- 带编号的验收标准及证据要求；
- 带路径或目标位置的交付物；
- 里程碑及各自退出条件；
- 时间、算力、费用、重试、版本切换和高成本实验预算；
- 允许动作、禁止动作和需审批动作；
- 过程归档目录、汇报频率和汇报对象；
- 停止、回滚、阻塞和升级条件；
- 条件化 ETA 与最晚决策点；
- 强制执行技能
$goal-execution。
4. 执行就绪审查
只有同时满足下列条件，才将状态从 DRAFT 改为 READY：
- 目标和非目标无实质冲突；
- 每个验收项都有可获得的证据；
- 每个必需交付件都有载体或目标位置；
- 环境、权限和预算足以开始第一个里程碑；
- 高风险动作具有审批人或明确禁令；
- 到期、物理不可行和外部依赖阻塞时有停止/升级路径；
- 用户确认关键条款，或明确授权采用已列出的默认值；
- Goal 明确绑定
$goal-execution。
不满足时输出：
- 当前
DRAFT； - 阻止
READY的最小问题集； - 推荐答案及其代价；
- 当前仍可安全进行的只读调查。
不要用低风险细节拖延就绪，也不要为了尽快开始而跳过关键门禁。
5. 完成确认
向用户展示一屏摘要：
- 一句话目标；
- 验收标准；
- 交付物；
- 截止时间和预算；
- 最大风险；
- 允许/禁止动作；
- 首个里程碑；
- 停止/升级条件。
获得确认后，将状态改为 READY。明确说明执行时必须携带 $goal-execution；本技能到此结束，不直接开展实现或实验。
Goal 变更
执行中出现范围、验收、截止时间、资源或权限变化时：
- 保留原条款；
- 记录变更原因和证据；
- 标出对进度、成本、风险和已有交付的影响；
- 生成待用户确认的变更项；
- 未确认前继续遵循原 Goal，无法继续则进入升级，不静默改写。