helloagents 3.0.33 → 3.0.37
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude-plugin/marketplace.json +1 -4
- package/.claude-plugin/plugin.json +2 -2
- package/.codex-plugin/plugin.json +3 -4
- package/README.md +78 -74
- package/README_CN.md +78 -74
- package/bootstrap-lite.md +9 -11
- package/bootstrap.md +21 -23
- package/gemini-extension.json +1 -1
- package/install.ps1 +27 -4
- package/install.sh +27 -3
- package/package.json +2 -2
- package/scripts/capability-registry.mjs +5 -3
- package/scripts/cli-doctor-codex.mjs +153 -1
- package/scripts/cli-doctor-render.mjs +2 -1
- package/scripts/cli-doctor.mjs +3 -3
- package/scripts/cli-hosts.mjs +1 -1
- package/scripts/cli-lifecycle-hosts.mjs +124 -54
- package/scripts/cli-lifecycle.mjs +50 -15
- package/scripts/cli-messages.mjs +7 -7
- package/scripts/cli-runtime-root.mjs +9 -1
- package/scripts/delivery-gate-messages.mjs +5 -4
- package/scripts/delivery-gate.mjs +11 -22
- package/scripts/guard.mjs +1 -1
- package/scripts/notify-closeout.mjs +61 -22
- package/scripts/notify-context.mjs +5 -5
- package/scripts/notify-route.mjs +1 -1
- package/scripts/notify-sound.mjs +2 -1
- package/scripts/notify.mjs +2 -2
- package/scripts/plan-contract.mjs +10 -14
- package/scripts/project-session-cleanup.mjs +91 -31
- package/scripts/qa-review-state.mjs +313 -0
- package/scripts/ralph-loop.mjs +32 -13
- package/scripts/runtime-artifacts.mjs +2 -2
- package/scripts/runtime-scope.mjs +14 -13
- package/scripts/runtime-ttl.mjs +7 -4
- package/scripts/session-capsule.mjs +75 -13
- package/scripts/session-token.mjs +44 -9
- package/scripts/state-document.mjs +77 -0
- package/scripts/workflow-core.mjs +13 -19
- package/scripts/workflow-plan-files.mjs +1 -1
- package/scripts/workflow-recommendation.mjs +55 -67
- package/scripts/workflow-state.mjs +8 -8
- package/skills/commands/auto/SKILL.md +12 -12
- package/skills/commands/build/SKILL.md +9 -10
- package/skills/commands/commit/SKILL.md +1 -1
- package/skills/commands/help/SKILL.md +11 -13
- package/skills/commands/init/SKILL.md +18 -9
- package/skills/commands/loop/SKILL.md +70 -96
- package/skills/commands/plan/SKILL.md +7 -8
- package/skills/commands/prd/SKILL.md +3 -3
- package/skills/commands/qa/SKILL.md +49 -0
- package/skills/hello-ui/SKILL.md +3 -3
- package/skills/helloagents/SKILL.md +11 -14
- package/skills/qa-review/SKILL.md +92 -0
- package/templates/plans/contract.json +4 -7
- package/templates/plans/plan.md +1 -1
- package/templates/plans/tasks.md +1 -1
- package/templates/verify.yaml +1 -1
- package/scripts/review-state.mjs +0 -193
- package/scripts/verify-state.mjs +0 -175
- package/skills/commands/global/SKILL.md +0 -71
- package/skills/commands/verify/SKILL.md +0 -46
- package/skills/commands/wiki/SKILL.md +0 -57
- package/skills/hello-review/SKILL.md +0 -42
- package/skills/hello-verify/SKILL.md +0 -144
- /package/hooks/{hooks.json → hooks-gemini.json} +0 -0
|
@@ -6,8 +6,8 @@ policy:
|
|
|
6
6
|
---
|
|
7
7
|
Trigger: ~build [description]
|
|
8
8
|
|
|
9
|
-
`~build`
|
|
10
|
-
执行 `~build` 时,通用阶段边界按当前已加载的 HelloAGENTS 规则执行;本 skill 负责补充实现前定位、实现约束,以及进入 `~
|
|
9
|
+
`~build` 是执行实现命令。它负责读取现有需求、方案包与项目上下文,完成实现、局部验证、修复循环,并把结果交给后续质量闭环与收尾。
|
|
10
|
+
执行 `~build` 时,通用阶段边界按当前已加载的 HelloAGENTS 规则执行;本 skill 负责补充实现前定位、实现约束,以及进入 `~qa` / 收尾前的实现边界。
|
|
11
11
|
`.helloagents/` 在本 skill 中统一按项目级存储路径理解:状态文件只使用 `state_path`;会话证据使用当前 `state_path` 所在目录下的 `artifacts/*.json`;若 `project_store_mode=repo-shared`,知识库、`DESIGN.md`、`verify.yaml` 与方案包按当前上下文中已注入的项目知识/方案目录解析。
|
|
12
12
|
|
|
13
13
|
## 铁律
|
|
@@ -27,7 +27,7 @@ Trigger: ~build [description]
|
|
|
27
27
|
- `tasks.md`
|
|
28
28
|
- `contract.json`
|
|
29
29
|
- 实现时优先把 `tasks.md` 中每个任务的“完成标准”当作本次实现约束,不要只按任务标题猜测范围
|
|
30
|
-
- `contract.json` 存在时,优先按其中的 `
|
|
30
|
+
- `contract.json` 存在时,优先按其中的 `qaMode`、`qaFocus` 理解后续质量闭环边界
|
|
31
31
|
- 若当前运行在 Codex active goal 下,按 `tasks.md` 未完成项、`contract.json` 与 `state_path` 恢复实现位置;不要自动创建新 goal,也不要把 goal 目标原文替代方案包
|
|
32
32
|
- 若当前上下文中已注入“当前工作流约束”或“当前推荐下一命令”,先服从它;只有推荐仍为 `~build`,或用户明确提出新增实现范围时,才继续 `~build`
|
|
33
33
|
- 其余项目知识库与相关代码文件,按 HelloAGENTS 项目上下文要求读取
|
|
@@ -53,17 +53,16 @@ Trigger: ~build [description]
|
|
|
53
53
|
- 每次编辑后主动跑确定性检查
|
|
54
54
|
- 可并行任务通过子代理执行,但不同子代理不得改同一文件
|
|
55
55
|
|
|
56
|
-
### 4.
|
|
56
|
+
### 4. 局部验证与修复循环
|
|
57
57
|
|
|
58
|
-
-
|
|
59
|
-
- 运行 lint / typecheck / test / build 等验证
|
|
58
|
+
- 按当前任务与 `tasks.md` 中的“验证方式”运行 lint / typecheck / test / build 等局部验证
|
|
60
59
|
- 若失败,修复后重跑
|
|
61
|
-
-
|
|
60
|
+
- 若当前实现已接近交付,主动对照 `qaFocus` 自检本次改动是否覆盖关键风险
|
|
62
61
|
|
|
63
62
|
### 5. 交付前处理
|
|
64
63
|
|
|
65
64
|
- 有方案包时,只同步本次实现直接影响的任务状态;未完成项保持打开
|
|
66
|
-
- 当前实现已闭合、且需要进入交付或收尾时,转入 `~
|
|
67
|
-
- 若 Codex active goal 仍有未完成 AFK 任务,继续下一项可执行任务;若目标已满足,先转入 `~
|
|
68
|
-
- 状态文件、知识库、`CHANGELOG.md`、modules 文档与归档边界,按当前已加载的 HelloAGENTS 规则进入
|
|
65
|
+
- 当前实现已闭合、且需要进入交付或收尾时,转入 `~qa`
|
|
66
|
+
- 若 Codex active goal 仍有未完成 AFK 任务,继续下一项可执行任务;若目标已满足,先转入 `~qa` 与 HelloAGENTS 收尾,再标记 goal complete
|
|
67
|
+
- 状态文件、知识库、`CHANGELOG.md`、modules 文档与归档边界,按当前已加载的 HelloAGENTS 规则进入 QA / CONSOLIDATE
|
|
69
68
|
- 不在 `~build` 内把仍未闭合的方案包整体报告为已完成
|
|
@@ -27,5 +27,5 @@ Trigger: ~commit [message]
|
|
|
27
27
|
提交后,继续复用上方已解析的同一份设置获取 `kb_create_mode`,不要再次读取 `~/.helloagents/helloagents.json`:
|
|
28
28
|
- 0 = 跳过
|
|
29
29
|
- 1 = 知识库已存在时自动同步(默认)
|
|
30
|
-
- 2 =
|
|
30
|
+
- 2 = 编码任务在知识库已存在或当前项目已初始化时自动创建或同步
|
|
31
31
|
同步范围与更新格式按当前已加载的 HelloAGENTS CONSOLIDATE 阶段执行。
|
|
@@ -12,16 +12,14 @@ Trigger: ~help
|
|
|
12
12
|
| 命令 | 说明 |
|
|
13
13
|
|------|------|
|
|
14
14
|
| ~idea | 轻量点子探索与方向比较 |
|
|
15
|
-
| ~auto |
|
|
15
|
+
| ~auto | 自动执行:自动选主路径并持续推进到实现 / 质量闭环 / 收尾,除非命中真实阻塞 |
|
|
16
16
|
| ~plan | 结构化规划:需求澄清 + 方案确认 + 方案包 |
|
|
17
|
-
| ~build |
|
|
17
|
+
| ~build | 执行实现:按需求或方案包完成实现与局部验证 |
|
|
18
18
|
| ~prd | 完整 PRD:头脑风暴式逐维度挖掘,生成现代产品需求文档 |
|
|
19
|
-
| ~loop |
|
|
20
|
-
| ~
|
|
21
|
-
| ~init | 同 `~wiki` |
|
|
22
|
-
| ~global | 初始化项目级全局模式 |
|
|
19
|
+
| ~loop | 长任务入口:在 Codex 中优先走 `/goal -> ~auto -> ~qa` |
|
|
20
|
+
| ~init | 初始化项目工作流并同步知识库 |
|
|
23
21
|
| ~test | 为指定模块或最近变更编写完整测试 |
|
|
24
|
-
| ~
|
|
22
|
+
| ~qa | 统一质量总入口:审查 + 运行验证命令 + 修复循环 + 收尾前证据 |
|
|
25
23
|
| ~commit | 规范化提交 + 知识库同步 |
|
|
26
24
|
| ~clean | 清理临时文件和归档方案包 |
|
|
27
25
|
| ~help | 显示此帮助 |
|
|
@@ -29,15 +27,15 @@ Trigger: ~help
|
|
|
29
27
|
兼容别名:
|
|
30
28
|
- `~do` → 等同 `~build`
|
|
31
29
|
- `~design` → 等同 `~plan`
|
|
32
|
-
- `~review` → 等同 `~
|
|
30
|
+
- `~review` → 等同 `~qa`
|
|
33
31
|
|
|
34
32
|
### 自动激活技能
|
|
35
|
-
|
|
33
|
+
以下技能仅在宿主全局模式或已初始化项目时自动激活(例如当前项目级规则文件已包含 `<!-- HELLOAGENTS_PROFILE: full -->`,通常由 `~init` 建立)。
|
|
36
34
|
纯标准模式、且项目未初始化时不会自动触发这些技能;但涉及 UI 的任务仍受 UI 质量基线约束。
|
|
37
35
|
|
|
38
36
|
编码时:hello-ui, hello-api, hello-data, hello-security, hello-errors, hello-perf, hello-arch, hello-test
|
|
39
|
-
特定场景:hello-debug, hello-subagent, hello-write
|
|
40
|
-
完成时:
|
|
37
|
+
特定场景:hello-debug, hello-subagent, hello-write
|
|
38
|
+
完成时:qa-review, hello-reflect
|
|
41
39
|
|
|
42
40
|
### 当前设置
|
|
43
41
|
优先使用当前会话上下文中已注入的“当前用户设置”、该配置文件原始 JSON 或此前读取结果摘要显示;若会话上下文不存在该信息,或缺少下表任一配置项,才读取一次 `~/.helloagents/helloagents.json`,并在后续轮次复用。对 Codex 来说,首次对话前若当前上下文仍缺少这些配置项,或刚经历压缩/恢复后的首次对话,同样先读取一次再继续。
|
|
@@ -47,9 +45,9 @@ Trigger: ~help
|
|
|
47
45
|
| output_language | "" | 空=跟随用户语言/填写则指定(如 zh-CN、en) | Claude Code + Gemini CLI + Codex CLI |
|
|
48
46
|
| output_format | true | true=主代理最终回复必须使用 HelloAGENTS 格式,流式/中间输出及子代理输出保持自然;false=自然输出 | Claude Code + Gemini CLI + Codex CLI |
|
|
49
47
|
| notify_level | 0 | 0=关闭/1=桌面通知/2=声音/3=两者 | Claude Code + Gemini CLI + Codex CLI |
|
|
50
|
-
| ralph_loop_enabled | true |
|
|
48
|
+
| ralph_loop_enabled | true | 收尾 QA gate(显式 ~qa / ~loop 或收尾要求时触发审查、lint/test/build) | Claude Code + Gemini CLI + Codex CLI |
|
|
51
49
|
| guard_enabled | true | 阻断危险命令与写入后的安全扫描 | Claude Code + Gemini CLI + Codex CLI |
|
|
52
|
-
| kb_create_mode | 1 | 0=关闭/1=知识库已存在时自动同步/2
|
|
50
|
+
| kb_create_mode | 1 | 0=关闭/1=知识库已存在时自动同步/2=编码任务在知识库已存在或当前项目已初始化时自动创建或同步 | Claude Code + Gemini CLI + Codex CLI |
|
|
53
51
|
| project_store_mode | "local" | "local"=知识库/方案包保留在项目本地 `.helloagents/`;"repo-shared"=本地 `.helloagents/` 仅保留项目本地状态/运行态,知识库与方案包改写到 `~/.helloagents/projects/<repo-key>/` | Claude Code + Gemini CLI + Codex CLI |
|
|
54
52
|
| auto_commit_enabled | true | true=验证完成且有变更时自动执行本地提交;false=跳过自动提交,仍可手动用 `~commit` | Claude Code + Gemini CLI + Codex CLI |
|
|
55
53
|
| commit_attribution | "" | 空=不添加/填写内容则添加到 commit message | Claude Code + Gemini CLI + Codex CLI |
|
|
@@ -1,31 +1,39 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ~init
|
|
3
|
-
description:
|
|
3
|
+
description: 初始化项目工作流并同步知识库
|
|
4
4
|
policy:
|
|
5
5
|
allow_implicit_invocation: false
|
|
6
6
|
---
|
|
7
7
|
Trigger: ~init
|
|
8
8
|
|
|
9
|
-
`~init`
|
|
10
|
-
|
|
11
|
-
执行 `~init`
|
|
9
|
+
`~init` 是用户显式命令,用来初始化或刷新当前项目的完整工作流。
|
|
10
|
+
它不受 `kb_create_mode` 限制。
|
|
11
|
+
执行 `~init` 时,按当前规则模板创建或更新项目本地 `.helloagents/`,同步知识库,并为支持的宿主写入项目级 full carrier 标记:`<!-- HELLOAGENTS_PROFILE: full -->`。
|
|
12
12
|
`.helloagents/` 在本 skill 中统一按项目级存储路径理解:项目本地 `.helloagents/` 继续承担项目本地存储目录;状态文件只使用 `state_path`;若 `project_store_mode=repo-shared`,知识库、`DESIGN.md` 与方案包按当前上下文中已注入的项目知识/方案目录写入。
|
|
13
13
|
|
|
14
14
|
## 流程
|
|
15
15
|
|
|
16
|
-
### 阶段 1
|
|
16
|
+
### 阶段 1:初始化项目工作流(必做)
|
|
17
17
|
|
|
18
|
-
1. 创建 `.helloagents/` 目录 + `state_path`(按 templates/STATE.md
|
|
19
|
-
2.
|
|
18
|
+
1. 创建 `.helloagents/` 目录 + `state_path`(按 templates/STATE.md 格式,初始“主线目标”写当前项目初始化任务,初始状态为空闲)
|
|
19
|
+
2. 用当前完整规则模板刷新项目级规则文件,在受管内容第一行写入 `<!-- HELLOAGENTS_PROFILE: full -->`,再用 `<!-- HELLOAGENTS_START -->` / `<!-- HELLOAGENTS_END -->` 包裹后写入:
|
|
20
|
+
- `AGENTS.md`
|
|
21
|
+
- `CLAUDE.md`
|
|
22
|
+
- `.gemini/GEMINI.md`(不存在则先创建 `.gemini/` 目录)
|
|
23
|
+
如果文件已存在且包含标记,替换标记内内容;已存在但无标记,则追加到末尾;不存在则新建
|
|
24
|
+
3. 追加 `.gitignore`(如果对应行不存在):
|
|
20
25
|
```
|
|
21
26
|
.helloagents/
|
|
27
|
+
AGENTS.md
|
|
28
|
+
CLAUDE.md
|
|
29
|
+
.gemini/GEMINI.md
|
|
22
30
|
```
|
|
23
31
|
|
|
24
32
|
### 阶段 2:知识库创建或补全(条件性)
|
|
25
33
|
|
|
26
34
|
检查项目是否有实际代码文件(非空项目):
|
|
27
35
|
- 有代码文件 → 执行完整知识库创建(下方流程)
|
|
28
|
-
- 空项目 →
|
|
36
|
+
- 空项目 → 保留 `.helloagents/` 和项目级规则文件,告知用户"项目为空,其余知识文件将在后续开发或首次编码任务中补全"
|
|
29
37
|
|
|
30
38
|
知识库创建/补全流程(统一写入 `.helloagents/` 对应的项目级存储路径;`project_store_mode=repo-shared` 时实际落在共享知识目录):
|
|
31
39
|
1. 按 templates/ 目录的模板格式,分析项目代码库后生成:
|
|
@@ -35,7 +43,7 @@ Trigger: ~init
|
|
|
35
43
|
- CHANGELOG.md — 按 templates/CHANGELOG.md 格式,初始版本
|
|
36
44
|
- DESIGN.md — 如果项目包含 UI 代码,按 templates/DESIGN.md 格式提取项目级设计契约(产品表面、设计 token、组件与模式、状态覆盖、无障碍要求、禁止事项等)
|
|
37
45
|
2. 创建 modules/ 目录,按 templates/modules/module.md 格式为主要模块生成文档
|
|
38
|
-
3.
|
|
46
|
+
3. 已存在的文件按模板增量更新,不自由改写结构;无新增信息时保持原样
|
|
39
47
|
|
|
40
48
|
## verify.yaml 格式
|
|
41
49
|
```yaml
|
|
@@ -48,5 +56,6 @@ commands:
|
|
|
48
56
|
重复执行 ~init 是安全的:
|
|
49
57
|
- `.helloagents/` 缺失时创建,已存在时复用
|
|
50
58
|
- `state_path` 按当前任务状态重写,不追加历史;它只记录当前知识库任务,不承担项目的长期记忆
|
|
59
|
+
- 项目级规则文件中的受管标记块会刷新到最新
|
|
51
60
|
- 知识库文件缺失时补全,已存在时按模板增量更新
|
|
52
61
|
- `.gitignore` 只追加缺失行
|
|
@@ -1,101 +1,75 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ~loop
|
|
3
|
-
description:
|
|
3
|
+
description: 长任务入口 — 在 Codex 中优先走 `/goal -> ~auto -> ~qa`,把长程续跑交给 `/goal`,把执行推进交给 `~auto`,把最终质量闭环交给 `~qa`(~loop 命令)
|
|
4
4
|
policy:
|
|
5
5
|
allow_implicit_invocation: false
|
|
6
6
|
---
|
|
7
|
-
Trigger: ~loop <目标描述>
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
-
|
|
15
|
-
-
|
|
16
|
-
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
-
|
|
47
|
-
-
|
|
48
|
-
-
|
|
49
|
-
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
-
|
|
54
|
-
-
|
|
55
|
-
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
-
|
|
60
|
-
-
|
|
61
|
-
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
-
|
|
69
|
-
-
|
|
70
|
-
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
-
|
|
75
|
-
-
|
|
76
|
-
- CRASHED(命令执行失败)→ revert + 记录
|
|
77
|
-
|
|
78
|
-
### 第 7 阶段:记录
|
|
79
|
-
- 追加一行到 results log
|
|
80
|
-
- status: baseline / keep / discard / crash / no-op
|
|
81
|
-
- 重写 `state_path`:保持主线目标=当前优化目标,并记录当前迭代轮次、最近一次决策(keep / discard / crash)、当前最佳指标、下一步动作
|
|
82
|
-
|
|
83
|
-
### 第 8 阶段:继续
|
|
84
|
-
- 如果 iterations > 0 且 current_iteration >= max_iterations → 输出总结并停止
|
|
85
|
-
- 否则 → 回到 Phase 1
|
|
86
|
-
|
|
87
|
-
## 总结输出
|
|
88
|
-
|
|
89
|
-
循环结束时输出:
|
|
90
|
-
- 基线值 → 最终值(改善幅度)
|
|
91
|
-
- 总迭代次数 / 保留次数 / 丢弃次数
|
|
92
|
-
- 最有效的 3 个改进
|
|
93
|
-
- results log 路径
|
|
94
|
-
- 重写 `state_path`:将“主线目标”保留为本次优化目标,“正在做什么”更新为已完成,保留最终结论摘要,清空阻塞项,并给出可立即执行的下一步(如继续优化、停止、切换目标)
|
|
95
|
-
- 若 Codex `/goal` 处于 active 且目标已达成,完成 HelloAGENTS 验证和收尾后再标记 goal complete;不得因达到预算或单轮结束而标记 complete
|
|
96
|
-
|
|
97
|
-
## 安全规则
|
|
98
|
-
- 使用 `git revert`(保留历史)而非 `git reset --hard`(丢失历史)
|
|
99
|
-
- 不修改测试文件和守卫命令涉及的文件
|
|
100
|
-
- 单次修改涉及 >5 个文件 → 重新评估,可能需要拆分
|
|
101
|
-
- 守卫命令是底线,指标改善但守卫失败 = 不可接受
|
|
7
|
+
Trigger: ~loop <目标描述>
|
|
8
|
+
|
|
9
|
+
`~loop` 不再维护独立的指标实验循环。它是长任务入口,默认把链路收敛为:
|
|
10
|
+
|
|
11
|
+
`/goal -> ~auto -> ~qa`
|
|
12
|
+
|
|
13
|
+
其中:
|
|
14
|
+
- `/goal` 负责长程续跑、恢复与预算
|
|
15
|
+
- `~auto` 负责按方案包持续推进 AFK 任务
|
|
16
|
+
- `~qa` 负责最终审查、验证命令、阻断修复、回归验证与收尾证据
|
|
17
|
+
|
|
18
|
+
## 适用边界
|
|
19
|
+
|
|
20
|
+
- 适合:多轮持续执行、跨会话恢复、较长的 AFK 任务
|
|
21
|
+
- 不适合:普通小任务、单轮可完成任务、单纯质量审查;这些优先直接走 `~auto` 或 `~qa`
|
|
22
|
+
- 真正的指标实验、benchmark 对赌、keep/revert 试验,不再由 `~loop` 承担
|
|
23
|
+
|
|
24
|
+
## 流程
|
|
25
|
+
|
|
26
|
+
### 0. 当前工作流优先
|
|
27
|
+
|
|
28
|
+
- 若当前上下文中已注入“当前工作流约束”或“当前推荐下一命令”,先服从它
|
|
29
|
+
- `~loop` 不是绕过方案包和质量契约的越级入口;它只是把长任务执行链路固定为 `/goal -> ~auto -> ~qa`
|
|
30
|
+
|
|
31
|
+
### 1. 先落稳方案包
|
|
32
|
+
|
|
33
|
+
- 优先复用当前活跃方案包
|
|
34
|
+
- 若当前没有足够可信的方案包,而任务又属于长任务、跨模块任务或高风险任务,先补 `~plan` 或 `~prd`
|
|
35
|
+
- `tasks.md` 必须能支撑长程执行:任务按顺序拆好,标注 `AFK` / `HITL`,写清依赖、涉及文件、完成标准和验证方式
|
|
36
|
+
- `contract.json` 必须至少落成 `qaMode` 与 `qaFocus`
|
|
37
|
+
|
|
38
|
+
### 2. Codex + goals 已启用时
|
|
39
|
+
|
|
40
|
+
- 把 `~loop` 视为 Codex 的长任务入口,优先直接进入 `/goal`
|
|
41
|
+
- `/goal` 不直接消费原始需求文档;只消费当前方案包里的 “Codex /goal 执行入口”
|
|
42
|
+
- `/goal` 入口必须明确以下约束:
|
|
43
|
+
- 默认主执行命令是 `~auto`
|
|
44
|
+
- 按 `tasks.md` 顺序完成所有可执行 `AFK` 任务
|
|
45
|
+
- `HITL` 只在缺少用户决策、凭据、人工验收或其他真实阻塞时暂停
|
|
46
|
+
- 不得把单轮结果、阶段总结或“下一步建议”当成完成
|
|
47
|
+
- 全部 `AFK` 任务完成后,必须进入 `~qa`
|
|
48
|
+
- 只有 `~qa` 通过、当前会话证据写全、HelloAGENTS 收尾完成后,才允许标记 goal complete
|
|
49
|
+
- 若当前已经运行在 Codex active goal 下,继续沿当前 goal 执行,不重复创建新 goal
|
|
50
|
+
|
|
51
|
+
### 3. 非 Codex 或 goals 不可用时
|
|
52
|
+
|
|
53
|
+
- 明确当前无法使用 Codex 原生 `/goal`
|
|
54
|
+
- 仍按同一意图执行长任务,但只走 `~auto -> ~qa`
|
|
55
|
+
- 这种情况只是无 `/goal` 的降级路径,不把它包装成等价的 goal 能力
|
|
56
|
+
|
|
57
|
+
### 4. 执行期间的状态维护
|
|
58
|
+
|
|
59
|
+
- `~loop` 必须维护 `state_path`
|
|
60
|
+
- “主线目标”写当前长任务目标
|
|
61
|
+
- “正在做什么”写当前 `AFK` 任务或当前收尾阶段
|
|
62
|
+
- “下一步”写下一条具体可执行动作,必要时带文件路径
|
|
63
|
+
- 若当前运行在 Codex active goal 下,`state_path` 仍只负责本地恢复,不替代 goal 自身状态
|
|
64
|
+
|
|
65
|
+
### 5. 禁止事项
|
|
66
|
+
|
|
67
|
+
- 不再创建基线指标、results log、keep/revert 实验提交或守卫命令循环
|
|
68
|
+
- 不把 `/goal` 当作质量验收器;最终质量闭环始终由 `~qa` 负责
|
|
69
|
+
- 仍有可执行 `AFK` 任务时,不进入 complete
|
|
70
|
+
- 没有最新 `qa-review.json`、需要的 `advisor.json` / `visual.json` / `closeout.json` 时,不得报告完成
|
|
71
|
+
|
|
72
|
+
## 完成判定
|
|
73
|
+
|
|
74
|
+
- 只有当长任务链路已经走到 `~qa`,并且质量闭环通过、收尾证据完整、HelloAGENTS 允许进入 CONSOLIDATE 时,`~loop` 才算完成
|
|
75
|
+
- 若当前任务来自 Codex active goal,还要满足:当前 goal 的可执行 `AFK` 任务已全部完成,才允许标记 goal complete
|
|
@@ -12,7 +12,7 @@ Trigger: ~plan [description]
|
|
|
12
12
|
|
|
13
13
|
## 铁律
|
|
14
14
|
- 在用户确认方案之前,禁止编写任何实现代码、创建任何实现文件、或执行任何实现操作
|
|
15
|
-
- 需求澄清阶段不读取实现类技能(hello-ui / hello-test /
|
|
15
|
+
- 需求澄清阶段不读取实现类技能(hello-ui / hello-test / qa-review 等),需求明确后再按需读取
|
|
16
16
|
- 方案必须整理为可执行产物,不停留在泛化建议
|
|
17
17
|
- 若当前任务来自 `~auto`,则“开始执行”视为已包含在 `~auto` 授权内;方案包写入后默认继续执行,只有命中阻塞判定时才停下。`~design` 是 `~plan` 的兼容别名,只有在 `~auto` 内触发其语义时才默认继续进入 `~build`
|
|
18
18
|
- 涉及 UI 时,当前方案包中的 UI 决策优先于 `.helloagents/DESIGN.md`;`.helloagents/DESIGN.md`(按当前项目存储模式解析)优先于已读取的 `hello-ui` 规则;同时所有 UI 任务都必须满足 UI 质量基线
|
|
@@ -66,7 +66,7 @@ Trigger: ~plan [description]
|
|
|
66
66
|
|
|
67
67
|
用户确认方向后,一次性输出完整可执行方案:
|
|
68
68
|
- 架构与文件结构
|
|
69
|
-
-
|
|
69
|
+
- 完成定义(功能完成时必须为真的条件、关键验收点、`qaMode`、`qaFocus`、进入收尾前必须补齐的质量证据)
|
|
70
70
|
- 数据流与错误处理
|
|
71
71
|
- 验证策略
|
|
72
72
|
- 涉及 UI 时的设计方向、状态覆盖与 `DESIGN.md` 更新点
|
|
@@ -82,12 +82,12 @@ Trigger: ~plan [description]
|
|
|
82
82
|
- `plan.md`
|
|
83
83
|
- `tasks.md`
|
|
84
84
|
- `contract.json`
|
|
85
|
-
- 写 `contract.json` 时,至少落成以下字段:`
|
|
85
|
+
- 写 `contract.json` 时,至少落成以下字段:`qaMode`、`qaFocus`;涉及 UI 时再写 `ui.required`、`ui.designContract` 与 `ui.sourcePriority`
|
|
86
86
|
- 只有在 UI 方向确需先明确时,才额外写 `ui.styleAdvisor.required`、`ui.styleAdvisor.reason` 与 `ui.styleAdvisor.focus`;它复用当前会话 `artifacts/advisor.json`,不是默认常驻步骤
|
|
87
87
|
- 只有在 UI 验收确有收益时,才额外写 `ui.visualValidation.required`、`ui.visualValidation.reason`、`ui.visualValidation.screens` 与 `ui.visualValidation.states`;不要把视觉验收扩成所有 UI 任务的固定步骤
|
|
88
88
|
- 只有在 `T3`、非 UI 的高风险审查或确需额外跨模型建议时,才写 `advisor.required`、`advisor.reason`、`advisor.focus` 与 `advisor.preferredSources`;不要把 advisor 变成默认常驻流程
|
|
89
89
|
- 使用 `scripts/plan-contract.mjs write` 写 `contract.json`,不要让后续检查脚本再从 `plan.md` 的自然语言说明里猜验证主路径
|
|
90
|
-
- 在 `tasks.md` 中保留 “Codex /goal 执行入口”,内容必须引用当前方案包路径、AFK/HITL
|
|
90
|
+
- 在 `tasks.md` 中保留 “Codex /goal 执行入口”,内容必须引用当前方案包路径、AFK/HITL 边界,并明确 `/goal -> ~auto -> ~qa` 这条链路;不要把普通 PRD 原文当作 `/goal` 目标
|
|
91
91
|
- 涉及 UI 的项目:生成或更新 `.helloagents/DESIGN.md`(按当前项目存储模式解析);若原文件不存在,先按模板建立最小设计契约,再写入已确认的稳定设计决策
|
|
92
92
|
- 重写 `state_path`,其中“主线目标”写本次规划要完成的目标,不保留其他任务的内容
|
|
93
93
|
|
|
@@ -111,12 +111,11 @@ Trigger: ~plan [description]
|
|
|
111
111
|
- 每个任务标注 `AFK` 或 `HITL`:`AFK` 表示代理可独立完成,`HITL` 表示需要用户决策、外部凭据、人工视觉确认或手动验收
|
|
112
112
|
- 明确文件路径、预期变更、完成标准、验证方式与依赖关系
|
|
113
113
|
- 每个任务可独立验证;厚任务必须拆成更薄的可验收切片
|
|
114
|
-
- “Codex /goal 执行入口”只作为长程执行提示,不计入任务列表;入口必须让 Codex 按已拆好的 `tasks.md`
|
|
114
|
+
- “Codex /goal 执行入口”只作为长程执行提示,不计入任务列表;入口必须让 Codex 按已拆好的 `tasks.md` 执行,默认主执行命令是 `~auto`,最终必须进入 `~qa`,而不是直接消费未拆分需求文档
|
|
115
115
|
|
|
116
116
|
方案包中的 `contract.json` 必须满足:
|
|
117
|
-
- `
|
|
118
|
-
- `
|
|
119
|
-
- `review-first` 时 `reviewerFocus` 必填
|
|
117
|
+
- `qaMode` 只能是 `standard` 或 `deep`
|
|
118
|
+
- `qaFocus` 必填
|
|
120
119
|
- 涉及 UI 时显式写出 UI 契约来源优先级
|
|
121
120
|
- 若启用 `ui.styleAdvisor`,必须写清触发原因与 focus
|
|
122
121
|
- 若启用 `ui.visualValidation`,必须写清触发原因,以及至少一组关键 screens 或 states
|
|
@@ -103,9 +103,9 @@ c. AI 总结该维度的决策结果,进入下一个维度
|
|
|
103
103
|
- 创建 `.helloagents/plans/YYYYMMDDHHMM_{feature}/prd/`(按当前项目存储模式解析)
|
|
104
104
|
- 按 templates/plans/prd/ 的模板格式,仅写入用户未跳过的维度文件
|
|
105
105
|
- 生成 tasks.md(每个任务默认是端到端垂直切片,标注 AFK / HITL、依赖、具体文件路径、预期变更、完成标准与验证方式;任务独立可验证)
|
|
106
|
-
- 在 `tasks.md` 中保留 “Codex /goal 执行入口”,让 Codex
|
|
106
|
+
- 在 `tasks.md` 中保留 “Codex /goal 执行入口”,让 Codex 按 `/goal -> ~auto -> ~qa` 执行已拆分任务、验收边界和 `contract.json`;不要把完整 PRD 原文直接当作 `/goal` 目标
|
|
107
107
|
- 生成 decisions.md(贯穿全程的决策日志)
|
|
108
|
-
- 生成 `contract.json`(至少包含 `
|
|
108
|
+
- 生成 `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`)
|
|
109
109
|
- 使用 `scripts/plan-contract.mjs write` 写 `contract.json`,不要只把验证路径留在自然语言说明里
|
|
110
110
|
- 涉及 UI 的项目:生成或更新 `.helloagents/DESIGN.md`(按当前项目存储模式解析);若原文件不存在,先按模板建立最小设计契约,再同步已确认的稳定 UI 决策
|
|
111
111
|
- 重写 `state_path`,其中“主线目标”写本次 PRD 要完成的产品 / 功能目标,不保留其他任务的内容
|
|
@@ -127,7 +127,7 @@ c. AI 总结该维度的决策结果,进入下一个维度
|
|
|
127
127
|
|
|
128
128
|
按 tasks.md 逐项完成,每项进入当前已加载的 HelloAGENTS 统一执行流程,完成后同步重写 `state_path`。
|
|
129
129
|
任务状态标记仅写入 tasks.md、验收清单或验证结果;普通说明、方案解释、状态汇报不用 [√] / [-] / [ ]。
|
|
130
|
-
所有任务完成后进入当前已加载的 HelloAGENTS
|
|
130
|
+
所有任务完成后进入当前已加载的 HelloAGENTS QA / CONSOLIDATE 收尾阶段。
|
|
131
131
|
可并行的任务标记后用子代理并行执行(不同子代理不改同一文件)。
|
|
132
132
|
执行过程中遇到阻塞(依赖缺失、指令不清、验证反复失败)→ 立即停下询问用户,不猜测。
|
|
133
133
|
执行过程中遇到高风险操作(删除文件/修改配置/数据库变更)→ 暂停确认。
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ~qa
|
|
3
|
+
description: 统一质量命令 — 审查、命令验证、阻断修复、回归验证与收尾前质量闭环(~qa 命令)
|
|
4
|
+
policy:
|
|
5
|
+
allow_implicit_invocation: false
|
|
6
|
+
---
|
|
7
|
+
Trigger: ~qa [scope]
|
|
8
|
+
|
|
9
|
+
## 流程
|
|
10
|
+
|
|
11
|
+
0. 先对齐当前工作流状态:
|
|
12
|
+
- 若当前上下文中已注入“当前工作流约束”或“当前推荐下一命令”,先服从它
|
|
13
|
+
- 即使命令通过,也不能越过当前方案包边界:不完整方案包不能视为可信交付记录
|
|
14
|
+
- 当前存在活跃方案包时,先读取 `requirements.md`、`plan.md`、`tasks.md`、`contract.json`
|
|
15
|
+
- 若当前运行在 Codex active goal 下,按 active goal 关联方案包和 `state_path` 复核范围;`/goal` 只负责续跑,不改变质量契约
|
|
16
|
+
- 若 `contract.json` 声明 `advisor.required=true` 或 `ui.styleAdvisor.required=true`,则本次质量闭环还必须补齐当前会话 `artifacts/advisor.json`
|
|
17
|
+
- 若 `contract.json` 声明 `ui.visualValidation.required=true`,则本次质量闭环还必须补齐当前会话 `artifacts/visual.json`
|
|
18
|
+
1. 读取 `skills/qa-review/SKILL.md`
|
|
19
|
+
2. 先确定本次范围:
|
|
20
|
+
- 无参数默认当前未提交变更
|
|
21
|
+
- `staged` 代表暂存区
|
|
22
|
+
- 指定文件/目录则只审查对应范围
|
|
23
|
+
- 高风险流程除显式范围外,还要主动补查相关配置、迁移、权限、部署或安全边界文件
|
|
24
|
+
3. 执行统一 qa-review:
|
|
25
|
+
- 先做质量审查
|
|
26
|
+
- 再运行验证命令
|
|
27
|
+
- 有阻断问题或命令失败 → 修复 → 重新验证
|
|
28
|
+
- 直到质量闭环通过,或命中真实阻塞
|
|
29
|
+
4. 对照当前契约逐项核对:
|
|
30
|
+
- requirements 是否覆盖
|
|
31
|
+
- tasks 中每项“完成标准”是否满足
|
|
32
|
+
- `plan.md` 中风险与设计约束是否被验证
|
|
33
|
+
- `contract.json` 中声明的 `qaMode` / `qaFocus` 是否已被本次质量闭环覆盖
|
|
34
|
+
- 若 Codex active goal 存在,还要确认 `tasks.md` 的 AFK/HITL 边界:仍有可执行 AFK 项时,不进入 complete
|
|
35
|
+
5. 写结构化证据:
|
|
36
|
+
- 立即调用 `scripts/qa-review-state.mjs write` 写当前会话 `artifacts/qa-review.json`
|
|
37
|
+
- 若 `advisor.required=true` 或 `ui.styleAdvisor.required=true`,调用 `scripts/advisor-state.mjs write`
|
|
38
|
+
- 若 `ui.visualValidation.required=true`,调用 `scripts/visual-state.mjs write`
|
|
39
|
+
- 若当前准备进入最终收尾,优先调用 `scripts/closeout-state.mjs write`
|
|
40
|
+
6. 汇总:
|
|
41
|
+
- ✅ 通过的审查项 / 命令
|
|
42
|
+
- ❌ 失败的审查项 / 命令 + 修复结果
|
|
43
|
+
- 仍未满足的阻断项
|
|
44
|
+
- 是否已满足进入 CONSOLIDATE 的条件
|
|
45
|
+
|
|
46
|
+
## 失败处理
|
|
47
|
+
|
|
48
|
+
- 有失败 → 逐个修复,修复后重新运行对应审查或验证
|
|
49
|
+
- 全部通过 → 按当前已加载的 HelloAGENTS 规则进入 CONSOLIDATE 收尾;若 Codex active goal 的目标也已满足,再标记 goal complete,并按交付边界报告完成
|
package/skills/hello-ui/SKILL.md
CHANGED
|
@@ -1,13 +1,13 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hello-ui
|
|
3
|
-
description: 已进入显式 UI
|
|
3
|
+
description: 已进入显式 UI 工作流、宿主全局模式下的 UI 任务、已初始化项目的视觉变更、设计系统改造或需要视觉验收时使用;在通用 UI 基线之上补充项目契约执行、设计系统映射与视觉验证。
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
本 skill 不是 UI 质量的唯一来源。当前已加载的 HelloAGENTS UI 质量基线负责所有 UI 任务的基础水准;本 skill 在显式 UI
|
|
6
|
+
本 skill 不是 UI 质量的唯一来源。当前已加载的 HelloAGENTS UI 质量基线负责所有 UI 任务的基础水准;本 skill 在显式 UI 工作流、宿主全局模式和复杂 UI 任务中,补充更明确的契约执行、实现映射与视觉验收。
|
|
7
7
|
`.helloagents/` 在本 skill 中统一按项目级存储路径理解:会话证据使用当前 `state_path` 所在目录下的 `artifacts/*.json`;若 `project_store_mode=repo-shared`,`DESIGN.md` 与方案包按当前上下文中已注入的项目知识/方案目录解析。
|
|
8
8
|
|
|
9
9
|
## 适用边界
|
|
10
|
-
已进入显式 UI
|
|
10
|
+
已进入显式 UI 规划/实现/验证路径、宿主全局模式下的 UI 任务,或当前已初始化项目且任务涉及整页新建、跨多个组件的视觉重做、设计系统改造、需要截图验收的界面任务时,读取本 skill。
|
|
11
11
|
标准模式、且项目未初始化时的普通 UI 请求,仍只受当前已加载的 HelloAGENTS UI 质量基线约束;修复 bug、调整文案、改业务逻辑等不涉及视觉变更的任务,不读取本 skill。在已有设计系统中工作时,保留已建立的模式、结构和视觉语言。
|
|
12
12
|
|
|
13
13
|
## 设计契约优先级
|
|
@@ -22,17 +22,17 @@ description: 按任务类型适用 — 建立质量驱动工作流,通过技
|
|
|
22
22
|
|
|
23
23
|
### 流程纪律(执行时)
|
|
24
24
|
- 执行 command skill 时,公共阶段边界以当前已加载的 HelloAGENTS 规则为准;command skill 只补充该命令的专属动作和边界
|
|
25
|
-
- 统一执行流程的六个阶段(ROUTE/TIER→SPEC→PLAN→BUILD→
|
|
26
|
-
- 所有 UI 任务先受当前已加载的 HelloAGENTS UI
|
|
27
|
-
- 方案包存在 `contract.json`
|
|
25
|
+
- 统一执行流程的六个阶段(ROUTE/TIER→SPEC→PLAN→BUILD→QA→CONSOLIDATE)按当前 Delivery Tier 和实际任务推进;未进入的阶段不强行补齐,已进入的阶段不可跳过
|
|
26
|
+
- 所有 UI 任务先受当前已加载的 HelloAGENTS UI 质量基线约束;已初始化项目、宿主全局模式或显式 UI 工作流中的设计约束优先级固定为:当前 `plan.md` / PRD UI 决策 → `.helloagents/DESIGN.md`(按当前项目存储模式解析) → 已读取的 `hello-ui` 具体规则
|
|
27
|
+
- 方案包存在 `contract.json` 时,`qaMode`、`qaFocus`、可选 style advisor / visual validation 与交付检查优先按它执行,不再从自然语言总结里回推
|
|
28
28
|
- 因阻塞判定而必须等待用户输入时,按当前已加载的 HelloAGENTS 规则处理,不得把等待输入包装成完成态
|
|
29
29
|
- ~plan 的需求澄清与方案确认不可跳过,不可一个问题就出方案
|
|
30
30
|
- ~prd 的维度探索不可跳过,每个激活维度必须经过讨论或用户明确跳过
|
|
31
31
|
- ~auto 的复杂度判断不可省略
|
|
32
|
-
-
|
|
32
|
+
- qa-review 的质量铁律:没有实际审查、没有运行验证、没有留下证据 = 不能说完成
|
|
33
33
|
|
|
34
34
|
### 检查清单把关(完成时)
|
|
35
|
-
任务完成后,必须执行以下检查流程(详见
|
|
35
|
+
任务完成后,必须执行以下检查流程(详见 qa-review):
|
|
36
36
|
1. 运行验证命令(lint/test/build)→ 循环直到通过
|
|
37
37
|
2. 收集所有已激活技能的交付检查清单
|
|
38
38
|
3. 逐项验证。仅在交付检查清单、验收记录和验证结果中使用 [√] / [-] 标记,并附带证据;普通说明、方案解释、状态汇报不用这些标记
|
|
@@ -48,7 +48,7 @@ description: 按任务类型适用 — 建立质量驱动工作流,通过技
|
|
|
48
48
|
- 技能引用的 `templates/`、`modules/*.md` 等文件,只在技能明确要求时再读
|
|
49
49
|
|
|
50
50
|
禁止行为:
|
|
51
|
-
- 禁止在 ROUTE / TIER / SPEC 阶段读取实现类技能(hello-ui/hello-test/
|
|
51
|
+
- 禁止在 ROUTE / TIER / SPEC 阶段读取实现类技能(hello-ui/hello-test/qa-review 等)
|
|
52
52
|
- 禁止因为"可能用到"就提前读取技能文件——等到真正需要时再读
|
|
53
53
|
- 同一会话内,同一路径的配置文件、模块、SKILL、模板只读一次并跨轮复用;缺少所需内容、读取失败、用户要求刷新或本次修改后才重新读取
|
|
54
54
|
- ~command 命令只读取对应的 command SKILL.md,不连带读取其他技能
|
|
@@ -63,7 +63,7 @@ description: 按任务类型适用 — 建立质量驱动工作流,通过技
|
|
|
63
63
|
- 若当前上下文未注入,则使用稳定运行根目录 `~/.helloagents/helloagents`
|
|
64
64
|
- 宿主固定链接(Codex `~/.codex/helloagents`、Claude `~/.claude/helloagents`、Gemini `~/.gemini/helloagents`)只作为兼容别名,不作为优先探测路径
|
|
65
65
|
- 仍无法确定时,明确说明缺少 HelloAGENTS 读取根目录;不要递归扫描 `$HOME`、`Downloads`、项目目录或旧版本目录
|
|
66
|
-
-
|
|
66
|
+
- 宿主全局模式或已初始化项目时,技能是否需要使用由当前已加载 AGENTS 规则决定;不要因此额外探测项目目录里的 HelloAGENTS skills 路径
|
|
67
67
|
|
|
68
68
|
### hello-* 技能
|
|
69
69
|
读取 `{HELLOAGENTS_READ_ROOT}/skills/{技能名}/SKILL.md`
|
|
@@ -91,10 +91,9 @@ description: 按任务类型适用 — 建立质量驱动工作流,通过技
|
|
|
91
91
|
- hello-debug — 调试错误/修复 bug/排查失败时
|
|
92
92
|
- hello-subagent — 使用子代理执行任务时
|
|
93
93
|
- hello-write — 撰写文档/报告/方案等非编码文本时
|
|
94
|
-
-
|
|
94
|
+
- qa-review — 统一质量审查、验证、修复与收尾时
|
|
95
95
|
|
|
96
|
-
### 完成时(
|
|
97
|
-
- hello-verify — 声称完成前(必定读取)
|
|
96
|
+
### 完成时(QA / CONSOLIDATE 阶段读取)
|
|
98
97
|
- hello-reflect — 符合触发条件时(详见 hello-reflect SKILL.md)
|
|
99
98
|
|
|
100
99
|
## 命令路由
|
|
@@ -106,11 +105,9 @@ description: 按任务类型适用 — 建立质量驱动工作流,通过技
|
|
|
106
105
|
- `~build`
|
|
107
106
|
- `~prd`
|
|
108
107
|
- `~loop`
|
|
109
|
-
- `~global`
|
|
110
|
-
- `~wiki`
|
|
111
108
|
- `~init`
|
|
112
109
|
- `~test`
|
|
113
|
-
- `~
|
|
110
|
+
- `~qa`
|
|
114
111
|
- `~commit`
|
|
115
112
|
- `~clean`
|
|
116
113
|
- `~help`
|
|
@@ -118,6 +115,6 @@ description: 按任务类型适用 — 建立质量驱动工作流,通过技
|
|
|
118
115
|
兼容别名:
|
|
119
116
|
- `~do` → 直接按 `~build` 的 command skill 路径读取并执行
|
|
120
117
|
- `~design` → 直接按 `~plan` 的 command skill 路径读取并执行
|
|
121
|
-
- `~review` → 直接按 `~
|
|
118
|
+
- `~review` → 直接按 `~qa` 的 command skill 路径读取并执行
|
|
122
119
|
|
|
123
120
|
只有当对应 command skill 明确要求再读取 hello-* 技能时,才按上方“hello-* 技能”规则继续读取。
|