diff --git a/skills/goalpro/CHANGELOG.md b/skills/goalpro/CHANGELOG.md
index 6f286bb..4a11254 100644
--- a/skills/goalpro/CHANGELOG.md
+++ b/skills/goalpro/CHANGELOG.md
@@ -1,5 +1,19 @@
 # Changelog
 
+## Unreleased
+
+### Changed
+
+- Make one-shot requests return only `Goal Prompt`; append `Loop Prompt` only when the user explicitly requests iteration or post-delivery evidence will determine another cycle.
+- Split intent into `User-stated intent`, `AI-inferred potential intent`, and `Value judgments requiring confirmation`.
+- Keep research, workflow, repair, and automation guidance inside the applicable prompt instead of adding default explanatory output.
+
+### Benefits
+
+- Reduces unnecessary output and avoids turning finite tasks into artificial recurring workflows.
+- Makes AI inference auditable and prevents inferred motives or value choices from being presented as user-confirmed intent.
+- Preserves the existing evidence-bound Loop protocol for tasks that genuinely need continued iteration.
+
 ## Kim Service V1.0 - 2026-07-15
 
 - Imported `KimYx0207/GoalPro` revision `39adc8db765e0e4ad4df8d4ce02e7059fed69f26` as a self-contained Kim Service component.
diff --git a/skills/goalpro/README.md b/skills/goalpro/README.md
index 114057f..1fc6a90 100644
--- a/skills/goalpro/README.md
+++ b/skills/goalpro/README.md
@@ -1,7 +1,7 @@
 <div align="center">
 
 <h1 style="font-size: 4em; font-weight: 900; margin-bottom: 0.1em; letter-spacing: 0.04em;">GoalPro</h1>
-<p style="font-size: 1.1em; color: #2563eb; font-weight: 600; margin-top: 0;">意图放大、Goal Prompt 与 Loop Prompt 协议</p>
+<p style="font-size: 1.1em; color: #2563eb; font-weight: 600; margin-top: 0;">意图区分、Goal Prompt 与按需 Loop Prompt 协议</p>
 
 <p>
   <strong>简体中文</strong>
@@ -18,18 +18,20 @@
 
 ## 简介
 
-**GoalPro** 是一个给 Codex 和 Claude Code 共用的 `goalpro` Skill，用来写出高质量 Goal Prompt，并附带交付后继续进化用的 Loop Prompt。
+**GoalPro** 是一个给 Codex 和 Claude Code 共用的 `goalpro` Skill，用来写出高质量 Goal Prompt；只有存在真实后续迭代需求时，才附带交付后继续进化用的 Loop Prompt。
 
 它要解决的问题很直接：用户给 Agent 的任务常常是模糊的、情绪化的、战略标准不清的。模型如果直接执行，很容易过度规划、乱读上下文、先改后想、命令跑通就假装完成。
 
-GoalPro 的作用，是先把请求变成两段交给执行者使用的、可复制、可验证、可暂停的提示词：
+GoalPro 的作用，是先把请求变成一段交给执行者使用的、可复制、可验证、可暂停的 Goal Prompt；若交付后还会出现决定下一轮动作的新证据，再追加 Loop Prompt：
 
 - **Goal Prompt**：启动本轮执行，核心是可执行的 **Goal Contract**。
-- **Loop Prompt**：在本轮执行结果出来之后使用，引导复盘、差距修复和持续进化；开头先给 `时间参数`，让用户直接填写下一轮什么时候继续，如“手动贴入结果后”或“每天早上 09:00”。
+- **Loop Prompt（按需）**：仅在真实后续迭代需求存在时使用，引导复盘、差距修复和持续进化；开头先给 `时间参数`，让用户直接填写下一轮什么时候继续，如“手动贴入结果后”或“每天早上 09:00”。
 
 Goal Prompt 要回答：
 
-- 真实意图是什么？
+- 用户明确表达了什么意图？
+- 哪些只是 AI 推断的潜在意图？
+- 哪些价值判断必须由用户确认？
 - 完成后局面应该发生什么变化？
 - 什么算赢，什么算失败？
 - 需要哪些证据、上下文和反证？
@@ -52,13 +54,13 @@ Loop Prompt 要回答：
 
 > 目标不是把提示词写长，也不是替用户执行 goal，而是把 Agent 从“猜用户想要什么”拉回到“按清楚的完成契约执行”。
 
