name	task-decomp
description	任务拆分 — 功能到任务的分解，确保粒度单一可控。当 ARCH 完成、需要拆解任务卡、划分 Sprint 或定义 TDD 验收标准时使用。
argument-hint	<ARCH文档路径或模块列表>
suggested-tools	file_read, file_write, file_edit, file_grep, shell_exec
depends	["context","task-dep-analysis"]
disable-model-invocation	false
user-invocable	true

任务拆分 (task-decomp)

能力边界

能做: 功能→任务分解、复杂度评级、Sprint 初步划分、TDD 验收标准定义
不做: 架构决策、代码实现、测试执行、最终 Sprint 分组判定（依赖关系由 task-dep-analysis 计算并给出权威建议）

输入规范

ARCH模块划分(M-{NNN}) + 接口契约(API-{NNN})
UI-SPEC组件(UC-{NNN}) + 页面(P-{NNN})

输出规范

任务卡(T-{NNN})，每个包含:
- 目标、模块、接口、复杂度(S/M/L/XL)
- tdd_acceptance: 验收标准映射（GWT 格式，见执行流程 3）
- deliverables: 交付物文件清单
- context_load: context加载清单
- 实现提示(仅在必要时)
Sprint划分表
依赖图 + 关键路径
集成/E2E测试规划: 按Sprint标注需验证的模块间交互和端到端用户流程

执行流程

从ARCH模块和接口推导任务
评估每个任务复杂度：跨越多个模块、或 context_load > 5 个章节、或步骤无法在单次 Agent 调用中枚举完整时，继续拆分
定义tdd_acceptance(映射AC)。每条 AC 采用 Given-When-Then 格式：
- Given: 前置条件（输入数据、系统状态）
- When: 触发动作（调用方法、发送请求、用户操作）
- Then: 可观测结果（具体返回值/字段、状态变化、错误类型+消息）
- Then 子句必须包含可断言的具体值或约束，禁止"实现 X"、"支持 Y"等无行为描述
- 契约完整性对账: AC 引用某 arch#§N.API-xxx 契约时，把契约声明的全部响应码 / 安全路径 / 集成点逐一与派生 AC 交叉核验；每项须有对应 AC，无对应的须显式标 [ASSUMPTION] 豁免并附理由
定义deliverables(明确交付文件)
定义context_load(context引用)
建立依赖图: 调用 task-dep-analysis skill 计算拓扑/关键路径/环检测，再用 cataforge viz tasks --format mermaid 产出 Mermaid 依赖图并写入 dev-plan#§2
按依赖关系划分Sprint(参考 task-dep-analysis 输出的 sprint_groups)，遵循 Sprint 切分原则:
- 每个 Sprint 的产出应包含至少一个用户可感知的完整功能
- 优先安排用户核心路径（user_facing_critical_path: true）的任务到前几个 Sprint
- Sprint 1 例外: 基础设施任务允许集中在首个 Sprint，不要求用户可感知功能
- 纯后端服务项目无此约束
- arch §1.5 external_oracles 非空时，Sprint 1 强制一张 walking_skeleton: true 任务卡并作为规模化 Sprint 的 blocking dependency（契约见 external-truth-first.md；doc-review Layer 1 强制）
插入验证任务: 每个包含 user_facing_critical_path: true 任务的 Sprint 末尾，追加一个 task_kind: validation 的验证任务。验证任务不产出代码，orchestrator 遇到时暂停并向用户展示验证清单

Anti-Patterns

禁止: 单任务预估 LOC > TASK_SPLIT_LOC 或 AC > 6 条而不拆 —— 超此尺寸任务粒度不再单一，应在 task-decomp 阶段先拆
禁止: 把"重构 X"作为独立任务 —— 重构是 TDD REFACTOR 阶段的自然产物，独立 T-xxx 会让重构脱离测试安全网
禁止: deliverables 仅写 "实现 X 功能" 而不具体到文件路径 —— sprint-review 无法验证 AC 是否落到声明文件，验收形同虚设
避免: 任务横跨 ≥3 个 arch#§2.M-xxx —— 跨模块任务在 task-dep-analysis 输出中容易触发环依赖
禁止: AC 仅描述"实现 X 功能"/"支持 Y 格式" —— 模糊 AC 导致 test-writer 退化为存在性检查，无法推导断言期望值
禁止: AC 只覆盖被引用 arch#§N.API-xxx 契约的正常路径 —— 如契约声明 401 E_AUTH + 403 E_PERMISSION_DENIED 两条安全路径，AC 只测正常返回，缺口要到下游 code-review 标 HIGH 或 pre-wiring 审计才暴露
禁止: arch 模块为有序管线（stage 序列）时遗漏某 stage 的承载任务 —— 模块管线含 A→B→C 三 stage 而只为 A、C 建任务卡，B 接线无任务、以空返回满足下游字面 AC，运行时管线在 B 静默断裂；每个 stage 的接线须有任务卡 deliverables 承载
禁止: Sprint 内全部为后端任务而无任何用户可感知的功能交付（Sprint 1 例外），除非项目为纯后端服务
禁止: task-dep-analysis 报环依赖或无法计算拓扑序时仍输出任务计划 —— 环路使 Sprint 排期失真，应返回 blocked 附环路 task_id 链请人工拆环（COMMON-RULES §通用 Error Handling），不静默降级为无序计划

