@godv61/dsh-task-engine 0.28.0 → 0.29.1

package/skills/architecture-design/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: architecture-design
+description: 为新模块或大范围重构确定边界、接口、兼容点和关键取舍。
+whenToUse: 超高复杂度任务进入架构设计元技能时。
+---
+
+# 架构设计元技能
+
+基于需求产物和实际代码库，说明模块边界、关键数据流、接口与依赖变化、兼容性和主要取舍。优先延续项目现有架构；偏离时说明理由。使用 `dev_task record` 写入当前阶段 `architecture` 产物。
+
+交接给任务编排：可按先后顺序实施的结构、受影响范围、必须保持的接口契约。迁移或回退演练只在任务实际涉及相应风险时提出。

package/skills/code-development/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: code-development
+description: 按验收条件和有序任务清单实现代码，并遵守绑定的项目规则。
+whenToUse: 自适应任务进入代码开发元技能时。
+---
+
+# 代码开发元技能
+
+先读取当前阶段绑定的项目地图、领域编码技能和规则。按任务先后顺序修改代码，遵守已有接口和技术栈约束。每个实施项完成时记录结果及对应审核；不要为了分发给多个开发者而拆项。发现需求或方案发生变化时使用 `revise` 回到相应阶段。
+
+交接给测试：变更文件、实现要点、验收场景及已知限制。SonarQube 若启用，在代码审核阶段运行，不在每次编辑时触发。

package/skills/code-review/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: code-review
+description: 审核需求符合性、代码质量与可选的 SonarQube 结果，推动失败项修复。
+whenToUse: 自适应任务进入代码审核元技能时。
+---
+
+# 代码审核元技能
+
+对照需求、任务产物、变更和测试回执审核。项目若启用 SonarQube，在本阶段读取本次分支或合并请求的新代码分析与质量门禁结果；有阻断问题时记录、修复、重新测试和复审，不能只填一个通过结论。使用 `dev_task review` 记录结果。
+
+对可复用的失败案例提出项目 Rule 候选，包含触发场景、错误与正确示例、对应 Sonar 规则；经审阅后挂到相应代码开发 Skill。不要把单次误报或整个 Quality Profile 原样写成规则。

package/skills/eng-delivery/SKILL.md

@@ -4,11 +4,15 @@ description: 使用 dev_task 读取任务状态、执行流程门禁与完成条
 whenToUse: 在启用工程化交付会话预设后，开始或继续开发任务时先读取状态；阶段流转与完成必须通过 dev_task。
 ---
 
-# 工程流程编排
+# 工程任务编排
+
+新需求先按改动范围、实现依赖和架构影响选择 `low`、`medium`、`high` 或 `ultra`，调用 `dev_task assess` 查看相应阶段与有效技能来源。创建时提供 `complexity` 和具体的 `complexity_reason`。低档为局部明确修改；中档先形成需求与验收；高档增加按实现先后顺序的任务编排；超高档适用于完整新模块或大范围重构，增加架构设计。风险等级独立选择。没有 `complexity` 的旧调用继续使用 `.dsh/eng.json`。
+
+自适应任务的当前元技能及附加技能都以 `status.bindings` 为准，用 `dev_task load_skill` 和准确的 `source:name` 加载；项目同名 Skill 覆盖用户与内置 Skill，Rule 由生效 Skill 自身的 `profile.json` 持有。当前任务的流程在创建时冻结，其他会话的任务可选择不同档次。
 
 `dev_task` 是任务状态、阶段流转与门禁的唯一事实来源。流程预设决定阶段图与守卫；项目配置决定阶段使用哪些技能、每个技能遵守哪些规则，以及产物字段和提交文本。没有绑定时仅执行状态机，不自行补充技能或规则。
 
-1. 先调用 `dev_task`（operation=status）查找当前工作区和分支的任务；有多个候选时让使用者明确目标。没有任务时按实际需求调用 `create`，已有任务则从返回的 `stage` 继续。
+1. 先调用 `dev_task`（operation=status）查找当前工作区和分支的任务；有多个候选时让使用者明确目标。没有任务时评估复杂度，调用 `assess`，然后按实际需求调用 `create`；已有任务从返回的 `stage` 继续。
 2. 读取 `status.bindings`、`skill_obligations`、`artifact_requirements`、`legal_next` 和 `commit`。只加载当前及即将进入的终态实际绑定的技能，遵守本次交互读取的最新规则正文；没有绑定时不自行补上技能或规则。
 3. 技能要求的证据以其配置和 `status.skill_obligations` 为准：仅对 `command_receipts_required` 列出的技能通过带真实命令的 `skill_result` 记录；`manual` 通过人工审批记录；`artifact`、`review` 与 `none` 按对应阶段操作或无需额外回执处理。不要把所有技能都当成命令型技能。技能加载成功不等于要求的证据已经完成。
 4. 需要记录产物时，只使用 `artifact_requirements` 给出的 id 与字段。按当前流程要求完成确认、实施项、验证和审核，再调用 `advance`；被拒绝时按返回的阻塞原因修正，不改任务文件绕过门禁。

package/skills/requirements-analysis/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: requirements-analysis
+description: 澄清需求目标、边界和可验收结果，形成后续设计与开发的输入。
+whenToUse: 自适应任务进入需求分析元技能时。
+---
+
+# 需求分析元技能
+
+读取用户需求与项目现状，区分已确认事实、推断和待澄清问题。给出目标、范围、非目标及可验证的验收条件。只对影响实现的缺口提问；能够依据现有上下文确定的内容直接写明依据。使用 `dev_task record` 写入当前阶段 `requirement` 产物，其字段以任务快照为准。
+
+交接给下一元技能：明确的验收条件、受影响的业务路径和仍未解决的约束。不要把实现步骤伪装成需求。

package/skills/task-orchestration/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: task-orchestration
+description: 按需求实现的依赖顺序拆解任务，记录每步输入、输出和验收。
+whenToUse: 高或超高复杂度任务进入任务编排元技能时。
+---
+
+# 任务编排元技能
+
+把需求和架构决定拆成按实现先后推进的步骤。每步写清依赖、预期代码或文档产物、完成判据及交接给下一步的内容；先实现基础能力，再实现依赖它的能力。拆分服务于正确推进，不按人员或分支数量机械分包。使用 `dev_task record` 写入 `task-plan` 产物，并用 `items` 按此顺序登记实施项。
+
+交接给代码开发：有序任务清单、依赖关系、每步完成定义。负责人和分支仅在用户或团队配置要求时记录。

package/skills/test-validation/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: test-validation
+description: 执行与本次变更相称的验证，并记录可追溯的实际命令回执。
+whenToUse: 自适应任务进入测试元技能时。
+---
+
+# 测试元技能
+
+根据验收条件选择验证场景，运行真实测试或构建命令，并通过 `dev_task verify` 保存回执。失败时先修复再重新运行；测试范围应覆盖本次改动及其主要回归风险。
+
+交接给代码审核：测试命令、结果、覆盖的场景和未覆盖原因。不要把模型的口头判断当成通过的测试。