-GoalPro 默认只输出可复制的 Goal Prompt + Loop Prompt，并在输出后停住。两个提示词必须用代码块外的 `Goal Prompt:` / `Loop Prompt:` 标签分开，不额外包一层 prompt rewrite 解释。只有用户另外明确授权执行，后续 Codex / Claude Code / 其他 Agent 才按 Goal Prompt 开始做事；Loop Prompt 只在拿到执行结果后用于持续进化。Loop Prompt 开头必须先给一个可填写的 `时间参数`，但写了时间不等于已经创建后台任务；如果用户要真正定时或后台运行，需要单独设置自动化。
+GoalPro 默认只输出可复制的 Goal Prompt，并在输出后停住，不额外包一层 prompt rewrite 解释。只有用户明确要求持续迭代，或交付后会出现决定下一轮动作的新证据时，才追加独立的 Loop Prompt。只有用户另外明确授权执行，后续 Codex / Claude Code / 其他 Agent 才按 Goal Prompt 开始做事；Loop Prompt 只在拿到执行结果后用于持续进化。Loop Prompt 开头必须先给一个可填写的 `时间参数`，但写了时间不等于已经创建后台任务；如果用户要真正定时或后台运行，需要单独设置自动化。
 
 ```mermaid
 flowchart LR
     subgraph intent["意图层"]
-        A["表面请求"] --> B["真实意图"]
-        B --> C["战略结果"]
+        A["表面请求"] --> B["三类意图区分"]
+        B --> C["已确认战略结果"]
     end
 
     subgraph contract["契约层"]
@@ -104,32 +106,33 @@ flowchart LR
 
 ### 一句话总结
 
-> 先放大真实意图，再锁定战略标准，然后写成 Agent 能执行、用户能验收、结果能继续进化的双提示词。
+> 先区分用户意图、AI 推断和价值判断，再锁定战略标准，默认交付 Goal Prompt；真实需要迭代时再追加 Loop Prompt。
 
 ## GoalPro 是什么、不是什么
 
 | 概念 | 它是什么 | 它不是什么 |
 |---|---|---|
-| **GoalPro Skill** | 写出 Goal Prompt + Loop Prompt 的 Skill | 执行 goal 的工具，也不是简单的提示词润色器 |
+| **GoalPro Skill** | 默认写出 Goal Prompt，并按真实迭代需求追加 Loop Prompt 的 Skill | 执行 goal 的工具，也不是简单的提示词润色器 |
 | **Goal Prompt** | 给执行者启动本轮任务的可执行提示词，核心是 Goal Contract | 一串漂亮但无法验收的愿景 |
 | **Loop Prompt** | 给执行结果之后使用的持续循环协议，开头给 `时间参数`，每轮产出 `Next LOOP packet` | 当前回合的自动执行授权、一次性返工提示词、后台调度器本身，或无限循环的借口 |
 | **Goal Contract** | Goal Prompt 里的可执行、可验证、可暂停目标说明 | 空泛愿景或待办清单 |
-| **Workflow lens** | 生成 Goal Prompt / Loop Prompt 时使用的判断层：识别重复工作，并把必要的 Trigger / Checkpoint / Brief 写进这两段提示词 | 第三个输出、Workflow Prompt、执行器、流程图交付物，或后台自动化 |
+| **Workflow lens** | 识别重复工作，并把必要的 Trigger / Checkpoint / Brief 写进 Goal Prompt；存在真实循环时再写进 Loop Prompt | 第三个输出、Workflow Prompt、执行器、流程图交付物，或后台自动化 |
 | **Deep Research 门槛** | 战略和外部事实任务的证据前置要求 | 为了显得专业而堆链接 |
 | **Inventory** | 大改前的影响面、调用方、测试入口盘点 | 先重构再补解释 |
 | **表达经济** | 战略完整后的删空话 | 把省字数当核心目标 |
 
-## 好 Goal + Loop 的质量门
+## 好 Goal / 可选 Loop 的质量门
 
-输出 Goal Prompt + Loop Prompt 前，先过这七个门：
+输出 Goal Prompt / 可选 Loop Prompt 前，先过这八个门：
 
-1. **意图对齐**：不能只复述用户原话，必须说清用户真正要改变的局面；如果多种解释会改变路线、风险或验收，先问或写明默认假设。
-2. **字段互证**：`Intent`、`Strategic outcome`、`Decision standard`、`Execution policy`、`Verification` 必须互相支撑，不能各写各的。
+1. **意图区分**：分别写清 `User-stated intent`、`AI-inferred potential intent`、`Value judgments requiring confirmation`，不把推断或价值判断冒充用户原意。
+2. **字段互证**：三类意图字段、`Strategic outcome`、`Decision standard`、`Execution policy`、`Verification` 必须互相支撑，不能各写各的。
 3. **可执行**：执行者能看出对象、动作、先读什么、做哪一片、不做什么、何时暂停。
 4. **可验收**：验证证据必须对应用户目标，不能用命令通过冒充真实完成；完成后必须展示一个实际样例、案例片段、截图说明或改后输出片段，让用户能判断是否通过。
-5. **Workflow lens**：看到每天、每周、自动、持续、发布、运营、监控、队列、复盘等信号时，先判断是不是重复工作；只有重复工作才在 Goal Prompt / Loop Prompt 里补 Trigger、Checkpoint、Brief，不新增第三段输出。
-6. **可进化**：Loop Prompt 必须先给 `时间参数`，再要求读取上一轮真实结果和证据，指出剩余差距，给出 Done / Continue / Pause 判断，在 Continue 时输出 `Next LOOP packet`，并用 guardrails 防止无限循环。
-7. **不过度**：小任务不强行 deep research、inventory、workflow lens 或 eval；只有会改变判断、防止真实失败时才加流程。
+5. **Loop 按需**：复杂、多步骤或多文件本身不触发 Loop；只有用户明确要求，或交付后会出现决定下一轮动作的新证据时才生成。
+6. **Workflow lens**：看到每天、每周、自动、持续、发布、运营、监控、队列、复盘等信号时，先判断是不是重复工作；只有重复工作才补 Trigger、Checkpoint、Brief，不新增第三段输出。
+7. **可进化**：若生成 Loop Prompt，必须先给 `时间参数`，再要求读取上一轮真实结果和证据，指出剩余差距，给出 Done / Continue / Pause 判断，在 Continue 时输出 `Next LOOP packet`，并用 guardrails 防止无限循环。
+8. **不过度**：小任务不强行 deep research、inventory、workflow lens、Loop 或 eval；只有会改变判断、防止真实失败时才加机制。
 
 ## 快速示例
 
@@ -137,7 +140,7 @@ flowchart LR
 
 > 帮我写一个高质量 goal，让 Codex 修这个项目，别再跑偏。
 
-**GoalPro 应该输出两段：**
+**GoalPro 默认只输出 Goal Prompt：**
 
 Goal Prompt:
 
@@ -145,8 +148,14 @@ Goal Prompt:
 Goal:
 修复项目当前阻塞问题，并交付一份能证明行为恢复的变更。
 
-Intent:
-用户真正要的不是“看起来改了代码”，而是让 Agent 先搞清失败点、影响面和验收标准，再做最小必要修复。
+User-stated intent:
+修复项目，并避免 Codex 再次跑偏。
+
+AI-inferred potential intent:
+用户可能更在意可验证的行为恢复，而不只是“看起来改了代码”；这是基于“别再跑偏”的推断，可由用户修正。
+
+Value judgments requiring confirmation:
+是否优先最小改动而非更彻底重构；若该选择会改变修复路线，先确认。
 
 Strategic outcome:
 项目从不可判断/不可运行状态回到可验证状态；后续继续迭代时不会靠聊天记忆猜测完成度。
@@ -164,6 +173,8 @@ Stop conditions:
 需要删除数据、发布、处理密钥、改公共接口，或发现多条互斥路线时暂停确认。
 ```
 
+若用户明确要求交付后继续根据运行结果迭代，再追加：
+
 Loop Prompt:
 
 ```markdown
@@ -277,12 +288,12 @@ Skill 名称是 `goalpro`。
 
 | 任务 | 方法重点 | 输出 |
 |---|---|---|
-| **模糊需求** | 放大真实意图、定义成败标准 | Goal Prompt + Loop Prompt |
-| **战略任务** | Deep Research、证据地图、反证 | Research-backed Goal Prompt + Loop Prompt |
-| **执行前 goal** | 先读上下文、分片执行、验证 | Codex `/goal` block 或 Claude Code 任务提示词 + Loop Prompt |
+| **模糊需求** | 区分三类意图、定义成败标准 | Goal Prompt |
+| **战略任务** | Deep Research、证据地图、反证 | Research-backed Goal Prompt；真实需要迭代时追加 Loop |
+| **执行前 goal** | 先读上下文、分片执行、验证 | Codex `/goal` block 或 Claude Code 任务提示词 |
 | **大改/重构** | Inventory、影响面、测试入口 | 分片计划和暂停条件 |
-| **修复跑偏** | 找旧目标错位点、重写边界 | 修正版 Goal Prompt + Loop Prompt |
-| **重复工作/自动化** | 判断是否是可委托 workflow，写清 Trigger / Checkpoint / Brief / source of truth | Goal Prompt + Loop Prompt，必要时给自动化设置说明 |
+| **修复跑偏** | 找旧目标错位点、重写边界 | 修正版 Goal Prompt |
+| **重复工作/自动化** | 判断是否是可委托 workflow，写清 Trigger / Checkpoint / Brief / source of truth | Goal Prompt + Loop Prompt |
 | **交付后进化** | 复盘上一轮结果、定位差距、收敛验证 | Loop Prompt |
 | **验收收尾** | 区分结构检查、本地验证、人工验收 | 最终报告标准 |
 
@@ -316,10 +327,10 @@ X <a href="https://x.com/KimYx0207">@KimYx0207</a> |
 
 ## 方法架构
 
-GoalPro 的核心不是固定模板，而是一条把意图写成可执行 Goal Prompt、再给出交付后 Loop Prompt 的主干。它保障提示词质量，不替执行者完成任务。遇到持续、自动、发布、运营、监控、队列、复盘类请求时，先用 workflow lens 判断哪些信息应该写进这两段提示词；workflow lens 自己不成为第三个交付物。
+GoalPro 的核心不是固定模板，而是一条先区分三类意图、再写成可执行 Goal Prompt，并按真实后续迭代需求决定是否追加 Loop Prompt 的主干。它保障提示词质量，不替执行者完成任务。遇到持续、自动、发布、运营、监控、队列、复盘类请求时，先用 workflow lens 判断哪些信息应该写进 Goal；真实循环存在时再写进 Loop。workflow lens 自己不成为第三个交付物。
 
 ```text
