@siming-org/cli 0.8.0 → 0.8.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/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@siming-org/cli",
|
|
3
|
-
"version": "0.8.
|
|
3
|
+
"version": "0.8.1",
|
|
4
4
|
"license": "MIT",
|
|
5
5
|
"author": "Wuchao",
|
|
6
6
|
"engines": {
|
|
@@ -27,8 +27,8 @@
|
|
|
27
27
|
"picocolors": "^1.1.1",
|
|
28
28
|
"yaml": "^2.6.0",
|
|
29
29
|
"zod": "^4.4.3",
|
|
30
|
-
"@siming-org/core": "0.8.
|
|
31
|
-
"@siming-org/server": "0.8.
|
|
30
|
+
"@siming-org/core": "0.8.1",
|
|
31
|
+
"@siming-org/server": "0.8.1"
|
|
32
32
|
},
|
|
33
33
|
"devDependencies": {
|
|
34
34
|
"tsup": "^8.3.5",
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"exportFormatVersion": "1.0",
|
|
3
|
-
"exportedAt": "2026-09-
|
|
3
|
+
"exportedAt": "2026-09-23T10:30:51.111Z",
|
|
4
4
|
"warnings": [],
|
|
5
5
|
"template": {
|
|
6
6
|
"name": "full_workflow",
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
"label": "PRD 设计",
|
|
12
12
|
"phase": "entry",
|
|
13
13
|
"track": "all",
|
|
14
|
-
"prompt": "# PRD 设计\n\n## 节点职责\n\n
|
|
14
|
+
"prompt": "# PRD 设计\n\n## 节点职责\n\n把模糊需求整理成不依赖当前对话、可直接供技术设计、实现和验收使用的产品需求文档，并通过独立评审建立后续工作的产品基线；用户确认由流程暂停点承载。\n\n本节点只定义产品的 What 和 Why：解决什么问题、服务哪些用户、用户可见行为是什么，以及依据什么结果验收；不决定技术实现方式。\n\n## 依赖信息\n\n先检查当前 Siming 任务上下文中的需求概述、验收标准、非目标、前序节点记录，以及项目产品资料和项目约束；已有信息直接复用，缺失时再加载或确认。\n\n按名称加载 `workflow-discipline` Skill，并调用 `prd-reviewer` Agent 完成独立评审。评审时只提供 PRD、客观产品约束和必要参照，不提供主会话的设计结论、预期评审结果或“用户已确认”等预设信息。\n\n## 正向执行流程\n\n1. **明确问题与价值**：识别当前问题、受影响用户、期望改善及不处理的后果，避免把用户提出的方案直接当成问题本身。\n2. **还原用户场景**：说明谁在什么条件下执行什么操作、期望得到什么结果，并覆盖关键异常和边界场景。\n3. **提炼产品规则**：从场景中整理功能行为、状态变化、权限差异、数据约束和失败反馈，只保留用户或业务可感知的规则。\n4. **控制交付范围**：区分本次必须完成、明确不做和仍待决定的内容，避免把后续设想混入当前交付。\n5. **建立验收闭环**：为每项核心行为定义可观察、可判定的结果，且不依赖内部实现方式。\n6. **处理信息缺口**：只有缺口会改变需求范围、用户可见行为、业务规则、异常处理或验收结论时才询问用户，每次只问一个需要决定的问题。非阻塞信息采用明确假设继续，并记录假设及影响。\n7. **编写并保存 PRD**：根据任务规模组织内容，不要求固定篇幅或章节数量。项目有文档目录时按项目声明保存全文；登记任务产物时必须携带 PRD 全文（`file` 或 `content`），纯路径引用仅用于超过 200k 字符快照上限的文件，且须说明理由。项目要求版本控制时，按项目约定保存可追溯版本。\n8. **执行独立评审**：调用 `prd-reviewer`：\n - `BLOCKED`：补齐评审输入后重新评审；\n - 存在 `BLOCKER`：修订 PRD；无法自行收敛时，向用户呈现分歧后再处理；\n - `WARNING` 或 `SUGGESTION`：逐条决定修订或保留，并记录理由；\n - 没有 `BLOCKER` 且总体为 `PASS` 后，进入呈现与推进。\n9. **呈现审批材料并推进**：呈现需求范围、关键场景与规则、验收标准、非目标、假设、开放问题和评审结论（作为暂停点审批材料）；完成产出检查后推进，进入暂停点等待用户审批——审批通过即 PRD 基线确认，确认原文以审批记录留痕。\n\n## 产出检查\n\n推进前确认：\n\n1. PRD 全文可读取、已保存，登记值携带全文（超限时为路径引用且已说明理由）。\n2. 每项核心功能都能追溯到明确的问题、价值或用户场景。\n3. 每项关键场景都有对应的产品行为、业务规则和可观察验收结果。\n4. 范围、异常边界、非目标、假设和开放问题之间没有矛盾，也没有阻塞后续设计的隐藏歧义。\n5. 文档不依赖当前聊天背景，不包含类、文件、接口路径、数据库结构、框架选型、部署方式或实现步骤。\n6. 独立评审总体为 `PASS`，所有 Finding 已修订或记录保留理由。\n7. 审批材料已完整呈现，可支撑暂停点审批。\n\n## 任务差异处理\n\n根据需求规模调整文档深度；简单需求可以简短，但不能省略影响实现和验收的关键信息。\n\n界面需求应描述用户可见状态、交互反馈、可访问性和适配要求，但不指定组件、样式框架或前端实现方式。\n\n某项内容因任务性质确实不适用时，写明不适用对象和理由，不使用空章节或占位文本代替分析。\n\n任务输入不足、评审处于 `BLOCKED`、仍有未解决的 `BLOCKER` 时，保留在本节点继续处理，不得推进。\n\n## 节点记录与推进\n\n记录以下信息：\n\n- PRD 产物或全文及其版本引用；\n- 需求结论摘要；\n- 完成检查结果；\n- 独立评审的总体结论、轮次和 Findings 处理结果；\n- 关键产品决定、假设和开放问题；\n- 不适用项及其理由；\n- 呈现给用户的审批材料索引（确认原文由暂停点审批记录承载，须逐字引用用户确认表态、不得转述失真；不双写）。\n\n只有全部产出检查满足后，才以 PRD 完成摘要推进流程。",
|
|
15
15
|
"skills": [
|
|
16
16
|
"workflow-discipline"
|
|
17
17
|
],
|
|
@@ -20,8 +20,8 @@
|
|
|
20
20
|
],
|
|
21
21
|
"sourcePreset": {
|
|
22
22
|
"code": "prd-design",
|
|
23
|
-
"version": "1.
|
|
24
|
-
"contentHash": "
|
|
23
|
+
"version": "1.6.0",
|
|
24
|
+
"contentHash": "c1eb39b97f768594",
|
|
25
25
|
"agents": [
|
|
26
26
|
"prd-reviewer"
|
|
27
27
|
]
|
|
@@ -49,7 +49,7 @@
|
|
|
49
49
|
"label": "技术方案",
|
|
50
50
|
"phase": "entry",
|
|
51
51
|
"track": "all",
|
|
52
|
-
"prompt": "# 技术方案\n\n## 节点职责\n\n
|
|
52
|
+
"prompt": "# 技术方案\n\n## 节点职责\n\n将已确认的产品需求转化为可直接指导实现和验证的技术方案，并通过需求对齐审查、架构评审建立实现基线；用户确认由流程暂停点承载。本节点只产出设计，不编写生产代码或测试代码。\n\n## 依赖信息\n\n检查当前任务上下文、需求与验收标准、非目标、PRD、前序节点产物、项目提示词和相关架构资料；已有信息直接复用，缺失时再加载。\n\n按名称加载：\n\n- `tech-design` Skill：技术方案设计方法及文档模板；\n- `workflow-discipline` Skill：执行、审查和暂停点纪律。\n\n方案完成后，依次调用：\n\n1. `alignment-reviewer` Agent：检查方案与需求的对齐关系；\n2. `arch-reviewer` Agent：检查方案的架构质量。\n\n## 正向执行流程\n\n1. 确认需求范围和后端、前端或混合轨道，并读取相关项目约束与现有架构。\n2. 使用 `tech-design` Skill 设计方案，并读取其 `references/template.md` 生成技术方案文档；方案默认包含架构图与核心功能流程图——用可渲染的图形语法表达（项目未约定时用 Mermaid），不使用文字罗列代替，且图中模块、步骤、分支在正文均有对应说明。\n3. 项目有文档目录时按项目声明保存方案文件；登记任务产物时必须携带方案全文（`record-artifact-add` 用 `file` 或 `content`），纯路径引用仅用于超过 200k 字符快照上限的文件，且须说明理由。\n4. 调用 `alignment-reviewer`。存在需求偏差时先修订方案，直至总体 `PASS`。\n5. 调用 `arch-reviewer`。处理 BLOCKER 和 HIGH；MEDIUM、LOW 逐项修订或记录保留理由，直至总体 `PASS`。\n6. 向用户呈现已保存的方案文档及其可读位置，以及方案摘要、关键取舍、两道审查结论和即将进入的实现轨道——用户在审批前必须能打开完整方案。\n7. 按项目分支规则创建任务分支；完成产出检查后推进，进入暂停点等待用户审批——审批通过即进入实现阶段，确认原文以审批记录留痕。\n\n## 产出检查\n\n推进前确认：\n\n- 技术方案全文可读取、已保存，登记值携带全文（超限时为路径引用且已说明理由）；\n- 文档符合 `tech-design` 模板使用规则，最低必备信息完整；\n- 方案默认包含架构图与核心功能流程图，以可渲染的图形呈现且与正文一致；确实不适用时已在“不适用项”写明具体对象和理由；\n- 需求、验收标准和非目标均有对应设计；\n- 按需设计已完成，或在“不适用项”中写明具体对象和理由；\n- `alignment-reviewer` 总体为 `PASS`；\n- `arch-reviewer` 总体为 `PASS`，其余 Finding 已处理或记录保留理由；\n- 审批材料（方案文档、摘要、关键取舍、审查结论、实现轨道）已完整呈现，可支撑暂停点审批；\n- 呈现给用户的方案文档可独立打开阅读，且与当前方案版本一致。\n\n## 任务差异处理\n\n没有独立 PRD 时，以任务需求、验收标准和非目标作为对齐基线。\n\n方案出现需要用户决定的产品方向、破坏性变更、新依赖或重大架构取舍时，先呈现选项、影响和建议。\n\n任一道审查处于 `BLOCKED` 或 `FAIL`，或项目约束与方案无法同时满足时，保留在本节点继续处理。\n\n## 节点记录与推进\n\n记录技术方案产物、方案摘要、关键决策与取舍、完成检查、两道审查的结论与轮次、Finding 处理结果、不适用项及理由，以及呈现给用户的审批材料索引（确认原文由暂停点审批记录承载，须逐字引用用户确认表态、不得转述失真；不双写）。\n\n全部产出检查满足后再推进；创建任务分支后，记录任务与分支的关联。",
|
|
53
53
|
"skills": [
|
|
54
54
|
"tech-design",
|
|
55
55
|
"workflow-discipline"
|
|
@@ -60,8 +60,8 @@
|
|
|
60
60
|
],
|
|
61
61
|
"sourcePreset": {
|
|
62
62
|
"code": "design-tech",
|
|
63
|
-
"version": "1.
|
|
64
|
-
"contentHash": "
|
|
63
|
+
"version": "1.6.0",
|
|
64
|
+
"contentHash": "5d62a31f3b2764f0",
|
|
65
65
|
"agents": [
|
|
66
66
|
"alignment-reviewer",
|
|
67
67
|
"arch-reviewer"
|
|
@@ -73,7 +73,7 @@
|
|
|
73
73
|
"label": "交互设计",
|
|
74
74
|
"phase": "entry",
|
|
75
75
|
"track": "ui",
|
|
76
|
-
"prompt": "# 交互设计\n\n## 节点职责\n\n
|
|
76
|
+
"prompt": "# 交互设计\n\n## 节点职责\n\n把已确认的需求与技术方案中用户可见的交互意图，翻译为不依赖具体实现、可逐项核对的交互契约——界面结构与路径总览、状态矩阵、交互契约规则、键盘与焦点、反馈与播报、边界与内容策略、文案逐字稿、令牌绑定、自检清单——经独立对齐核验后，作为编码节点的显式输入依赖与视觉验证的验收依据；用户确认由流程暂停点承载。本节点不编写生产代码、不做视觉审美裁定、不做技术选型、不产出可运行原型。\n\n## 依赖信息\n\n先检查当前任务上下文：PRD 或需求描述、验收标准、非目标、技术方案（含形态与载体决策）、前序节点产物，以及项目和所属模块的提示词。加载 `workflow-discipline`；契约完成后调用 `alignment-reviewer` 核验契约与需求的回溯关系。\n\n形态层映射（Web/桌面/游戏引擎等）以技术方案的载体决策为准；技术方案未明确载体时先向用户澄清，不猜测。\n\n## 正向执行流程\n\n1. 从需求与技术方案提取全部用户可见交互面：每个数据驱动视图、每个可触发元素、每条用户路径。任务无任何用户可见交互面时，判定本节点不适用，在节点记录写明判定与理由后推进。\n2. 逐项产出契约必备项，每项均可逐字核对、不依赖对话上下文：\n - 界面结构与路径总览：布局用文本线框、状态流转用状态图、用户路径用流程图，以可渲染的图形语法内嵌契约文档（项目未约定时用 Mermaid），作为人工审阅的第一入口；\n - 状态矩阵：每个数据驱动视图的 loading / empty / error / disabled 呈现定义与文案；\n - 交互契约规则：触发元素、事件、效果元素、效果类型、效果位置、可逆性、目标状态；\n - 键盘与焦点契约：Tab 顺序、初始焦点、Esc/Enter 语义、disabled 元素可聚焦策略；\n - 反馈与播报机制：每个状态变更选用哪种机制（focus / role=status / live region 等）及理由；\n - 边界与内容策略：最小支持宽度、320px 级重排、超长文本截断、大数据分页/滚动、空值文案；\n - 文案逐字稿：含错误文案与空态文案，逐字给出，不留占位符；\n - 令牌绑定：颜色、间距、圆角、字阶引用设计令牌，禁止裸值；\n - 自检清单：实现者可逐项勾选的验收点清单，覆盖以上全部条款。\n3. 每条交互规则标注回溯来源（需求哪一条 / 技术方案哪项决策）；无法回溯的条目视为新增需求，上升用户裁定后才可写入契约。\n4. 将契约全文保存为项目文档并登记任务产物（携带全文；超限时路径引用须说明理由），向用户呈现契约要点、自检清单核对结果与文档可读位置（作为暂停点审批材料）。\n5. 随后按通用层与形态层组织契约：通用层条款形态无关；形态层条款按技术方案载体映射（HTML/CSS、UXML/USS、.tscn/Theme 等），映射关系写入契约。\n\n## 产出与检查\n\n推进前确认：\n\n- 全部必备产出（含界面结构与路径总览）齐全，不适用的单项已写明具体对象和理由；\n- 每条交互规则可回溯到需求或技术方案，无发明需求；\n- 文案全部逐字给出，令牌引用无裸值；\n- 自检清单覆盖全部契约条款；\n- `alignment-reviewer` 对回溯关系的核验为 PASS，Findings 已处理或记录保留理由；\n- 审批材料（契约要点、自检清单核对结果、文档位置）已完整呈现，可支撑暂停点审批；\n- 契约文档已保存登记，呈现给用户的版本与确认版本一致。\n\n## 任务差异处理\n\n无用户可见交互面的任务：判定不适用并记录理由后推进，下游编码节点按「无契约」路径实现。信息不足以产出某项契约时，保留在本节点补齐或向用户澄清，不静默降级；确属可选项的增强（视觉基线、设计文件同步、动效规格）按需说明取舍，不默认纳入。\n\n可运行草图：默认不产出。用户点名要求审查辅助时，按当前版本契约生成静态草图到工作区 `temp/` 供用户在浏览器查看；草图是契约的派生视图而非第二设计来源——契约发生任何修订即作废重生成并重新呈现，草图页首声明「非契约正文，与契约不一致时以契约文档为准」，草图暴露的契约缺口只能回写契约修正，不在草图上直接改。草图不写入契约文档、不登记为任务产物，节点推进后即完成使命。\n\n## 节点记录与推进\n\n将契约文档产物与引用、必备产出核对结果、不适用判定及理由（如有）、草图辅助审查事实（如有，含生成路径与派生版本对应关系）、`alignment-reviewer` 结论与轮次、呈现给用户的审批材料索引写入当前节点记录（确认原文由暂停点审批记录承载，须逐字引用用户确认表态、不得转述失真；不双写），完成产出检查后推进下一节点。",
|
|
77
77
|
"skills": [
|
|
78
78
|
"workflow-discipline"
|
|
79
79
|
],
|
|
@@ -82,8 +82,8 @@
|
|
|
82
82
|
],
|
|
83
83
|
"sourcePreset": {
|
|
84
84
|
"code": "interaction-design",
|
|
85
|
-
"version": "1.
|
|
86
|
-
"contentHash": "
|
|
85
|
+
"version": "1.1.0",
|
|
86
|
+
"contentHash": "2e3855953b0a1bbd",
|
|
87
87
|
"agents": [
|
|
88
88
|
"alignment-reviewer"
|
|
89
89
|
]
|
|
@@ -138,7 +138,7 @@
|
|
|
138
138
|
"label": "视觉验证",
|
|
139
139
|
"phase": "track",
|
|
140
140
|
"track": "ui",
|
|
141
|
-
"prompt": "# 视觉验证\n\n## 节点职责\n\n
|
|
141
|
+
"prompt": "# 视觉验证\n\n## 节点职责\n\n组织界面视觉验证的完整闭环：由独立 `visual-reviewer` 在单一 subagent 会话内自主完成「驱动界面 → 截图取证 → 分析判定」；本节点执行者（主会话）负责环境准备、锁定评估范围、消费报告与修复代码，不操作浏览器采证。本节点只建立**呈现断言**（页面是否按需求呈现：布局、还原度、色系、文案呈现、代表性视口观感、加载/空/错误等状态的视觉呈现）；功能结果、请求结果、字段语义、状态推导与持久化结果等**行为语义断言归端到端验证**，不在本节点建立。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、技术方案、前端实现记录，以及项目和所属模块的提示词。存在交互契约产物时，读取契约并将其自检清单与验收点作为呈现断言的锚点底座；无契约时以验收标准为底座。加载 `workflow-discipline`，委派独立 `visual-reviewer` 执行视觉验证。\n\n根据需求整理待验证页面与目标视觉状态。缺少运行方式、访问地址、认证或数据准备信息时，先从项目脚本、配置和现有环境中查找；仍无法运行当前实现时，说明缺失信息并暂停。\n\n## 执行流程\n\n1. 环境准备（主会话，不做浏览器操作）：按项目声明构建并启动当前实现及其依赖服务，确认页面对应本次代码，以命令行探活（curl 级）确认运行地址可访问；完成验证所需数据前置（种子数据、测试账号等）；记录运行地址、认证方式与数据前置说明。\n2. 产出场景清单：每条为“场景 × 呈现断言 × 锚点”三要素，锚点为交互契约条款（有契约时）或验收标准条款（无契约时）。**无锚点的呈现断言不得进入清单**；确有需求依据而契约缺条款时，登记契约缺口交回，不自行补写需求；既无锚点又无需求依据的呈现断言删除并记录原因。\n3. 委派 `visual-reviewer`：提供运行地址、认证方式（如有）、数据前置说明、场景清单、需求与设计规范、交互契约（如有）、证据落盘目录（工作区 temp/）；不提供实现者结论或预期缺陷。采证与分析策略由 `visual-reviewer` 自行决策，主会话不预备截图。\n4. 接收报告：逐条核对 Finding 与证据引用，证据文件留存 temp/ 供追溯；报告中标注的行为异常观察项按缺陷记录并交回处理，不在本节点沉淀为行为断言。\n5. 修复循环：呈现缺陷以及 BLOCKER、HIGH Findings 由主会话修复代码（不经 `visual-reviewer` 之手），受影响场景重新委派 `visual-reviewer` 重新驱动、重新采证、重新评审，直至视觉评审 PASS。MEDIUM、LOW 逐项处理或记录保留理由。\n6. 同一场景连续 2 轮评审 FAIL 即停止重跑，人工检查页面结构、运行轨迹与报告证据定位根因，禁止继续盲改重跑。\n7. 将本节点观察到的、应由端到端覆盖而设计未纳入的行为场景，通过节点记录交接给端到端设计/开发节点；该交接走节点记录，不进问题池。\n8. 清理本次创建的临时数据和运行资源，不删除非本次创建的数据。\n\n## 产出与检查\n\n推进前确认：\n\n- 场景清单每条含“场景 × 呈现断言 × 锚点”三要素，无锚点断言已按规则处置；\n- 运行地址探活通过、数据前置完成，页面已确认对应当前实现；\n- `visual-reviewer` 最终结论为 PASS，所有 Findings 均已处理或说明，行为异常观察项已交回；\n- 每条锚点在报告中有证据引用且证据文件存在于 temp/；\n- 主会话全程未操作浏览器采证；\n- 未在本节点建立行为语义断言，越界观察已记录并归回对应节点；\n- 同一场景未连续超过 2 轮盲改重跑，触发停手时已人工定位根因并记录结论；\n- 行为场景交接与临时数据、运行资源清理已完成。\n\n## 任务差异处理\n\n根据需求和页面能力选择目标状态与视口，不套用固定 CRUD 或截图数量。某项不适用时说明理由，不得静默跳过。运行地址无法就绪或 `visual-reviewer` 多轮（≥3）仍 FAIL 时暂停上升用户；修复需要改变已确认需求、设计方向、公开契约或引入新依赖时，说明影响并暂停；验证与修订轮次按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将场景清单、运行地址形态与数据前置、委派轮次、每轮结论与 Finding 处置、证据目录索引、越界观察与行为场景交接、未适用项及理由写入当前节点记录。完成上述检查后推进下一节点。",
|
|
142
142
|
"skills": [
|
|
143
143
|
"workflow-discipline"
|
|
144
144
|
],
|
|
@@ -147,8 +147,8 @@
|
|
|
147
147
|
],
|
|
148
148
|
"sourcePreset": {
|
|
149
149
|
"code": "verify-visual",
|
|
150
|
-
"version": "1.
|
|
151
|
-
"contentHash": "
|
|
150
|
+
"version": "1.6.0",
|
|
151
|
+
"contentHash": "2fce493ca1bebbf8",
|
|
152
152
|
"agents": [
|
|
153
153
|
"visual-reviewer"
|
|
154
154
|
]
|
|
@@ -317,15 +317,15 @@
|
|
|
317
317
|
"label": "发布验收",
|
|
318
318
|
"phase": "exit",
|
|
319
319
|
"track": "all",
|
|
320
|
-
"prompt": "# 发布验收\n\n## 节点职责\n\n
|
|
320
|
+
"prompt": "# 发布验收\n\n## 节点职责\n\n核对最终集成验证证据与当前版本是否一致，向用户呈现可独立理解的验收摘要，并按本节点在流程中的位置承载确认与代码归档：存在后继审批边时，用户确认由流转边暂停点承载，本节点不重复确认；本节点为任务终点时，节点内确认是任务收尾唯一授权门。本节点不重复执行测试、代码评审或回归分析。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、非目标、已激活节点的完成记录、`test-integrate` 的测试范围与结果、日志以及已验证版本标识，并读取项目分支与归档策略。加载 `workflow-discipline`。\n\n缺少集成验证证据、版本标识或前序完成记录时，先从任务上下文补齐；证据仍不完整或无法对应当前版本时停止验收，不推断通过。\n\n## 执行流程\n\n1. 确认所有已激活的前序节点均已完成，不写死某一模板路径下的节点清单。\n2. 比较当前生产代码与 `test-integrate` 绑定的已验证版本。存在新的生产代码变化时，退回集成验证重新判断范围并回归；纯文档或记录变化说明为何不影响证据。\n3. 逐条核对验收标准对应的实现位置和前序验证证据，并确认非目标未被误实现、范围变化已说明、所有 reviewer 的阻塞问题已解决。\n4. 汇总集成测试范围与统计、未授权跳过、实现与验收标准对应关系、范围变化、已知问题和风险，形成简洁且不依赖任务内部术语的验收摘要。\n5. 判定本节点位置：读取任务上下文中的任务结构（DAG 节点集与各节点状态）——本节点是任务最后一个节点（如快速流程形态，已完成数加一等于节点总数）即为终态形态；存在后继节点（如架构归档节点）即为非终态形态。advance 响应的 nextNode 资料包可作交叉印证。两种形态的确认与归档时序不同，按后续步骤分支执行，判定结果写入节点记录。\n6. **终态形态（本节点为任务终点，无后继审批边）**：向用户呈现验收摘要并在节点内取得明确决定。只有明确的通过、确认归档或等价肯定表达构成确认；提问、条件句、部分认同、沉默或模糊表态不构成确认。确认后逐字记录确认原文，并按项目声明完成提交、合并、推送或其他代码归档动作。无项目策略时采用保留历史且可回退的常规方式，并记录采用的默认。\n7. **非终态形态（存在后继审批边）**：向用户呈现验收摘要（作为暂停点审批材料）；推进前在节点记录写入显式「归档待办」条目（归档动作清单：目标分支、合并方式、推送范围）；然后推进进入暂停点等待用户审批——审批通过即验收确认，确认原文以审批记录留痕（须逐字引用用户确认表态，不得转述失真），本节点不重复确认。审批通过后、开始下一节点工作前，先完成归档待办中的代码归档动作（提交/合并/推送），完成后回写归档结果闭环该待办；归档待办在归档完成前不得闭环。\n8. 归档过程中遇到冲突或失败时先检查实际版本控制状态并自主诊断；无法可靠解决时说明当前状态和卡点，不猜测操作结果。\n\n## 产出与检查\n\n推进前确认：\n\n- 所有已激活前序节点已完成；\n- 集成验证证据完整，所有适用测试通过，失败为 0，未授权跳过为 0；\n- 当前生产代码与已验证版本一致；\n- 每条验收标准都有实现和验证证据，非目标、范围变化与已知问题已说明；\n- 没有未解决的 BLOCKER、HIGH 或其他流程定义的阻塞问题；\n- 终态形态：用户已明确确认，确认原文已逐字记录，代码已按项目策略归档；\n- 非终态形态：验收摘要已呈现，归档待办已写入且动作清单明确（归档动作待审批通过后执行，不在本节点提前归档）；\n- 最终提交、分支和远程状态可追溯。\n\n## 任务差异处理\n\n任务没有代码或项目没有分支归档流程时，执行适用的验收确认并说明不适用项。用户要求附条件通过或接受具体风险时，终态形态在节点内记录条件、风险和确认原文；非终态形态该表态在暂停点审批中给出，审批记录即留痕。未被明确接受的阻塞问题不得归档。证据过期、验收标准缺失或代码归档失败时，按实际问题返回相应节点处理，不在本节点重新执行其职责。\n\n## 节点记录与推进\n\n推进前将验收摘要、证据时效、验收标准对照、范围变化、已知问题和位置判定结果写入当前节点记录；非终态形态同时写入归档待办，并在归档完成前保持其未闭环。终态形态在用户确认后追加确认原文与归档结果；非终态形态在暂停点审批通过并完成归档后，追加审批引用、归档策略与结果、最终提交和远程状态，闭环归档待办。完成推进前检查后推进下一节点；批后追加动作发生在推进之后，不阻塞推进。",
|
|
321
321
|
"skills": [
|
|
322
322
|
"workflow-discipline"
|
|
323
323
|
],
|
|
324
324
|
"agents": [],
|
|
325
325
|
"sourcePreset": {
|
|
326
326
|
"code": "release-accept",
|
|
327
|
-
"version": "1.
|
|
328
|
-
"contentHash": "
|
|
327
|
+
"version": "1.4.0",
|
|
328
|
+
"contentHash": "d9ef06ee6f469ce2",
|
|
329
329
|
"agents": []
|
|
330
330
|
}
|
|
331
331
|
},
|
|
@@ -334,7 +334,7 @@
|
|
|
334
334
|
"label": "架构信息归档",
|
|
335
335
|
"phase": "exit",
|
|
336
336
|
"track": "all",
|
|
337
|
-
"prompt": "# 架构信息归档\n\n## 节点职责\n\n从任务决策中筛选对未来设计持续有帮助的项目重大信息，形成架构信息修改计划，经独立 `arch-info-reviewer` 评审和用户明确确认后写入项目架构文档。没有合格条目是正常结果，本节点完成后任务正式收敛。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、关键决策、技术方案、各节点记录、架构候选素材和发布验收结果，并读取项目及架构文档目录的提示词、记录标准、索引和相关现有条目。加载 `workflow-discipline`，调用独立 `arch-info-reviewer` 评审修改计划。\n\n项目已有架构文档体系时遵循其分类、命名、索引和写入规则。没有体系时先判断是否确有合格条目，不为“无新增”创建空目录或空文档。\n\n## 执行流程\n\n1. 汇总任务中的候选决策，逐条判断它是否会约束未来多个设计或实现，是否属于项目特有的重要业务规则、模块边界、技术选型、兼容策略或跨任务约束。\n2. 排除常规功能演进、局部实现、缺陷修复过程、工作流水和通用工程常识；说明不收录理由及更合适的载体，没有其他载体时保留在任务记录。\n3. 检索架构索引和相关正文，判断候选是新增主题、现有主题演进、替代或退役，避免创建重复或冲突条目。\n4. 形成修改计划：建议项写明主题、决策、未来约束、适用范围、目标文档及新增或演进方式；不收录项写明门槛结论。允许建议项为零。\n5. 将项目记录标准、现有相关文档、客观决策素材和修改计划交给 `arch-info-reviewer`，不提供撰写者结论或预期结果。修复 BLOCKER、HIGH Findings 后重新评审，直至获得 PASS；MEDIUM、LOW 逐项处理或记录保留理由。\n6. 向用户同时呈现修改计划和独立评审结论。只有明确批准、调整后批准、放弃或确认无新增构成决定；逐字记录用户原文。\n7. 仅写入用户批准的条目：按项目组织更新正文和索引，同主题优先演进；无批准条目时不创建或修改架构文档。\n8. 核对批准条目与实际写入、正文与索引、演进与替代关系。有文档变化时按项目策略提交并推送；无变化时记录跳过。\n\n## 产出与检查\n\n推进前确认：\n\n- 任务决策和候选素材已完整读取；\n- 所有候选均经过记录门槛判断，修改计划包含建议项和不收录理由；\n- 相关现有条目已检索，新增、演进、替代和退役关系明确；\n- `arch-info-reviewer` 最终结论为 PASS，所有 Findings 均已处理或说明；\n- 修改计划和评审结论已呈现用户，确认原文已逐字记录；\n- 仅有用户批准的条目被写入，正文与索引一致；\n- 无新增时未创建空文档，有变化时提交与远程状态可追溯；\n- 当前节点记录完整，任务可以正式收敛。\n\n## 任务差异处理\n\n项目没有架构体系但有获批的重大决策时，优先使用项目声明的文档根建立最小结构；无文档根声明时使用 `docs/architecture/`，只创建承载获批内容所需的文件。用户未批准修改计划时保持暂停，不提前写入。候选全部不达门槛时，呈现“无新增”及主要理由，经用户确认后正常完成。\n\n## 节点记录与推进\n\n将架构归档结论、候选过滤、修改计划、独立评审结论、用户确认原文、写入或不收录决定、架构文档与索引引用、提交和远程状态写入当前节点记录。完成上述检查后推进终态，使任务完成；在任务完成前不开始其他任务。",
|
|
337
|
+
"prompt": "# 架构信息归档\n\n## 节点职责\n\n从任务决策中筛选对未来设计持续有帮助的项目重大信息，形成架构信息修改计划，经独立 `arch-info-reviewer` 评审和用户明确确认后写入项目架构文档。没有合格条目是正常结果，本节点完成后任务正式收敛。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、关键决策、技术方案、各节点记录、架构候选素材和发布验收结果，并读取项目及架构文档目录的提示词、记录标准、索引和相关现有条目。加载 `workflow-discipline`，调用独立 `arch-info-reviewer` 评审修改计划。\n\n项目已有架构文档体系时遵循其分类、命名、索引和写入规则。没有体系时先判断是否确有合格条目，不为“无新增”创建空目录或空文档。\n\n开工自检：检查前序节点记录中存在未闭环的归档待办（如发布验收节点审批通过后尚未完成的代码归档）时，先完成该归档并回写闭环，再开始本节点工作。\n\n## 执行流程\n\n1. 汇总任务中的候选决策，逐条判断它是否会约束未来多个设计或实现，是否属于项目特有的重要业务规则、模块边界、技术选型、兼容策略或跨任务约束。\n2. 排除常规功能演进、局部实现、缺陷修复过程、工作流水和通用工程常识；说明不收录理由及更合适的载体，没有其他载体时保留在任务记录。\n3. 检索架构索引和相关正文，判断候选是新增主题、现有主题演进、替代或退役，避免创建重复或冲突条目。\n4. 形成修改计划：建议项写明主题、决策、未来约束、适用范围、目标文档及新增或演进方式；不收录项写明门槛结论。允许建议项为零。\n5. 将项目记录标准、现有相关文档、客观决策素材和修改计划交给 `arch-info-reviewer`，不提供撰写者结论或预期结果。修复 BLOCKER、HIGH Findings 后重新评审，直至获得 PASS；MEDIUM、LOW 逐项处理或记录保留理由。\n6. 向用户同时呈现修改计划和独立评审结论。只有明确批准、调整后批准、放弃或确认无新增构成决定；逐字记录用户原文。\n7. 仅写入用户批准的条目：按项目组织更新正文和索引，同主题优先演进；无批准条目时不创建或修改架构文档。\n8. 核对批准条目与实际写入、正文与索引、演进与替代关系。有文档变化时按项目策略提交并推送；无变化时记录跳过。\n\n## 产出与检查\n\n推进前确认：\n\n- 任务决策和候选素材已完整读取；\n- 所有候选均经过记录门槛判断，修改计划包含建议项和不收录理由；\n- 相关现有条目已检索，新增、演进、替代和退役关系明确；\n- `arch-info-reviewer` 最终结论为 PASS，所有 Findings 均已处理或说明；\n- 修改计划和评审结论已呈现用户，确认原文已逐字记录；\n- 仅有用户批准的条目被写入，正文与索引一致；\n- 无新增时未创建空文档，有变化时提交与远程状态可追溯；\n- 当前节点记录完整，任务可以正式收敛。\n\n## 任务差异处理\n\n项目没有架构体系但有获批的重大决策时，优先使用项目声明的文档根建立最小结构；无文档根声明时使用 `docs/architecture/`，只创建承载获批内容所需的文件。用户未批准修改计划时保持暂停，不提前写入。候选全部不达门槛时，呈现“无新增”及主要理由，经用户确认后正常完成。\n\n## 节点记录与推进\n\n将架构归档结论、候选过滤、修改计划、独立评审结论、用户确认原文、写入或不收录决定、架构文档与索引引用、提交和远程状态写入当前节点记录。完成上述检查后推进终态，使任务完成；在任务完成前不开始其他任务。",
|
|
338
338
|
"skills": [
|
|
339
339
|
"workflow-discipline"
|
|
340
340
|
],
|
|
@@ -343,8 +343,8 @@
|
|
|
343
343
|
],
|
|
344
344
|
"sourcePreset": {
|
|
345
345
|
"code": "archive-architecture",
|
|
346
|
-
"version": "1.
|
|
347
|
-
"contentHash": "
|
|
346
|
+
"version": "1.4.0",
|
|
347
|
+
"contentHash": "a585464156b6179c",
|
|
348
348
|
"agents": [
|
|
349
349
|
"arch-info-reviewer"
|
|
350
350
|
]
|
|
@@ -523,7 +523,7 @@
|
|
|
523
523
|
}
|
|
524
524
|
},
|
|
525
525
|
"isDefault": false,
|
|
526
|
-
"version": "3.6.
|
|
526
|
+
"version": "3.6.3"
|
|
527
527
|
},
|
|
528
528
|
"dependencies": {
|
|
529
529
|
"skills": [
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"exportFormatVersion": "1.0",
|
|
3
|
-
"exportedAt": "2026-09-
|
|
3
|
+
"exportedAt": "2026-09-23T10:30:51.118Z",
|
|
4
4
|
"warnings": [],
|
|
5
5
|
"template": {
|
|
6
6
|
"name": "quick_workflow",
|
|
@@ -28,7 +28,7 @@
|
|
|
28
28
|
"label": "快速设计",
|
|
29
29
|
"phase": "entry",
|
|
30
30
|
"track": "all",
|
|
31
|
-
"prompt": "# 快速设计\n\n## 节点职责\n\n将用户描述的小型改动直接整理为最小技术方案——改动点、影响面、验证方式——经一次独立 AI
|
|
31
|
+
"prompt": "# 快速设计\n\n## 节点职责\n\n将用户描述的小型改动直接整理为最小技术方案——改动点、影响面、验证方式——经一次独立 AI 评审后进入编码；用户人工确认由流程暂停点承载。本流程不设独立需求节点：用户描述与任务上下文就是需求源头。本节点只产出方案，不编写生产代码或测试代码。\n\n## 依赖信息\n\n先检查当前任务上下文：用户需求描述、验收标准、非目标、已有决策，以及项目和所属模块的提示词。加载 `workflow-discipline`；调用独立 `arch-reviewer` 完成方案评审。\n\n直接阅读相关代码和文档，确认真实改动位置、调用关系、依赖方与影响。缺少会改变方案的关键信息时先从仓库现状补齐；仍存在歧义时集中向用户说明并确认，不凭猜测设计。\n\n## 正向执行流程\n\n1. 从用户描述提炼目标行为、保持不变的行为和非目标，整理为可核对的改动点清单。\n2. 逐项定位改动点涉及的模块、调用关系与依赖方，说明对接口、数据、配置、兼容性和用户行为的影响。\n3. 形成最小技术方案，必含：背景与目标、改动点清单（位置+目标行为）、影响面、架构图与核心功能流程图、验证方式、非目标、必要决策；验证方式须能对应验收标准。两张图用可渲染的图形语法表达（项目未约定时用 Mermaid），示意级别即可，不使用文字罗列代替；图中模块、步骤、分支与正文互相有对应说明。\n4. 检查复杂度红线：跨多个边界模块、新增公开接口或数据契约、数据迁移、新依赖、破坏性变更、需要多路线取舍。命中时说明快速流程为何不足，建议改走完整流程；红线判断作为暂停点审批材料呈现，用户明确接受风险坚持快速路径的表态在审批中给出，审批记录即确认留痕。\n5. 将方案全文与评审目标、材料（用户描述、验收标准、参照代码位置）交给 `arch-reviewer` 单轮独立评审，不提供主会话的设计结论。存在 BLOCKER 或 HIGH 时修复后重新发起评审；MEDIUM、LOW 逐项处理或记录保留理由，直至评审 PASS。\n6. 评审通过后先把方案全文落盘为可独立阅读的文档（项目正式文档路径；尚未确定时写临时草稿并注明），再向用户呈现该文档的可读位置、改动点清单、影响面、验证方式、AI 评审结论与红线判断（作为暂停点审批材料）——审批前用户必须能打开完整方案。\n7. 完成产出检查后推进，进入暂停点等待用户审批——审批通过即方案确认，确认原文以审批记录留痕。推进前把已呈现的方案文档按项目文档约定保存为正式文档并登记任务产物（携带全文；超限时路径引用须说明理由），已落盘的草稿直接转为正式文档，不重写内容；按项目分支策略创建任务分支并记录关联。若预判改动可能无可自动验证行为，在方案中显式声明——该声明进入编码节点测试范围判定与本次审批范围。\n\n## 产出与检查\n\n推进前确认：每个改动点有位置、目标行为与影响说明；验证方式对应验收标准；方案含架构图与核心功能流程图，以可渲染的图形呈现且与正文一致（确实不适用时已写明对象与理由）；复杂度红线已检查，命中项已升级或红线判断已纳入审批材料；`arch-reviewer` 最终 PASS 且 Findings 处理留痕；审批材料（文档位置、改动点清单、影响面、验证方式、AI 评审结论、红线判断）已完整呈现，可支撑暂停点审批；方案全文已保存登记；任务分支已就绪；呈现给用户的方案文档可独立打开阅读，且与确认的版本一致。\n\n## 任务差异处理\n\n纯文档、配置类改动可裁剪方案章节，但改动点、影响面、架构图与核心功能流程图、验证方式、非目标不得缺失。信息不足以形成方案时保留在本节点补齐，不推进。\n\n## 节点记录与推进\n\n将方案要点、改动点、影响面、验证方式、红线判断、AI 评审结论与轮次、方案产物与分支信息写入节点记录，推进编码节点（确认原文由暂停点审批记录承载，须逐字引用用户确认表态、不得转述失真；不双写）。",
|
|
32
32
|
"skills": [
|
|
33
33
|
"workflow-discipline"
|
|
34
34
|
],
|
|
@@ -37,8 +37,8 @@
|
|
|
37
37
|
],
|
|
38
38
|
"sourcePreset": {
|
|
39
39
|
"code": "quick-design",
|
|
40
|
-
"version": "1.
|
|
41
|
-
"contentHash": "
|
|
40
|
+
"version": "1.2.0",
|
|
41
|
+
"contentHash": "522c3d00f4ee7a26",
|
|
42
42
|
"agents": [
|
|
43
43
|
"arch-reviewer"
|
|
44
44
|
]
|
|
@@ -73,7 +73,7 @@
|
|
|
73
73
|
"label": "前端编码与测试",
|
|
74
74
|
"phase": "track",
|
|
75
75
|
"track": "ui",
|
|
76
|
-
"prompt": "# 前端编码与测试\n\n## 节点职责\n\n在单一节点内完成界面实现与验证闭环：界面生产代码与配套测试、测试全绿、视觉验证、独立代码评审，五项同为节点完成判定。\n\n## 依赖信息\n\n
|
|
76
|
+
"prompt": "# 前端编码与测试\n\n## 节点职责\n\n在单一节点内完成界面实现与验证闭环：界面生产代码与配套测试、测试全绿、视觉验证、独立代码评审，五项同为节点完成判定。\n\n## 依赖信息\n\n同「后端编码与测试」，另：涉及后端接口时读取服务端入口与请求响应结构确认真实契约；委派 `visual-reviewer` 自主采证执行视觉验证（提供运行地址、认证与数据前置，采证由其完成）；`coding-standards` 读 UI 相关 reference。\n\n## 正向执行流程\n\n1. 将方案整理为界面实现项：页面结构、交互流程、视觉状态、数据状态、响应式与可访问性；调查现有页面、组件、设计系统与状态管理，沿用既有模式。\n2. 实现生产代码：完整覆盖结构、数据流、事件、副作用、样式与反馈；处理加载、空、错误、成功、重复操作、危险操作、长内容、窄屏、键盘与焦点等适用状态；不清除无关注释。\n3. 编写配套测试：按项目声明的前端验证体系（类型检查+组件/逻辑单测）覆盖本次改动；同节点产出生产与测试代码（同后端条款）。\n4. 无可自动验证行为判定与静态检查：同后端条款。\n5. 测试执行交 `test-executor`，纪律同后端（根因先行、禁制造通过）。\n6. 界面可视改动委派 `visual-reviewer` 自主采证验证（主会话提供运行地址、认证与数据前置，不预备截图），纳入完成判定；纯非可视改动（逻辑/数据层）记录不适用理由。\n7. `code-reviewer` 独立评审至 PASS，条款同后端。\n\n## 产出与检查\n\n推进前确认：界面实现与方案逐项对应；配套测试完成（或判定已记录）；静态检查通过；`test-executor` 全绿；`visual-reviewer` PASS（或不适用理由已记录）；`code-reviewer` PASS。\n\n## 任务差异处理 / 节点记录与推进\n\n同后端条款，另记录视觉验证结论与不适用理由。",
|
|
77
77
|
"skills": [
|
|
78
78
|
"coding-standards",
|
|
79
79
|
"workflow-discipline"
|
|
@@ -85,8 +85,8 @@
|
|
|
85
85
|
],
|
|
86
86
|
"sourcePreset": {
|
|
87
87
|
"code": "quick-code-frontend",
|
|
88
|
-
"version": "1.
|
|
89
|
-
"contentHash": "
|
|
88
|
+
"version": "1.1.0",
|
|
89
|
+
"contentHash": "4ee29fe569790c0a",
|
|
90
90
|
"agents": [
|
|
91
91
|
"code-reviewer",
|
|
92
92
|
"test-executor",
|
|
@@ -122,15 +122,15 @@
|
|
|
122
122
|
"label": "发布验收",
|
|
123
123
|
"phase": "exit",
|
|
124
124
|
"track": "all",
|
|
125
|
-
"prompt": "# 发布验收\n\n## 节点职责\n\n
|
|
125
|
+
"prompt": "# 发布验收\n\n## 节点职责\n\n核对最终集成验证证据与当前版本是否一致，向用户呈现可独立理解的验收摘要，并按本节点在流程中的位置承载确认与代码归档：存在后继审批边时，用户确认由流转边暂停点承载，本节点不重复确认；本节点为任务终点时，节点内确认是任务收尾唯一授权门。本节点不重复执行测试、代码评审或回归分析。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、非目标、已激活节点的完成记录、`test-integrate` 的测试范围与结果、日志以及已验证版本标识，并读取项目分支与归档策略。加载 `workflow-discipline`。\n\n缺少集成验证证据、版本标识或前序完成记录时，先从任务上下文补齐；证据仍不完整或无法对应当前版本时停止验收，不推断通过。\n\n## 执行流程\n\n1. 确认所有已激活的前序节点均已完成，不写死某一模板路径下的节点清单。\n2. 比较当前生产代码与 `test-integrate` 绑定的已验证版本。存在新的生产代码变化时，退回集成验证重新判断范围并回归；纯文档或记录变化说明为何不影响证据。\n3. 逐条核对验收标准对应的实现位置和前序验证证据，并确认非目标未被误实现、范围变化已说明、所有 reviewer 的阻塞问题已解决。\n4. 汇总集成测试范围与统计、未授权跳过、实现与验收标准对应关系、范围变化、已知问题和风险，形成简洁且不依赖任务内部术语的验收摘要。\n5. 判定本节点位置：读取任务上下文中的任务结构（DAG 节点集与各节点状态）——本节点是任务最后一个节点（如快速流程形态，已完成数加一等于节点总数）即为终态形态；存在后继节点（如架构归档节点）即为非终态形态。advance 响应的 nextNode 资料包可作交叉印证。两种形态的确认与归档时序不同，按后续步骤分支执行，判定结果写入节点记录。\n6. **终态形态（本节点为任务终点，无后继审批边）**：向用户呈现验收摘要并在节点内取得明确决定。只有明确的通过、确认归档或等价肯定表达构成确认；提问、条件句、部分认同、沉默或模糊表态不构成确认。确认后逐字记录确认原文，并按项目声明完成提交、合并、推送或其他代码归档动作。无项目策略时采用保留历史且可回退的常规方式，并记录采用的默认。\n7. **非终态形态（存在后继审批边）**：向用户呈现验收摘要（作为暂停点审批材料）；推进前在节点记录写入显式「归档待办」条目（归档动作清单：目标分支、合并方式、推送范围）；然后推进进入暂停点等待用户审批——审批通过即验收确认，确认原文以审批记录留痕（须逐字引用用户确认表态，不得转述失真），本节点不重复确认。审批通过后、开始下一节点工作前，先完成归档待办中的代码归档动作（提交/合并/推送），完成后回写归档结果闭环该待办；归档待办在归档完成前不得闭环。\n8. 归档过程中遇到冲突或失败时先检查实际版本控制状态并自主诊断；无法可靠解决时说明当前状态和卡点，不猜测操作结果。\n\n## 产出与检查\n\n推进前确认：\n\n- 所有已激活前序节点已完成；\n- 集成验证证据完整，所有适用测试通过，失败为 0，未授权跳过为 0；\n- 当前生产代码与已验证版本一致；\n- 每条验收标准都有实现和验证证据，非目标、范围变化与已知问题已说明；\n- 没有未解决的 BLOCKER、HIGH 或其他流程定义的阻塞问题；\n- 终态形态：用户已明确确认，确认原文已逐字记录，代码已按项目策略归档；\n- 非终态形态：验收摘要已呈现，归档待办已写入且动作清单明确（归档动作待审批通过后执行，不在本节点提前归档）；\n- 最终提交、分支和远程状态可追溯。\n\n## 任务差异处理\n\n任务没有代码或项目没有分支归档流程时，执行适用的验收确认并说明不适用项。用户要求附条件通过或接受具体风险时，终态形态在节点内记录条件、风险和确认原文；非终态形态该表态在暂停点审批中给出，审批记录即留痕。未被明确接受的阻塞问题不得归档。证据过期、验收标准缺失或代码归档失败时，按实际问题返回相应节点处理，不在本节点重新执行其职责。\n\n## 节点记录与推进\n\n推进前将验收摘要、证据时效、验收标准对照、范围变化、已知问题和位置判定结果写入当前节点记录；非终态形态同时写入归档待办，并在归档完成前保持其未闭环。终态形态在用户确认后追加确认原文与归档结果；非终态形态在暂停点审批通过并完成归档后，追加审批引用、归档策略与结果、最终提交和远程状态，闭环归档待办。完成推进前检查后推进下一节点；批后追加动作发生在推进之后，不阻塞推进。",
|
|
126
126
|
"skills": [
|
|
127
127
|
"workflow-discipline"
|
|
128
128
|
],
|
|
129
129
|
"agents": [],
|
|
130
130
|
"sourcePreset": {
|
|
131
131
|
"code": "release-accept",
|
|
132
|
-
"version": "1.
|
|
133
|
-
"contentHash": "
|
|
132
|
+
"version": "1.4.0",
|
|
133
|
+
"contentHash": "d9ef06ee6f469ce2",
|
|
134
134
|
"agents": []
|
|
135
135
|
}
|
|
136
136
|
}
|
|
@@ -176,7 +176,7 @@
|
|
|
176
176
|
}
|
|
177
177
|
],
|
|
178
178
|
"isDefault": false,
|
|
179
|
-
"version": "2.0.
|
|
179
|
+
"version": "2.0.5"
|
|
180
180
|
},
|
|
181
181
|
"dependencies": {
|
|
182
182
|
"skills": [
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"exportFormatVersion": "1.0",
|
|
3
|
-
"exportedAt": "2026-09-
|
|
3
|
+
"exportedAt": "2026-09-23T10:30:51.116Z",
|
|
4
4
|
"warnings": [],
|
|
5
5
|
"template": {
|
|
6
6
|
"name": "research_workflow",
|
|
@@ -11,15 +11,15 @@
|
|
|
11
11
|
"label": "调研范围确认",
|
|
12
12
|
"phase": "entry",
|
|
13
13
|
"track": "research",
|
|
14
|
-
"prompt": "# 调研范围确认\n\n## 节点职责\n\n
|
|
14
|
+
"prompt": "# 调研范围确认\n\n## 节点职责\n\n将初始调研诉求整理为可直接执行的范围说明，明确需要回答的问题、纳入与排除边界、证据标准和交付物。关键缺口补齐后进入调研执行，用户确认由流程暂停点承载；本节点不提前给出调研结论或实施方案。\n\n## 依赖信息\n\n先检查当前任务上下文，读取初始诉求、期望支持的决策、已有材料、时间或环境限制，以及项目提示词。加载 `workflow-discipline`。\n\n优先复用已有信息，只对会改变调研方向、证据有效性或交付结果的关键缺口向用户确认。非关键的格式、命名和组织偏好沿用项目惯例；无惯例时采用清晰常规格式并记录默认。\n\n## 执行流程\n\n1. 明确调研背景、使用者及结果将支持的具体决策，避免把调研目的写成“全面了解”或“深入研究”。\n2. 将诉求拆成可判定的问题。每个问题写明为何需要回答、可接受证据、结论判定方式，以及证据不足时如何标记无法得出结论。\n3. 定义纳入主题、排除主题、目标对象、来源范围、时间窗口、运行环境和其他限制，防止执行阶段无边界扩张。\n4. 定义来源优先级与可信度规则。优先使用官方文档、官方仓库、标准、原始数据和可复现实验；使用二手资料时说明来源身份与局限，不把搜索摘要当作最终证据。\n5. 约定交付物结构、证据引用方式、结论粒度、对比维度、开放问题和建议是否需要；不预设结论方向。\n6. 检查范围说明是否足以让独立执行者无歧义开工。仍有关键缺口时逐项向用户确认；相关问题可合并呈现，但不得用大而模糊的问题清单转移分析责任。\n7. 按项目文档组织保存完整范围说明，并向用户呈现问题清单、范围、证据标准、交付物和采用的默认（作为暂停点审批材料）；完成产出检查后推进，进入暂停点等待用户审批——审批通过即范围确认，确认原文以审批记录留痕。\n\n## 产出与检查\n\n推进前确认：\n\n- 调研背景、使用者和决策用途明确；\n- 每个调研问题都可判定，并定义了证据要求和无法结论条件；\n- 纳入范围、排除范围、来源、时间与环境限制明确；\n- 来源优先级和可信度规则可执行；\n- 交付物结构、证据引用方式和结论粒度明确；\n- 关键缺口已清零，非关键默认已记录；\n- 范围说明已完整保存，审批材料已完整呈现，可支撑暂停点审批。\n\n## 任务差异处理\n\n探索性调研允许问题在执行中被证据细化，但新增问题不得改变已确认的决策用途或显著扩大范围；确需扩张时说明原因和影响并重新确认。调研目的实际变成功能设计、技术方案或代码实现时，停止本节点并调整任务类型，不在调研范围中夹带实现承诺。\n\n## 节点记录与推进\n\n将调研背景与决策用途、问题清单、纳入与排除范围、证据标准、来源规则、交付物、限制、默认和审批材料索引写入当前节点记录（确认原文由暂停点审批记录承载，须逐字引用用户确认表态、不得转述失真；不双写），并登记完整范围说明产物（登记携带全文，超限时路径引用并说明理由）。完成上述检查后推进调研执行节点。",
|
|
15
15
|
"skills": [
|
|
16
16
|
"workflow-discipline"
|
|
17
17
|
],
|
|
18
18
|
"agents": [],
|
|
19
19
|
"sourcePreset": {
|
|
20
20
|
"code": "research-scope",
|
|
21
|
-
"version": "1.
|
|
22
|
-
"contentHash": "
|
|
21
|
+
"version": "1.5.0",
|
|
22
|
+
"contentHash": "c37bfd8f733f259b",
|
|
23
23
|
"agents": []
|
|
24
24
|
}
|
|
25
25
|
},
|
|
@@ -88,7 +88,7 @@
|
|
|
88
88
|
}
|
|
89
89
|
},
|
|
90
90
|
"isDefault": false,
|
|
91
|
-
"version": "1.0.
|
|
91
|
+
"version": "1.0.3"
|
|
92
92
|
},
|
|
93
93
|
"dependencies": {
|
|
94
94
|
"skills": [
|