效率策略

先拆后排: 先拆任务再排依赖
context_load精确到章节，避免全文加载

Más de este repositorio

mismo repositorio

framework-walkthrough

lync-cyber/CataForge

项目走查 — 在隔离沙盒中以指定执行模式（缺省 standard 全阶段）把一个小型示例项目跑通整条 SDLC 工作流（初始化→核心执行链路→分支→异常→终止清理），逐路径观察各阶段/门禁/降级/恢复的真实行为，产出『框架本身 + 走查流程本身』两类改进建议，并把走查流程自身的改进经自更新协议回灌本 skill 迭代。与 framework-review 形成动静对偶：后者静态审元资产，本 skill 动态端到端自测。当用户想验证一次框架部署是否真能跑通、为非 Claude-Code 平台做行为级冒烟、或自测 workflow-framework-generator 生成的框架时使用。

2026-07-17134

testing

lync-cyber/CataForge

测试 — 测试策略规划、测试编写与执行、覆盖率分析、缺陷记录。当需要规划测试策略、编写或执行测试套件、分析覆盖率或记录缺陷时使用。本 skill 不改源码（缺陷修复由 debug 负责），单任务 RED/GREEN 单元测试由 tdd-engine 负责，testing 聚焦集成/E2E 与覆盖盲区补充。

2026-07-17134

code-review

lync-cyber/CataForge

代码评审 — 任务粒度评审 (review) 与项目级健康度扫描 (scan) 双入口；代码质量检查、规范合规验证、安全漏洞检测、腐化指标扫描。当任务卡 GREEN 完成 / Sprint 发布前 / 用户要求扫描代码腐化时使用此 skill。审查范围限 src/ 业务代码：文档审查由 doc-review 负责；框架元资产 (.cataforge/) 审查由 framework-review 负责；Sprint 完成度由 sprint-review 负责。

2026-07-16134

context

lync-cyber/CataForge

统一上下文 I/O — 按需读取章节/实体、查询追溯关系、生成与写入、门禁校验。文档生命周期的单一入口；后端(知识图谱/文件)由框架按配置方案透明路由,调用方只表达意图。按操作分支见 references/。

2026-07-16134

feature-walkthrough

lync-cyber/CataForge

功能走查 — 对交付项目的功能实现做验收式动态走查，两层正交判定：①功能是否兑现 spec（missing/drift/bug/pass）；②代码本身是否健康（复用 COMMON-RULES §统一问题分类体系的 code category）。用真实数据路径起真实服务复现，专捞门禁全绿仍漏的跨模块集成缝隙。当项目功能交付后需验收、Sprint 发布前做功能级复核、或用户要求走查某功能域时使用。与 framework-walkthrough 动静对偶：后者在沙盒自测框架 SDLC，本 skill 验收交付项目的功能实现。

2026-07-16134

framework-review

lync-cyber/CataForge

框架元资产审查 — 对 .cataforge/ 下的 agents/skills/hooks/rules + workflow 拓扑做内容质量与一致性审查。与 platform-audit 形成内审/外审对偶；与 code-review/doc-review 服务于业务产物不同，本 skill 专审框架自身配置。当用户提到框架腐化、SKILL.md/AGENT.md 质量、agent 引用孤立、SKILL/MANIFEST 漂移、Workflow 完整性、model_tier 合规时使用。

2026-07-16134

任务拆分 (task-decomp)

能力边界

能做: 功能→任务分解、复杂度评级、Sprint 初步划分、TDD 验收标准定义

不做: 架构决策、代码实现、测试执行、最终 Sprint 分组判定（依赖关系由 task-dep-analysis 计算并给出权威建议）

输入规范

ARCH模块划分(M-{NNN}) + 接口契约(API-{NNN})