-Critical -> Fetch -> Thinking -> Workflow lens -> Inventory -> Contract -> Review -> Verification -> Loop
+Critical -> Fetch -> Thinking -> Workflow lens -> Inventory -> Contract -> Review -> Verification -> Loop gate
 ```
 
 ### 主干
@@ -329,12 +340,12 @@ Critical -> Fetch -> Thinking -> Workflow lens -> Inventory -> Contract -> Revie
 | **Critical** | 用户真正要改变什么？ | 回到意图，不直接执行表面请求 |
 | **Fetch** | 哪些材料会改变判断？ | 先读本地上下文或外部来源 |
 | **Thinking** | 哪条路线最能赢？ | 比较取舍，标出反证和未知 |
-| **Workflow lens** | 这是一件一次性任务，还是可委托的重复工作？ | 重复工作才把 Trigger、Checkpoint、Brief 写进 Goal Prompt / Loop Prompt；一次性任务不加流程包袱 |
+| **Workflow lens** | 这是一件一次性任务，还是可委托的重复工作？ | 重复工作才把 Trigger、Checkpoint、Brief 写进 Goal；一次性任务不加流程包袱 |
 | **Inventory** | 执行者需要先知道哪些影响面和验证入口？ | 大改前把盘点要求写进 goal |
 | **Contract** | 如何写成执行者能照着做的契约？ | 补齐目标、边界、暂停条件 |
 | **Review** | 有没有空话、越界、假完成？ | 删掉装饰性流程，保留判断 |
 | **Verification** | 执行者最后要拿什么证明完成？ | 区分未验证、结构检查、本地验证、人工验收 |
-| **Loop** | 执行结果回来后如何继续进化？ | 写清复盘证据、剩余差距、迭代上限和停止条件 |
+| **Loop gate** | 交付后是否会出现决定下一轮动作的新证据？ | 是才写 Loop；复杂或多步骤本身不触发 |
 
 ### Deep Research 门
 
@@ -345,7 +356,7 @@ flowchart TD
     A["用户请求"] --> B{"是否影响战略 / 外部事实 / 高风险？"}
     B -->|否| C["本地 Fetch<br/>读会改变判断的材料"]
     B -->|是| D["Deep Research<br/>来源 + 反证 + 信心等级"]
-    C --> E["Goal Prompt + Loop Prompt"]
+    C --> E["Goal Prompt<br/>按需追加 Loop Prompt"]
     D --> F{"证据是否足够？"}
     F -->|足够| E
     F -->|不足| G["Draft Goal / Research Plan"]
@@ -401,7 +412,9 @@ flowchart LR
 | 字段 | 作用 | 常见错误 |
 |---|---|---|
 | `Goal` | 一句话说明任务对象、动作和方向 | 写成愿景 |
-| `Intent` | 放大后的真实意图 | 复述用户原话 |
+| `User-stated intent` | 用户明确表达或已经确认的意图 | 把 AI 猜测写成用户原意 |
+| `AI-inferred potential intent` | AI 基于上下文推断的潜在意图，并标注依据与不确定性 | 省略推断标签或过度心理揣测 |
+| `Value judgments requiring confirmation` | 会改变优先级、质量线、风险容忍或取舍的待确认判断 | 静默替用户做价值决定 |
 | `Strategic outcome` | 完成后局面发生什么变化 | 只写交付物 |
 | `Decision standard` | 路线判断、优先级、失败条件 | “高质量”但不可判 |
 | `Evidence standard` | 来源、验证、反证、信心等级 | 搜到资料就算完成 |
@@ -439,7 +452,7 @@ flowchart LR
 | 原则 | 原因 |
 |---|---|
 | 意图完成度优先 | 任务真正完成，比提示词漂亮更重要 |
-| 意图对齐先过门 | 表面请求、真实意图、战略结果、执行策略和验收证据必须互相支撑 |
+| 意图区分先过门 | 用户明确意图、AI 推断、待确认价值判断必须分开，战略结果和验收证据只绑定已确认意图 |
 | 可执行性优先 | goal 必须让执行者知道对象、动作、边界、检查点和停止条件 |
 | 证据先于战略 | 没有 Fetch 的战略只能是草案 |
 | 上下文按需读取 | 全仓库漫游会制造噪音和误判 |
@@ -449,7 +462,7 @@ flowchart LR
 | 验证分层 | 结构检查、本地验证、线上验证、人工验收不是一回事 |
 | 完成后给样例 | 改完必须给用户看实际样例/案例片段，否则用户无法判断是否通过 |
 | Prompt-only 边界 | GoalPro 产出 goal 后停止，执行需要用户另行授权 |
-| 输出永远是两段提示词 | 默认只交付 `Goal Prompt` 和 `Loop Prompt`；workflow lens、inventory、deep research 都只是生成这两段提示词的判断规则 |
+| 默认只交付 Goal Prompt | 一次性交付不附送 Loop；只有存在真实后续迭代需求时才追加 `Loop Prompt` |
 | Loop 不是执行授权 | Loop Prompt 只供交付后粘贴使用，不能让 GoalPro 当前回合继续执行 |
 | Loop 有时间入口 | 开头先给 `时间参数`；定时/后台执行属于自动化设置，需要显式授权 |
 | Loop 必须可持续且可停止 | 每轮结束要输出 `Next LOOP packet` 或明确 Done / Pause，同时保留 guardrails，不能只修一轮也不能无限循环 |
diff --git a/skills/goalpro/SKILL.md b/skills/goalpro/SKILL.md
index cea2aeb..17f8635 100644
--- a/skills/goalpro/SKILL.md
+++ b/skills/goalpro/SKILL.md
@@ -1,13 +1,13 @@
 ---
 name: goalpro
-description: 当用户要写出高质量 Goal Prompt 和交付后继续进化用的 Loop Prompt，把模糊、战略性、多步骤、证据不足、持续/自动化或容易跑偏的请求整理成可执行、可验证、可暂停且带时间参数的目标契约时使用。适用于写 goal、优化任务提示词、明确 done/success criteria、deep research 后定战略、大改前 inventory、修复跑偏计划、识别可委托的重复 workflow、为 Codex 或 Claude Code 准备执行任务；默认只生成提示词，不执行 goal 或 loop，也不创建自动化。
+description: 当用户要写出高质量 Goal Prompt，把模糊、战略性、多步骤、证据不足、持续/自动化或容易跑偏的请求整理成可执行、可验证、可暂停的目标契约时使用。适用于写 goal、优化任务提示词、明确 done/success criteria、deep research 后定战略、大改前 inventory、修复跑偏计划、识别可委托的重复 workflow、为 Codex 或 Claude Code 准备执行任务；默认一次性交付只生成 Goal Prompt，只有存在真实后续迭代需求时才追加 Loop Prompt，不执行 goal 或 loop，也不创建自动化。
 ---
 
-# Goal Prompt + Loop Prompt
+# Goal Prompt
 
-目标：先把真实意图、战略判断、证据标准和成败边界讲清楚，再写成 Codex / Claude Code 能执行、能验收、少跑偏的 Goal Prompt；同时产出一个交付后继续进化用的 Loop Prompt。
+目标：先区分用户明确表达的意图、AI 推断的潜在意图和需要用户确认的价值判断，再把战略判断、证据标准和成败边界写成 Codex / Claude Code 能执行、能验收、少跑偏的 Goal Prompt。只有存在真实后续迭代需求时，才追加交付后使用的 Loop Prompt。
 
-GoalPro 的交付物是可复制的提示词，不是任务执行结果。默认输出两段：`Goal Prompt` 用于启动执行，`Loop Prompt` 用于执行结果出来后的复盘、差距修复和持续进化。Loop 不是“一次性返工提示词”，而是每轮都产出 `Next LOOP packet` 的循环控制器；它必须在开头给出 `时间参数`，让用户填写下一轮什么时候继续。除非用户明确说“按这个 goal 执行 / 开始改 / 写入文件 / 提交 / 创建自动化”，否则输出两段提示词后必须停止。
+GoalPro 的交付物是可复制的提示词，不是任务执行结果。默认一次性交付只输出 `Goal Prompt`。只有用户明确要求持续迭代 / LOOP，或任务在本次交付后会持续产生新证据并需要下一轮动作时，才追加 `Loop Prompt`。Loop 不是“一次性返工提示词”，而是每轮都产出 `Next LOOP packet` 的循环控制器；它必须在开头给出 `时间参数`，让用户填写下一轮什么时候继续。除非用户明确说“按这个 goal 执行 / 开始改 / 写入文件 / 提交 / 创建自动化”，否则输出适用的提示词后必须停止。
 
 这不是“让提示词更短”的 Skill。表达经济只在战略完整后处理：删空话，不删判断、边界、证据和验收。
 
@@ -18,15 +18,16 @@ GoalPro 的交付物是可复制的提示词，不是任务执行结果。默认
 - `Execution`：用户要给 agent 一份按 goal 开始做的执行提示词。
 - `Repair`：之前输出跑偏、太粗糙、太复杂、问太多、假完成。
 - `Governed`：高风险、多文件、发布、外部事实、生产相邻或会影响真实用户的任务。
-- `Workflow`：用户提到每天、每周、自动、持续、发布、运营、监控、队列、复盘等重复性工作时，先判断哪些 Trigger / Checkpoint / Brief 信息应写进 Goal Prompt / Loop Prompt。
+- `Workflow`：用户提到每天、每周、自动、持续、发布、运营、监控、队列、复盘等重复性工作时，先判断哪些 Trigger / Checkpoint / Brief 信息应写进 Goal Prompt；这类任务通常存在真实后续迭代需求，可再追加 Loop Prompt。
 
 用能诚实验收的最轻模式；但战略性任务必须先过证据门槛。
 
 ## Prompt-only 闸门
 
 - Skill mention 不等于执行授权。用户只说 `goalpro`、`写 goal`、`优化提示词`、`帮我做个目标` 时，只生成可复制的 goal 提示词。
-- 新版默认生成两段提示词：`Goal Prompt` 和 `Loop Prompt`。Loop 只是交付后可粘贴的继续进化提示词，不授权当前回合执行。
-- Workflow lens 不改变输出形态：默认仍然只输出 `Goal Prompt` 和 `Loop Prompt`，不新增第三个 `Workflow Prompt`，不把 GoalPro 变成执行器或自动化平台。
+- 默认一次性交付只生成一段 `Goal Prompt`，不为了显得完整而附送 Loop。
+- 只有通过“Loop 需求判断门”时才追加 `Loop Prompt`。Loop 只是交付后可粘贴的继续进化提示词，不授权当前回合执行。
+- Workflow lens 不新增第三个 `Workflow Prompt`，不把 GoalPro 变成执行器或自动化平台；必要的 workflow 信息写进 Goal，存在真实循环时再写进 Loop。
 - Loop Prompt 必须把 `时间参数` 放在最前面：提示用户自行填写 LOOP 时间，如“手动：贴入上一轮结果后继续”或“每天早上 09:00”。
 - 定时/自动 Loop 只是自动化设置说明，除非用户明确授权创建或修改自动化；写了时间不等于已经创建后台任务。
 - 生成的 goal 必须能指导后续执行者：对象、动作、上下文、范围、非目标、检查点、暂停条件和验收证据都要清楚。
@@ -35,15 +36,27 @@ GoalPro 的交付物是可复制的提示词，不是任务执行结果。默认
 - 不要因为 loop 里写了 Review evidence、Cycle action、Verification delta，就在当前回合开始复盘或修复。
 - 只有用户额外明确授权执行、保存、修改文件、提交或发布时，才进入独立的执行任务；那已经不是 GoalPro 的默认输出模式。
 
+## Loop 需求判断门
+
+先判断本次是一次性交付，还是存在真实后续迭代需求：
+
+- `只生成 Goal Prompt`：用户只要 goal / prompt / spec；任务虽复杂或多步骤，但可以在一次执行合同内完成和验收；所谓“后续优化”没有明确的新输入、新证据、触发条件或下一轮动作。
+- `Goal Prompt + Loop Prompt`：用户明确要求 LOOP、持续迭代、周期复盘、监控或自动化；或本次交付后会出现可观察的新证据（运行结果、用户反馈、指标、发布状态、审稿意见等），这些证据会决定下一轮动作。
+- 复杂、多文件、需要多个 checkpoint、一次执行内反复验证，不自动构成真实后续迭代需求。
+- 不确定时默认一次性交付，只生成 Goal Prompt；不要凭 AI 对“持续进化”的偏好擅自追加 Loop。
+- 若只要求 Loop，则只输出 Loop Prompt，并要求用户提供上一轮结果或 `Next LOOP packet`。
+
 ## 意图对齐质量门
 
-输出任何 Goal Prompt + Loop Prompt 前，先做一次短自检：
+输出任何提示词前，先做一次短自检：
 
-- 对齐链路：表面请求 -> 真实意图 -> 战略结果 -> 可执行动作 -> 验收证据；链路断开的字段必须重写。
-- `Intent` 不能只复述用户原话；必须说明用户真正要改变的局面、当前不满和最大误伤点。
+- 对齐链路：用户明确表达的意图 -> AI 推断的潜在意图 -> 待确认价值判断 -> 战略结果 -> 可执行动作 -> 验收证据；链路断开的字段必须重写。
+- `User-stated intent` 只记录用户明确说过或上下文中已确认的意图，不替用户补充动机。
+- `AI-inferred potential intent` 单独列出基于上下文的推断及依据，明确标记为可修正假设，不冒充用户原意。
+- `Value judgments requiring confirmation` 单独列出会影响优先级、质量线、风险容忍、范围或取舍的价值判断。若它会改变路线，先问一个阻塞问题；不得把未确认判断静默写进 Goal。
 - `Strategic outcome` 和 `Decision standard` 必须解释为什么这个 goal 符合用户意图，而不是只描述交付物。
 - 如果换掉项目名、文件名或用户场景后仍然成立，就太泛；补对象、边界、先读材料、检查点或暂停条件。
-- `Loop Prompt` 必须绑定上一轮交付物和验证证据，不能写成一个不看结果的新 goal；它必须先给可填写的时间参数，再包含可继承的 loop state 和下一轮 LOOP 生成规则。
+- 仅在通过 Loop 需求判断门时检查：`Loop Prompt` 必须绑定上一轮交付物和验证证据，不能写成一个不看结果的新 goal；它必须先给可填写的时间参数，再包含可继承的 loop state 和下一轮 LOOP 生成规则。
 - 如果不同解释会改变路线、风险、权限、范围或验收，先问一个阻塞问题，并给出推荐答案；能通过读取上下文解决的问题，不要丢给用户。
 
 ## Workflow lens
@@ -52,7 +65,7 @@ GoalPro 的交付物是可复制的提示词，不是任务执行结果。默认
 
 - 触发信号：每天、每周、自动、持续、发布、运营、监控、队列、复盘、提醒、审核、同步、巡检、内容日历。
 - 先判断这是不是一个可委托的重复模式：是否有稳定输入、触发时机、执行步骤、人工确认点、输出记录和复盘证据。
-- 如果是重复 workflow，只把必要信息写进 `Goal Prompt` 和 `Loop Prompt`：在 Goal 的 `Decision standard` / `Execution policy` 或可选 `Workflow lens` 段里写清判断，在 Loop 里写清 Trigger、Checkpoint、Brief、source of truth、非目标。
+- 如果是重复 workflow，只把必要信息写进适用的提示词：在 Goal 的 `Decision standard` / `Execution policy` 或可选 `Workflow lens` 段里写清判断；存在真实循环时，再在 Loop 里写清 Trigger、Checkpoint、Brief、source of truth、非目标。
 - `Trigger` 说明每轮何时开始：事件触发通常优先于固定时间；固定时间只是时间参数，不等于已创建后台任务。
 - `Checkpoint` 要尽量后移：先让执行者把材料准备好，再让用户确认一次关键判断，而不是开头问一串问题。
 - `Brief` 是给用户看的决策摘要：做了什么、为什么、证据在哪、推荐动作是什么；不要把原始草稿或日志直接丢给用户审。
@@ -77,8 +90,8 @@ Deep Research 执行顺序：
 5. 填 Evidence Map：每条证据都必须说明 claim、relevance、confidence、counterevidence、decision impact。
 6. 反证检查：主动找能推翻当前路线的证据；冲突保留，不强行合并。
 7. 定信心等级：high / medium / low，并说明依据。
-8. 选输出形态：证据足够才输出 `Research-backed Goal Prompt + Loop Prompt`；不足输出 `Draft Goal + Draft Loop` 或 `Research Plan`。
-9. 写回 Goal / Loop：研究结果必须改变 Decision standard、Evidence standard、Scope、Non-goals、Execution policy、Verification、Stop conditions 或 Loop 的时间参数、Review evidence、Gap diagnosis、Verification delta、自动化设置边界、Continuation protocol、Next LOOP packet；否则不算 deep research。
+8. 选输出形态：证据足够才输出 `Research-backed Goal Prompt`；不足输出 `Draft Goal` 或 `Research Plan`。仅在通过 Loop 需求判断门时追加相应 Loop。
+9. 写回 Goal / 可选 Loop：研究结果必须改变 Decision standard、Evidence standard、Scope、Non-goals、Execution policy、Verification、Stop conditions；若生成 Loop，还必须改变其时间参数、Review evidence、Gap diagnosis、Verification delta、自动化设置边界、Continuation protocol 或 Next LOOP packet，否则不算 deep research。
 
 `Evidence Map` 格式：
 
@@ -100,11 +113,11 @@ Evidence Map:
 1. Critical：先指出用户真正不满、要推进的局面、最大误伤点。
 2. Fetch：只读取会改变战略、边界、验收或执行路线的材料；战略任务先做 deep research。
 3. Thinking：比较路线，写清取舍；把反例、未知和信心等级放进判断。
-4. Workflow lens：如果请求是重复性工作，先判断它配不配变成 workflow；需要时把 Trigger、Checkpoint、Brief 和 source of truth 写进 Goal Prompt / Loop Prompt。
+4. Workflow lens：如果请求是重复性工作，先判断它配不配变成 workflow；需要时把 Trigger、Checkpoint、Brief 和 source of truth 写进 Goal Prompt。
 5. Inventory：涉及代码库、文档库或复杂系统时，先列会受影响的文件、调用方、测试和验证入口，再允许执行。
 6. Contract：写 Goal Prompt，让执行者知道做什么、不做什么、先读什么、何时停。
 7. Review：用成败标准反查合同，删掉装饰性流程，保留关键判断。
-8. Loop：写 Loop Prompt，让交付结果回来后能按证据复盘、收敛差距、输出下一轮 LOOP 包，直到 Done 或 Pause。
+8. Loop gate：只有存在真实后续迭代需求时，才写 Loop Prompt，让交付结果回来后能按证据复盘、收敛差距、输出下一轮 LOOP 包，直到 Done 或 Pause。
 9. Expression economy：最后才压缩表达；不得牺牲意图完成度、执行边界或 Loop 的停止条件。
 
 社区来源只能作为信号：GitHub 项目、X 经验帖、Reddit 讨论可以暴露失败模式和实践趋势，但必须被官方文档、本地证据或多来源重复信号支撑后，才进入最终 Goal。
@@ -113,7 +126,9 @@ Evidence Map:
 
 一个 Goal 达标，必须回答清楚：
 
-- `真实意图`：用户真正要改变的局面，不是复述原话。
+- `用户明确表达的意图`：只写用户明确提出或已确认的目标、限制和不满。
+- `AI 推断的潜在意图`：写清推断、依据与不确定性，不冒充已确认事实。
+- `需要用户确认的价值判断`：明确哪些优先级、质量线、风险容忍或取舍仍需用户决定。
 - `战略结果`：完成后什么会变好，为什么值得做。
 - `成败标准`：什么算赢，什么算没做到，必须可判断。
 - `可执行性`：后续执行者是否能照着 goal 开始工作、知道先读什么、做到哪一步、何时暂停。
@@ -125,15 +140,17 @@ Evidence Map:
 
 ## 字段标准
 
-默认输出两个 fenced `markdown` 代码块：先 `Goal Prompt`，再 `Loop Prompt`。每个代码块前必须有代码块外的可见标签 `Goal Prompt:` / `Loop Prompt:`；标签不能放进 fenced block 内，不要只靠字段名暗示；不要把两个提示词合并到同一个代码块里，也不要新增第三个 `Workflow Prompt`。如果用户只明确要求 LOOP，则只输出 Loop Prompt，并要求用户贴入上一轮结果或 `Next LOOP packet`。
+默认输出一个 fenced `markdown` 代码块，并在代码块外显示标签 `Goal Prompt:`。只有通过 Loop 需求判断门时，才在其后追加第二个独立代码块，并显示标签 `Loop Prompt:`。标签不能放进 fenced block 内；不要合并两个提示词，也不要新增第三个 `Workflow Prompt`。
 
-不要输出 `原始输入 / 优化后的理解 / 优化后的完整提示词` 这类 meta prompt rewrite 包装，除非用户明确要求做 meta-theory 改写；GoalPro 的默认正文就是可复制的 Goal Prompt + Loop Prompt。
+不要输出 `原始输入 / 优化后的理解 / 优化后的完整提示词` 这类 meta prompt rewrite 包装，除非用户明确要求做 meta-theory 改写；GoalPro 的默认正文就是可复制的 Goal Prompt，以及满足条件时的 Loop Prompt。
 
 Goal Prompt:
 
 ```markdown
 Goal:
