helloagents 3.0.32 → 3.0.35

package/skills/commands/auto/SKILL.md

@@ -1,18 +1,18 @@
 ---
 name: ~auto
-description: 自动执行命令 — 自动选择并依次执行 ~idea / ~plan / ~build / ~verify / ~prd，默认持续推进直到交付完成（~auto 命令）
+description: 自动执行命令 — 自动选择并依次执行 ~idea / ~plan / ~build / ~qa / ~prd，默认持续推进直到交付完成（~auto 命令）
 policy:
   allow_implicit_invocation: false
 ---
 Trigger: ~auto <任务描述>
 
-`~auto` 是自动执行命令。它根据任务类型、复杂度、风险等级与项目状态，在 `~idea`、`~plan`、`~build`、`~verify`、`~prd` 之间选择合适主路径，并连续推进。
+`~auto` 是自动执行命令。它根据任务类型、复杂度、风险等级与项目状态，在 `~idea`、`~plan`、`~build`、`~qa`、`~prd` 之间选择合适主路径，并连续推进。
 `~auto` 不止做一次选路；主路径一旦确定，就按需要继续执行后续阶段，默认持续推进直到完成交付，只有命中 HelloAGENTS 阻塞判定时才停下。
 
 ## 铁律
 - 不为了“自动化”而强行走重流程
 - 复杂度与风险不足以支撑更重路径时，优先选更轻但能保证质量的路线
-- `T3` 高风险或不可逆操作默认不直接进入 `~build`；优先先走 `~plan` 或 `~prd`，纯审查/纯验证请求才可先进入 `~verify`
+- `T3` 高风险或不可逆操作默认不直接进入 `~build`；优先先走 `~plan` 或 `~prd`，纯质量审查、验真或收尾请求才可先进入 `~qa`
 - 主路径一旦确定，立即读取对应 command skill，并在阶段完成后继续执行后续阶段，避免同一任务重复探索或重复等待
 - 选路不替代授权；涉及外部副作用或高风险不可逆操作时，仍遵守 HelloAGENTS 阻塞判定与确认规则
 - 用户显式使用 `~auto`，表示已授权在当前任务边界内沿选定主路径持续执行；若当前运行在 Codex `/goal` 下，`/goal` 只提供长程续跑与预算，`~auto` 仍按方案包、`state_path` 与验证契约推进；`~plan` / `~prd` 作为中间阶段时，不再额外询问“是否开始执行”，除非仍有真实阻塞；不得把 `🔄 下一步` 当作阶段交接或继续执行占位
@@ -25,8 +25,8 @@ Trigger: ~auto <任务描述>
 - 若当前上下文中已注入“当前工作流提示”或“当前工作流约束”，优先服从其中的推荐下一命令 / 主路径
 - 默认原则：
   - 活跃方案包不完整或缺少任务清单 → 先 `~plan`
-  - 活跃方案包仍在执行 → 先 `~build`，完成当前实现后再 `~verify`
-  - 活跃方案包已闭合 → 先 `~verify` 或收尾
+  - 活跃方案包仍在执行 → 先 `~build`，完成当前实现后再 `~qa`
+  - 活跃方案包已闭合 → 先 `~qa` 或收尾
   - Codex active goal 已关联方案包 → 按 `tasks.md` 未完成 AFK 项、`contract.json` 与 `state_path` 确定主路径，不把 goal 目标原文替代方案包
 - 只有当用户明确要求换方向、重做方案，或现有方案已失效时，才偏离当前推荐重新规划
 
@@ -36,7 +36,7 @@ Trigger: ~auto <任务描述>
 - 若当前上下文没有足够的注入约束，再结合以下信号补足判断：影响范围、风险等级、是否需要结构化产物、是否已有活跃方案包、用户是否只想先比较方向
 - 选路优先级：
   - 纯探索 / 点子 / 方向比较 → `~idea`
-  - 明确要求验证 / 审查 / 跑检查 → `~verify`
+  - 明确要求质量审查 / 验真 / 跑检查 / 收尾 → `~qa`
   - 0 到 1 / 产品级 / 多维规格 → `~prd`
   - 多文件功能 / 架构变更 / 新项目规划 → `~plan`
   - 明确修复 / 小范围实现 / 按现有方案实现 → `~build`
@@ -44,28 +44,28 @@ Trigger: ~auto <任务描述>
 ### 2. 按 Tier 校正
 
 - `T0` → 保持在 `~idea`，不创建项目文件
-- `T1` → 在 `~build` / `~verify` 间选择最短可交付路径
+- `T1` → 在 `~build` / `~qa` 间选择最短可交付路径
 - `T2` → 需要结构化产物或范围未完全明确时优先 `~plan`
-- `T3` → 纯审查/验真走 `~verify`；其余默认 `~plan` 或 `~prd`，待方案与风险边界明确后再进入实现
+- `T3` → 纯质量审查/验真走 `~qa`；其余默认 `~plan` 或 `~prd`，待方案与风险边界明确后再进入实现
 
 ### 3. 读取对应命令并执行主路径
 
 - 选中 `idea` → 读取 `skills/commands/idea/SKILL.md`
 - 选中 `plan` → 读取 `skills/commands/plan/SKILL.md`
 - 选中 `build` → 读取 `skills/commands/build/SKILL.md`
-- 选中 `verify` → 读取 `skills/commands/verify/SKILL.md`
+- 选中 `qa` → 读取 `skills/commands/qa/SKILL.md`
 - 选中 `prd` → 读取 `skills/commands/prd/SKILL.md`
 
 不要额外读取未选中的 command skill。
 
 ### 4. 持续执行直到完成
 
