goal-crafting 用于撰写高质量的 Claude Code /goal 提示词。它把粗略意图转成可执行的会话目标，写明范围、约束、验证方式与成功标准；产物是供用户粘贴的 /goal 文本，技能本身不运行 /goal，也不执行目标中的实现工作（除非用户在接受后明确要求继续）。
/goal 的机制：它会安装一个会话 Stop 钩子，在条件成立之前阻止本轮对话结束，条件成立后自动清除。因此“成功标准”不是叙述性文字，而是该钩子实际判定的谓词，智能体会持续朝它工作，而不是中途停下来询问。
输入可以是：粗略的任务、缺陷报告、功能想法、重构、评审请求、迁移、UI 变更或调查目标；一段需要改进或评审的既有 /goal；来自项目、规格、工单、报错、截图或对话的片段上下文。
若输入是待评审的既有 /goal，可跳过类型判定与提问两步，直接做质量检查，报告问题并给出修正版本。
工作流程：先判定目标类型（调查、缺陷修复、功能实现、重构、评审、规划或规格、UI 工作、迁移、清理），类型决定默认工作模式与典型成功标准，例如调查与评审默认不修改文件、交付发现；缺陷修复默认先复现再修复、以失败测试转为通过为标准；功能与迁移默认先提议再编辑、以构建与测试通过为标准；规划默认不写代码、交付书面计划；重构与清理默认最小安全改动、行为不变且测试通过。用户上下文需要时可覆盖默认值，但绝不把只读类型悄悄降级为会改文件的类型。
提问采用混合策略：上下文足够就直接起草；缺失答案会实质改变目标才先问；最多一轮提问，用一次结构化提问承载三到四组决策，而不是分多轮；低风险缺口采用安全默认值，并在生成的目标中写明假设。可选项化的问题包括工作模式、风险容忍度、验证深度、范围边界；只有自由文本类信息（如工单号、接口名、报错原文、产品措辞）才用普通对话询问。
起草的 /goal 常用结构：主要成果；Context（背景与关注区域）；Objective（可观察结果）；Scope（包含的文件、模块、流程、行为或系统）；Out of scope（明确排除与未授权改动）；Constraints（兼容性、架构、风格、API、数据、设计、安全或性能规则）；Work mode；Verification（应运行的检查或应收集的证据）；Success criteria（具体完成条件）；Communication（何时提问、何时假设、最终汇报要求）。必需项为主要成果、Scope、Verification、Success criteria；其余部分只有会改变智能体行为时才写，小而低风险的任务用四段式优于九段式。整体约控制在 30 行内，超长说明承载了多个目标，应拆分。
若目标要产出报告、笔记、计划或审计等交付物，两处必须一致：Scope 与 Out of scope 要明确授权这一次写入（如“唯一获授权的写入是创建该笔记，不得修改现有项目文件”）；只读范围加需要产出文件的成功标准是自相矛盾的目标。同时要说明产出位置：漏洞、凭据、事件类发现默认写到临时位置而非仓库路径，除非用户明确选择写入仓库。
输出包括：推荐 /goal（放入代码块、可直接粘贴）；为何有效（2 至 5 条要点）；仅在做了假设时给出假设；仅在用户需要在实质不同的版本间选择时给出可选变体。评审既有 /goal 时输出：问题与风险、改进后的 /goal、改动说明。
红线：不在目标中预先授权推送、部署、删除数据、运行生产迁移、发送消息、发布等不可逆或对外动作，因为目标贯穿整个会话，会移除原本可拦截这些操作的确认点；确有需要时写成“准备改动并等待用户明确确认”。不写“保持测试通过”“监控错误”等开放式或无终止条件的目标，否则会困住会话。除非用户明确要求继续，否则不实现所生成的目标。不为可安全假设且不影响结果的答案提问。不产出无范围与验证的模糊目标（如“改进应用”“修复缺陷”），也不在看似狭窄的目标中隐藏范围扩张。在保护架构、兼容性、公开契约、数据完整性、安全或设计系统一致性时写实现约束；用户要的是产品、规划、评审或调查方向时不写。不编造项目事实，未知的项目特定事实应写成假设或保持通用。
适用场景：用户要创建、改写、改进、审查 Claude Code /goal 提示词，或需要把一段粗略任务整理成可粘贴的会话目标时使用。限制：技能不执行 /goal、不做目标实现；分类依据为提示词与目标撰写辅助，未提供价格、平台支持范围等更多信息。