-Intent:
+User-stated intent:
+AI-inferred potential intent:
+Value judgments requiring confirmation:
 Strategic outcome:
 Decision standard:
 Evidence standard:
@@ -168,7 +185,9 @@ Next LOOP packet:
 | 字段 | 写什么 | 合格标准 | 常见错误 |
 |---|---|---|---|
 | `Goal` | 一句话任务 | 有对象、有动作、有方向，执行者能立即知道要做什么 | 写成愿景 |
-| `Intent` | 放大后的真实意图 | 说清用户真正要改变的局面 | 复述原话 |
+| `User-stated intent` | 用户明确表达的意图 | 仅包含用户说过或已确认的目标、限制和不满 | 把 AI 猜测写成用户原意 |
+| `AI-inferred potential intent` | AI 推断的潜在意图 | 标注推断依据、不确定性和可修正性 | 省略“推断”标签或过度心理揣测 |
+| `Value judgments requiring confirmation` | 需要用户确认的价值判断 | 列出会改变优先级、质量线、风险容忍、范围或取舍的判断；无则明确写无 | 静默替用户决定“更重要”“更好”或“可接受” |
 | `Strategic outcome` | 最终战略结果 | 能解释为什么这次工作值得做 | 只写交付物 |
 | `Decision standard` | 路线判断标准 | 明确优先级、取舍和失败条件 | “高质量”但不可判 |
 | `Evidence standard` | 证据要求 | 区分来源、验证、人工验收和信心等级 | 搜到资料就算完成 |