-- 若主路径是 `~build` → 完成实现后继续进入 `~verify`，再进入收尾
+- 若主路径是 `~build` → 完成实现后继续进入 `~qa`，再进入收尾
 - 若主路径是 `~plan` → 方案包写入后，若当前任务来自 `~auto` 且未命中阻塞判定，直接继续进入 `~build`，不要把“方案已形成”当作最终停点
 - 若主路径是 `~prd` → PRD / 任务 / 契约写入后，若当前任务来自 `~auto` 且未命中阻塞判定，按当前结果继续进入 `~build`，必要时先补一轮轻量 `~plan`
-- 若主路径是 `~verify` → 完成审查 / 验证 / 收尾后结束
+- 若主路径是 `~qa` → 完成质量闭环 / 收尾后结束
 - 若主路径是 `~idea`，且用户本意就是探索/比较，则在探索输出后结束；若探索后已有明确方向且当前任务仍要求写文件或改代码，则继续进入 `~plan` 或 `~build`
-- 若 Codex active goal 的目标已满足 → 仍先完成 `~verify` 与 HelloAGENTS 收尾，再标记 goal complete；未满足时继续下一项可执行 AFK 任务
+- 若 Codex active goal 的目标已满足 → 仍先完成 `~qa` 与 HelloAGENTS 收尾，再标记 goal complete；未满足时继续下一项可执行 AFK 任务
 
 ### 5. 何时允许停下
 

package/skills/commands/build/SKILL.md

@@ -6,8 +6,8 @@ policy:
 ---
 Trigger: ~build [description]
 
-`~build` 是执行实现命令。它负责读取现有需求、方案包与项目上下文，完成实现、局部验证、修复循环，并把结果交给后续验证与收尾。
-执行 `~build` 时，通用阶段边界按当前已加载的 HelloAGENTS 规则执行；本 skill 负责补充实现前定位、实现约束，以及进入 `~verify` / 收尾前的实现边界。
+`~build` 是执行实现命令。它负责读取现有需求、方案包与项目上下文，完成实现、局部验证、修复循环，并把结果交给后续质量闭环与收尾。
+执行 `~build` 时，通用阶段边界按当前已加载的 HelloAGENTS 规则执行；本 skill 负责补充实现前定位、实现约束，以及进入 `~qa` / 收尾前的实现边界。
 `.helloagents/` 在本 skill 中统一按项目级存储路径理解：状态文件只使用 `state_path`；会话证据使用当前 `state_path` 所在目录下的 `artifacts/*.json`；若 `project_store_mode=repo-shared`，知识库、`DESIGN.md`、`verify.yaml` 与方案包按当前上下文中已注入的项目知识/方案目录解析。
 
 ## 铁律
@@ -27,7 +27,7 @@ Trigger: ~build [description]
   - `tasks.md`
   - `contract.json`
   - 实现时优先把 `tasks.md` 中每个任务的“完成标准”当作本次实现约束，不要只按任务标题猜测范围
-  - `contract.json` 存在时，优先按其中的 `verifyMode`、`reviewerFocus`、`testerFocus` 理解后续验证边界
+  - `contract.json` 存在时，优先按其中的 `qaMode`、`qaFocus` 理解后续质量闭环边界
 - 若当前运行在 Codex active goal 下，按 `tasks.md` 未完成项、`contract.json` 与 `state_path` 恢复实现位置；不要自动创建新 goal，也不要把 goal 目标原文替代方案包
 - 若当前上下文中已注入“当前工作流约束”或“当前推荐下一命令”，先服从它；只有推荐仍为 `~build`，或用户明确提出新增实现范围时，才继续 `~build`
 - 其余项目知识库与相关代码文件，按 HelloAGENTS 项目上下文要求读取
@@ -53,17 +53,16 @@ Trigger: ~build [description]
   - 每次编辑后主动跑确定性检查
 - 可并行任务通过子代理执行，但不同子代理不得改同一文件
 
-### 4. 验证与修复循环
+### 4. 局部验证与修复循环
 
-- 读取 `hello-verify` SKILL.md
-- 运行 lint / typecheck / test / build 等验证
+- 按当前任务与 `tasks.md` 中的“验证方式”运行 lint / typecheck / test / build 等局部验证
 - 若失败，修复后重跑
-- 若涉及 review 场景，可按需读取 `hello-review`
+- 若当前实现已接近交付，主动对照 `qaFocus` 自检本次改动是否覆盖关键风险
 
 ### 5. 交付前处理
 
 - 有方案包时，只同步本次实现直接影响的任务状态；未完成项保持打开
-- 当前实现已闭合、且需要进入交付或收尾时，转入 `~verify`
-- 若 Codex active goal 仍有未完成 AFK 任务，继续下一项可执行任务；若目标已满足，先转入 `~verify` 与 HelloAGENTS 收尾，再标记 goal complete
-- 状态文件、知识库、`CHANGELOG.md`、modules 文档与归档边界，按当前已加载的 HelloAGENTS 规则进入 VERIFY / CONSOLIDATE
+- 当前实现已闭合、且需要进入交付或收尾时，转入 `~qa`
+- 若 Codex active goal 仍有未完成 AFK 任务，继续下一项可执行任务；若目标已满足，先转入 `~qa` 与 HelloAGENTS 收尾，再标记 goal complete
+- 状态文件、知识库、`CHANGELOG.md`、modules 文档与归档边界，按当前已加载的 HelloAGENTS 规则进入 QA / CONSOLIDATE
 - 不在 `~build` 内把仍未闭合的方案包整体报告为已完成

package/skills/commands/commit/SKILL.md

@@ -27,5 +27,5 @@ Trigger: ~commit [message]
 提交后，继续复用上方已解析的同一份设置获取 `kb_create_mode`，不要再次读取 `~/.helloagents/helloagents.json`：
 - 0 = 跳过
 - 1 = 知识库已存在时自动同步（默认）
-- 2 = 编码任务在知识库已存在或全局模式下自动创建或同步
+- 2 = 编码任务在知识库已存在或当前项目已初始化时自动创建或同步
 同步范围与更新格式按当前已加载的 HelloAGENTS CONSOLIDATE 阶段执行。