UI-SPEC组件(UC-{NNN}) + 页面(P-{NNN})

输出规范

任务卡(T-{NNN})，每个包含:

目标、模块、接口、复杂度(S/M/L/XL)
tdd_acceptance: 验收标准映射（GWT 格式，见执行流程 3）
deliverables: 交付物文件清单
context_load: context加载清单
实现提示(仅在必要时)

Sprint划分表

依赖图 + 关键路径

集成/E2E测试规划: 按Sprint标注需验证的模块间交互和端到端用户流程

执行流程

从ARCH模块和接口推导任务

评估每个任务复杂度：跨越多个模块、或 context_load > 5 个章节、或步骤无法在单次 Agent 调用中枚举完整时，继续拆分

定义tdd_acceptance(映射AC)。每条 AC 采用 Given-When-Then 格式：

Given: 前置条件（输入数据、系统状态）
When: 触发动作（调用方法、发送请求、用户操作）
Then: 可观测结果（具体返回值/字段、状态变化、错误类型+消息）
Then 子句必须包含可断言的具体值或约束，禁止"实现 X"、"支持 Y"等无行为描述
契约完整性对账: AC 引用某 arch#§N.API-xxx 契约时，把契约声明的全部响应码 / 安全路径 / 集成点逐一与派生 AC 交叉核验；每项须有对应 AC，无对应的须显式标 [ASSUMPTION] 豁免并附理由

定义deliverables(明确交付文件)

定义context_load(context引用)

建立依赖图: 调用 task-dep-analysis skill 计算拓扑/关键路径/环检测，再用 cataforge viz tasks --format mermaid 产出 Mermaid 依赖图并写入 dev-plan#§2

按依赖关系划分Sprint(参考 task-dep-analysis 输出的 sprint_groups)，遵循 Sprint 切分原则:

每个 Sprint 的产出应包含至少一个用户可感知的完整功能
优先安排用户核心路径（user_facing_critical_path: true）的任务到前几个 Sprint
Sprint 1 例外: 基础设施任务允许集中在首个 Sprint，不要求用户可感知功能
纯后端服务项目无此约束
arch §1.5 external_oracles 非空时，Sprint 1 强制一张 walking_skeleton: true 任务卡并作为规模化 Sprint 的 blocking dependency（契约见 external-truth-first.md；doc-review Layer 1 强制）

插入验证任务: 每个包含 user_facing_critical_path: true 任务的 Sprint 末尾，追加一个 task_kind: validation 的验证任务。验证任务不产出代码，orchestrator 遇到时暂停并向用户展示验证清单

Anti-Patterns

禁止: 单任务预估 LOC > TASK_SPLIT_LOC 或 AC > 6 条而不拆 —— 超此尺寸任务粒度不再单一，应在 task-decomp 阶段先拆

禁止: 把"重构 X"作为独立任务 —— 重构是 TDD REFACTOR 阶段的自然产物，独立 T-xxx 会让重构脱离测试安全网

禁止: deliverables 仅写 "实现 X 功能" 而不具体到文件路径 —— sprint-review 无法验证 AC 是否落到声明文件，验收形同虚设

避免: 任务横跨 ≥3 个 arch#§2.M-xxx —— 跨模块任务在 task-dep-analysis 输出中容易触发环依赖

禁止: AC 仅描述"实现 X 功能"/"支持 Y 格式" —— 模糊 AC 导致 test-writer 退化为存在性检查，无法推导断言期望值

禁止: AC 只覆盖被引用 arch#§N.API-xxx 契约的正常路径 —— 如契约声明 401 E_AUTH + 403 E_PERMISSION_DENIED 两条安全路径，AC 只测正常返回，缺口要到下游 code-review 标 HIGH 或 pre-wiring 审计才暴露

禁止: arch 模块为有序管线（stage 序列）时遗漏某 stage 的承载任务 —— 模块管线含 A→B→C 三 stage 而只为 A、C 建任务卡，B 接线无任务、以空返回满足下游字面 AC，运行时管线在 B 静默断裂；每个 stage 的接线须有任务卡 deliverables 承载

禁止: Sprint 内全部为后端任务而无任何用户可感知的功能交付（Sprint 1 例外），除非项目为纯后端服务

禁止: task-dep-analysis 报环依赖或无法计算拓扑序时仍输出任务计划 —— 环路使 Sprint 排期失真，应返回 blocked 附环路 task_id 链请人工拆环（COMMON-RULES §通用 Error Handling），不静默降级为无序计划

效率策略

先拆后排: 先拆任务再排依赖

context_load精确到章节，避免全文加载