@@ -204,34 +223,35 @@ Next LOOP packet:
 ## 输出位置规则
 
 - 默认位置：聊天窗口。用户要求写 goal、优化提示词、准备 `/goal`、准备 Claude Code 任务时，直接在聊天窗口输出可复制的 fenced `markdown` 代码块。
-- 文件位置：只有用户明确要求保存、写入文件、生成文档、提交 git、更新项目资料，才把 Goal Prompt / Loop Prompt 写入文件。
-- 双输出：一旦写入文件，聊天窗口仍必须同步输出同一份可复制的 Goal Prompt / Loop Prompt 代码块，并说明文件路径。
+- 文件位置：只有用户明确要求保存、写入文件、生成文档、提交 git、更新项目资料，才把适用的 Goal Prompt / Loop Prompt 写入文件。
+- 双输出：一旦写入文件，聊天窗口仍必须同步输出同一份可复制提示词代码块，并说明文件路径。
 - 不确定时：默认聊天窗口输出，不要为了“完整”自动创建文件。
 - 文件建议路径：目标文档优先用 `docs/goals/<topic>.md`；示例、方法依据或 Skill 本体改动仍放回对应 `references/` 或 `SKILL.md`。
-- 代码块要求：可复制提示词必须放在 fenced `markdown` code block 内；默认分成 `Goal Prompt` 和 `Loop Prompt` 两个代码块，每个块前有代码块外的同名标签，不要只给文件链接或摘要。
+- 代码块要求：可复制提示词必须放在 fenced `markdown` code block 内；默认只有 `Goal Prompt`，通过 Loop 需求判断门时再追加独立的 `Loop Prompt`；每个块前有代码块外的同名标签，不要只给文件链接或摘要。
 
 ## 输出模式
 
