| name | upaseo-goal |
| description | 将用户的自然语言描述整理成简洁、统一、可由 agent 验证的 goal，并落盘到 `.paseo/goals/slug.md`。适用于用户说“帮我写 goal”“把这个需求变成 goal”“整理成可执行目标”“先定目标再做计划”等场景。 |
Upaseo Goal Skill
User's request: $ARGUMENTS
本技能只做一件事：把用户的粗略描述转成一个短小、统一、可由 agent 验证的目标文档，并写入项目根目录：
<项目根目录>/.paseo/goals/<slug>.md
本技能不启动执行、不产出计划、不调用 /goal。它只负责把零散描述整理成后续可供 /using-upaseo 读取的 goal。
Step 0: 避障读取
执行标准避障前置读取，见 upaseo/references/learnings-precheck.md。本技能相关 category 为 design_flaw|wrong_assumption。提炼与"目标定义、范围控制、验证方式、工具误用"相关的避障规则，作为 goal 草案的约束来源。
Step 0.5: 读取当前项目上下文
在起草 goal 前，优先结合当前项目的真实上下文：
- 若存在
AGENTS.md，先读取其中的项目规则。
- 若目标会影响功能边界、模块职责、接口或架构约束，按需读取
.agents/story/ 下相关资产。
- 若用户给了已有文件、旧计划、旧 goal 或验收线索，先读取这些事实源，再整理目标。
不要脱离当前项目现状写一个“看起来合理”的通用 goal。
Goal 定义原则
在整理 goal 时，主动应用以下本地技能/原则：
upaseo-brainstorm：当用户描述仍有歧义、存在多种合理方向、或边界不够清楚时，先按 Discover -> Propose -> Converge 流程收敛。最多给用户 3 个关键问题，或给出 2 个候选 goal 方向与 trade-offs，等用户确认后再落盘。karpathy-guidelines：显式写出关键假设，不默默替用户做高风险决定；优先更简单、更窄、更容易验证的目标表述；把“完成标准”写成可检查的事实。upaseo-simplify：在落盘前对 goal 文案做一次脱水。删掉实现方案、迭代拆分、角色分工、泛泛背景和未来扩展，只保留目标、边界和验证。
Workflow
-
提炼意图
- 找出用户真正想要的最终结果，而不是复述任务动作。
- 至少要沉淀三类信息：要完成什么目标、边界在哪里、怎么验证完成。
- 用户明确提到的硬约束优先写入
边界 或 验证，不要把它们埋在背景描述里。
- 如果缺少关键验证方式，优先给出合理默认验证；只有无法安全假设时才问 1 个问题。
-
生成 goal 草案
- 使用“结果导向”的写法：
完成什么目标 + 边界 + 怎么验证完成。
- Goal 必须能被另一个 Agent 独立理解和验证，不依赖本轮对话中的隐含语境。
- Goal 不写实现方案、迭代拆分、角色分工、风险审计或执行步骤；这些都属于后续
/using-upaseo 产出的 plan。
- 为 goal 生成一个短小稳定的 slug，作为
.paseo/goals/<slug>.md 的文件名。
-
请求确认
- 向用户展示 goal 草案、拟写入路径和关键假设。
- 明确说明：回复“确认”/“落盘”/“保存”后才会写入
.paseo/goals/<slug>.md。
- 用户提出修改时，更新草案并再次确认；不要开始执行，也不要替用户生成计划。
-
确认后落盘
- 若
.paseo/goals/ 不存在，先创建目录。
- 将最终 goal 草案写入
.paseo/goals/<slug>.md。
- 写入完成后只汇报路径、内容摘要和后续衔接方式：
/using-upaseo 可以读取这个 goal 再单独生成 .paseo/plans/<slug>.md。
Goal 文档模板
# Goal: <short title>
Priority: goal
> 本文件在 SoT 优先级链中位列最低（compact > handoff > plan > goal），但目标边界与验收约束不可被更高优先级文档覆盖或稀释。链定义见 `upaseo/SKILL.md` "Source-of-Truth Priority Chain"。
目标：
【一句话说明最终要完成的结果。】
边界：
【一句话说明本目标包含什么、不包含什么；若无需强调可写“仅限 ...，不扩展到 ...”。】
验证：
1. 【验证方式: logs|tests|browser|manual|agent-run】+【客观验证点 1】
2. 【验证方式: logs|tests|browser|manual|agent-run】+【客观验证点 2（如无则省略）】
Quality Bar
好的 goal 应该满足：
- 结果清楚：读者知道最终要交付什么。
- 边界清楚：读者知道本次目标不打算顺手解决什么。
- 证据清楚：知道用什么事实判断完成。
- 可独立落盘：goal 文件脱离对话也能被另一个 Agent 读取。
- 长度克制：优先 6-10 行；避免写成计划书。
- 职责单一：goal 只定义目标、边界和验证，不混入 plan。
输出格式
确认前只输出：
我建议把 goal 写成：
路径：
<项目根目录>/.paseo/goals/<slug>.md
<goal 草案>
回复“确认”后我会把它落盘；也可以直接告诉我要改哪一项。
确认后只写入 goal 文件，不启动执行，不追加计划讨论；若用户要继续推进，应交给 /using-upaseo 基于这个 goal 产出独立的 plan。