package/skills/commands/help/SKILL.md

@@ -12,16 +12,14 @@ Trigger: ~help
 | 命令 | 说明 |
 |------|------|
 | ~idea | 轻量点子探索与方向比较 |
-| ~auto | 自动执行：自动选主路径并持续推进到执行 / 验证 / 收尾，除非命中真实阻塞 |
+| ~auto | 自动执行：自动选主路径并持续推进到实现 / 质量闭环 / 收尾，除非命中真实阻塞 |
 | ~plan | 结构化规划：需求澄清 + 方案确认 + 方案包 |
-| ~build | 执行实现：按需求或方案包完成实现与验证 |
+| ~build | 执行实现：按需求或方案包完成实现与局部验证 |
 | ~prd | 完整 PRD：头脑风暴式逐维度挖掘，生成现代产品需求文档 |
-| ~loop | 自主迭代优化：设定目标和指标，循环修改-验证-保留/回滚 |
-| ~wiki | 仅创建/同步项目知识库 |
-| ~init | 同 `~wiki` |
-| ~global | 初始化项目级全局模式 |
+| ~loop | 长任务入口：在 Codex 中优先走 `/goal -> ~auto -> ~qa` |
+| ~init | 初始化项目工作流并同步知识库 |
 | ~test | 为指定模块或最近变更编写完整测试 |
-| ~verify | 验证总入口：审查 + 运行验证命令 + 修复循环 |
+| ~qa | 统一质量总入口：审查 + 运行验证命令 + 修复循环 + 收尾前证据 |
 | ~commit | 规范化提交 + 知识库同步 |
 | ~clean | 清理临时文件和归档方案包 |
 | ~help | 显示此帮助 |
@@ -29,15 +27,15 @@ Trigger: ~help
 兼容别名：
 - `~do` → 等同 `~build`
 - `~design` → 等同 `~plan`
-- `~review` → 等同 `~verify` 的审查优先模式
+- `~review` → 等同 `~qa`
 
 ### 自动激活技能
-以下技能仅在全局模式或已初始化项目时自动激活（例如执行过 `~global`，或当前项目级规则文件已包含 `<!-- HELLOAGENTS_PROFILE: full -->`）。
+以下技能仅在宿主全局模式或已初始化项目时自动激活（例如当前项目级规则文件已包含 `<!-- HELLOAGENTS_PROFILE: full -->`，通常由 `~init` 建立）。
 纯标准模式、且项目未初始化时不会自动触发这些技能；但涉及 UI 的任务仍受 UI 质量基线约束。
 
 编码时：hello-ui, hello-api, hello-data, hello-security, hello-errors, hello-perf, hello-arch, hello-test
-特定场景：hello-debug, hello-subagent, hello-write, hello-review
-完成时：hello-verify, hello-reflect
+特定场景：hello-debug, hello-subagent, hello-write
+完成时：qa-review, hello-reflect
 
 ### 当前设置
 优先使用当前会话上下文中已注入的“当前用户设置”、该配置文件原始 JSON 或此前读取结果摘要显示；若会话上下文不存在该信息，或缺少下表任一配置项，才读取一次 `~/.helloagents/helloagents.json`，并在后续轮次复用。对 Codex 来说，首次对话前若当前上下文仍缺少这些配置项，或刚经历压缩/恢复后的首次对话，同样先读取一次再继续。
@@ -47,9 +45,9 @@ Trigger: ~help
 | output_language | "" | 空=跟随用户语言/填写则指定（如 zh-CN、en） | Claude Code + Gemini CLI + Codex CLI |
 | output_format | true | true=主代理最终回复必须使用 HelloAGENTS 格式，流式/中间输出及子代理输出保持自然；false=自然输出 | Claude Code + Gemini CLI + Codex CLI |
 | notify_level | 0 | 0=关闭/1=桌面通知/2=声音/3=两者 | Claude Code + Gemini CLI + Codex CLI |
-| ralph_loop_enabled | true | 自动验证循环（显式 ~verify / ~loop 或收尾要求时触发 lint/test/build） | Claude Code + Gemini CLI + Codex CLI |
+| ralph_loop_enabled | true | 收尾 QA gate（显式 ~qa / ~loop 或收尾要求时触发审查、lint/test/build） | Claude Code + Gemini CLI + Codex CLI |
 | guard_enabled | true | 阻断危险命令与写入后的安全扫描 | Claude Code + Gemini CLI + Codex CLI |
-| kb_create_mode | 1 | 0=关闭/1=知识库已存在时自动同步/2=编码任务在知识库已存在或全局模式下自动创建或同步 | Claude Code + Gemini CLI + Codex CLI |
+| kb_create_mode | 1 | 0=关闭/1=知识库已存在时自动同步/2=编码任务在知识库已存在或当前项目已初始化时自动创建或同步 | Claude Code + Gemini CLI + Codex CLI |
 | project_store_mode | "local" | "local"=知识库/方案包保留在项目本地 `.helloagents/`；"repo-shared"=本地 `.helloagents/` 仅保留项目本地状态/运行态，知识库与方案包改写到 `~/.helloagents/projects/<repo-key>/` | Claude Code + Gemini CLI + Codex CLI |
 | auto_commit_enabled | true | true=验证完成且有变更时自动执行本地提交；false=跳过自动提交，仍可手动用 `~commit` | Claude Code + Gemini CLI + Codex CLI |
 | commit_attribution | "" | 空=不添加/填写内容则添加到 commit message | Claude Code + Gemini CLI + Codex CLI |

package/skills/commands/init/SKILL.md

@@ -1,31 +1,39 @@
 ---
 name: ~init
-description: 初始化或同步项目知识库（与 ~wiki 同义）
+description: 初始化项目工作流并同步知识库
 policy:
   allow_implicit_invocation: false
 ---
 Trigger: ~init
 