-- 普通 goal：输出 `Goal Prompt`、`Loop Prompt`、`为什么这样写`、必要时的 `阻塞问题`。
-- 战略/研究 goal：输出 `Research-backed Goal Prompt`、`Loop Prompt`、`Evidence Map 摘要`、`反证/未知`。
-- Codex 执行场景：给 `/goal` block，包含 done-when、read-first、checkpoints、pause-if；另给交付后的 `Loop Prompt`。
-- Claude Code 执行场景：给任务提示词，包含先读材料、执行策略、验证和暂停条件；另给交付后的 `Loop Prompt`。
-- 大改/重构场景：先输出 inventory、影响面、分片计划、每片验证；不得先重构再补解释。
-- Repair 场景：先指出旧目标哪里错，再给修正版和防跑偏检查。
-- Workflow 场景：如果用户请求是重复性工作，输出仍然是 Goal Prompt + Loop Prompt；只在这两段提示词里补充 workflow lens、Trigger、Checkpoint、Brief。若需要确认路线，只问一个阻塞问题并给推荐答案。
+- 普通 goal：只输出 `Goal Prompt`；不附加“为什么这样写”、摘要、使用说明或 Loop。
+- 战略/研究 goal：只输出 `Research-backed Goal Prompt`，把 Evidence Map 摘要、反证和未知写进 Goal 的对应字段；仅在存在真实后续迭代需求时追加 Loop。
+- Codex 执行场景：给 `/goal` block，包含 done-when、read-first、checkpoints、pause-if；仅在存在真实后续迭代需求时另给交付后的 `Loop Prompt`。
+- Claude Code 执行场景：给任务提示词，包含先读材料、执行策略、验证和暂停条件；仅在存在真实后续迭代需求时另给交付后的 `Loop Prompt`。
+- 大改/重构场景：把 inventory、影响面、分片计划和每片验证写进 Goal Prompt；不得另行输出计划包。
+- Repair 场景：在内部先定位旧目标错位点，最终只交付修正版 Goal Prompt；防跑偏规则写进 Goal 字段。
+- Workflow 场景：如果用户请求是重复性工作，在 Goal Prompt 中补充 workflow lens、Trigger、Checkpoint、Brief；由于存在后续周期，通常追加 Loop Prompt。若需要确认路线，只问一个阻塞问题并给推荐答案。
 - Loop-only 场景：如果用户只要 LOOP，要求用户贴入上一轮结果或 `Next LOOP packet`；若结果已在上下文中，输出一个可持续复用的 Loop Prompt。
-- 自动化 Loop 场景：如果用户明确说自动、定时、每天、每周、持续监控或后台运行，先在 `时间参数` 中给可填写示例，再输出简短自动化设置说明；除非用户授权创建或修改自动化，否则不实际创建。
+- 自动化 Loop 场景：如果用户明确说自动、定时、每天、每周、持续监控或后台运行，在 `时间参数` 和 guardrails 中写清自动化设置要求；不另行输出设置说明，除非用户授权创建或修改自动化，否则不实际创建。
 
-所有输出模式默认在 Goal Prompt + Loop Prompt 后停止；不要追加“我现在开始执行”。最后提醒：你可以使用 LOOP 继续进行进化。
+所有输出模式在适用的提示词交付后停止；不要追加解释、摘要、提醒或“我现在开始执行”。
 
 ## 验收清单
 
-- 意图：说的是用户真正要的结果，不只是表面动作。
-- 对齐：`Intent`、`Strategic outcome`、`Decision standard`、`Execution policy`、`Verification` 能解释为什么这个 goal 符合用户意图。
+- 意图区分：`User-stated intent`、`AI-inferred potential intent`、`Value judgments requiring confirmation` 三类边界清楚，未把推断或价值判断伪装成用户原意。
+- 对齐：三类意图字段、`Strategic outcome`、`Decision standard`、`Execution policy`、`Verification` 能解释为什么这个 goal 符合已确认意图。
 - 反泛化：把项目名、对象名替换后仍然成立的空话已经删掉或补成具体边界。
 - 可执行：执行者能看出对象、动作、先读材料、推进顺序、暂停条件和验收证据。
-- Workflow：只有重复性工作才启用 workflow lens；启用时能看出 Trigger、Checkpoint、Brief、source of truth 和不该自动化的边界，但输出形态仍是 Goal Prompt + Loop Prompt。
-- Loop：Loop Prompt 开头有可填写 `时间参数`，并能看出上一轮结果要读什么、如何找差距、本轮做什么、何时 Done / Continue / Pause、下一轮 `Next LOOP packet` 如何生成。
+- Workflow：只有重复性工作才启用 workflow lens；启用时能看出 Trigger、Checkpoint、Brief、source of truth 和不该自动化的边界。
+- Loop 判断：一次性交付只生成 Goal Prompt；复杂或多步骤本身不触发 Loop；真实后续迭代需求才追加 Loop Prompt。
+- Loop：若生成，开头有可填写 `时间参数`，并能看出上一轮结果要读什么、如何找差距、本轮做什么、何时 Done / Continue / Pause、下一轮 `Next LOOP packet` 如何生成。
 - 战略：说明结果价值、成败标准、证据标准和关键取舍。
 - Deep Research：战略或外部事实任务有来源、反证、信心等级和决策影响。
 - Community Signal：GitHub / X / Reddit 只当候选证据，已说明来源类型和采纳理由。
@@ -239,9 +259,9 @@ Next LOOP packet:
 - 边界：保留用户限制，明确不做什么。
 - 标准：每个关键字段能判断合格/不合格。
 - 位置：默认聊天窗口给 fenced `markdown` 代码块；写文件时也要同步给代码块和文件路径。
-- 标签：默认输出必须有 `Goal Prompt:` 与 `Loop Prompt:` 两个可见标签。
+- 标签：默认输出必须有 `Goal Prompt:` 可见标签；只有生成 Loop 时才增加 `Loop Prompt:` 标签。
 - 停止：没有明确执行授权时，输出 goal 后停止，不继续读仓库、改文件、运行命令或提交。
