@siming-org/cli 0.6.0 → 0.6.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/dist/index.js +2 -2
- package/package.json +3 -3
- package/templates/builtin/full_workflow.bundle.json +265 -503
- package/templates/builtin/quick_workflow.bundle.json +250 -0
- package/templates/builtin/research_workflow.bundle.json +37 -14
- package/templates/builtin/quick_fix_workflow.bundle.json +0 -401
|
@@ -0,0 +1,250 @@
|
|
|
1
|
+
{
|
|
2
|
+
"exportFormatVersion": "1.0",
|
|
3
|
+
"exportedAt": "2026-09-09T15:57:17.950Z",
|
|
4
|
+
"warnings": [],
|
|
5
|
+
"template": {
|
|
6
|
+
"name": "quick_workflow",
|
|
7
|
+
"description": "通用快速开发流程：分支对齐、快速设计（AI 评审 + 人工确认）、后端或前端实现与测试一体（自动测试全绿 + 代码评审 + 视觉验证）、集成验证与发布验收。适用于范围明确的小型改动；命中复杂度红线时建议改走完整流程。混合任务先完成后端实现，再进入前端实现。",
|
|
8
|
+
"nodes": [
|
|
9
|
+
{
|
|
10
|
+
"id": "ALIGN",
|
|
11
|
+
"label": "分支对齐",
|
|
12
|
+
"phase": "entry",
|
|
13
|
+
"track": "all",
|
|
14
|
+
"prompt": "# 分支对齐\n\n## 节点职责\n\n在后续工作开始前，确认是否需要合并基础分支的远程最新代码。\n\n## 依赖信息\n\n检查当前任务上下文和项目提示词，从中解析基础分支，例如 `main`、`master` 或 `dev`。按名称加载 `workflow-discipline` Skill。\n\n## 正向执行流程\n\n1. 能解析出基础分支时，获取并合并该分支的远程最新代码。\n2. 无法解析时，询问用户是否需要合并某个分支的远程代码。\n3. 用户指定分支后执行合并；用户明确表示不需要时，直接推进下一节点。\n\n## 产出检查\n\n推进前确认：基础分支的远程代码已成功合并，或者用户已明确表示不需要合并。\n\n## 任务差异处理\n\n没有远程仓库或用户不要求合并时，记录不执行的事实和理由。合并发生冲突且无法可靠解决时，保留在当前节点并向用户说明。\n\n## 节点记录与推进\n\n记录基础分支、合并结果，或不执行合并的理由，然后推进下一节点。",
|
|
15
|
+
"skills": [
|
|
16
|
+
"workflow-discipline"
|
|
17
|
+
],
|
|
18
|
+
"agents": [],
|
|
19
|
+
"sourcePreset": {
|
|
20
|
+
"code": "align-branch",
|
|
21
|
+
"version": "1.3.0",
|
|
22
|
+
"contentHash": "ffba197df7edb043",
|
|
23
|
+
"agents": []
|
|
24
|
+
}
|
|
25
|
+
},
|
|
26
|
+
{
|
|
27
|
+
"id": "DESIGN",
|
|
28
|
+
"label": "快速设计",
|
|
29
|
+
"phase": "entry",
|
|
30
|
+
"track": "all",
|
|
31
|
+
"prompt": "# 快速设计\n\n## 节点职责\n\n将用户描述的小型改动直接整理为最小技术方案——改动点、影响面、验证方式——经一次独立 AI 评审和用户人工确认后进入编码。本流程不设独立需求节点：用户描述与任务上下文就是需求源头。本节点只产出方案，不编写生产代码或测试代码。\n\n## 依赖信息\n\n先检查当前任务上下文：用户需求描述、验收标准、非目标、已有决策，以及项目和所属模块的提示词。加载 `workflow-discipline`；调用独立 `arch-reviewer` 完成方案评审。\n\n直接阅读相关代码和文档，确认真实改动位置、调用关系、依赖方与影响。缺少会改变方案的关键信息时先从仓库现状补齐；仍存在歧义时集中向用户说明并确认，不凭猜测设计。\n\n## 正向执行流程\n\n1. 从用户描述提炼目标行为、保持不变的行为和非目标，整理为可核对的改动点清单。\n2. 逐项定位改动点涉及的模块、调用关系与依赖方，说明对接口、数据、配置、兼容性和用户行为的影响。\n3. 形成最小技术方案，必含：背景与目标、改动点清单（位置+目标行为）、影响面、验证方式、非目标、必要决策；验证方式须能对应验收标准。\n4. 检查复杂度红线：跨多个边界模块、新增公开接口或数据契约、数据迁移、新依赖、破坏性变更、需要多路线取舍。命中时说明快速流程为何不足，建议改走完整流程；用户明确接受风险坚持快速路径时，记录确认原文。\n5. 将方案全文与客观约束（用户描述、验收标准、参照代码位置）交给 `arch-reviewer` 单轮独立评审，不提供主会话的设计结论。存在 BLOCKER 或 HIGH 时修复后重新发起评审；MEDIUM、LOW 逐项处理或记录保留理由，直至评审 PASS。\n6. 评审通过后向用户呈现方案：改动点清单、影响面、验证方式、AI 评审结论与红线判断，等待人工确认。\n7. 用户确认后：方案全文按项目文档约定保存并登记任务产物（携带全文；超限时路径引用须说明理由）；按项目分支策略创建任务分支并记录关联。若预判改动可能无可自动验证行为，在方案中显式声明——该声明进入编码节点测试范围判定与本次确认范围。\n\n## 产出与检查\n\n推进前确认：每个改动点有位置、目标行为与影响说明；验证方式对应验收标准；复杂度红线已检查，命中项已升级或取得用户风险确认；`arch-reviewer` 最终 PASS 且 Findings 处理留痕；用户明确确认且原文已记录；方案全文已保存登记；任务分支已就绪。\n\n## 任务差异处理\n\n纯文档、配置类改动可裁剪方案章节，但改动点、影响面、验证方式、非目标不得缺失。信息不足以形成方案时保留在本节点补齐，不推进。\n\n## 节点记录与推进\n\n将方案要点、改动点、影响面、验证方式、红线判断、AI 评审结论与轮次、用户确认原文、方案产物与分支信息写入节点记录，推进编码节点。",
|
|
32
|
+
"skills": [
|
|
33
|
+
"workflow-discipline"
|
|
34
|
+
],
|
|
35
|
+
"agents": [
|
|
36
|
+
"arch-reviewer"
|
|
37
|
+
],
|
|
38
|
+
"sourcePreset": {
|
|
39
|
+
"code": "quick-design",
|
|
40
|
+
"version": "1.0.0",
|
|
41
|
+
"contentHash": "accec735ad0791af",
|
|
42
|
+
"agents": [
|
|
43
|
+
"arch-reviewer"
|
|
44
|
+
]
|
|
45
|
+
}
|
|
46
|
+
},
|
|
47
|
+
{
|
|
48
|
+
"id": "CODE_BACKEND",
|
|
49
|
+
"label": "后端编码与测试",
|
|
50
|
+
"phase": "track",
|
|
51
|
+
"track": "backend",
|
|
52
|
+
"prompt": "# 后端编码与测试\n\n## 节点职责\n\n在单一节点内完成实现与验证闭环：编写生产代码与配套测试、执行测试取得全绿结果、通过独立代码评审。四项同为节点完成判定，缺一不可。\n\n## 依赖信息\n\n先检查当前任务上下文：需求、验收标准、技术方案、既有决策、项目和所属模块提示词。加载 `coding-standards`（按技术栈读对应 reference）、`workflow-discipline`；调用 `test-executor` 执行测试、`code-reviewer` 评审代码；测试失败根因不明时加载 `bugfix-root-cause-verification`。\n\n## 正向执行流程\n\n1. 将方案改动点整理为实现项，明确行为边界、错误处理、状态变化与副作用；调查调用链、数据模型与既有契约，沿用项目惯例。\n2. 实现生产代码：最小充分范围，遵循分层与规范，不清除无关注释。\n3. 编写配套测试：按改动影响面确定测试层级与用例集，新增行为必有对应测试，受影响的存量测试同步修正。本节点同时产出生产代码与测试代码——通用流程「编码节点不修改测试」的分工不适用于本合节点形态。\n4. 判定确无可自动验证行为时（如纯配置或文案），在节点记录写明判定与理由；未记录判定的，测试集不得为空。设计阶段已声明该预判的，按声明执行。\n5. 主会话执行类型检查、编译、构建、静态分析并留痕。\n6. 将测试命令、范围、顺序与通过标准交给 `test-executor` 执行，核对统计与日志。失败时先完成根因调查再做最小正确修复，重跑原失败范围与受影响回归；禁止删除有效测试、skip/only、缩小范围、放宽断言制造通过。\n7. 将需求、方案、项目约束与变更位置交给 `code-reviewer` 独立评审，不提供主会话结论。BLOCKER、HIGH 修复后重审直至 PASS；MEDIUM、LOW 逐项处理或记录保留理由。\n\n## 产出与检查\n\n推进前确认：实现完成且与方案逐项对应；配套测试完成（或无可测行为判定已记录理由）；静态检查通过并留痕；`test-executor` 报告全绿（失败 0、未授权跳过 0）；`code-reviewer` 最终 PASS 且 Findings 处理留痕。\n\n## 任务差异处理\n\n执行障碍与修复循环按 `workflow-discipline` 处理，不收敛时暂停上升用户。某项检查不适用时说明理由，不静默跳过。\n\n## 节点记录与推进\n\n记录实现摘要、主要变更、静态检查结果、测试范围与统计、无可测行为判定（如有）、评审结论与 Findings 处理、产物引用，推进下一节点。",
|
|
53
|
+
"skills": [
|
|
54
|
+
"coding-standards",
|
|
55
|
+
"workflow-discipline"
|
|
56
|
+
],
|
|
57
|
+
"agents": [
|
|
58
|
+
"code-reviewer",
|
|
59
|
+
"test-executor"
|
|
60
|
+
],
|
|
61
|
+
"sourcePreset": {
|
|
62
|
+
"code": "quick-code-backend",
|
|
63
|
+
"version": "1.0.0",
|
|
64
|
+
"contentHash": "a388266ee8a38461",
|
|
65
|
+
"agents": [
|
|
66
|
+
"code-reviewer",
|
|
67
|
+
"test-executor"
|
|
68
|
+
]
|
|
69
|
+
}
|
|
70
|
+
},
|
|
71
|
+
{
|
|
72
|
+
"id": "CODE_UI",
|
|
73
|
+
"label": "前端编码与测试",
|
|
74
|
+
"phase": "track",
|
|
75
|
+
"track": "ui",
|
|
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
|
+
"skills": [
|
|
78
|
+
"coding-standards",
|
|
79
|
+
"workflow-discipline"
|
|
80
|
+
],
|
|
81
|
+
"agents": [
|
|
82
|
+
"code-reviewer",
|
|
83
|
+
"test-executor",
|
|
84
|
+
"visual-reviewer"
|
|
85
|
+
],
|
|
86
|
+
"sourcePreset": {
|
|
87
|
+
"code": "quick-code-frontend",
|
|
88
|
+
"version": "1.0.0",
|
|
89
|
+
"contentHash": "98a43ff1510a415f",
|
|
90
|
+
"agents": [
|
|
91
|
+
"code-reviewer",
|
|
92
|
+
"test-executor",
|
|
93
|
+
"visual-reviewer"
|
|
94
|
+
]
|
|
95
|
+
}
|
|
96
|
+
},
|
|
97
|
+
{
|
|
98
|
+
"id": "INTEGRATE",
|
|
99
|
+
"label": "集成验证",
|
|
100
|
+
"phase": "test",
|
|
101
|
+
"track": "all",
|
|
102
|
+
"prompt": "# 集成验证\n\n## 节点职责\n\n将远程主线最新状态整合到任务分支，并在最终集成态执行适用回归，形成绑定明确版本的验证结论。版本控制与范围判断由当前执行者负责，测试命令交给独立 `test-executor` 执行；若产生代码修复，再交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、技术方案、实现与测试记录、`align-branch` 的基础分支与合并记录，以及项目的分支策略、测试体系和所属模块提示词。加载 `workflow-discipline`，调用 `test-executor` 执行回归；发生代码修复时调用 `code-reviewer`。测试失败且根因不明确时，再加载 `bugfix-root-cause-verification`。\n\n优先使用 `align-branch` 已记录的基础分支；记录缺失时，按与该节点相同的规则从任务上下文或项目提示词解析，例如 `main`、`master` 或 `dev`。仍无法解析时询问用户是否需要合并某个分支的远程代码，不根据版本历史猜测基础分支。\n\n## 执行流程\n\n1. 获取远程状态，优先读取 `align-branch` 记录的基础分支；记录缺失时从任务上下文或项目提示词解析，仍无法解析则询问用户。记录当前任务版本、基础分支、远程版本及判断依据。\n2. 用户明确表示无需合并时记录该决定；否则按项目策略整合基础分支的远程最新代码。发生冲突时理解双方意图后逐项融合并验证结果，不盲目选择任一侧；无法可靠解决时说明冲突与缺失决策并暂停。\n3. 汇总任务改动和主线整合改动，读取项目测试目录、配置、脚本与现有用例，列出适用的测试层级和执行入口；项目未定义的层级记录 N/A。\n4. 根据代码差异、模块依赖和测试映射确定回归范围。无法可靠判断某一层级的受影响范围时，将该层级扩大到全量。\n5. 将明确的命令、顺序、范围和通过标准交给 `test-executor` 执行，依据事实报告核对各层级统计、失败、跳过和日志。\n6. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按需加载 `bugfix-root-cause-verification`，确认根因后再修改代码、测试或环境。\n7. 每次修复后重新执行原失败范围和受影响回归。不得通过删除有效测试、skip/only、缩小应执行范围、放宽正确断言、吞异常或硬编码结果制造通过。\n8. 检查新增 skip/only、测试删除、未执行的适用层级、范围遗漏和统计对账。发生代码修复时，将客观约束与变更位置交给 `code-reviewer`；修复 BLOCKER、HIGH Findings 后重跑受影响测试并复审，直至测试通过且评审为 PASS。\n9. 记录最终同步状态、实际回归范围、测试结果和已验证的提交或等价版本标识，确保后续能够判断证据是否仍有效。\n\n## 产出与检查\n\n推进前确认：\n\n- 基础分支沿用 `align-branch` 记录，或已按相同规则重新解析并留痕；\n- 基础分支的远程状态已获取并完成整合，或用户已明确表示无需合并；\n- 所有冲突均已理解并正确融合；\n- 项目适用测试层级与执行入口已识别，N/A 有具体依据；\n- 回归范围有代码差异、依赖或测试映射依据，无法判断的层级已扩大到全量；\n- `test-executor` 报告所有适用回归通过，失败为 0，未授权跳过为 0；\n- 所有失败均在根因明确后修复，没有制造假绿；\n- 发生代码修复时，`code-reviewer` 最终结论为 PASS；\n- 集成结论绑定明确版本，日志和报告可追溯。\n\n## 任务差异处理\n\n基础分支没有新提交时无需制造合并提交，但回归验证仍须执行。用户明确表示无需合并时保留决定并继续验证当前版本。根据项目实际体系选择测试层级和命令，不擅自引入未定义的测试类型。远程状态不可获取、冲突无法可靠解决，或修复涉及破坏性契约、新依赖和真实范围扩张时，说明证据与影响并暂停；同一问题多轮不收敛时按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将基础分支来源、同步策略与结果、任务和远程版本、冲突处理、适用测试层级、回归范围及依据、实际命令与统计、失败根因和修复、完整性检查、代码评审结果、日志与报告引用、最终已验证版本写入当前节点记录。完成上述检查后推进下一节点。",
|
|
103
|
+
"skills": [
|
|
104
|
+
"workflow-discipline"
|
|
105
|
+
],
|
|
106
|
+
"agents": [
|
|
107
|
+
"test-executor",
|
|
108
|
+
"code-reviewer"
|
|
109
|
+
],
|
|
110
|
+
"sourcePreset": {
|
|
111
|
+
"code": "test-integrate",
|
|
112
|
+
"version": "1.3.0",
|
|
113
|
+
"contentHash": "a29435e9ed9bbc68",
|
|
114
|
+
"agents": [
|
|
115
|
+
"test-executor",
|
|
116
|
+
"code-reviewer"
|
|
117
|
+
]
|
|
118
|
+
}
|
|
119
|
+
},
|
|
120
|
+
{
|
|
121
|
+
"id": "ACCEPT",
|
|
122
|
+
"label": "发布验收",
|
|
123
|
+
"phase": "exit",
|
|
124
|
+
"track": "all",
|
|
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. 向用户呈现验收摘要并等待明确决定。只有明确的通过、确认归档或等价肯定表达构成确认；提问、条件句、部分认同、沉默或模糊表态不构成确认。\n6. 用户明确确认后，逐字记录确认原文，并按项目声明完成提交、合并、推送或其他代码归档动作。无项目策略时采用保留历史且可回退的常规方式，并记录采用的默认。\n7. 归档过程中遇到冲突或失败时先检查实际版本控制状态并自主诊断；无法可靠解决时说明当前状态和卡点，不猜测操作结果。\n\n## 产出与检查\n\n推进前确认：\n\n- 所有已激活前序节点已完成；\n- 集成验证证据完整，所有适用测试通过，失败为 0，未授权跳过为 0；\n- 当前生产代码与已验证版本一致；\n- 每条验收标准都有实现和验证证据，非目标、范围变化与已知问题已说明；\n- 没有未解决的 BLOCKER、HIGH 或其他流程定义的阻塞问题；\n- 用户已明确确认，确认原文已逐字记录；\n- 代码已按项目策略归档，最终提交、分支和远程状态可追溯。\n\n## 任务差异处理\n\n任务没有代码或项目没有分支归档流程时，执行适用的验收确认并说明不适用项。用户要求附条件通过或接受具体风险时，记录条件、风险和确认原文；未被明确接受的阻塞问题不得归档。证据过期、验收标准缺失或代码归档失败时，按实际问题返回相应节点处理，不在本节点重新执行其职责。\n\n## 节点记录与推进\n\n在用户确认前，将验收摘要、证据时效、验收标准对照、范围变化和已知问题写入当前节点记录并保持暂停。用户确认后，追加确认原文、归档策略与结果、最终提交和远程状态。完成上述检查后推进下一节点。",
|
|
126
|
+
"skills": [
|
|
127
|
+
"workflow-discipline"
|
|
128
|
+
],
|
|
129
|
+
"agents": [],
|
|
130
|
+
"sourcePreset": {
|
|
131
|
+
"code": "release-accept",
|
|
132
|
+
"version": "1.3.0",
|
|
133
|
+
"contentHash": "d661172440a87940",
|
|
134
|
+
"agents": []
|
|
135
|
+
}
|
|
136
|
+
}
|
|
137
|
+
],
|
|
138
|
+
"edges": [
|
|
139
|
+
{
|
|
140
|
+
"from": "ALIGN",
|
|
141
|
+
"to": "DESIGN"
|
|
142
|
+
},
|
|
143
|
+
{
|
|
144
|
+
"from": "DESIGN",
|
|
145
|
+
"to": "CODE_BACKEND",
|
|
146
|
+
"pausePoint": {
|
|
147
|
+
"type": "human_approval",
|
|
148
|
+
"description": "快速设计人工评审（快速设计 → Track 阶段；须呈现改动点清单 + 影响面 + 验证方式 + AI 评审结论）",
|
|
149
|
+
"autoResume": false
|
|
150
|
+
}
|
|
151
|
+
},
|
|
152
|
+
{
|
|
153
|
+
"from": "DESIGN",
|
|
154
|
+
"to": "CODE_UI",
|
|
155
|
+
"pausePoint": {
|
|
156
|
+
"type": "human_approval",
|
|
157
|
+
"description": "快速设计人工评审（快速设计 → Track 阶段；须呈现改动点清单 + 影响面 + 验证方式 + AI 评审结论）",
|
|
158
|
+
"autoResume": false
|
|
159
|
+
}
|
|
160
|
+
},
|
|
161
|
+
{
|
|
162
|
+
"from": "CODE_BACKEND",
|
|
163
|
+
"to": "CODE_UI"
|
|
164
|
+
},
|
|
165
|
+
{
|
|
166
|
+
"from": "CODE_BACKEND",
|
|
167
|
+
"to": "INTEGRATE"
|
|
168
|
+
},
|
|
169
|
+
{
|
|
170
|
+
"from": "CODE_UI",
|
|
171
|
+
"to": "INTEGRATE"
|
|
172
|
+
},
|
|
173
|
+
{
|
|
174
|
+
"from": "INTEGRATE",
|
|
175
|
+
"to": "ACCEPT"
|
|
176
|
+
}
|
|
177
|
+
],
|
|
178
|
+
"isDefault": false,
|
|
179
|
+
"version": "2.0.0"
|
|
180
|
+
},
|
|
181
|
+
"dependencies": {
|
|
182
|
+
"skills": [
|
|
183
|
+
{
|
|
184
|
+
"name": "workflow-discipline",
|
|
185
|
+
"description": "DAG 节点执行、角色分离、授权、暂停点与任务边界纪律",
|
|
186
|
+
"content": "# workflow-discipline\n\n保证所有 DAG 节点以一致方式确定工作边界、分离执行与验证、处理授权与暂停点，并在完成判定满足后安全推进。\n\n## 适用边界\n\n- 所有节点执行者都应用本 Skill；任务简单、用户催促或改动很小，不改变节点步骤、质量门和完成标准。\n- 本 Skill规定跨节点通用纪律，不替代当前节点提示词中的职责、产出、检查项和具体执行方法。\n- 当前节点提示词与本 Skill共同生效；发现冲突时不得自行忽略任一约束，应先按权限和任务边界判断，无法收敛再向用户呈现冲突。\n\n## 节点执行流程\n\n1. **确认当前边界**：读取任务上下文、当前节点职责、所需产出、完成判定、暂停点和项目约束。执行 git 操作前确认当前分支及项目声明的分支模型。\n2. **确定执行角色**：设计文档和编码由主会话完成；测试命令由 `test-executor` 执行；节点要求独立审查时，由不同 session 的只读 Verifier 执行。\n3. **完成节点工作**：只实施当前节点和已确认任务范围内的工作。发现死代码删留、顺手重构、范围扩张或其他范围外动作时，将其作为独立决策呈现给用户，不自行纳入。\n4. **执行独立验证**：Worker 与 Verifier 必须分离。Verifier 只接收评审对象路径、客观约束和参照位置，不接收设计结论、决策理由或“用户已确认”等预设结论。\n5. **处理审查结果**：审查是否通过，以 Verifier 本次输出为准。逐条修复 finding，或记录不修复理由；修复阻塞问题后重新审查。交互式审查最多 3 轮，连续 3 轮仍未通过时，保留在当前节点并请用户决定。\n6. **检查并记录**：逐项核对当前节点的完成判定，记录实际产出、检查结果、评审结论与轮次、关键决定、不适用项及其理由。\n7. **提交节点成果**：完成判定全部满足后、推进节点前，检查工作树和 diff。存在本节点产生的应提交改动时，只纳入当前任务与当前节点范围内的代码、测试、文档等成果并创建 git commit；不得混入无关改动，也不得用空提交代替成果提交。提交失败或本节点应提交改动仍有遗漏时，留在当前节点处理。\n8. **推进节点**：确认完成判定全部满足，且本节点应提交成果已经提交后，才按节点规定推进或进入暂停点。没有应提交改动的纯审查、纯审批节点直接推进，不制造空提交。\n\n## 执行与质量边界\n\n- Track 编码节点只修改生产代码，不修改测试或其他验证代码；测试节点不得以“现有测试已经覆盖”代替逐项验证。\n- 本任务改动导致的测试失败必须完成根因调查并处理，不得标记为“既有问题”后拒绝处理，也不得通过删除测试、放宽断言或添加 skip 制造通过。\n- 预算或时间不足是暂停并上升决策的理由，不是降低质量门的理由。\n- 已知问题必须逐条判断是否影响功能完整性；影响验收的，在任务结束前处理。只有用户明确接受风险并留下原文记录，才可作为例外。\n- 增量测试或增量评审只能缩小经过证据证明的受影响范围，不得降低原有测试、审查和通过标准。\n\n## 审查与委派规则\n\n- Worker 与 Verifier 使用不同 session；Verifier 只读，不修改代码或文档，不接管主会话协调。\n- 增量复审聚焦本轮改动及其影响面，但沿用完整审查标准。\n- 委派 prompt 使用七段结构：`IDENTITY → TASK → EXPECTED → CONTEXT → CONSTRAINTS → MUST DO / MUST NOT DO → VERIFICATION`。\n- `IDENTITY` 必须说明 agent 类型、读写边界、所需 Skill 和禁止再次委派；借用其他 Skill 时说明是执行该 Skill，还是仅借用其输出格式。\n- subagent 完成指定产出后立即结束；审查修订、重新委派和多轮协调由主会话负责。\n\n## 授权与暂停点\n\n- **决策授权**只覆盖具体方案或风险选择，不自动跳过审查、复审、测试或其他流程步骤。\n- **流程授权**只覆盖用户明确指名跳过的步骤，不得扩展到其他质量门。\n- “跳过人工审批”只跳过对应的用户暂停点，不等于跳过自动审查或验证。\n- 暂停点只有用户明确肯定当前待确认内容时才算通过，并记录用户原文。用户的提问、评估、条件句或新诉求不是确认；应先回应并继续等待明确结论。\n\n## 任务完成边界\n\n- 当前节点全部完成判定满足，且本节点产生的应提交成果已经提交后，才能推进到下一节点；单项测试通过、核心代码完成、存在未提交成果或分支合并，都不能代替节点完成。没有应提交改动的节点不制造空提交。\n- 节点完成不等于任务完成。架构信息归档完成，或该步骤经用户明确授权跳过并留下记录后，任务才进入终态。\n- 任务终止前，不推荐、不询问、不切换到下一个任务；终止后再输出完整任务总结。",
|
|
187
|
+
"category": "process",
|
|
188
|
+
"version": "1.1.1",
|
|
189
|
+
"references": [],
|
|
190
|
+
"scope": "global"
|
|
191
|
+
},
|
|
192
|
+
{
|
|
193
|
+
"name": "coding-standards",
|
|
194
|
+
"description": "通用编码规范与多技术栈实现约束",
|
|
195
|
+
"content": "# 通用编码规范\n\n指导 AI 根据项目技术栈编写正确、清晰、可维护且可验证的代码。\n\n## 规则优先级\n\n依次遵循：\n\n1. 当前任务需求和已确认的技术方案；\n2. 项目及所属模块的提示词、技术栈和既有代码约定；\n3. 本 Skill 中与当前技术栈匹配的 reference；\n4. 本文的跨技术栈通用规则。\n\n技术栈 reference 用于补充语言和运行时特有约束，不覆盖项目已经明确的版本、框架、目录、接口和工具配置。\n\n## Reference 加载\n\n编码前识别当前改动实际涉及的技术栈，并读取所有匹配的 reference。\n\n常见组合：\n\n- TypeScript 后端：`typescript.md` + `node.md`\n- TypeScript 前端：`typescript.md` + `ui.md`\n- JavaScript 后端：`javascript.md` + `node.md`\n- JavaScript 前端：`javascript.md` + `ui.md`\n- 应用代码涉及关系数据库：对应语言 reference + `sql.md`\n- 构建或运维脚本：`shell.md`\n\n同一任务可以同时加载多个 reference。未来新增技术栈时，追加 reference 和本节路由即可，不重写通用规则。\n\n## 通用规则\n\n### 1. 先理解再修改\n\n先读取任务范围、技术方案、项目约束和相关现有代码。新增实现应沿用项目已经采用的架构、错误模型、命名、测试方式和工具链；不要仅因存在另一种惯用写法就替换既有设计。\n\n### 2. 在边界建立可信数据\n\n外部输入、配置、网络响应、持久化数据和跨模块数据进入内部逻辑前，应完成必要的解析、校验和归一化。进入内部后使用能够表达业务约束的类型或数据结构，不在每一层重复猜测和修补无效数据。\n\n### 3. 让状态与职责清楚\n\n优先用类型、枚举、状态机、约束和封装排除非法状态。互斥状态不要拆成可能相互矛盾的布尔值。每个模块、对象和函数保持单一、可说明的职责；没有实际复用或替换需求时，不提前增加抽象层。\n\n### 4. 让状态变化显式\n\n尽量减少共享可变状态和隐藏副作用。纯计算优先写成输入到输出的可预测函数；确实需要修改状态、执行 I/O 或操作外部系统时，把副作用集中在清楚的边界，并明确所有权、生命周期和执行顺序。\n\n这不是全面函数式要求。实体、缓存、缓冲区和框架管理对象可以按其职责保持可变。\n\n### 5. 正确表达失败\n\n区分预期失败、调用方错误、系统故障和内部不变量破坏，并使用当前技术栈惯用的错误机制表达。错误不得静默丢失；包装错误时保留原始原因和必要上下文。只有能够处理或转换错误的层才捕获错误。\n\n不要把所有失败都机械地转成异常、panic 或进程退出；具体边界以对应技术栈 reference 为准。\n\n### 6. 成对管理资源与并发生命周期\n\n文件、连接、锁、事务、流、线程、任务、订阅和临时资源必须有明确的创建、释放、取消和失败路径。优先使用语言或标准库提供的结构化资源管理方式。\n\n启动并发工作时，应能说明：\n\n- 谁拥有它；\n- 何时结束；\n- 如何取消；\n- 错误由谁接收；\n- 是否需要背压、限流或同步。\n\n### 7. 接口保持最小且稳定\n\n公开接口只暴露调用方需要的能力，优先使用能够表达语义的类型，不用无结构字符串、布尔开关或通用对象代替领域概念。兼容性、错误契约和副作用属于接口的一部分。\n\n抽象应来自已经出现的变化或复用需求，不为测试替身、未来设想或形式上的“解耦”提前创建接口。\n\n### 8. 可读性来自结构和命名\n\n控制流保持线性，优先处理边界和失败路径，避免不必要的深层嵌套。命名表达业务含义和单位，让调用处能够读懂意图。\n\n注释只说明代码本身无法表达的约束、业务原因、不变量、兼容考虑和安全前提，不复述代码行为。公开 API 是否需要文档注释，以及文档格式，按技术栈 reference 和项目约定执行。\n\n### 9. 让代码可验证\n\n核心逻辑应能在不依赖真实网络、文件、数据库、时钟或全局状态的情况下验证。外部系统集中在边界，并通过项目既有方式提供可替换入口。\n\n测试验证可观察行为、边界和失败路径，保持确定性与相互独立；不要为了方便测试而扭曲生产接口或增加没有业务价值的抽象。\n\n### 10. 工具负责机械规则\n\n缩进、换行、导入排序和其他机械格式服从项目已有 formatter、lint、编译器和静态分析配置。本 Skill 不重复这些工具能够可靠执行的规则。\n\n没有测量证据时不做性能微优化；先保证正确性和清晰度，再依据 profiling、运行指标或容量目标优化。\n\n## 完成检查\n\n编码完成前确认：\n\n- 已读取所有匹配的技术栈 reference；\n- 外部输入在边界得到处理，内部状态没有依赖隐含猜测；\n- 错误、资源和并发生命周期均有明确归属；\n- 新增抽象具有实际需求，未重复已有能力；\n- 注释只保留有长期价值的信息；\n- 代码符合项目现有 formatter、lint、编译和静态分析要求；\n- 受影响行为具有可验证路径。",
|
|
196
|
+
"category": "process",
|
|
197
|
+
"version": "1.0.0",
|
|
198
|
+
"references": [
|
|
199
|
+
{
|
|
200
|
+
"path": "references/dotnet.md",
|
|
201
|
+
"content": "# C# 与 .NET 编码规范\n\n- 开启 nullable reference types；可空值用 `?` 表达，`!` 只用于编译器无法证明但代码已有可靠不变量的场景。\n- 异常只用于异常情况；常见可预期失败优先 `Try*` 模式。捕获后使用裸 `throw` 保留堆栈，不主动抛出运行时保留异常类型。\n- I/O 使用 async 全链路；不得用 `.Result`、`.Wait()` 或同步阻塞方式等待 Task。`async void` 仅限事件处理器。\n- 独立库代码按项目分析规则决定是否使用 `ConfigureAwait(false)`；应用层不机械添加。\n- 长时间或异步公开操作接收并向下传递 `CancellationToken`；协作取消不是普通失败。\n- 拥有 `IDisposable` 或 `IAsyncDisposable` 资源的对象负责释放；优先使用 `using`、`await using`，Dispose 应幂等。\n- 异步路径不跨 `await` 持有 `lock`；使用适合异步的同步原语。简单原子状态优先使用 `Interlocked`。\n- 纯数据和值语义模型可以使用 record；实体、可变状态和依赖引用相等的模型使用 class。注意 `with` 是浅拷贝。\n- 公开 API 遵循 Framework Design Guidelines；内部实现不为形式一致性过度暴露。\n- LINQ 查询存在延迟执行；避免无意的重复枚举，需要复用结果时明确物化。\n- ASP.NET Core 请求路径不执行同步阻塞或 `Task.Run` 伪异步；HttpClient 和依赖生命周期交给项目既有宿主管理方式。\n- 测试保持快速、隔离、可重复和自检；时钟、文件、网络、数据库等外部依赖通过明确边界替换。\n\n依据：dotnet/docs、dotnet/runtime、dotnet/csharplang、dotnet/AspNetCore.Docs 官方仓库。"
|
|
202
|
+
},
|
|
203
|
+
{
|
|
204
|
+
"path": "references/go.md",
|
|
205
|
+
"content": "# Go 编码规范\n\n- 错误是普通返回值，必须显式检查；不得用 `_` 静默丢弃可能影响结果的错误。\n- 错误消息以小写开始且不以句号结束。调用方需要判断错误时，使用稳定哨兵或自定义类型配合 `errors.Is`、`errors.As`。\n- 增加上下文时使用 `%w` 保留错误链；公开函数返回 `error` 接口，不返回可能形成“非空接口包裹空指针”的具体错误指针。\n- 接口由消费方按需要定义，并保持最小；实现方通常返回具体类型，不为测试替身或未来设想提前创建接口。\n- 修改接收者、包含锁或复制成本较大的类型使用指针 receiver；同一类型的方法保持 receiver 选择一致。\n- `context.Context` 作为第一个参数传递，不存入结构体，不自定义替代类型。\n- 每个 goroutine 都必须有明确退出、取消和错误接收路径；阻塞 goroutine 不会由垃圾回收器自动清理。\n- 默认提供同步 API，由调用方决定是否并发。共享状态可使用 channel 或锁，按语义选择，不机械套用口号。\n- 资源获取后立即安排 `defer` 清理；理解 defer 参数立即求值和后进先出语义。\n- 类型尽量让零值可用；不要仅为微小复制成本把所有参数改成指针。\n- 包名、接收者和导出名称遵循 Go 惯例；导出声明的 doc 注释以声明名称开头。\n- 格式完全交给 `gofmt`/`goimports`；测试失败信息包含输入、got 和 want，重复场景使用表驱动测试。\n\n依据：golang/website、golang/wiki、golang/go 官方仓库。"
|
|
206
|
+
},
|
|
207
|
+
{
|
|
208
|
+
"path": "references/java.md",
|
|
209
|
+
"content": "# Java 编码规范\n\n适用于现代 Java 应用和库。项目使用 Spring、JPA 等框架时，再叠加项目自身框架约束。\n\n- 公开接口默认非空；可空参数或返回值应显式标注。集合和数组无结果时返回空值对象，不返回 `null`。\n- `Optional` 主要用于表达“单个返回值可能不存在”，不作为字段、参数或集合元素使用。\n- 优先基本类型；金额和精确十进制计算使用 `BigDecimal`，不用浮点数代替。\n- 异常只表达异常路径，不用于普通控制流。优先标准异常；跨层传播时转换为当前层语义并保留原因。\n- `catch` 不得静默吞错。确实无需处理时，注释说明为什么可以安全忽略。\n- `AutoCloseable` 资源使用 try-with-resources；跨对象生命周期资源由明确的拥有者释放。\n- 共享可变状态使用同步或并发工具；优先不可变对象，但不强制实体、DTO 和内部缓冲区不可变。\n- 面向接口声明集合等依赖；重写 `equals` 时同时重写 `hashCode`。\n- 公开 API 保持最小暴露，并以 Javadoc 说明契约、异常、副作用和线程安全要求；自解释的内部成员不强制注释。\n- Spring 单例组件默认跨请求共享，组件字段应为依赖或不可变配置；JPA 实体的相等性不得依赖会在持久化过程中变化的值。\n\n依据：OpenJDK、Google Java Style Guide、Spring Framework 官方仓库文档。"
|
|
210
|
+
},
|
|
211
|
+
{
|
|
212
|
+
"path": "references/javascript.md",
|
|
213
|
+
"content": "# JavaScript 编码规范\n\n适用于未由 TypeScript 类型系统约束的现代 JavaScript。Node.js 和 UI 规则分别叠加对应 reference。\n\n- 默认 `const`，需要重新赋值时使用 `let`，不使用 `var`。\n- 使用 `===` 和 `!==`；仅在明确需要同时匹配 `null` 与 `undefined` 时使用 `value == null`。\n- 默认值只针对空值时使用 `??`，不要用 `||` 意外覆盖 `0`、空字符串或 `false`。\n- 可选链只保护其直接访问链；后续调用或运算仍需处理 `undefined`。\n- 使用 `Number.isNaN` 判断 `NaN`，不用 `value === NaN` 或带隐式转换的全局 `isNaN`。\n- 只抛出 `Error` 或其子类；包装错误使用 `cause` 保留原始原因。\n- Promise 链保持平坦并返回内部 Promise；错误在链尾或明确的局部恢复点处理。\n- 根据业务语义选择 `Promise.all`、`allSettled`、`any` 或 `race`，不要把它们视为可互换工具。\n- 数组和可迭代对象使用 `for...of` 或数组方法；对象键使用 `Object.keys`、`Object.entries` 和 `Object.hasOwn`。\n- ESM 和 class 自动处于严格模式；遗留脚本是否声明严格模式按项目环境决定。\n- 注释说明业务原因和约束，不复述代码。\n\n依据：eslint/eslint、mdn/content；Google JavaScript Guide 已冻结，仅用于命名和注释的一般原则。"
|
|
214
|
+
},
|
|
215
|
+
{
|
|
216
|
+
"path": "references/node.md",
|
|
217
|
+
"content": "# Node.js 运行时与服务端规范\n\n与 TypeScript 或 JavaScript reference 共同使用。\n\n- 请求处理路径不使用同步文件、进程、压缩和加密 API。CPU 密集工作移出事件循环，并使用有界 worker 或进程池。\n- 明确处理四类错误通道：同步异常、Promise rejection、EventEmitter `error` 事件和 Stream 错误；一种通道的处理方式不能替代另一种。\n- Promise 必须被 `await`、返回或显式捕获；异步事件监听器必须自行处理 rejection。\n- 包装错误使用 `cause`；程序分支依据稳定错误类型或错误码，不匹配 message 文本。\n- 会发出 `error` 的 EventEmitter 必须有错误处理；监听器数量异常先调查泄漏，不直接提高限制。\n- 流式处理尊重 `write`、`push` 的背压信号；多流串联优先 `pipeline`，并处理其销毁底层资源的语义。\n- `uncaughtException` 只用于同步清理和退出，不用于恢复运行。进程重启交给外部监督者。\n- 避免用 `process.exit()` 截断异步输出和清理；优先设置退出码并让事件循环自然结束。\n- 请求体、JSON 结构、正则、路径和命令参数都视为不可信输入；执行子进程优先参数数组，不拼接 shell 命令。\n- 请求上下文使用 `AsyncLocalStorage` 等明确机制，不用模块级可变变量在并发请求间传递上下文。\n- 定时器、连接、流、worker 和订阅必须具备关闭或取消路径；测试结束前清理所有活动句柄。\n\n依据：nodejs/node、nodejs/learn、OWASP CheatSheetSeries 官方仓库。"
|
|
218
|
+
},
|
|
219
|
+
{
|
|
220
|
+
"path": "references/python.md",
|
|
221
|
+
"content": "# Python 编码规范\n\n- 公共接口提供类型标注，但不得把类型注解当成运行时校验；需要运行时约束时在边界显式解析。\n- 需要“任意但仍受类型保护”的值时优先 `object`，慎用会关闭检查链的 `Any`。\n- 数据容器优先考虑 `dataclass`；可变对象不要强行实现哈希，值对象可使用 `frozen=True`。\n- Python 惯用 EAFP：可恢复的异常情况先执行再捕获；普通业务分支仍使用清楚的条件判断。\n- 只捕获能够处理的具体异常。裸 `except` 禁止；最外层 `except Exception` 仅用于记录、转换或重新抛出。\n- 自定义异常继承 `Exception` 并以 `Error` 结尾；跨层转换使用 `raise ... from ...` 保留原因链。\n- 文件、锁、连接和临时资源使用 `with`；没有现成上下文管理器时用 `contextlib` 封装。\n- 禁止可变默认参数；使用 `None` 或独立哨兵，并在函数体内创建新对象。\n- 不在迭代期间修改当前集合；一次性迭代器需要多次使用时先明确物化。\n- 公共 API 编写 docstring；实现注释说明原因，不重复签名或类型信息。\n- 不吞掉 `asyncio.CancelledError`；清理完成后继续传播，并优先使用结构化并发原语。\n- FastAPI、Django、pandas 等规则仅在项目确实采用对应框架时叠加，不作为 Python 语言硬规则。\n\n依据：python/peps、python/cpython、FastAPI、Django 和 pandas 官方仓库文档。"
|
|
222
|
+
},
|
|
223
|
+
{
|
|
224
|
+
"path": "references/rust.md",
|
|
225
|
+
"content": "# Rust 编码规范\n\n- 使用 `Option`、`Result`、enum、新类型和私有字段表达值域与状态；能够由类型排除的非法状态不留到运行时猜测。\n- 可恢复或预期失败返回 `Result` 并用 `?` 传播；错误类型提供可读上下文和原因链，不使用 `()` 作为公开错误类型。\n- `panic` 只用于调用方违反契约、内部不变量破坏或继续执行不安全的情况；解析、I/O、网络和业务校验失败返回 `Result`。\n- `unwrap`、`expect` 仅用于测试、原型或已有不变量能够证明成功的场景；后者使用 `expect` 说明为什么不可能失败。\n- 只读时借用，修改时使用可变借用，转移所有权时按值传递；不要用无意义的 `clone` 或 `unsafe` 绕开所有权设计问题。\n- 默认不写 `unsafe`。确需使用时将块保持最小，封装在安全 API 内，并以 `SAFETY` 注释或 `# Safety` 文档说明必须维持的不变量。\n- `Send`、`Sync` 依赖编译器自动推导；手写 `unsafe impl` 前必须证明任意安全调用方都无法触发数据竞争或未定义行为。\n- 公开 API 按语义实现适用的通用 trait；转换优先实现 `From`、`TryFrom`，不直接实现已有 blanket implementation 的反向 trait。\n- 公开函数可能失败、panic 或要求 unsafe 前提时，分别编写 `# Errors`、`# Panics`、`# Safety`。\n- 文档示例使用 `?` 处理错误，并作为 doctest 保持可执行。unsafe 相关代码除常规测试外使用 Miri 等工具增强验证。\n- 格式交给 rustfmt，静态问题交给 Clippy；不要把 Clippy 的所有 restriction 规则无差别提升为项目硬门。\n\n依据：Rust Book、Rust Reference、Rust API Guidelines、rust-lang 官方仓库。"
|
|
226
|
+
},
|
|
227
|
+
{
|
|
228
|
+
"path": "references/shell.md",
|
|
229
|
+
"content": "# Shell 与 Bash 编码规范\n\nShell 适合构建、发布、运维和简单胶水任务。脚本过长或控制流复杂时，改用结构化语言。\n\n- 默认使用 Bash 时明确 shebang 和最低版本；只有交付环境要求 `/bin/sh` 时才采用 POSIX sh，两种语法边界不混写。\n- 变量、命令替换和路径展开默认加双引号。参数列表使用数组并以 `\"${array[@]}\"` 展开。\n- 文件列表不解析 `ls` 输出；使用 glob、`find -print0`、`readarray` 等能够保留文件名边界的方式。\n- `set -euo pipefail` 不是完整错误处理方案：`-e` 在条件、管道、函数和命令替换中的行为有例外，`pipefail` 也可能把预期 SIGPIPE 判为失败。\n- 必须成功的步骤显式写出失败处理，如 `command || return` 或 `command || exit`；预期可能失败的命令在条件表达式中判断。\n- 使用 `if command` 或 `if ! command` 检查结果，不通过稍后的 `$?` 判断；错误消息写入 stderr。\n- `read` 使用 `-r`；需要原样读取行时同时设置 `IFS=`。\n- 临时文件和目录使用 `mktemp`，并用 `trap ... EXIT` 清理；不用 PID 拼接可预测临时路径。\n- 不使用 `eval`，不把外部输入拼成命令字符串；命令及参数通过数组或正常参数边界传递。\n- 外部依赖使用 `command -v` 检查；函数内变量使用 `local`，需要保留命令退出码时将声明与命令替换分开。\n- 静态检查使用 ShellCheck；脚本验收同时检查退出码和关键输出或实际结果，不能只信退出码。\n- 格式和低价值样式差异服从项目已有工具与脚本约定。\n\n依据：Google Shell Style Guide、ShellCheck、GNU Bash 与 GNU Coreutils。Bash GitHub 镜像使用 `gnu-mirror-unofficial/bash`，不引用不存在的 `bminor/bash`。"
|
|
230
|
+
},
|
|
231
|
+
{
|
|
232
|
+
"path": "references/sql.md",
|
|
233
|
+
"content": "# SQL 与关系数据库规范\n\n本文件只规定跨关系数据库的共同原则。隔离级别、NULL、索引、在线 DDL 和错误码的具体语义必须再核对当前数据库与版本。\n\n- 所有外部值使用参数化查询或驱动提供的绑定参数；不得用字符串拼接、转义替代参数化。\n- 关键业务约束同时落入数据库约束，如主键、外键、唯一性、非空和检查约束；应用校验不能替代数据库最终保护。\n- 事务边界保持明确且尽量短，只覆盖必须原子完成的操作；网络调用和长时间计算通常不放在事务内部。\n- 根据业务一致性要求选择隔离级别，不依赖数据库默认值。明确评估丢失更新、不可重复读、幻读和写偏差。\n- 序列化失败和死锁只能在操作可安全重试时重试，并设置次数、退避和最终失败处理。\n- 查询显式列出所需字段，不使用 `SELECT *` 作为稳定接口；批量操作使用数据库或驱动的批处理能力，避免逐行往返。\n- 索引来自实际查询、排序和约束需要；使用执行计划和运行指标验证，不为每个字段机械建索引。\n- NULL 使用数据库三值逻辑处理；唯一约束、聚合和排序中的 NULL 行为按当前数据库版本核对。\n- Schema 变更优先采用兼容性演进：先扩展、再迁移、再切换读取、最后收缩；大表变更先确认锁和在线能力。\n- 已部署的版本化迁移不修改其语义内容；修复通过新迁移完成。回滚能力需要单独设计，不能假设迁移工具自动提供。\n- 动态表名、列名和排序字段不能通过普通参数绑定，必须由受控白名单映射。\n- 性能结论以真实执行计划、数据规模和运行指标为依据，不凭 SQL 文本外观判断。\n\n依据：postgres/postgres、MicrosoftDocs/sql-docs、OWASP CheatSheetSeries、Flyway 与 Liquibase 官方仓库。MySQL 方言资料只有官网正文，不作为跨数据库硬规则。"
|
|
234
|
+
},
|
|
235
|
+
{
|
|
236
|
+
"path": "references/typescript.md",
|
|
237
|
+
"content": "# TypeScript 编码规范\n\n- 项目默认开启 `strict`。新项目推荐同时启用 `noImplicitOverride`、`noImplicitReturns`、`noFallthroughCasesInSwitch`；其他严格选项按存量迁移情况逐步开启。\n- 禁止让 `any` 进入内部逻辑；未知输入使用 `unknown`，完成收窄或边界解析后再使用。\n- 类型断言和非空断言没有运行时保护，只作为最后手段。优先使用 `typeof`、`instanceof`、判别字段和类型守卫。\n- 外部数据在边界执行运行时解析；TypeScript 类型声明本身不能证明网络、配置或持久化数据有效。\n- 互斥状态使用可辨识联合，并用 `never` 检查穷尽性；不要用多个可能矛盾的可选字段或布尔值表达同一状态机。\n- 对象形状优先 `interface`，联合、映射和条件类型使用 `type`。对象字面量使用类型注解或 `satisfies`，不要用 `as` 掩盖字段错误。\n- Promise 不得悬空；只抛出或拒绝 `Error` 实例。捕获值按 `unknown` 处理，包装时保留 `cause`。\n- 默认 `const`；只读参数和属性用于表达不修改意图，但不把浅层 `readonly` 误认为运行时深不可变。\n- 使用 ESM 与 `import type`；是否允许其他模块形态，以项目运行时和构建配置为准。\n- 使用 `===` 和 `!==`；只有项目明确采用 `value == null` 同时判断 `null`/`undefined` 时例外。\n- JSDoc 不重复 TypeScript 已表达的类型；实现注释只说明原因、约束和不变量。\n- formatter、lint 和 tsconfig 的项目现值优先，不在业务代码中手工创造另一套风格。\n\n依据：microsoft/TypeScript-Website、typescript-eslint、Google TypeScript Style Guide。"
|
|
238
|
+
},
|
|
239
|
+
{
|
|
240
|
+
"path": "references/ui.md",
|
|
241
|
+
"content": "# UI 与 React 编码规范\n\n与 TypeScript 或 JavaScript reference 共同使用。具体组件库、样式框架和数据层服从项目配置。\n\n- 原生语义元素优先于 ARIA 和自绘控件；必须自定义时，同时实现可访问名称、键盘行为和焦点管理。\n- React 组件渲染保持幂等，不在渲染期修改 props、state、全局对象或既有数据。\n- 状态保持最小：能从 props 或现有 state 推导的值在渲染期计算，不重复存储。\n- 互斥界面状态用单一状态机表达，不用可能同时为真的多个布尔值。\n- Effect 只用于同步外部系统；用户事件在事件处理器中执行，渲染数据直接计算。\n- Effect 中的订阅和异步操作必须清理，并防止过期响应覆盖新状态。已有数据层时优先使用其缓存、取消和竞态能力。\n- 列表 key 必须稳定、唯一且来自数据；动态列表不使用数组下标或渲染时随机值。\n- 数据区域显式处理加载、空、错误、成功和边界状态，并为用户提供可执行的下一步。\n- 表单优先使用原生约束；客户端校验用于反馈，服务端仍须验证。错误信息与字段建立可访问关联。\n- 对话框打开时焦点进入，Tab 保持在内部，Escape 可关闭，关闭后焦点返回触发点。\n- `memo`、`useMemo`、`useCallback` 只用于经过测量的性能问题，不作为默认编码模板。\n- 测试用户可见行为，优先通过 role、label 和可见文本定位；只有无法表达用户语义时使用 test id。\n\n依据：reactjs/react.dev、w3c/aria-practices、mdn/content、Testing Library、Playwright 官方仓库。"
|
|
242
|
+
}
|
|
243
|
+
],
|
|
244
|
+
"scope": "global"
|
|
245
|
+
}
|
|
246
|
+
],
|
|
247
|
+
"agents": [],
|
|
248
|
+
"modelAliases": []
|
|
249
|
+
}
|
|
250
|
+
}
|
|
@@ -1,38 +1,61 @@
|
|
|
1
1
|
{
|
|
2
2
|
"exportFormatVersion": "1.0",
|
|
3
|
-
"exportedAt": "2026-
|
|
3
|
+
"exportedAt": "2026-09-09T15:57:17.946Z",
|
|
4
4
|
"warnings": [],
|
|
5
5
|
"template": {
|
|
6
6
|
"name": "research_workflow",
|
|
7
|
-
"description": "
|
|
7
|
+
"description": "通用调研流程：确认可判定的调研问题、范围、证据标准与交付物，逐项执行有证据的调研，再按风险核验结论并由用户确认归档。调研任务不修改生产代码，主要产出为可追溯的调研报告。",
|
|
8
8
|
"nodes": [
|
|
9
9
|
{
|
|
10
10
|
"id": "PRD",
|
|
11
|
-
"label": "
|
|
11
|
+
"label": "调研范围确认",
|
|
12
12
|
"phase": "entry",
|
|
13
13
|
"track": "research",
|
|
14
|
-
"prompt": "#
|
|
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
|
+
"agents": [],
|
|
19
|
+
"sourcePreset": {
|
|
20
|
+
"code": "research-scope",
|
|
21
|
+
"version": "1.4.0",
|
|
22
|
+
"contentHash": "68f158047fb53369",
|
|
23
|
+
"agents": []
|
|
24
|
+
}
|
|
18
25
|
},
|
|
19
26
|
{
|
|
20
27
|
"id": "RESEARCH",
|
|
21
28
|
"label": "调研执行",
|
|
22
29
|
"phase": "track",
|
|
23
30
|
"track": "research",
|
|
24
|
-
"prompt": "#
|
|
25
|
-
"skills": [
|
|
31
|
+
"prompt": "# 调研执行\n\n## 节点职责\n\n依据已确认的调研范围，由当前主会话确定调研方向、执行方法、证据来源和验收条件，将具体取证任务委派给独立子会话执行，并复核、交叉验证和整合结果，形成可追溯的调研报告。\n\n## 依赖信息\n\n先检查当前任务上下文，读取已确认的调研问题、纳入与排除范围、证据标准、停止条件、交付物，以及相关项目提示词和前序记录。加载 `workflow-discipline`。\n\n对每个调研问题，由主会话先确定需要验证的事实、适用的检索或实验方法、优先来源、输出格式和完成标准，再发起委派。外部资料优先使用官方标准、官方文档、官方组织或官方仓库及其他原始资料；官网不可达时优先查找其官方 GitHub 内容。缺少会改变调研方向的输入时，先向用户确认，不把方向选择交给子会话。\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将问题与任务映射、各项委派的方法和来源要求、证据与结论、交叉验证、来源冲突、无法确认项、范围差异、调研报告产物（登记携带全文，超限时路径引用并说明理由）及完成检查写入当前节点记录。完成上述检查后推进下一节点。",
|
|
32
|
+
"skills": [
|
|
33
|
+
"workflow-discipline"
|
|
34
|
+
],
|
|
35
|
+
"agents": [],
|
|
36
|
+
"sourcePreset": {
|
|
37
|
+
"code": "research-execute",
|
|
38
|
+
"version": "1.4.0",
|
|
39
|
+
"contentHash": "bcd4b09e12ac5624",
|
|
40
|
+
"agents": []
|
|
41
|
+
}
|
|
26
42
|
},
|
|
27
43
|
{
|
|
28
44
|
"id": "ACCEPT",
|
|
29
|
-
"label": "
|
|
45
|
+
"label": "调研验收",
|
|
30
46
|
"phase": "exit",
|
|
31
47
|
"track": "all",
|
|
32
|
-
"prompt": "#
|
|
48
|
+
"prompt": "# 调研验收\n\n## 节点职责\n\n对照已确认的调研范围核对报告完整性和证据状态，向用户呈现可独立判断的验收摘要；用户明确确认后，按项目策略归档报告并完成任务。\n\n## 依赖信息\n\n先检查当前任务上下文，读取已确认的调研问题、范围、证据标准、停止条件、调研报告、来源与实验记录、限制和开放问题，以及项目的归档约定。加载 `workflow-discipline`。\n\n本节点不重新执行调研，不虚构独立 reviewer，也不做代码测试或代码评审。报告存在缺失、越界或证据不匹配时，返回 `research-execute` 补充或修订。\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将问题覆盖关系、证据核对结果、退回修订及结果、无法结论、限制和开放问题、验收摘要、用户确认原文、报告与归档引用写入当前节点记录。所有检查完成后结束任务；任何检查未满足时保留在当前节点或返回相应节点处理。",
|
|
33
49
|
"skills": [
|
|
34
50
|
"workflow-discipline"
|
|
35
|
-
]
|
|
51
|
+
],
|
|
52
|
+
"agents": [],
|
|
53
|
+
"sourcePreset": {
|
|
54
|
+
"code": "research-accept",
|
|
55
|
+
"version": "1.3.0",
|
|
56
|
+
"contentHash": "26e6f298b87ec0bf",
|
|
57
|
+
"agents": []
|
|
58
|
+
}
|
|
36
59
|
}
|
|
37
60
|
],
|
|
38
61
|
"edges": [
|
|
@@ -65,16 +88,16 @@
|
|
|
65
88
|
}
|
|
66
89
|
},
|
|
67
90
|
"isDefault": false,
|
|
68
|
-
"version": "1.0.
|
|
91
|
+
"version": "1.0.2"
|
|
69
92
|
},
|
|
70
93
|
"dependencies": {
|
|
71
94
|
"skills": [
|
|
72
95
|
{
|
|
73
96
|
"name": "workflow-discipline",
|
|
74
|
-
"description": "
|
|
75
|
-
"content": "# workflow-discipline
|
|
97
|
+
"description": "DAG 节点执行、角色分离、授权、暂停点与任务边界纪律",
|
|
98
|
+
"content": "# workflow-discipline\n\n保证所有 DAG 节点以一致方式确定工作边界、分离执行与验证、处理授权与暂停点，并在完成判定满足后安全推进。\n\n## 适用边界\n\n- 所有节点执行者都应用本 Skill；任务简单、用户催促或改动很小，不改变节点步骤、质量门和完成标准。\n- 本 Skill规定跨节点通用纪律，不替代当前节点提示词中的职责、产出、检查项和具体执行方法。\n- 当前节点提示词与本 Skill共同生效；发现冲突时不得自行忽略任一约束，应先按权限和任务边界判断，无法收敛再向用户呈现冲突。\n\n## 节点执行流程\n\n1. **确认当前边界**：读取任务上下文、当前节点职责、所需产出、完成判定、暂停点和项目约束。执行 git 操作前确认当前分支及项目声明的分支模型。\n2. **确定执行角色**：设计文档和编码由主会话完成；测试命令由 `test-executor` 执行；节点要求独立审查时，由不同 session 的只读 Verifier 执行。\n3. **完成节点工作**：只实施当前节点和已确认任务范围内的工作。发现死代码删留、顺手重构、范围扩张或其他范围外动作时，将其作为独立决策呈现给用户，不自行纳入。\n4. **执行独立验证**：Worker 与 Verifier 必须分离。Verifier 只接收评审对象路径、客观约束和参照位置，不接收设计结论、决策理由或“用户已确认”等预设结论。\n5. **处理审查结果**：审查是否通过，以 Verifier 本次输出为准。逐条修复 finding，或记录不修复理由；修复阻塞问题后重新审查。交互式审查最多 3 轮，连续 3 轮仍未通过时，保留在当前节点并请用户决定。\n6. **检查并记录**：逐项核对当前节点的完成判定，记录实际产出、检查结果、评审结论与轮次、关键决定、不适用项及其理由。\n7. **提交节点成果**：完成判定全部满足后、推进节点前，检查工作树和 diff。存在本节点产生的应提交改动时，只纳入当前任务与当前节点范围内的代码、测试、文档等成果并创建 git commit；不得混入无关改动，也不得用空提交代替成果提交。提交失败或本节点应提交改动仍有遗漏时，留在当前节点处理。\n8. **推进节点**：确认完成判定全部满足，且本节点应提交成果已经提交后，才按节点规定推进或进入暂停点。没有应提交改动的纯审查、纯审批节点直接推进，不制造空提交。\n\n## 执行与质量边界\n\n- Track 编码节点只修改生产代码，不修改测试或其他验证代码；测试节点不得以“现有测试已经覆盖”代替逐项验证。\n- 本任务改动导致的测试失败必须完成根因调查并处理，不得标记为“既有问题”后拒绝处理，也不得通过删除测试、放宽断言或添加 skip 制造通过。\n- 预算或时间不足是暂停并上升决策的理由，不是降低质量门的理由。\n- 已知问题必须逐条判断是否影响功能完整性；影响验收的，在任务结束前处理。只有用户明确接受风险并留下原文记录，才可作为例外。\n- 增量测试或增量评审只能缩小经过证据证明的受影响范围，不得降低原有测试、审查和通过标准。\n\n## 审查与委派规则\n\n- Worker 与 Verifier 使用不同 session；Verifier 只读，不修改代码或文档，不接管主会话协调。\n- 增量复审聚焦本轮改动及其影响面，但沿用完整审查标准。\n- 委派 prompt 使用七段结构：`IDENTITY → TASK → EXPECTED → CONTEXT → CONSTRAINTS → MUST DO / MUST NOT DO → VERIFICATION`。\n- `IDENTITY` 必须说明 agent 类型、读写边界、所需 Skill 和禁止再次委派；借用其他 Skill 时说明是执行该 Skill，还是仅借用其输出格式。\n- subagent 完成指定产出后立即结束；审查修订、重新委派和多轮协调由主会话负责。\n\n## 授权与暂停点\n\n- **决策授权**只覆盖具体方案或风险选择，不自动跳过审查、复审、测试或其他流程步骤。\n- **流程授权**只覆盖用户明确指名跳过的步骤，不得扩展到其他质量门。\n- “跳过人工审批”只跳过对应的用户暂停点，不等于跳过自动审查或验证。\n- 暂停点只有用户明确肯定当前待确认内容时才算通过，并记录用户原文。用户的提问、评估、条件句或新诉求不是确认；应先回应并继续等待明确结论。\n\n## 任务完成边界\n\n- 当前节点全部完成判定满足，且本节点产生的应提交成果已经提交后，才能推进到下一节点；单项测试通过、核心代码完成、存在未提交成果或分支合并，都不能代替节点完成。没有应提交改动的节点不制造空提交。\n- 节点完成不等于任务完成。架构信息归档完成，或该步骤经用户明确授权跳过并留下记录后，任务才进入终态。\n- 任务终止前，不推荐、不询问、不切换到下一个任务；终止后再输出完整任务总结。",
|
|
76
99
|
"category": "process",
|
|
77
|
-
"version": "1.
|
|
100
|
+
"version": "1.1.1",
|
|
78
101
|
"references": [],
|
|
79
102
|
"scope": "global"
|
|
80
103
|
}
|