-`~init` 是用户显式命令，仅创建、补全或同步项目知识库。
-`~init` 与 `~wiki` 同义，不受 `kb_create_mode` 限制。
-执行 `~init` 时，`.helloagents/` 目录结构、模板格式和状态文件重写规则按当前已加载的 HelloAGENTS 规则执行；不写入项目级规则文件，也不创建项目级 HelloAGENTS 包根链接。
+`~init` 是用户显式命令，用来初始化或刷新当前项目的完整工作流。
+它不受 `kb_create_mode` 限制。
+执行 `~init` 时，按当前规则模板创建或更新项目本地 `.helloagents/`，同步知识库，并为支持的宿主写入项目级 full carrier 标记：`<!-- HELLOAGENTS_PROFILE: full -->`。
 `.helloagents/` 在本 skill 中统一按项目级存储路径理解：项目本地 `.helloagents/` 继续承担项目本地存储目录；状态文件只使用 `state_path`；若 `project_store_mode=repo-shared`，知识库、`DESIGN.md` 与方案包按当前上下文中已注入的项目知识/方案目录写入。
 
 ## 流程
 
-### 阶段 1：基础准备（必做）
+### 阶段 1：初始化项目工作流（必做）
 
-1. 创建 `.helloagents/` 目录 + `state_path`（按 templates/STATE.md 格式，初始“主线目标”写当前知识库初始化 / 同步任务，初始状态为空闲）
-2. 追加 `.gitignore`（如果对应行不存在）：
+1. 创建 `.helloagents/` 目录 + `state_path`（按 templates/STATE.md 格式，初始“主线目标”写当前项目初始化任务，初始状态为空闲）
+2. 用当前完整规则模板刷新项目级规则文件，在受管内容第一行写入 `<!-- HELLOAGENTS_PROFILE: full -->`，再用 `<!-- HELLOAGENTS_START -->` / `<!-- HELLOAGENTS_END -->` 包裹后写入：
+   - `AGENTS.md`
+   - `CLAUDE.md`
+   - `.gemini/GEMINI.md`（不存在则先创建 `.gemini/` 目录）
+   如果文件已存在且包含标记，替换标记内内容；已存在但无标记，则追加到末尾；不存在则新建
+3. 追加 `.gitignore`（如果对应行不存在）：
    ```
    .helloagents/
+   AGENTS.md
+   CLAUDE.md
+   .gemini/GEMINI.md
    ```
 
 ### 阶段 2：知识库创建或补全（条件性）
 
 检查项目是否有实际代码文件（非空项目）：
 - 有代码文件 → 执行完整知识库创建（下方流程）
-- 空项目 → 跳过，告知用户"项目为空，知识库将在后续开发中创建"
+- 空项目 → 保留 `.helloagents/` 和项目级规则文件，告知用户"项目为空，其余知识文件将在后续开发或首次编码任务中补全"
 
 知识库创建/补全流程（统一写入 `.helloagents/` 对应的项目级存储路径；`project_store_mode=repo-shared` 时实际落在共享知识目录）：
 1. 按 templates/ 目录的模板格式，分析项目代码库后生成：
@@ -35,7 +43,7 @@ Trigger: ~init
    - CHANGELOG.md — 按 templates/CHANGELOG.md 格式，初始版本
    - DESIGN.md — 如果项目包含 UI 代码，按 templates/DESIGN.md 格式提取项目级设计契约（产品表面、设计 token、组件与模式、状态覆盖、无障碍要求、禁止事项等）
 2. 创建 modules/ 目录，按 templates/modules/module.md 格式为主要模块生成文档