-- 进化：Loop 不授权当前回合执行；只作为交付后可复制的持续循环提示词，每轮必须产出可继承的 `Next LOOP packet` 或明确 Done / Pause。
+- 进化：不得为了“持续进化”口号默认生成 Loop；若真实需要 Loop，它不授权当前回合执行，只作为交付后可复制的持续循环提示词，每轮必须产出可继承的 `Next LOOP packet` 或明确 Done / Pause。
 - 自动化：`时间参数` 是用户填写入口，不是自动化创建结果；若写定时/后台自动化，必须说明需要另行授权创建。
 - 工具：只要求读取会改变判断的上下文。
 - 证据：区分未验证、结构检查、本地验证、线上验证、人工验收。
@@ -251,4 +271,4 @@ Next LOOP packet:
 ## 需要更多细节时
 
 - 方法依据：读 `references/source-rules.md`。
-- 示例校准：读 `references/examples.md`。
+- 示例校准：读 `references/examples.md`。其中旧示例若仍使用单一 `Intent` 或默认双提示词，只能参考任务内容；输出形态与字段必须以本文件当前的三类意图区分和 Loop 需求判断门为准。
diff --git a/skills/goalpro/references/source-rules.md b/skills/goalpro/references/source-rules.md
index 32f85b4..2e7ec4d 100644
--- a/skills/goalpro/references/source-rules.md
+++ b/skills/goalpro/references/source-rules.md
@@ -5,7 +5,7 @@
 ## 采用的规则
 
 - Goal 是完成契约，不只是提示词：必须写清结果、限制、done-when 和验证证据。
-- GoalPro 是提示词生成 Skill，不是执行器：默认产出可复制 Goal Prompt + Loop Prompt，执行需要用户另行明确授权。
+- GoalPro 是提示词生成 Skill，不是执行器：默认一次性交付只产出可复制 Goal Prompt；只有存在真实后续迭代需求时才追加 Loop Prompt，执行需要用户另行明确授权。
 - Loop Prompt 是交付后的持续进化协议，不是自动化运行时：必须读取上一轮真实结果、验证证据、用户反馈和 loop state，再决定本轮动作、Done / Continue / Pause，并在 Continue 时产出可直接复用的 `Next LOOP packet`；不能授权当前 GoalPro 回合执行。
 - Loop Prompt 必须把 `时间参数` 放在最前面：提示用户自行填写 LOOP 时间，如“手动：贴入上一轮结果后继续”“每天早上 09:00”“每次部署后”。这比把触发规则藏在后面更接近真实使用。
 - Loop Prompt 必须区分时间入口和自动化运行时：写了“每天 09:00”只是时间参数；只有用户明确授权创建自动化时，才进入自动化设置。
@@ -13,14 +13,14 @@
 - 生成的 Goal 必须可执行：执行者能看出对象、动作、先读材料、范围、非目标、检查点、暂停条件和完成证据。
 - 生成的 Loop 必须可持续且可收敛：后续执行者能看出时间参数怎么填、上一轮要读什么、继承什么状态、本轮修什么、如何证明新增价值、循环预算和无收敛阈值是什么、何时 Done / Continue / Pause、下一轮 LOOP 包怎么生成。
 - Workflow lens 只在重复性工作中启用：用户提到每天、每周、自动、持续、运营、发布、监控、队列、复盘、审核、同步等信号时，先判断它是不是可委托 workflow；不是重复工作就不要强行流程化。
-- Workflow lens 不改变输出形态：默认交付永远是 `Goal Prompt` + `Loop Prompt` 两段提示词；不要新增 `Workflow Prompt`，不要把 GoalPro 写成执行器、调度器或流程图交付工具。
+- Workflow lens 不新增 `Workflow Prompt`，不要把 GoalPro 写成执行器、调度器或流程图交付工具；必要信息先写进 Goal，存在真实循环时再写进 Loop。
 - 重复 workflow 要把 Trigger、Checkpoint、Brief 和 source of truth 写进 Goal / Loop：什么时候开始、在哪里让人确认、给用户看什么决策摘要、以哪个状态表/文件/系统为准。
 - 提问要少但要准：如果不同路线会改变风险、权限、范围或验收，最多问一个阻塞问题，并给推荐答案；能通过读取上下文解决的问题，先读上下文。
-- 生成的 Goal 必须先过意图对齐质量门：表面请求、真实意图、战略结果、执行策略和验收证据要互相支撑。
+- 生成的 Goal 必须先过意图对齐质量门：分别写清用户明确表达的意图、AI 推断的潜在意图、需要用户确认的价值判断，再让战略结果、执行策略和验收证据与已确认意图互相支撑。
 - Skill 的 `description` 是触发表面：只写“何时使用”和“做什么”，不能把次级优化目标写成触发词。
 - 输出位置是用户体验契约：默认聊天窗口给可复制代码块；只有用户明确要求保存或提交时才写文件。
 - 完成后的可判断样例是验收契约：最终汇报必须给用户看一个实际样例、案例片段、截图说明或改后输出片段，否则用户无法判断是否通过。
-- 输出形状必须清楚：默认用 `Goal Prompt:` 和 `Loop Prompt:` 两个代码块外标签分别引出两个 fenced `markdown` 代码块，不把标签放进代码块内，不输出 meta prompt rewrite 包装。
+- 输出形状必须清楚：默认用 `Goal Prompt:` 标签引出一个 fenced `markdown` 代码块；只有通过 Loop 需求判断门时才追加 `Loop Prompt:` 和第二个代码块，不把标签放进代码块内，不输出 meta prompt rewrite 包装。
 - Skill 正文要短；细节、来源、示例放 `references/`，靠 progressive disclosure 按需加载。
 - 战略任务必须先证据后定论：没有 deep research 的战略只能标为草案。
 - 复杂研究用 orchestrator-workers 思路拆源、拆观点、拆反证；有清晰评价标准时用 evaluator-optimizer 思路反复修正。Loop Prompt 把这个反复修正封装成可持续的循环协议：每轮执行后都更新 loop state 并产出 `Next LOOP packet`，但不在当前 GoalPro 回合自动运行。
@@ -85,18 +85,18 @@
    - `medium`：多来源支持，但缺少本地验证或存在部分反例。
    - `low`：主要来自单个帖子、单个项目、推测或未验证经验。
 8. `输出形态`：
-   - 证据足够：输出 `Research-backed Goal Prompt + Loop Prompt`。
-   - 证据不足但方向清楚：输出 `Draft Goal + Draft Loop`，标明缺口。
+   - 证据足够：输出 `Research-backed Goal Prompt`；存在真实后续迭代需求时再追加 Loop Prompt。
+   - 证据不足但方向清楚：输出 `Draft Goal`，标明缺口；存在真实后续迭代需求时再追加 Draft Loop。
    - 关键证据缺失：输出 `Research Plan`，不要假装已经能定战略。
    - 路线冲突：输出候选路线对比和推荐默认，不直接执行。
-9. `写回 Goal / Loop`：Deep Research 结果必须进入 Goal 或 Loop 字段。
+9. `写回 Goal / 可选 Loop`：Deep Research 结果必须进入 Goal；若通过 Loop 需求判断门，还要进入 Loop 字段。
    - 进入 `Decision standard`：改变优先级和取舍。
    - 进入 `Evidence standard`：规定后续还要验证什么。
    - 进入 `Scope / Non-goals`：明确做什么、不做什么。
    - 进入 `Execution policy`：决定直接做、先问、先 inventory 还是暂停。
    - 进入 `Verification`：定义怎么证明完成。
    - 进入 `Stop conditions`：定义哪些风险必须停。
