helloagents 3.0.7 → 3.0.8-beta.1
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 -1
- package/.claude-plugin/plugin.json +1 -1
- package/.codex-plugin/plugin.json +1 -1
- package/README.md +62 -55
- package/README_CN.md +56 -49
- package/bootstrap-lite.md +42 -25
- package/bootstrap.md +46 -30
- package/gemini-extension.json +1 -1
- package/package.json +12 -2
- package/scripts/capability-registry.mjs +4 -4
- package/scripts/cli-codex-config.mjs +49 -55
- package/scripts/cli-codex.mjs +67 -77
- package/scripts/cli-doctor.mjs +20 -17
- package/scripts/cli-messages.mjs +1 -1
- package/scripts/cli-toml.mjs +30 -0
- package/scripts/guard-rules.mjs +26 -1
- package/scripts/guard.mjs +38 -10
- package/scripts/notify-context.mjs +2 -7
- package/scripts/notify.mjs +19 -8
- package/scripts/turn-state.mjs +173 -0
- package/scripts/workflow-core.mjs +6 -6
- package/scripts/workflow-recommendation.mjs +14 -14
- package/scripts/workflow-state.mjs +2 -2
- package/skills/_meta/SKILL.md +1 -1
- package/skills/commands/auto/SKILL.md +24 -9
- package/skills/commands/build/SKILL.md +3 -3
- package/skills/commands/clean/SKILL.md +3 -3
- package/skills/commands/help/SKILL.md +3 -3
- package/skills/commands/idea/SKILL.md +2 -2
- package/skills/commands/init/SKILL.md +12 -7
- package/skills/commands/loop/SKILL.md +1 -1
- package/skills/commands/plan/SKILL.md +11 -9
- package/skills/commands/prd/SKILL.md +8 -6
- package/skills/commands/verify/SKILL.md +5 -5
- package/skills/commands/wiki/SKILL.md +8 -10
- package/skills/hello-review/SKILL.md +1 -1
- package/skills/hello-subagent/SKILL.md +3 -2
- package/skills/hello-ui/SKILL.md +12 -12
- package/skills/hello-verify/SKILL.md +6 -5
- package/skills/helloagents/SKILL.md +17 -12
|
@@ -59,7 +59,7 @@ function buildConsolidateAction(recommendation) {
|
|
|
59
59
|
phase: 'consolidate',
|
|
60
60
|
mode: recommendation.mode,
|
|
61
61
|
routeHint: recommendation.guidance,
|
|
62
|
-
gateHint: '
|
|
62
|
+
gateHint: '交付把关:审查与验证证据已满足;先写 `.helloagents/.ralph-closeout.json` 记录需求覆盖与交付清单,再完成 STATE.md / 归档后才可交付。',
|
|
63
63
|
}
|
|
64
64
|
}
|
|
65
65
|
|
|
@@ -67,7 +67,7 @@ function buildConsolidateAction(recommendation) {
|
|
|
67
67
|
phase: 'consolidate',
|
|
68
68
|
mode: recommendation.mode || 'ready',
|
|
69
69
|
routeHint: recommendation.guidance,
|
|
70
|
-
gateHint: '
|
|
70
|
+
gateHint: '交付把关:当前已具备收尾证据;完成 STATE.md、知识沉淀与归档后即可交付。',
|
|
71
71
|
}
|
|
72
72
|
}
|
|
73
73
|
|
|
@@ -88,7 +88,7 @@ function buildVerifyAction(plan, verifyMode) {
|
|
|
88
88
|
phase: 'verify',
|
|
89
89
|
mode: verifyMode.mode,
|
|
90
90
|
routeHint: verifyMode.guidance,
|
|
91
|
-
gateHint:
|
|
91
|
+
gateHint: `交付把关:进入 CONSOLIDATE 前,必须先完成 reviewer / hello-review 范围审查,再完成 tester / hello-verify 全量验证,并留下最新验证证据;两步都通过后才可交付。${gateSuffix}`.trim(),
|
|
92
92
|
}
|
|
93
93
|
}
|
|
94
94
|
if (verifyMode.mode === 'metadata-first') {
|
|
@@ -97,8 +97,8 @@ function buildVerifyAction(plan, verifyMode) {
|
|
|
97
97
|
mode: verifyMode.mode,
|
|
98
98
|
routeHint: verifyMode.guidance,
|
|
99
99
|
gateHint: plan.contractIssues.length > 0
|
|
100
|
-
? '
|
|
101
|
-
: '
|
|
100
|
+
? '交付把关:当前还不能进入 CONSOLIDATE;先补齐 `contract.json` 中的 `verifyMode`、`reviewerFocus`、`testerFocus`,再进入 reviewer / tester。'
|
|
101
|
+
: '交付把关:当前还不能进入 CONSOLIDATE;先补齐 tasks.md 中每个任务的“涉及文件”“完成标准”和“验证方式”,再进入 reviewer / tester。',
|
|
102
102
|
}
|
|
103
103
|
}
|
|
104
104
|
|
|
@@ -106,7 +106,7 @@ function buildVerifyAction(plan, verifyMode) {
|
|
|
106
106
|
phase: 'verify',
|
|
107
107
|
mode: verifyMode.mode,
|
|
108
108
|
routeHint: verifyMode.guidance,
|
|
109
|
-
gateHint:
|
|
109
|
+
gateHint: `交付把关:进入 CONSOLIDATE 前,先完成 tester / hello-verify 全量验证并留下最新验证证据,再针对失败点或关键边界补充 hello-review;确认通过后才可交付。${gateSuffix}`.trim(),
|
|
110
110
|
}
|
|
111
111
|
}
|
|
112
112
|
|
|
@@ -124,13 +124,13 @@ export function buildDeliveryActionFromSnapshot(snapshot, cwd, recommendation =
|
|
|
124
124
|
if (recommendation.nextCommand === 'build') {
|
|
125
125
|
return {
|
|
126
126
|
phase: 'build',
|
|
127
|
-
gateHint: '
|
|
127
|
+
gateHint: '交付把关:当前还不能报告完成;先回到 ~build 完成剩余任务,再进入 ~verify。',
|
|
128
128
|
}
|
|
129
129
|
}
|
|
130
130
|
if (recommendation.nextCommand === 'plan') {
|
|
131
131
|
return {
|
|
132
132
|
phase: 'plan',
|
|
133
|
-
gateHint: '
|
|
133
|
+
gateHint: '交付把关:当前还不能报告完成;先回到 ~plan 修复或补齐当前方案包,再进入 ~build / ~verify。',
|
|
134
134
|
}
|
|
135
135
|
}
|
|
136
136
|
|
|
@@ -153,7 +153,7 @@ function buildPlanRecommendation(scopeLabel, plan, classification) {
|
|
|
153
153
|
? `${scopeLabel} "${plan.planName}" 仍不完整(${classification.details.join(';')})。`
|
|
154
154
|
: `${scopeLabel} "${plan.planName}" 尚未形成可执行任务清单。`,
|
|
155
155
|
guidance: classification.status === 'incomplete'
|
|
156
|
-
? '优先先走 ~plan
|
|
156
|
+
? '优先先走 ~plan 修复或补全当前方案包,再进入实现或验证;不要把不完整的结构化产物直接当成可交付依据。'
|
|
157
157
|
: '先回到 ~plan 补齐 tasks.md 的原子任务,再进入实现、验证或收尾。',
|
|
158
158
|
}
|
|
159
159
|
}
|
|
@@ -180,7 +180,7 @@ function buildClosedRecommendation(scopeLabel, plan, cwd) {
|
|
|
180
180
|
status: 'closed',
|
|
181
181
|
nextCommand: 'verify',
|
|
182
182
|
nextPath: '~verify -> CONSOLIDATE',
|
|
183
|
-
summary: `${scopeLabel} "${plan.planName}"
|
|
183
|
+
summary: `${scopeLabel} "${plan.planName}" 的任务已全部闭合,但验证契约仍未结构化。`,
|
|
184
184
|
guidance: closedPlanEvidence.verifyMode.guidance,
|
|
185
185
|
}
|
|
186
186
|
}
|
|
@@ -197,7 +197,7 @@ function buildClosedRecommendation(scopeLabel, plan, cwd) {
|
|
|
197
197
|
status: 'closed',
|
|
198
198
|
nextCommand: 'verify',
|
|
199
199
|
nextPath: '~verify -> CONSOLIDATE',
|
|
200
|
-
summary: `${scopeLabel} "${plan.planName}" 的任务已闭合,但当前 UI
|
|
200
|
+
summary: `${scopeLabel} "${plan.planName}" 的任务已闭合,但当前 UI 契约仍要求独立 advisor 复查与视觉验收。`,
|
|
201
201
|
guidance: '先在 ~verify 阶段完成独立 advisor / style advisor 复查,并写入 `.helloagents/.ralph-advisor.json`;再完成视觉验收并写入 `.helloagents/.ralph-visual.json`,记录 reason、tooling、screensChecked、statesChecked、status 与 summary;两项都通过后再进入 CONSOLIDATE。',
|
|
202
202
|
}
|
|
203
203
|
}
|
|
@@ -209,7 +209,7 @@ function buildClosedRecommendation(scopeLabel, plan, cwd) {
|
|
|
209
209
|
status: 'closed',
|
|
210
210
|
nextCommand: 'verify',
|
|
211
211
|
nextPath: '~verify -> CONSOLIDATE',
|
|
212
|
-
summary: `${scopeLabel} "${plan.planName}"
|
|
212
|
+
summary: `${scopeLabel} "${plan.planName}" 的任务已闭合,但当前契约仍要求独立 advisor 复查。`,
|
|
213
213
|
guidance: '先在 ~verify 阶段完成独立 advisor / style advisor 复查,并写入 `.helloagents/.ralph-advisor.json` 记录复查原因、focus、来源与结论;advisor 通过后再进入 CONSOLIDATE。',
|
|
214
214
|
}
|
|
215
215
|
}
|
|
@@ -221,7 +221,7 @@ function buildClosedRecommendation(scopeLabel, plan, cwd) {
|
|
|
221
221
|
status: 'closed',
|
|
222
222
|
nextCommand: 'verify',
|
|
223
223
|
nextPath: '~verify -> CONSOLIDATE',
|
|
224
|
-
summary: `${scopeLabel} "${plan.planName}" 的任务已闭合,但当前 UI
|
|
224
|
+
summary: `${scopeLabel} "${plan.planName}" 的任务已闭合,但当前 UI 契约仍要求视觉验收。`,
|
|
225
225
|
guidance: '先在 ~verify 阶段完成视觉验收,并写入 `.helloagents/.ralph-visual.json` 记录 reason、tooling、screensChecked、statesChecked、status 与 summary;视觉验收通过后再进入 CONSOLIDATE。',
|
|
226
226
|
}
|
|
227
227
|
}
|
|
@@ -307,7 +307,7 @@ function buildBuildOrchestrationHint(plan) {
|
|
|
307
307
|
return `编排提示:检测到可并行的开放任务;如需提速,可先读取 hello-subagent 再按 tasks.md 分派。任务A:${describeTask(pair[0])};任务B:${describeTask(pair[1])}。`
|
|
308
308
|
}
|
|
309
309
|
if (openTasks.every((item) => item.files.length === 0)) {
|
|
310
|
-
return '编排提示:当前有多个开放任务,但 tasks.md
|
|
310
|
+
return '编排提示:当前有多个开放任务,但 tasks.md 尚未写清契约元数据;考虑子代理并行前先补足文件路径、完成标准与验证方式。'
|
|
311
311
|
}
|
|
312
312
|
return '编排提示:当前仍有多个开放任务,但文件范围存在重叠;暂不建议并行子代理,优先串行推进。'
|
|
313
313
|
}
|
|
@@ -57,8 +57,8 @@ export function buildWorkflowRouteHint(cwd) {
|
|
|
57
57
|
function buildCommandRouteMessage(skillName, recommendation, verifyModeHint) {
|
|
58
58
|
if (skillName === 'auto') {
|
|
59
59
|
return recommendation.stage === 'consolidate'
|
|
60
|
-
? `当前工作流约束:${recommendation.summary} 当前建议下一阶段:CONSOLIDATE。${recommendation.guidance}
|
|
61
|
-
: `当前工作流约束:${recommendation.summary} 当前建议主路径:${recommendation.nextPath}。${recommendation.guidance}
|
|
60
|
+
? `当前工作流约束:${recommendation.summary} 当前建议下一阶段:CONSOLIDATE。${recommendation.guidance} 若本次明确使用 ~auto,则在未命中阻塞判定时直接完成当前收尾,不再额外停下询问。`
|
|
61
|
+
: `当前工作流约束:${recommendation.summary} 当前建议主路径:${recommendation.nextPath}。${recommendation.guidance} 若本次明确使用 ~auto,则命中主路径后继续衔接后续阶段,除非触发阻塞判定,否则不要在方案/PRD 阶段额外停下。`
|
|
62
62
|
}
|
|
63
63
|
if (skillName === 'plan') {
|
|
64
64
|
if (recommendation.stage === 'consolidate') {
|
package/skills/_meta/SKILL.md
CHANGED
|
@@ -1,27 +1,28 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ~auto
|
|
3
|
-
description:
|
|
3
|
+
description: 自动编排命令 — 自动选择并串联 ~idea / ~plan / ~build / ~verify / ~prd,默认持续推进直到交付完成(~auto 命令)
|
|
4
4
|
policy:
|
|
5
5
|
allow_implicit_invocation: false
|
|
6
6
|
---
|
|
7
7
|
Trigger: ~auto <任务描述>
|
|
8
8
|
|
|
9
|
-
`~auto`
|
|
10
|
-
`~auto`
|
|
9
|
+
`~auto` 是自动编排命令。它根据任务类型、复杂度、风险等级与项目状态,自动在 `~idea`、`~plan`、`~build`、`~verify`、`~prd` 之间选择合适主路径,并把这些阶段串成一条连续交付链路。
|
|
10
|
+
`~auto` 不止做一次选路;主路径一旦确定,就按需要继续衔接后续阶段,默认持续推进直到完成交付,只有命中 bootstrap 的阻塞判定时才停下。
|
|
11
11
|
|
|
12
12
|
## 铁律
|
|
13
13
|
- 不为了“自动化”而强行走重流程
|
|
14
14
|
- 复杂度与风险不足以支撑更重路径时,优先选更轻但能保证质量的路线
|
|
15
15
|
- `T3` 高风险或不可逆链路默认不直接进入 `~build`;优先先走 `~plan` 或 `~prd`,纯审查/纯验证请求才可先进入 `~verify`
|
|
16
|
-
-
|
|
16
|
+
- 主路径一旦确定,立即读取对应 command skill,并在阶段完成后继续衔接后续阶段,避免同一任务重复探索或重复等待
|
|
17
17
|
- 选路不替代授权;涉及外部副作用或高风险不可逆操作时,仍遵守 bootstrap 的阻塞判定与确认规则
|
|
18
|
-
-
|
|
18
|
+
- 用户显式使用 `~auto`,表示已授权在当前任务边界内沿选定主路径持续执行;`~plan` / `~prd` 作为中间阶段时,不再额外询问“是否开始执行”,除非仍有真实阻塞
|
|
19
|
+
- 优先消费当前上下文中已注入的 ROUTE / TIER、当前工作流约束与项目状态;不要在 `~auto` 内另建一套关键词路由表
|
|
19
20
|
|
|
20
21
|
## 流程
|
|
21
22
|
|
|
22
23
|
### 0. 当前工作流优先
|
|
23
24
|
|
|
24
|
-
-
|
|
25
|
+
- 若当前上下文中已注入“当前工作流提示”或“当前工作流约束”,优先服从其中的推荐下一命令 / 主路径
|
|
25
26
|
- 默认原则:
|
|
26
27
|
- 活跃方案包不完整或缺少任务清单 → 先 `~plan`
|
|
27
28
|
- 活跃方案包仍在执行 → 先 `~build`,完成当前实现后再 `~verify`
|
|
@@ -31,7 +32,7 @@ Trigger: ~auto <任务描述>
|
|
|
31
32
|
### 1. 选路
|
|
32
33
|
|
|
33
34
|
- 先按当前上下文里已注入的 ROUTE / TIER 语义约束判断,不依赖关键词命中做机械分流
|
|
34
|
-
-
|
|
35
|
+
- 若本轮没有足够的注入约束,再结合以下信号补足判断:影响范围、风险等级、是否需要结构化产物、是否已有活跃方案包、用户是否只想先比较方向
|
|
35
36
|
- 选路优先级:
|
|
36
37
|
- 纯探索 / 点子 / 方向比较 → `~idea`
|
|
37
38
|
- 明确要求验证 / 审查 / 跑检查 → `~verify`
|
|
@@ -43,10 +44,10 @@ Trigger: ~auto <任务描述>
|
|
|
43
44
|
|
|
44
45
|
- `T0` → 保持在 `~idea`,不创建项目文件
|
|
45
46
|
- `T1` → 在 `~build` / `~verify` 间选择最短可交付路径
|
|
46
|
-
- `T2` →
|
|
47
|
+
- `T2` → 需要结构化产物或范围未完全收敛时优先 `~plan`
|
|
47
48
|
- `T3` → 纯审查/验真走 `~verify`;其余默认 `~plan` 或 `~prd`,待方案与风险边界明确后再进入实现
|
|
48
49
|
|
|
49
|
-
### 3.
|
|
50
|
+
### 3. 读取对应命令并执行主路径
|
|
50
51
|
|
|
51
52
|
- 选中 `idea` → 读取 `skills/commands/idea/SKILL.md`
|
|
52
53
|
- 选中 `plan` → 读取 `skills/commands/plan/SKILL.md`
|
|
@@ -55,3 +56,17 @@ Trigger: ~auto <任务描述>
|
|
|
55
56
|
- 选中 `prd` → 读取 `skills/commands/prd/SKILL.md`
|
|
56
57
|
|
|
57
58
|
不要额外读取未选中的 command skill。
|
|
59
|
+
|
|
60
|
+
### 4. 自动衔接直到完成
|
|
61
|
+
|
|
62
|
+
- 若主路径是 `~build` → 完成实现后继续进入 `~verify`,再按当前链路进入收尾
|
|
63
|
+
- 若主路径是 `~plan` → 方案包落地后,若当前链路来自 `~auto` 且未命中阻塞判定,直接继续进入 `~build`,不要把“方案已形成”当作最终停点
|
|
64
|
+
- 若主路径是 `~prd` → PRD / 任务 / 契约落地后,若当前链路来自 `~auto` 且未命中阻塞判定,按收敛结果继续进入 `~build`,必要时先补一轮轻量 `~plan`
|
|
65
|
+
- 若主路径是 `~verify` → 完成审查 / 验证 / 收尾后结束
|
|
66
|
+
- 若主路径是 `~idea`,且用户本意就是探索/比较,则在探索输出后结束;若探索后已收敛成明确方向且当前任务仍要求落地,则继续进入 `~plan` 或 `~build`
|
|
67
|
+
|
|
68
|
+
### 5. 何时允许停下
|
|
69
|
+
|
|
70
|
+
- 仅在 bootstrap 的阻塞判定成立时停下:真实歧义、缺必需信息/文件/凭据、未授权外部副作用、高风险或不可逆操作
|
|
71
|
+
- 不得把 `~plan` / `~prd` 中“是否进入执行”的默认询问原样带入 `~auto` 链路
|
|
72
|
+
- 不得把“给出方案”“给出任务列表”“给出建议下一步”当作 `~auto` 的默认完成态;用户显式要求 `~auto` 时,默认目标是把当前任务推进到可交付完成
|
|
@@ -8,7 +8,7 @@ Trigger: ~build [description]
|
|
|
8
8
|
|
|
9
9
|
`~build` 是执行实现命令。它负责读取现有需求、方案包与项目上下文,完成实现、局部验证、修复循环,并把结果衔接到后续验证与收尾。
|
|
10
10
|
执行 `~build` 时,通用阶段边界按当前已加载 bootstrap 执行;本 skill 负责补充实现前定位、实现约束,以及进入 `~verify` / 收尾前的实现边界。
|
|
11
|
-
`.helloagents/` 在本 skill
|
|
11
|
+
`.helloagents/` 在本 skill 中统一按项目级存储路径理解:`STATE.md` 与 `.ralph-*.json` 保持项目本地;若 `project_store_mode=repo-shared`,知识库、`DESIGN.md`、`verify.yaml` 与方案包按当前上下文中已注入的项目知识/方案目录解析。
|
|
12
12
|
|
|
13
13
|
## 铁律
|
|
14
14
|
- 默认先定位上下文与范围,再修改代码
|
|
@@ -26,9 +26,9 @@ Trigger: ~build [description]
|
|
|
26
26
|
- `plan.md`
|
|
27
27
|
- `tasks.md`
|
|
28
28
|
- `contract.json`
|
|
29
|
-
- 实现时优先把 `tasks.md`
|
|
29
|
+
- 实现时优先把 `tasks.md` 中每个任务的“完成标准”当作本轮实现约束,不要只按任务标题猜测范围
|
|
30
30
|
- `contract.json` 存在时,优先按其中的 `verifyMode`、`reviewerFocus`、`testerFocus` 理解后续验证边界
|
|
31
|
-
-
|
|
31
|
+
- 若当前上下文中已注入“当前工作流约束”或“当前建议下一命令”,先服从它;只有推荐仍为 `~build`,或用户明确提出新增实现范围时,才继续 `~build`
|
|
32
32
|
- 其余项目知识库与相关代码文件,按 bootstrap 的项目上下文规则按需读取
|
|
33
33
|
- 若任务涉及 UI,按以下优先级读取并遵循:当前活跃 `plan.md` / PRD 中的 UI 决策 > 逻辑 `.helloagents/DESIGN.md`(实际路径按当前项目存储模式解析) > `hello-ui` 通用规则
|
|
34
34
|
- 若已激活项目且当前任务属于整页新建、设计系统改造、或跨多个组件的视觉重做,但逻辑 `.helloagents/DESIGN.md` 不存在,先按模板创建最小设计契约,再继续大规模实现
|
|
@@ -7,13 +7,13 @@ policy:
|
|
|
7
7
|
Trigger: ~clean
|
|
8
8
|
|
|
9
9
|
执行 `~clean` 时,方案包归档、临时文件清理和 `STATE.md` 更新边界按当前已加载 bootstrap 执行;本命令只负责判定哪些方案包可以清理,以及输出清理摘要。
|
|
10
|
-
`.helloagents/` 在本 skill
|
|
10
|
+
`.helloagents/` 在本 skill 中统一按项目级存储路径理解:`STATE.md` 和临时运行态文件保持项目本地;若 `project_store_mode=repo-shared`,`plans/` 与 `archive/` 按当前上下文中已注入的项目知识/方案目录解析。
|
|
11
11
|
|
|
12
12
|
## 流程
|
|
13
13
|
|
|
14
|
-
1.
|
|
14
|
+
1. 扫描 `.helloagents/plans/` 下的方案包(按当前项目存储模式解析;`project_store_mode=repo-shared` 时使用共享知识/方案目录)
|
|
15
15
|
2. 判定完成状态:优先以 tasks.md 中所有任务已标记 [√] 为准;只有任务清单无法判断时,才把 `STATE.md` 中与当前方案一致的“主线目标”+“正在做什么”作为辅助信号,避免把旧恢复快照误当当前主线
|
|
16
|
-
3. 已完成的方案包 → 按 bootstrap
|
|
16
|
+
3. 已完成的方案包 → 按 bootstrap 的归档规则移入 `.helloagents/archive/YYYY-MM/`(按当前项目存储模式解析),并同步更新 `.helloagents/archive/_index.md`
|
|
17
17
|
4. 清理 bootstrap 中定义的临时文件
|
|
18
18
|
5. 按 bootstrap 的流程状态规则更新 `STATE.md`;若当前状态指向已归档方案包,则清空对应方案路径
|
|
19
19
|
7. 输出清理摘要(归档了几个方案包、清理了哪些文件)
|
|
@@ -12,13 +12,13 @@ Trigger: ~help
|
|
|
12
12
|
| 命令 | 说明 |
|
|
13
13
|
|------|------|
|
|
14
14
|
| ~idea | 轻量点子探索与方向比较 |
|
|
15
|
-
| ~auto |
|
|
15
|
+
| ~auto | 自动编排:自动选主路径并持续衔接到执行 / 验证 / 收尾,除非命中真实阻塞 |
|
|
16
16
|
| ~plan | 结构化规划:需求澄清 + 方案收敛 + 方案包 |
|
|
17
17
|
| ~build | 执行实现:按需求或方案包完成实现与验证 |
|
|
18
18
|
| ~prd | 完整 PRD:头脑风暴式逐维度挖掘,生成现代产品需求文档 |
|
|
19
19
|
| ~loop | 自主迭代优化:设定目标和指标,循环修改-验证-保留/回滚 |
|
|
20
20
|
| ~wiki | 仅创建/同步项目知识库(`.helloagents/`) |
|
|
21
|
-
| ~init | 完整初始化项目:知识库 +
|
|
21
|
+
| ~init | 完整初始化项目:知识库 + 项目级规则文件配置 |
|
|
22
22
|
| ~test | 为指定模块或最近变更编写完整测试 |
|
|
23
23
|
| ~verify | 验证总入口:审查 + 运行验证命令 + 修复循环 |
|
|
24
24
|
| ~commit | 规范化提交 + 知识库同步 |
|
|
@@ -32,7 +32,7 @@ Trigger: ~help
|
|
|
32
32
|
|
|
33
33
|
### 自动激活技能
|
|
34
34
|
以下技能仅在全局模式或已激活项目中自动激活(例如执行过 `~wiki`、`~init`,或已处于项目级连续流程)。
|
|
35
|
-
纯标准模式未激活项目不会自动触发这些深层技能;但涉及 UI 的任务仍受 UI
|
|
35
|
+
纯标准模式未激活项目不会自动触发这些深层技能;但涉及 UI 的任务仍受 UI 质量基线约束。
|
|
36
36
|
|
|
37
37
|
编码时:hello-ui, hello-api, hello-data, hello-security, hello-errors, hello-perf, hello-arch, hello-test
|
|
38
38
|
特定场景:hello-debug, hello-subagent, hello-write, hello-review
|
|
@@ -11,7 +11,7 @@ Trigger: ~idea [description]
|
|
|
11
11
|
## 铁律
|
|
12
12
|
- 只讨论,不编写实现代码,不创建项目文件,不执行实现操作
|
|
13
13
|
- 不创建 `.helloagents/`
|
|
14
|
-
- 不创建或更新 `.helloagents/STATE.md
|
|
14
|
+
- 不创建或更新 `.helloagents/STATE.md`、知识库文件、方案包或项目级规则文件
|
|
15
15
|
- 不生成方案包
|
|
16
16
|
- 不执行会改变工作区或外部状态的命令
|
|
17
17
|
- 不默认使用子代理
|
|
@@ -45,7 +45,7 @@ Trigger: ~idea [description]
|
|
|
45
45
|
- 想形成结构化方案 → `~plan`
|
|
46
46
|
- 想直接进入实现 → `~build`
|
|
47
47
|
- 需要重型产品规格 → `~prd`
|
|
48
|
-
- 想让 AI
|
|
48
|
+
- 想让 AI 自动编排完整链路 → `~auto`
|
|
49
49
|
- 如果用户在 `~idea` 过程中转而明确要求写文件、改代码、创建知识库或执行命令,不在 `~idea` 内偷偷落地;改为按最合适的升级路径继续
|
|
50
50
|
|
|
51
51
|
## 输出要求
|
|
@@ -1,22 +1,25 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ~init
|
|
3
|
-
description:
|
|
3
|
+
description: 初始化项目知识库与项目级规则文件(~init 命令)
|
|
4
4
|
policy:
|
|
5
5
|
allow_implicit_invocation: false
|
|
6
6
|
---
|
|
7
7
|
Trigger: ~init
|
|
8
8
|
|
|
9
9
|
~init 是用户显式命令,创建完整知识库,不受 kb_create_mode 限制。
|
|
10
|
-
执行 `~init` 时,`.helloagents/` 目录结构、模板格式和 `STATE.md` 规则按当前已加载 bootstrap
|
|
11
|
-
`.helloagents/` 在本 skill
|
|
10
|
+
执行 `~init` 时,`.helloagents/` 目录结构、模板格式和 `STATE.md` 规则按当前已加载 bootstrap 执行;本命令额外负责项目级规则文件和各宿主项目级原生 skills 链接。
|
|
11
|
+
`.helloagents/` 在本 skill 中统一按项目级存储路径理解:项目本地 `.helloagents/` 继续承担激活目录与 `STATE.md`;若 `project_store_mode=repo-shared`,知识库、`DESIGN.md` 与方案包按当前上下文中已注入的项目知识/方案目录写入。
|
|
12
12
|
|
|
13
13
|
## 流程
|
|
14
14
|
|
|
15
15
|
### 阶段 1:环境搭建(必做)
|
|
16
16
|
|
|
17
17
|
1. 创建 `.helloagents/` 目录 + `STATE.md`(按 templates/STATE.md 格式,初始“主线目标”写当前初始化链路,初始状态为空闲)
|
|
18
|
-
2.
|
|
19
|
-
3.
|
|
18
|
+
2. 定位插件根目录:优先读取当前上下文中已注入的“当前 HelloAGENTS 包根目录”;若上下文未提供,再根据当前已加载的规则文件反推,禁止猜测其他目录
|
|
19
|
+
3. 刷新各宿主项目级原生 skills 链接(删除旧的重建):
|
|
20
|
+
- `.claude/skills/helloagents` symlink → `{插件根目录}/`
|
|
21
|
+
- `.gemini/skills/helloagents` symlink → `{插件根目录}/`
|
|
22
|
+
- `.codex/skills/helloagents` symlink → `{插件根目录}/`
|
|
20
23
|
4. 读取 `{插件根目录}/bootstrap.md`,用 `<!-- HELLOAGENTS_START -->` / `<!-- HELLOAGENTS_END -->` 标记包裹后写入:
|
|
21
24
|
- `AGENTS.md`(项目根目录,Codex 读取)
|
|
22
25
|
- `CLAUDE.md`(项目根目录,Claude Code 读取)
|
|
@@ -25,7 +28,9 @@ Trigger: ~init
|
|
|
25
28
|
5. 追加 `.gitignore`(如果对应行不存在):
|
|
26
29
|
```
|
|
27
30
|
.helloagents/
|
|
28
|
-
skills/helloagents
|
|
31
|
+
.claude/skills/helloagents
|
|
32
|
+
.gemini/skills/helloagents
|
|
33
|
+
.codex/skills/helloagents
|
|
29
34
|
AGENTS.md
|
|
30
35
|
CLAUDE.md
|
|
31
36
|
.gemini/GEMINI.md
|
|
@@ -58,6 +63,6 @@ commands:
|
|
|
58
63
|
重复执行 ~init 是安全的:
|
|
59
64
|
- 已存在的 .helloagents/ 文件不覆盖
|
|
60
65
|
- `STATE.md` 只作为当前初始化链路的恢复快照;后续进入其他主线任务时必须按新主线重写
|
|
61
|
-
-
|
|
66
|
+
- 各宿主项目级原生 skills 链接会刷新(删除旧的重建)
|
|
62
67
|
- AGENTS.md/CLAUDE.md/GEMINI.md 中标记内容替换更新
|
|
63
68
|
- .gitignore 只追加缺失行
|
|
@@ -77,7 +77,7 @@ iteration commit metric delta guard status description
|
|
|
77
77
|
### Phase 7: Log
|
|
78
78
|
- 追加一行到 results log
|
|
79
79
|
- status: baseline / keep / discard / crash / no-op
|
|
80
|
-
- 重写 `.helloagents/STATE.md
|
|
80
|
+
- 重写 `.helloagents/STATE.md`:保持主线目标=当前优化目标,并记录当前迭代轮次、最近一次决策(keep / discard / crash)、当前最佳指标、下一步动作
|
|
81
81
|
|
|
82
82
|
### Phase 8: Repeat
|
|
83
83
|
- 如果 iterations > 0 且 current_iteration >= max_iterations → 输出总结并停止
|
|
@@ -6,15 +6,16 @@ policy:
|
|
|
6
6
|
---
|
|
7
7
|
Trigger: ~plan [description]
|
|
8
8
|
|
|
9
|
-
`~plan`
|
|
9
|
+
`~plan` 是实现前的主规划命令。它负责需求澄清、方案设计、任务拆解与方案落盘;直接显式执行 `~plan` 时,默认停在“形成可执行方案”,只有用户明确授权继续时才衔接执行。
|
|
10
10
|
执行 `~plan` 时,通用阶段边界按当前已加载 bootstrap 执行;本 skill 负责补充 `~plan` 的需求澄清、方案收敛、方案包写入与执行衔接要求。
|
|
11
|
-
`.helloagents/` 在本 skill
|
|
11
|
+
`.helloagents/` 在本 skill 中统一按项目级存储路径理解:`STATE.md` 与 `.ralph-*.json` 保持项目本地;若 `project_store_mode=repo-shared`,知识库、`DESIGN.md` 与 `plans/` / `archive/` 按当前上下文中已注入的项目知识/方案目录解析。
|
|
12
12
|
|
|
13
13
|
## 铁律
|
|
14
14
|
- 在用户确认方案之前,禁止编写任何实现代码、创建任何实现文件、或执行任何实现操作
|
|
15
15
|
- 需求澄清阶段不读取实现类技能(hello-ui / hello-test / hello-verify 等),需求明确后再按需读取
|
|
16
|
-
-
|
|
17
|
-
-
|
|
16
|
+
- 方案必须收敛为可执行产物,不停留在泛化建议
|
|
17
|
+
- 若当前链路来自 `~auto`,则“开始执行”视为已包含在 `~auto` 授权内;方案包落地后默认继续衔接执行,只有命中阻塞判定时才停下
|
|
18
|
+
- 涉及 UI 时,当前方案包中的 UI 决策优先于 `.helloagents/DESIGN.md`;`.helloagents/DESIGN.md`(按当前项目存储模式解析)优先于通用 UI 规则
|
|
18
19
|
|
|
19
20
|
## 流程
|
|
20
21
|
|
|
@@ -22,7 +23,7 @@ Trigger: ~plan [description]
|
|
|
22
23
|
|
|
23
24
|
已有项目:
|
|
24
25
|
- 按当前已加载 bootstrap 的“.helloagents/ 文件读取优先级”和“项目文件”规则恢复上下文;若当前消息显式继续既有链路,或会话刚经历恢复 / 压缩,先把 `.helloagents/STATE.md` 当恢复快照使用,再用当前用户消息、显式命令、活跃方案包 / PRD 与代码事实校正主线
|
|
25
|
-
-
|
|
26
|
+
- 在需求澄清前,至少确认 `.helloagents/context.md`、`.helloagents/guidelines.md`(按当前项目存储模式解析);涉及 UI 时,如存在 `.helloagents/DESIGN.md`(按当前项目存储模式解析),一并读取现有设计契约
|
|
26
27
|
- 只扫描与当前需求直接相关的代码文件,用于形成假设和识别约束
|
|
27
28
|
|
|
28
29
|
全新项目(无 `.helloagents/` 目录):
|
|
@@ -58,7 +59,7 @@ Trigger: ~plan [description]
|
|
|
58
59
|
涉及 UI 的方案:
|
|
59
60
|
- 读取 `hello-ui` SKILL.md
|
|
60
61
|
- 将视觉、交互、设计系统要求纳入方案
|
|
61
|
-
- 区分“本次 feature 的 UI 决策”和“项目级稳定设计契约”:前者写入 `plan.md
|
|
62
|
+
- 区分“本次 feature 的 UI 决策”和“项目级稳定设计契约”:前者写入 `plan.md`,后者同步到 `.helloagents/DESIGN.md`(按当前项目存储模式解析)
|
|
62
63
|
|
|
63
64
|
### 4. 方案细化
|
|
64
65
|
|
|
@@ -73,7 +74,7 @@ Trigger: ~plan [description]
|
|
|
73
74
|
|
|
74
75
|
将确认的方案写入本地项目:
|
|
75
76
|
- 按当前已加载 bootstrap 的 `.helloagents/` 与流程状态规则,确保最小项目状态已建立
|
|
76
|
-
-
|
|
77
|
+
- 创建 `.helloagents/plans/YYYYMMDDHHMM_{feature}/`(按当前项目存储模式解析)
|
|
77
78
|
- 按模板写入:
|
|
78
79
|
- `requirements.md`
|
|
79
80
|
- `plan.md`
|
|
@@ -83,8 +84,8 @@ Trigger: ~plan [description]
|
|
|
83
84
|
- 只有在 UI 方向确需前置收敛时,才额外写 `ui.styleAdvisor.required`、`ui.styleAdvisor.reason` 与 `ui.styleAdvisor.focus`;它复用 `.helloagents/.ralph-advisor.json`,不是默认常驻步骤
|
|
84
85
|
- 只有在 UI 验收确有收益时,才额外写 `ui.visualValidation.required`、`ui.visualValidation.reason`、`ui.visualValidation.screens` 与 `ui.visualValidation.states`;不要把视觉验收扩成所有 UI 任务的固定步骤
|
|
85
86
|
- 只有在 `T3`、非 UI 的高风险审查或确需额外跨模型建议时,才写 `advisor.required`、`advisor.reason`、`advisor.focus` 与 `advisor.preferredSources`;不要把 advisor 变成默认常驻流程
|
|
86
|
-
- 使用 `scripts/plan-contract.mjs write` 写 `contract.json
|
|
87
|
-
- 涉及 UI
|
|
87
|
+
- 使用 `scripts/plan-contract.mjs write` 写 `contract.json`,不要让后续检查脚本再从 `plan.md` 的自然语言说明里猜验证主路径
|
|
88
|
+
- 涉及 UI 的项目:生成或更新 `.helloagents/DESIGN.md`(按当前项目存储模式解析);若原文件不存在,先按模板建立最小设计契约,再写入已确认的稳定设计决策
|
|
88
89
|
- 重写 `.helloagents/STATE.md`,其中“主线目标”写当前规划链路真正要完成的目标,不把旧任务残留为当前主线
|
|
89
90
|
|
|
90
91
|
知识库完整创建与归档按当前已加载 bootstrap 的后续规则执行。
|
|
@@ -97,6 +98,7 @@ Trigger: ~plan [description]
|
|
|
97
98
|
- 暂不执行,保留方案 → 更新 `STATE.md`;“主线目标”写当前已确认方案要解决的问题,下一步写为“方案已确认;执行需用户明确启动”
|
|
98
99
|
|
|
99
100
|
如果用户已明确表示继续执行,则视为授权成立,可直接衔接执行。
|
|
101
|
+
如果当前链路来自 `~auto`,且方案包已足够支撑实现、也未命中阻塞判定,则默认直接进入 `~build`,不再追加一次“是否开始执行”的询问。
|
|
100
102
|
|
|
101
103
|
## 方案包要求
|
|
102
104
|
|
|
@@ -8,14 +8,15 @@ Trigger: ~prd [description]
|
|
|
8
8
|
|
|
9
9
|
执行 `~prd` 时,不读取 `~plan` 的 command skill;只有当前流程明确需要时,才继续读取对应的 hello-* 技能。
|
|
10
10
|
执行 `~prd` 时,通用阶段边界按当前已加载 bootstrap 执行;本 skill 负责补充规格探索、PRD 落盘与执行衔接要求。
|
|
11
|
-
`.helloagents/` 在本 skill
|
|
11
|
+
`.helloagents/` 在本 skill 中统一按项目级存储路径理解:`STATE.md` 与 `.ralph-*.json` 保持项目本地;若 `project_store_mode=repo-shared`,知识库、`DESIGN.md` 与 `plans/` / `archive/` 按当前上下文中已注入的项目知识/方案目录解析。
|
|
12
12
|
|
|
13
13
|
## 铁律
|
|
14
14
|
- 在用户确认方案之前,禁止编写任何实现代码、创建任何文件、或执行任何实现操作。
|
|
15
15
|
- 每个维度的选项必须体现当前前沿水准。若当前已加载 bootstrap 含审美/体验规则则遵循其要求;否则至少给出具体、可执行、非泛化的视觉特征,不确定时主动搜索查阅。
|
|
16
16
|
- 用户说"跳过"某维度 → 跳过,不生成该文件。不强迫用户讨论不关心的维度。
|
|
17
17
|
- 大项目检测:涉及多个独立子系统时,先帮用户分解为子项目,每个子项目走独立的 ~prd 循环。
|
|
18
|
-
-
|
|
18
|
+
- 若当前链路来自 `~auto`,则 PRD / 任务 / 契约落地后默认继续衔接后续执行;只有真实阻塞时才停在规格阶段。
|
|
19
|
+
- 涉及 UI 时,`prd/03-ui-design.md` 负责沉淀本次产品/功能的 UI 决策;项目级稳定设计契约同步写入 `.helloagents/DESIGN.md`(按当前项目存储模式解析)
|
|
19
20
|
|
|
20
21
|
## PRD 维度清单
|
|
21
22
|
|
|
@@ -97,13 +98,13 @@ c. AI 总结该维度的决策结果,进入下一个维度
|
|
|
97
98
|
|
|
98
99
|
将讨论结果写入本地项目:
|
|
99
100
|
- 按当前已加载 bootstrap 的 `.helloagents/` 与流程状态规则,确保最小项目状态已建立;这是方案包写入的前置操作,不受 kb_create_mode 开关控制
|
|
100
|
-
-
|
|
101
|
+
- 创建 `.helloagents/plans/YYYYMMDDHHMM_{feature}/prd/`(按当前项目存储模式解析)
|
|
101
102
|
- 按 templates/plans/prd/ 的模板格式,仅写入用户未跳过的维度文件
|
|
102
103
|
- 生成 tasks.md(每个任务包含具体文件路径、预期变更、完成标准、验证方式;任务独立可验证;依赖顺序明确)
|
|
103
104
|
- 生成 decisions.md(贯穿全程的决策日志)
|
|
104
105
|
- 生成 `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`)
|
|
105
|
-
- 使用 `scripts/plan-contract.mjs write` 写 `contract.json
|
|
106
|
-
- 涉及 UI
|
|
106
|
+
- 使用 `scripts/plan-contract.mjs write` 写 `contract.json`,不要只把验证路径留在自然语言说明里
|
|
107
|
+
- 涉及 UI 的项目:生成或更新 `.helloagents/DESIGN.md`(按当前项目存储模式解析);若原文件不存在,先按模板建立最小设计契约,再同步已确认的稳定 UI 决策
|
|
107
108
|
- 重写 `.helloagents/STATE.md`,其中“主线目标”写当前 PRD 链路真正要完成的产品 / 功能目标,不延续无关旧主线
|
|
108
109
|
|
|
109
110
|
输出 PRD 完整度摘要:已覆盖 N/13 个维度,建议后续补充的维度(如有)。
|
|
@@ -116,6 +117,7 @@ c. AI 总结该维度的决策结果,进入下一个维度
|
|
|
116
117
|
- 暂不执行,保留方案 → 重写 `STATE.md`(“主线目标”保持当前 PRD 目标,下一步设为“方案已确认;执行需用户明确启动”)
|
|
117
118
|
|
|
118
119
|
如果用户已对当前 PRD 或继续执行作出明确同意,视为执行授权成立,可直接进入执行,或按需先补一轮 `~plan` 收敛实现方案。
|
|
120
|
+
如果当前链路来自 `~auto`,且 PRD 已收敛到可执行任务、也未命中阻塞判定,则默认继续进入 `~build`,必要时先补一轮轻量 `~plan`,不再额外询问一次“是否开始执行”。
|
|
119
121
|
|
|
120
122
|
### 6. 执行衔接
|
|
121
123
|
|
|
@@ -137,7 +139,7 @@ plans/YYYYMMDDHHMM_{feature}/
|
|
|
137
139
|
│ ├── 01-user-stories.md # 仅用户未跳过的维度
|
|
138
140
|
│ ├── 02-functional.md
|
|
139
141
|
│ └── ...
|
|
140
|
-
├── contract.json # 机器可消费的验证 /
|
|
142
|
+
├── contract.json # 机器可消费的验证 / 审查契约
|
|
141
143
|
├── tasks.md # 任务分解
|
|
142
144
|
└── decisions.md # 决策日志
|
|
143
145
|
```
|
|
@@ -9,27 +9,27 @@ Trigger: ~verify [scope]
|
|
|
9
9
|
## 流程
|
|
10
10
|
|
|
11
11
|
0. 先对齐当前工作流状态:
|
|
12
|
-
-
|
|
12
|
+
- 若当前上下文中已注入“当前工作流约束”或“当前建议下一命令”,先服从它
|
|
13
13
|
- 即使命令通过,也不能越过当前方案包边界:不完整方案包不能视为可信交付记录,未闭合方案包不能被整体报告为已完成
|
|
14
14
|
- 当推荐路径已进入 `~verify` / 收尾时,优先把本命令用于审查、验真和交付收尾
|
|
15
15
|
- 若当前存在活跃方案包,先读取 `requirements.md`、`plan.md`、`tasks.md`、`contract.json`,把它们当作本轮验证契约;不要只看命令结果
|
|
16
16
|
- 若 `contract.json` 声明 `advisor.required=true` 或 `ui.styleAdvisor.required=true`,则本轮还必须补齐 `.helloagents/.ralph-advisor.json`;advisor / style advisor 都是可选能力,不是默认常驻步骤
|
|
17
17
|
- 若 `contract.json` 声明 `ui.visualValidation.required=true`,则本轮还必须补齐 `.helloagents/.ralph-visual.json`;视觉验收优先用截图/浏览器工具,没有工具时才降级为结构化代码级自检
|
|
18
18
|
1. 先决定验证分流:
|
|
19
|
-
-
|
|
20
|
-
- 用户显式使用 `~review`
|
|
19
|
+
- 若当前上下文中已注入“验证分流”,先按该分流执行
|
|
20
|
+
- 用户显式使用 `~review` 时,即使本轮没有注入分流,也按审查优先起步
|
|
21
21
|
- 若没有注入分流、也不是 `~review`,默认先做全量验证;执行中一旦发现高风险链路、关键权限/配置/迁移/发布边界或明显未覆盖的风险点,立即补做 `hello-review`
|
|
22
22
|
2. 审查优先模式:
|
|
23
23
|
- 获取变更范围:无参数默认未提交变更;`staged` 代表暂存区;指定文件/目录则只审查对应范围
|
|
24
24
|
- 按 hello-* 技能查找路径读取 `hello-review` SKILL.md,执行逐文件审查
|
|
25
25
|
- 高风险链路除显式范围外,还要主动补查相关配置、迁移、权限、部署或安全边界文件,不能只盯住单个功能文件
|
|
26
|
-
- 审查结论确定后,立即调用 `scripts/review-state.mjs write` 写 `.helloagents/.ralph-review.json`;用结构化字段记录 `outcome`、`conclusion`、`findings`、`fileReferences
|
|
26
|
+
- 审查结论确定后,立即调用 `scripts/review-state.mjs write` 写 `.helloagents/.ralph-review.json`;用结构化字段记录 `outcome`、`conclusion`、`findings`、`fileReferences`,不要让后续检查脚本再从自然语言消息里猜结论
|
|
27
27
|
3. 全量验证模式或审查后继续验证:
|
|
28
28
|
- 读取 `hello-verify` SKILL.md
|
|
29
29
|
- 按其“验证命令来源”优先级检测命令
|
|
30
30
|
- 逐个运行所有检测到的命令
|
|
31
31
|
- 收集每个命令的输出和退出码
|
|
32
|
-
-
|
|
32
|
+
- 对照当前契约逐项核对:requirements 是否覆盖、tasks 中每项“完成标准”是否满足、`plan.md` 中风险与设计约束是否被验证、`contract.json` 中声明的 `verifyMode` / reviewer / tester 关注边界是否已被覆盖
|
|
33
33
|
- 若 `advisor.required=true` 或 `ui.styleAdvisor.required=true`,在进入收尾前调用 `scripts/advisor-state.mjs write` 写 `.helloagents/.ralph-advisor.json`;记录触发原因、focus、consultedSources、结论与建议,禁止只在自然语言里留一段 advisor 意见
|
|
34
34
|
- 若 `ui.visualValidation.required=true`,在进入收尾前调用 `scripts/visual-state.mjs write` 写 `.helloagents/.ralph-visual.json`;记录 `reason`、`tooling`、`screensChecked`、`statesChecked`、`status`、`summary`、`findings` 与 `recommendations`
|
|
35
35
|
4. 汇总报告:
|
|
@@ -1,16 +1,16 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ~wiki
|
|
3
|
-
description: 初始化或同步项目知识库(仅 `.helloagents
|
|
3
|
+
description: 初始化或同步项目知识库(仅 `.helloagents/`)
|
|
4
4
|
policy:
|
|
5
5
|
allow_implicit_invocation: false
|
|
6
6
|
---
|
|
7
7
|
Trigger: ~wiki
|
|
8
8
|
|
|
9
|
-
`~wiki`
|
|
9
|
+
`~wiki` 是用户显式命令,仅创建、补全或同步项目知识库。
|
|
10
10
|
|
|
11
11
|
`~wiki` 是显式知识库命令,不受 `kb_create_mode` 限制。
|
|
12
|
-
执行 `~wiki` 时,`.helloagents/` 目录结构、模板格式和 `STATE.md` 重写规则按当前已加载 bootstrap
|
|
13
|
-
`.helloagents/` 在本 skill
|
|
12
|
+
执行 `~wiki` 时,`.helloagents/` 目录结构、模板格式和 `STATE.md` 重写规则按当前已加载 bootstrap 执行;不写入项目级规则文件,也不创建项目级原生 skills 链接。
|
|
13
|
+
`.helloagents/` 在本 skill 中统一按项目级存储路径理解:`STATE.md` 保持项目本地;若 `project_store_mode=repo-shared`,`context.md`、`guidelines.md`、`verify.yaml`、`CHANGELOG.md`、`DESIGN.md`、`modules/` 改按当前上下文中已注入的项目知识目录写入。
|
|
14
14
|
|
|
15
15
|
## 流程
|
|
16
16
|
|
|
@@ -22,10 +22,8 @@ Trigger: ~wiki
|
|
|
22
22
|
.helloagents/
|
|
23
23
|
```
|
|
24
24
|
3. 明确不执行以下操作:
|
|
25
|
-
-
|
|
26
|
-
-
|
|
27
|
-
- 不创建或更新 `.gemini/GEMINI.md`
|
|
28
|
-
- 不创建项目级 `skills/helloagents` symlink
|
|
25
|
+
- 不创建或更新项目级规则文件(`AGENTS.md`、`CLAUDE.md`、`.gemini/GEMINI.md`)
|
|
26
|
+
- 不创建项目级原生 skills 链接
|
|
29
27
|
|
|
30
28
|
### 阶段 2:知识库创建或补全(条件性)
|
|
31
29
|
|
|
@@ -33,7 +31,7 @@ Trigger: ~wiki
|
|
|
33
31
|
- 有代码文件 → 执行完整知识库创建/补全(下方流程)
|
|
34
32
|
- 空项目 → 保留 `.helloagents/` 和 `STATE.md`,告知用户“项目为空,其余知识文件将在后续开发或首次编码任务中补全”
|
|
35
33
|
|
|
36
|
-
|
|
34
|
+
知识库创建/补全流程(统一写入 `.helloagents/` 对应的项目级存储路径;`project_store_mode=repo-shared` 时实际落在共享知识目录):
|
|
37
35
|
1. 按 templates/ 目录的模板格式,分析项目代码库后创建或补全:
|
|
38
36
|
- context.md — 按 templates/context.md 格式,填入项目概述、技术栈、架构、目录结构、模块链接
|
|
39
37
|
- guidelines.md — 按 templates/guidelines.md 格式,从现有代码推断编码约定
|
|
@@ -56,4 +54,4 @@ commands:
|
|
|
56
54
|
- `STATE.md` 按当前任务状态重写,不追加历史;它只记录当前知识库链路的恢复快照,不承担项目主线的唯一记忆
|
|
57
55
|
- 知识库文件缺失时补全,已存在时按模板增量更新
|
|
58
56
|
- `.gitignore` 只追加缺失行
|
|
59
|
-
-
|
|
57
|
+
- 永不写入项目级规则文件,也不创建任何项目级原生 skills 链接
|
|
@@ -32,7 +32,7 @@ description: 审查代码变更、检查 PR、review 代码质量,或用户要
|
|
|
32
32
|
- 审查结束时必须单独给出一行“审查结论:...”
|
|
33
33
|
- 若发现阻塞问题,结论中明确写出存在问题,并在正文中为每个问题附文件定位
|
|
34
34
|
- 若未发现阻塞问题,明确写“审查结论:未发现阻塞问题。”
|
|
35
|
-
-
|
|
35
|
+
- 若当前项目已激活,且本轮审查结果需要进入后续交付检查或收尾,审查结论确定后立即调用 `scripts/review-state.mjs write` 写 `.helloagents/.ralph-review.json`
|
|
36
36
|
- `.ralph-review.json` 必须使用结构化字段记录:`outcome`(`clean` / `findings`)、`conclusion`、`findings`、`fileReferences`
|
|
37
37
|
- 不要依赖“审查结论:...”这行让运行时再从自然语言里猜机器结论;这行只服务于人类阅读
|
|
38
38
|
|
|
@@ -4,13 +4,13 @@ description: 使用子代理执行任务、并行开发、分派工作时使用
|
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
子代理编排必须遵循以下规范。
|
|
7
|
-
`.helloagents/` 在本 skill
|
|
7
|
+
`.helloagents/` 在本 skill 中统一按项目级存储路径理解:`STATE.md` 和 `.ralph-*.json` 保持项目本地;若 `project_store_mode=repo-shared`,方案包、`verify.yaml` 与 `DESIGN.md` 按当前上下文中已注入的项目知识/方案目录解析。
|
|
8
8
|
|
|
9
9
|
## 编码前
|
|
10
10
|
先确定任务是否适合子代理(独立性高、边界清晰、可验证)。
|
|
11
11
|
|
|
12
12
|
## 派遣规范
|
|
13
|
-
- 每个子代理获得:tasks.md 中的对应任务 + 方案包中的相关约束(~plan: requirements.md + plan.md;~prd: prd/ 中的相关维度文件 + decisions.md)+ 验证命令;涉及 UI
|
|
13
|
+
- 每个子代理获得:tasks.md 中的对应任务 + 方案包中的相关约束(~plan: requirements.md + plan.md;~prd: prd/ 中的相关维度文件 + decisions.md)+ 验证命令;涉及 UI 时,再附 `.helloagents/DESIGN.md`(按当前项目存储模式解析)或其中相关片段
|
|
14
14
|
- 新鲜上下文:不继承主会话历史,避免上下文污染
|
|
15
15
|
- 提示开头标记 [子代理任务],让子代理跳过 bootstrap 加载
|
|
16
16
|
- 单一职责:一个子代理只做一件事
|
|
@@ -20,6 +20,7 @@ description: 使用子代理执行任务、并行开发、分派工作时使用
|
|
|
20
20
|
- 使用子代理时,主代理作为控制器跟踪进度
|
|
21
21
|
- 主代理只有在本轮最终收尾时才可使用 HelloAGENTS 外层输出格式。
|
|
22
22
|
- 团队协作中的进度与状态汇报都属于中间输出,不得包装 HelloAGENTS 外层输出格式。
|
|
23
|
+
- 子代理不得调用 `scripts/turn-state.mjs write` 代替主代理写完成态或等待态;turn-state 只由主代理在本轮最终收尾前写入
|
|
23
24
|
- 子代理完成后执行双阶段审查:
|
|
24
25
|
1. 需求符合性审查:变更是否符合方案包需求和 tasks.md 的要求?有无多做或少做?
|
|
25
26
|
2. 代码质量审查:运行验证命令,审查代码质量
|