-3. 不覆盖已存在的文件
+3. 已存在的文件按模板增量更新，不自由改写结构；无新增信息时保持原样
 
 ## verify.yaml 格式
 ```yaml
@@ -48,5 +56,6 @@ commands:
 重复执行 ~init 是安全的：
 - `.helloagents/` 缺失时创建，已存在时复用
 - `state_path` 按当前任务状态重写，不追加历史；它只记录当前知识库任务，不承担项目的长期记忆
+- 项目级规则文件中的受管标记块会刷新到最新
 - 知识库文件缺失时补全，已存在时按模板增量更新
 - `.gitignore` 只追加缺失行

package/skills/commands/loop/SKILL.md

@@ -1,101 +1,75 @@
 ---
 name: ~loop
-description: 自主迭代优化循环 — 设定目标和指标，AI 自主循环修改-验证-保留/回滚，直到达成目标或达到迭代上限（~loop 命令）
+description: 长任务入口 — 在 Codex 中优先走 `/goal -> ~auto -> ~qa`，把长程续跑交给 `/goal`，把执行推进交给 `~auto`，把最终质量闭环交给 `~qa`（~loop 命令）
 policy:
   allow_implicit_invocation: false
 ---
-Trigger: ~loop <目标描述> [--iterations N] [--metric "命令"] [--direction higher|lower] [--guard "命令"]
-
-## 交互式配置
-
-如果用户未提供完整参数，通过对话确认以下配置：
-- 目标：优化什么？（如：提升测试覆盖率、减少构建时间、提升性能分数）
-- 指标命令：运行什么命令获取数值？（如：`npm run test -- --coverage`）
-- 方向：higher（越高越好）还是 lower（越低越好）？
-- 迭代上限：最多跑几轮？（默认 20，无上限则设为 0）
-- 守卫命令（可选）：每轮必须通过的底线检查（如：`npm test`）
-- 作用范围：哪些文件/目录可以修改？
-
-## 初始化
-
-1. 确认 git 工作区干净（有未提交变更则先提醒用户处理）
-2. 确保 `.helloagents/` 目录和 `state_path` 存在；文件不存在时按 `templates/STATE.md` 创建。`~loop` 必须维护这个状态文件，不受 `kb_create_mode` 控制；“主线目标”固定写本次优化目标，避免混入其他任务
-3. 运行指标命令获取基线值，记录到 results log
-4. 如有守卫命令，运行确认基线通过
-5. 创建当前会话的 `.helloagents/sessions/{workspace}/{session}/artifacts/loop-results.tsv`
-6. 根据优化目标标记可能需要的 hello-* 质量技能（如性能优化标记 hello-perf，UI 优化标记 hello-ui）
-7. 重写 `state_path`：记录主线目标=当前优化目标、基线指标、守卫命令、下一步设为第一轮迭代的具体动作
-
-results log 格式：
-```
-# metric_direction: higher_is_better
-iteration	commit	metric	delta	guard	status	description
-0	a1b2c3d	85.2	0.0	pass	baseline	initial state
-```
-
-## 八阶段循环
-
-`~loop` 的八阶段循环是统一执行流程（ROUTE/TIER→SPEC→PLAN→BUILD→VERIFY→CONSOLIDATE）在迭代优化场景下的特化形式。每轮迭代的“修改”阶段遵循已标记的 hello-* 质量技能规范，“验证”阶段遵循 hello-verify 的验证规范。
-执行 `~loop` 时，涉及公共阶段边界、阻塞判定与收尾要求的部分，仍按当前已加载的 HelloAGENTS 规则执行；本 skill 负责补充 loop 场景的迭代顺序与回滚规则。
-若当前运行在 Codex `/goal` 下，`/goal` 只作为外层长程续跑与预算控制；`~loop` 仍负责指标、守卫、实验提交、keep/revert、results log、`state_path` 与收尾验证，不把 `/goal` 当成循环逻辑本身。
-
-除非达到迭代上限或命中阻塞判定，否则继续执行，不额外询问是否继续，也不把 `🔄 下一步` 当作单轮结果或继续执行占位。
-每轮迭代必须完整走完以下八个阶段：
-
-### 第 1 阶段：回顾
-- 读取 results log 最近 10-20 条记录
-- 运行 `git log --oneline -20` 查看最近变更
-- 运行 `git diff HEAD~1` 查看上一次变更
-- 如果 git log 有 results log 中未记录的 experiment commit → 上轮可能中断，先运行指标命令补录结果
-- 识别：什么有效、什么无效、什么还没试过
-
-### 第 2 阶段：构思
-- 基于 review 结果，选择下一个改进方向
-- 优先尝试未探索的方向
-- 避免重复已失败的方向（git history 是记忆）
-- 连续 5 次 discard → 升级策略：组合近似成功的尝试、尝试相反方向、考虑架构级变更
-
-### 第 3 阶段：修改
-- 做一个原子修改（单一关注点）
-- 只修改作用范围内的文件
-- 不修改测试文件和守卫命令涉及的文件
-
-### 第 4 阶段：提交
-- 在验证之前提交（便于干净回滚）
-- commit message 格式：`experiment(<scope>): <description>`
-
-### 第 5 阶段：验证
-- 运行指标命令，获取新值
-- 计算 delta（新值 - 基线或上一次保留值）
-- 如有守卫命令，运行守卫检查
-
-### 第 6 阶段：决策
-- IMPROVED（指标改善 + 守卫通过）→ keep
-- SAME/WORSE（指标未改善）→ `git revert HEAD`（保留历史）
-- GUARD FAILED（指标改善但守卫失败）→ 尝试修复（最多 2 次），仍失败则 revert
-- CRASHED（命令执行失败）→ revert + 记录
-
-### 第 7 阶段：记录
-- 追加一行到 results log
-- status: baseline / keep / discard / crash / no-op
-- 重写 `state_path`：保持主线目标=当前优化目标，并记录当前迭代轮次、最近一次决策（keep / discard / crash）、当前最佳指标、下一步动作
-
-### 第 8 阶段：继续
-- 如果 iterations > 0 且 current_iteration >= max_iterations → 输出总结并停止
-- 否则 → 回到 Phase 1
-
-## 总结输出
-
-循环结束时输出：
-- 基线值 → 最终值（改善幅度）
-- 总迭代次数 / 保留次数 / 丢弃次数
-- 最有效的 3 个改进
-- results log 路径
-- 重写 `state_path`：将“主线目标”保留为本次优化目标，“正在做什么”更新为已完成，保留最终结论摘要，清空阻塞项，并给出可立即执行的下一步（如继续优化、停止、切换目标）
-- 若 Codex `/goal` 处于 active 且目标已达成，完成 HelloAGENTS 验证和收尾后再标记 goal complete；不得因达到预算或单轮结束而标记 complete
-
-## 安全规则
-- 使用 `git revert`（保留历史）而非 `git reset --hard`（丢失历史）
-- 不修改测试文件和守卫命令涉及的文件
-- 单次修改涉及 >5 个文件 → 重新评估，可能需要拆分
-- 守卫命令是底线，指标改善但守卫失败 = 不可接受
+Trigger: ~loop <目标描述>
+
+`~loop` 不再维护独立的指标实验循环。它是长任务入口，默认把链路收敛为：
+
+`/goal -> ~auto -> ~qa`
+
+其中：
+- `/goal` 负责长程续跑、恢复与预算
+- `~auto` 负责按方案包持续推进 AFK 任务
+- `~qa` 负责最终审查、验证命令、阻断修复、回归验证与收尾证据
+
+## 适用边界
+
+- 适合：多轮持续执行、跨会话恢复、较长的 AFK 任务
+- 不适合：普通小任务、单轮可完成任务、单纯质量审查；这些优先直接走 `~auto` 或 `~qa`
+- 真正的指标实验、benchmark 对赌、keep/revert 试验，不再由 `~loop` 承担
+
+## 流程
+
+### 0. 当前工作流优先
+
+- 若当前上下文中已注入“当前工作流约束”或“当前推荐下一命令”，先服从它
+- `~loop` 不是绕过方案包和质量契约的越级入口；它只是把长任务执行链路固定为 `/goal -> ~auto -> ~qa`
+
+### 1. 先落稳方案包
+
+- 优先复用当前活跃方案包
+- 若当前没有足够可信的方案包，而任务又属于长任务、跨模块任务或高风险任务，先补 `~plan` 或 `~prd`
+- `tasks.md` 必须能支撑长程执行：任务按顺序拆好，标注 `AFK` / `HITL`，写清依赖、涉及文件、完成标准和验证方式
+- `contract.json` 必须至少落成 `qaMode` 与 `qaFocus`
+
+### 2. Codex + goals 已启用时
+
+- 把 `~loop` 视为 Codex 的长任务入口，优先直接进入 `/goal`
+- `/goal` 不直接消费原始需求文档；只消费当前方案包里的 “Codex /goal 执行入口”
+- `/goal` 入口必须明确以下约束：
+  - 默认主执行命令是 `~auto`
+  - 按 `tasks.md` 顺序完成所有可执行 `AFK` 任务
+  - `HITL` 只在缺少用户决策、凭据、人工验收或其他真实阻塞时暂停
+  - 不得把单轮结果、阶段总结或“下一步建议”当成完成
+  - 全部 `AFK` 任务完成后，必须进入 `~qa`
+  - 只有 `~qa` 通过、当前会话证据写全、HelloAGENTS 收尾完成后，才允许标记 goal complete
+- 若当前已经运行在 Codex active goal 下，继续沿当前 goal 执行，不重复创建新 goal
+
+### 3. 非 Codex 或 goals 不可用时
+
+- 明确当前无法使用 Codex 原生 `/goal`
+- 仍按同一意图执行长任务，但只走 `~auto -> ~qa`
+- 这种情况只是无 `/goal` 的降级路径，不把它包装成等价的 goal 能力
+
+### 4. 执行期间的状态维护
+
+- `~loop` 必须维护 `state_path`
+- “主线目标”写当前长任务目标
+- “正在做什么”写当前 `AFK` 任务或当前收尾阶段
+- “下一步”写下一条具体可执行动作，必要时带文件路径
+- 若当前运行在 Codex active goal 下，`state_path` 仍只负责本地恢复，不替代 goal 自身状态
+
+### 5. 禁止事项
+
+- 不再创建基线指标、results log、keep/revert 实验提交或守卫命令循环
+- 不把 `/goal` 当作质量验收器；最终质量闭环始终由 `~qa` 负责
+- 仍有可执行 `AFK` 任务时，不进入 complete
+- 没有最新 `qa-review.json`、需要的 `advisor.json` / `visual.json` / `closeout.json` 时，不得报告完成
+
+## 完成判定
+
+- 只有当长任务链路已经走到 `~qa`，并且质量闭环通过、收尾证据完整、HelloAGENTS 允许进入 CONSOLIDATE 时，`~loop` 才算完成
+- 若当前任务来自 Codex active goal，还要满足：当前 goal 的可执行 `AFK` 任务已全部完成，才允许标记 goal complete

package/skills/commands/plan/SKILL.md

@@ -12,7 +12,7 @@ Trigger: ~plan [description]
 
 ## 铁律
 - 在用户确认方案之前，禁止编写任何实现代码、创建任何实现文件、或执行任何实现操作
-- 需求澄清阶段不读取实现类技能（hello-ui / hello-test / hello-verify 等），需求明确后再按需读取
+- 需求澄清阶段不读取实现类技能（hello-ui / hello-test / qa-review 等），需求明确后再按需读取
 - 方案必须整理为可执行产物，不停留在泛化建议
 - 若当前任务来自 `~auto`，则“开始执行”视为已包含在 `~auto` 授权内；方案包写入后默认继续执行，只有命中阻塞判定时才停下。`~design` 是 `~plan` 的兼容别名，只有在 `~auto` 内触发其语义时才默认继续进入 `~build`
 - 涉及 UI 时，当前方案包中的 UI 决策优先于 `.helloagents/DESIGN.md`；`.helloagents/DESIGN.md`（按当前项目存储模式解析）优先于已读取的 `hello-ui` 规则；同时所有 UI 任务都必须满足 UI 质量基线
@@ -66,7 +66,7 @@ Trigger: ~plan [description]
 
 用户确认方向后，一次性输出完整可执行方案：
 - 架构与文件结构
-- 完成定义（功能完成时必须为真的条件、关键验收点、验证主路径= `test-first` 或 `review-first`、reviewer / tester 各自要验证什么）
+- 完成定义（功能完成时必须为真的条件、关键验收点、`qaMode`、`qaFocus`、进入收尾前必须补齐的质量证据）
 - 数据流与错误处理
 - 验证策略
 - 涉及 UI 时的设计方向、状态覆盖与 `DESIGN.md` 更新点
@@ -82,12 +82,12 @@ Trigger: ~plan [description]
   - `plan.md`
   - `tasks.md`
   - `contract.json`
-- 写 `contract.json` 时，至少落成以下字段：`verifyMode`、`reviewerFocus`、`testerFocus`；涉及 UI 时再写 `ui.required`、`ui.designContract` 与 `ui.sourcePriority`
+- 写 `contract.json` 时，至少落成以下字段：`qaMode`、`qaFocus`；涉及 UI 时再写 `ui.required`、`ui.designContract` 与 `ui.sourcePriority`
 - 只有在 UI 方向确需先明确时，才额外写 `ui.styleAdvisor.required`、`ui.styleAdvisor.reason` 与 `ui.styleAdvisor.focus`；它复用当前会话 `artifacts/advisor.json`，不是默认常驻步骤
 - 只有在 UI 验收确有收益时，才额外写 `ui.visualValidation.required`、`ui.visualValidation.reason`、`ui.visualValidation.screens` 与 `ui.visualValidation.states`；不要把视觉验收扩成所有 UI 任务的固定步骤
 - 只有在 `T3`、非 UI 的高风险审查或确需额外跨模型建议时，才写 `advisor.required`、`advisor.reason`、`advisor.focus` 与 `advisor.preferredSources`；不要把 advisor 变成默认常驻流程
 - 使用 `scripts/plan-contract.mjs write` 写 `contract.json`，不要让后续检查脚本再从 `plan.md` 的自然语言说明里猜验证主路径
-- 在 `tasks.md` 中保留 “Codex /goal 执行入口”，内容必须引用当前方案包路径、AFK/HITL 边界、完成前验证与 HelloAGENTS 收尾；不要把普通 PRD 原文当作 `/goal` 目标
+- 在 `tasks.md` 中保留 “Codex /goal 执行入口”，内容必须引用当前方案包路径、AFK/HITL 边界，并明确 `/goal -> ~auto -> ~qa` 这条链路；不要把普通 PRD 原文当作 `/goal` 目标
 - 涉及 UI 的项目：生成或更新 `.helloagents/DESIGN.md`（按当前项目存储模式解析）；若原文件不存在，先按模板建立最小设计契约，再写入已确认的稳定设计决策
 - 重写 `state_path`，其中“主线目标”写本次规划要完成的目标，不保留其他任务的内容
 
@@ -111,12 +111,11 @@ Trigger: ~plan [description]
 - 每个任务标注 `AFK` 或 `HITL`：`AFK` 表示代理可独立完成，`HITL` 表示需要用户决策、外部凭据、人工视觉确认或手动验收
 - 明确文件路径、预期变更、完成标准、验证方式与依赖关系
 - 每个任务可独立验证；厚任务必须拆成更薄的可验收切片
-- “Codex /goal 执行入口”只作为长程执行提示，不计入任务列表；入口必须让 Codex 按已拆好的 `tasks.md` 执行，而不是直接消费未拆分需求文档
+- “Codex /goal 执行入口”只作为长程执行提示，不计入任务列表；入口必须让 Codex 按已拆好的 `tasks.md` 执行，默认主执行命令是 `~auto`，最终必须进入 `~qa`，而不是直接消费未拆分需求文档
 
 方案包中的 `contract.json` 必须满足：
-- `verifyMode` 只能是 `test-first` 或 `review-first`
-- `testerFocus` 必填
-- `review-first` 时 `reviewerFocus` 必填
+- `qaMode` 只能是 `standard` 或 `deep`
+- `qaFocus` 必填
 - 涉及 UI 时显式写出 UI 契约来源优先级
 - 若启用 `ui.styleAdvisor`，必须写清触发原因与 focus
 - 若启用 `ui.visualValidation`，必须写清触发原因，以及至少一组关键 screens 或 states

package/skills/commands/prd/SKILL.md

@@ -103,9 +103,9 @@ c. AI 总结该维度的决策结果，进入下一个维度
 - 创建 `.helloagents/plans/YYYYMMDDHHMM_{feature}/prd/`（按当前项目存储模式解析）
 - 按 templates/plans/prd/ 的模板格式，仅写入用户未跳过的维度文件
 - 生成 tasks.md（每个任务默认是端到端垂直切片，标注 AFK / HITL、依赖、具体文件路径、预期变更、完成标准与验证方式；任务独立可验证）
-- 在 `tasks.md` 中保留 “Codex /goal 执行入口”，让 Codex 按已拆分任务、验收边界和 `contract.json` 执行；不要把完整 PRD 原文直接当作 `/goal` 目标
+- 在 `tasks.md` 中保留 “Codex /goal 执行入口”，让 Codex 按 `/goal -> ~auto -> ~qa` 执行已拆分任务、验收边界和 `contract.json`；不要把完整 PRD 原文直接当作 `/goal` 目标
 - 生成 decisions.md（贯穿全程的决策日志）
-- 生成 `contract.json`（至少包含 `verifyMode`、`reviewerFocus`、`testerFocus`；涉及 UI 时补 `ui.required`、`ui.designContract`、`ui.sourcePriority`；仅在确需先明确审美方向时再补 `ui.styleAdvisor.required`、`ui.styleAdvisor.reason`、`ui.styleAdvisor.focus`；仅在确需视觉验收时再补 `ui.visualValidation.required`、`ui.visualValidation.reason`、`ui.visualValidation.screens`、`ui.visualValidation.states`；仅在确需独立 advisor 时，再补 `advisor.required`、`advisor.reason`、`advisor.focus`、`advisor.preferredSources`）
+- 生成 `contract.json`（至少包含 `qaMode`、`qaFocus`；涉及 UI 时补 `ui.required`、`ui.designContract`、`ui.sourcePriority`；仅在确需先明确审美方向时再补 `ui.styleAdvisor.required`、`ui.styleAdvisor.reason`、`ui.styleAdvisor.focus`；仅在确需视觉验收时再补 `ui.visualValidation.required`、`ui.visualValidation.reason`、`ui.visualValidation.screens`、`ui.visualValidation.states`；仅在确需独立 advisor 时，再补 `advisor.required`、`advisor.reason`、`advisor.focus`、`advisor.preferredSources`）
 - 使用 `scripts/plan-contract.mjs write` 写 `contract.json`，不要只把验证路径留在自然语言说明里
 - 涉及 UI 的项目：生成或更新 `.helloagents/DESIGN.md`（按当前项目存储模式解析）；若原文件不存在，先按模板建立最小设计契约，再同步已确认的稳定 UI 决策
 - 重写 `state_path`，其中“主线目标”写本次 PRD 要完成的产品 / 功能目标，不保留其他任务的内容
@@ -127,7 +127,7 @@ c. AI 总结该维度的决策结果，进入下一个维度
 
 按 tasks.md 逐项完成，每项进入当前已加载的 HelloAGENTS 统一执行流程，完成后同步重写 `state_path`。
 任务状态标记仅写入 tasks.md、验收清单或验证结果；普通说明、方案解释、状态汇报不用 [√] / [-] / [ ]。
-所有任务完成后进入当前已加载的 HelloAGENTS VERIFY / CONSOLIDATE 收尾阶段。
+所有任务完成后进入当前已加载的 HelloAGENTS QA / CONSOLIDATE 收尾阶段。
 可并行的任务标记后用子代理并行执行（不同子代理不改同一文件）。
 执行过程中遇到阻塞（依赖缺失、指令不清、验证反复失败）→ 立即停下询问用户，不猜测。
 执行过程中遇到高风险操作（删除文件/修改配置/数据库变更）→ 暂停确认。

package/skills/commands/qa/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: ~qa
+description: 统一质量命令 — 审查、命令验证、阻断修复、回归验证与收尾前质量闭环（~qa 命令）
+policy:
+  allow_implicit_invocation: false
+---
+Trigger: ~qa [scope]
+
+## 流程
+
+0. 先对齐当前工作流状态：
+   - 若当前上下文中已注入“当前工作流约束”或“当前推荐下一命令”，先服从它
+   - 即使命令通过，也不能越过当前方案包边界：不完整方案包不能视为可信交付记录
+   - 当前存在活跃方案包时，先读取 `requirements.md`、`plan.md`、`tasks.md`、`contract.json`
+   - 若当前运行在 Codex active goal 下，按 active goal 关联方案包和 `state_path` 复核范围；`/goal` 只负责续跑，不改变质量契约
+   - 若 `contract.json` 声明 `advisor.required=true` 或 `ui.styleAdvisor.required=true`，则本次质量闭环还必须补齐当前会话 `artifacts/advisor.json`
+   - 若 `contract.json` 声明 `ui.visualValidation.required=true`，则本次质量闭环还必须补齐当前会话 `artifacts/visual.json`
+1. 读取 `skills/qa-review/SKILL.md`
+2. 先确定本次范围：
+   - 无参数默认当前未提交变更
+   - `staged` 代表暂存区
+   - 指定文件/目录则只审查对应范围
+   - 高风险流程除显式范围外，还要主动补查相关配置、迁移、权限、部署或安全边界文件
+3. 执行统一 qa-review：
+   - 先做质量审查
+   - 再运行验证命令
+   - 有阻断问题或命令失败 → 修复 → 重新验证
+   - 直到质量闭环通过，或命中真实阻塞
+4. 对照当前契约逐项核对：
+   - requirements 是否覆盖
+   - tasks 中每项“完成标准”是否满足
+   - `plan.md` 中风险与设计约束是否被验证
+   - `contract.json` 中声明的 `qaMode` / `qaFocus` 是否已被本次质量闭环覆盖
+   - 若 Codex active goal 存在，还要确认 `tasks.md` 的 AFK/HITL 边界：仍有可执行 AFK 项时，不进入 complete
+5. 写结构化证据：
+   - 立即调用 `scripts/qa-review-state.mjs write` 写当前会话 `artifacts/qa-review.json`
+   - 若 `advisor.required=true` 或 `ui.styleAdvisor.required=true`，调用 `scripts/advisor-state.mjs write`
+   - 若 `ui.visualValidation.required=true`，调用 `scripts/visual-state.mjs write`
+   - 若当前准备进入最终收尾，优先调用 `scripts/closeout-state.mjs write`
+6. 汇总：
+   - ✅ 通过的审查项 / 命令
+   - ❌ 失败的审查项 / 命令 + 修复结果
+   - 仍未满足的阻断项
+   - 是否已满足进入 CONSOLIDATE 的条件
+
+## 失败处理
+
+- 有失败 → 逐个修复，修复后重新运行对应审查或验证
+- 全部通过 → 按当前已加载的 HelloAGENTS 规则进入 CONSOLIDATE 收尾；若 Codex active goal 的目标也已满足，再标记 goal complete，并按交付边界报告完成

package/skills/hello-ui/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: hello-ui
-description: 已进入显式 UI 工作流、全局模式中的 UI 任务、已初始化项目的视觉变更、设计系统改造或需要视觉验收时使用；在通用 UI 基线之上补充项目契约执行、设计系统映射与视觉验证。
+description: 已进入显式 UI 工作流、宿主全局模式下的 UI 任务、已初始化项目的视觉变更、设计系统改造或需要视觉验收时使用；在通用 UI 基线之上补充项目契约执行、设计系统映射与视觉验证。
 ---
 
-本 skill 不是 UI 质量的唯一来源。当前已加载的 HelloAGENTS UI 质量基线负责所有 UI 任务的基础水准；本 skill 在显式 UI 工作流和复杂 UI 任务中，补充更明确的契约执行、实现映射与视觉验收。
+本 skill 不是 UI 质量的唯一来源。当前已加载的 HelloAGENTS UI 质量基线负责所有 UI 任务的基础水准；本 skill 在显式 UI 工作流、宿主全局模式和复杂 UI 任务中，补充更明确的契约执行、实现映射与视觉验收。
 `.helloagents/` 在本 skill 中统一按项目级存储路径理解：会话证据使用当前 `state_path` 所在目录下的 `artifacts/*.json`；若 `project_store_mode=repo-shared`，`DESIGN.md` 与方案包按当前上下文中已注入的项目知识/方案目录解析。
 
 ## 适用边界
-已进入显式 UI 规划/实现/验证路径、全局模式中的 UI 任务，或当前已初始化项目且任务涉及整页新建、跨多个组件的视觉重做、设计系统改造、需要截图验收的界面任务时，读取本 skill。
+已进入显式 UI 规划/实现/验证路径、宿主全局模式下的 UI 任务，或当前已初始化项目且任务涉及整页新建、跨多个组件的视觉重做、设计系统改造、需要截图验收的界面任务时，读取本 skill。
 标准模式、且项目未初始化时的普通 UI 请求，仍只受当前已加载的 HelloAGENTS UI 质量基线约束；修复 bug、调整文案、改业务逻辑等不涉及视觉变更的任务，不读取本 skill。在已有设计系统中工作时，保留已建立的模式、结构和视觉语言。
 
 ## 设计契约优先级