-   - 进入 `Loop Prompt`：定义时间参数、上一轮要看哪些结果、如何诊断差距、本轮怎么选动作、如需自动化要单独说明哪些边界、guardrails 怎么防止失控、如何判定 Done / Continue / Pause、下一轮 LOOP 包怎么生成。
+   - 若生成 `Loop Prompt`：定义时间参数、上一轮要看哪些结果、如何诊断差距、本轮怎么选动作、如需自动化要单独说明哪些边界、guardrails 怎么防止失控、如何判定 Done / Continue / Pause、下一轮 LOOP 包怎么生成。
 
 如果研究没有改变成败标准、边界、执行策略或验证方式，就不算 deep research。
 
@@ -119,7 +119,7 @@
 7. `Evidence-bound loops`：迭代提示词必须绑定上一轮产物、验证失败、用户反馈、loop state 和剩余 delta；不能凭模型主观感觉进入下一轮。
 8. `Time-parameter-first loops`：持续循环必须先给可填写的时间参数；定时或后台运行属于自动化设置，不能由提示词本身隐式产生。
 9. `Next loop packet`：持续循环不能只说“建议继续”，每轮必须产出下一轮可复制输入包，包含原始目标、轮次、已关闭证据、开放差距、时间参数、下一轮焦点、guardrails 和停止条件。
-10. `Workflow lens`：持续、自动、发布、运营、监控、队列、复盘类请求先判断是否是重复工作；只有重复工作才把 Trigger / Checkpoint / Brief 写进 Goal Prompt / Loop Prompt。
+10. `Workflow lens`：持续、自动、发布、运营、监控、队列、复盘类请求先判断是否是重复工作；只有重复工作才把 Trigger / Checkpoint / Brief 写进 Goal Prompt，并在真实循环存在时写进 Loop Prompt。
 11. `One question with recommended answer`：阻塞问题一次只问一个，并附推荐答案；不要把产品判断负担成串丢给用户。
 
 `Workflow lens` 字段建议：
@@ -140,25 +140,26 @@
 
 ## 质量原则
 
-1. 意图放大优先：不能只复述用户原话，要说清真实意图和战略结果。
-2. 意图对齐质量门：`Intent`、`Strategic outcome`、`Decision standard`、`Execution policy`、`Verification` 必须解释同一个用户目标。
+1. 意图区分优先：分别写清用户明确表达的意图、AI 推断的潜在意图、需要用户确认的价值判断；不能把推断或价值判断冒充用户原话。
+2. 意图对齐质量门：`User-stated intent`、`AI-inferred potential intent`、`Value judgments requiring confirmation`、`Strategic outcome`、`Decision standard`、`Execution policy`、`Verification` 必须围绕同一个已确认用户目标。
 3. 反泛化：把项目名、对象名替换后仍然成立的空话，要删掉或补成具体边界。
 4. 可执行性优先：Goal 必须让执行者知道做什么、不做什么、先读什么、如何推进、何时暂停、拿什么验收。
-5. Prompt-only 边界：除非用户明确授权执行、保存、修改或提交，否则输出 Goal Prompt + Loop Prompt 后停止。
+5. Prompt-only 边界：除非用户明确授权执行、保存、修改或提交，否则输出适用的 Goal Prompt / 可选 Loop Prompt 后停止。
 6. Loop-only 边界：Loop Prompt 只用于交付后继续进化，不授权当前回合执行、修复或验证。
 7. 完成度优先：成败标准、关键边界、证据路径和取舍逻辑必须清楚。
 8. 证据优先：战略和外部事实任务必须有来源、反证、信心等级和决策影响。
 9. 进化可持续且可收敛：Loop 必须有前置时间参数、上一轮材料、loop state、差距诊断、验证 delta、Loop guardrails、Continuation protocol、Next LOOP packet 和停止条件。
-10. Workflow lens 从属：只在重复性工作中把 Trigger、Checkpoint、Brief 写进 Goal Prompt / Loop Prompt；一次性任务不要背工作流包袱，任何任务都不要新增第三段 Workflow Prompt。
-11. 推荐答案优先：不得把可推断的路线选择全丢给用户；阻塞问题要给推荐默认。
-12. 表达经济从属：只删空话，不删判断、边界、标准、验证。
-13. 每个关键字段必须能判断合格/不合格。
-14. 输出位置必须可预期：聊天默认、文件显式、文件模式也给聊天代码块。
-15. 完成后必须给样例：最终汇报除了改动和验证，还要展示一个足以让用户判断通过/不通过的样例或案例片段。
-16. 上下文读取只列会改变路线或验收的材料。
-17. 验证必须区分：未验证、结构检查、本地验证、线上验证、人工验收。
-18. 不因“看起来完整”增加机制；只为防真实失败加规则。
-19. 社区经验要过来源权重和反证筛选，不能把热闹观点写成标准。
+10. Workflow lens 从属：只在重复性工作中把 Trigger、Checkpoint、Brief 写进 Goal Prompt，并在真实循环存在时写进 Loop Prompt；一次性任务不要背工作流包袱，任何任务都不要新增第三段 Workflow Prompt。
+11. Loop 按需：复杂、多步骤、多文件或一次执行内多次验证都不自动触发 Loop；只有用户明确要求，或交付后会出现决定下一轮动作的新证据时才生成。
+12. 推荐答案优先：不得把可推断的路线选择全丢给用户；阻塞问题要给推荐默认。
+13. 表达经济从属：只删空话，不删判断、边界、标准、验证。
+14. 每个关键字段必须能判断合格/不合格。
+15. 输出位置必须可预期：聊天默认、文件显式、文件模式也给聊天代码块。
+16. 完成后必须给样例：最终汇报除了改动和验证，还要展示一个足以让用户判断通过/不通过的样例或案例片段。
+17. 上下文读取只列会改变路线或验收的材料。
+18. 验证必须区分：未验证、结构检查、本地验证、线上验证、人工验收。
+19. 不因“看起来完整”增加机制；只为防真实失败加规则。
+20. 社区经验要过来源权重和反证筛选，不能把热闹观点写成标准。
 
 ## 来源地图
 
@@ -220,15 +221,17 @@
 ## 反模式
 
 - “做得更好”但没有用户、目标和验收。
-- `Intent` 只是复述用户原话，没有说明用户真正要改变的局面。
+- 把 AI 推断的潜在意图或价值判断写进 `User-stated intent`，冒充用户已经表达或确认。
+- 用单一 `Intent` 混合用户原话、AI 推断和价值判断，导致责任边界不清。
 - Goal Prompt 字段齐全，但互相不支撑：战略结果、执行策略和验收证据各说各话。
 - 把项目名、对象名替换后仍然成立，说明它只是通用好话。
 - 把“写 goal”误当成“开始执行 goal”。
 - 把“写 loop”误当成“当前回合继续修复或验证”。
+- 给一次性交付、复杂任务或多步骤执行默认附送 Loop Prompt，却没有交付后新证据和下一轮动作。
 - Loop Prompt 不看上一轮真实结果和 loop state，只泛泛要求“继续优化”。
 - Loop Prompt 只写 Continue / Next，却不给用户可填写的时间参数。
 - 把时间参数当成已经创建的后台自动化，没有调度器、频率、时区、输入来源、权限和暂停规则。
-- 把 workflow lens 当成第三个交付物，输出 `Workflow Prompt`、流程图或执行计划，反而弱化了 Goal Prompt + Loop Prompt。
+- 把 workflow lens 当成第三个交付物，输出 `Workflow Prompt`、流程图或执行计划，反而弱化了适用的 Goal Prompt / 可选 Loop Prompt。
 - 把所有任务都当 workflow，给一次性任务硬塞 Trigger、Checkpoint、Brief。
 - 问用户一串开放问题，却不给推荐答案；或者明明能读上下文解决，仍把问题甩给用户。
 - Checkpoint 太早，用户还没看到准备好的材料就被迫做判断。