SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场dev-tasks

dev-tasks

编程与开发

查看项目

更新于 10-15 08:13

技能介绍

用途

dev-tasks 用于将系统设计分解为可执行、可追踪的开发任务。其视角为项目经理——关注任务粒度合理性、依赖可行性与交付优先级，而非技术偏好。

触发条件包括：用户已完成系统设计和测试用例；用户要求拆分开发任务；用户需要迭代/Sprint 规划；来自 /feature、/bugfix、/insights 的增量需求。

前置条件（如不存在，建议先运行前置阶段）：

  • 需求文档：docs/devdocs/01-requirements.md
  • 系统设计文档：docs/devdocs/02-system-design.md
  • 测试用例文档：docs/devdocs/03-test-cases.md

主要能力

  • 读取所有前置阶段文档，识别组件，将系统模块映射为任务。
  • 按 TDD 分层对每个任务分类层级（🔴🟡🟢⚪）作为风险输入，并提议初始 review_profile。
  • 定义任务依赖，建立执行顺序，评估任务粒度。
  • 按层级分组生成任务文档，每个任务包含执行步骤参考。
  • 支持增量任务管理（新增、插入、更新依赖与状态）。
  • 支持 design_ref 回填（当 design_context 新增/更新后）。

使用方式

运行模式：

  • /dev-tasks → 标准模式（逐步确认）
  • /dev-tasks --realign[=scope] → 规范升级回扫（任务结构/字段差距补齐；不改任务状态）

快速档（ceremony: fast）：使用合理默认值，仅保留最终写入前的 1 次确认。档位由编排层下传的 ceremony 决定，子 Agent 只读归一化字段。

工作流程：读取文档 → 识别组件 → TDD 分层 → 定义依赖 → 评估范围 → 生成任务文档 → 用户确认 → 可选加载到 TodoWrite。

输出主文件：docs/devdocs/04-dev-tasks.md。当任务数量超过 20 个、文档超过 300 行或涉及多个独立模块时，应拆分文档（如 04-dev-tasks-infra.md、04-dev-tasks-core.md、04-dev-tasks-api.md、04-dev-tasks-test.md）。已完成任务过多时归档到 04-dev-tasks-archive.md。

任务设计原则

每个任务必须满足 TAR 原则：

  • 可测试 (Testable)：可通过自动化或手动测试验证，含测试方法和预期结果。
  • 可验收 (Acceptable)：有明确、可量化的完成标准。
  • 可审查 (Reviewable)：可独立进行代码审查，含 Review 要点。

任务分层与建议初始 review_profile：

  • 🔴 核心逻辑 (Service/Domain)：audit（含高风险信号时）/ guarded，测试先行，完整独立审查。
  • 🟡 接口层 (Controller/API)：guarded，建议测试先行。
  • 🟢 UI 层 (Component/View)：fast / guarded，可实现后补；有跨模块契约时升 guarded。
  • ⚪ 基础设施 (DB/Config)：fast（仅非运行时·非安全）/ audit（schema 迁移/部署），集成测试验证。

review_profile 风险分类器：audit 信号（如不可逆数据变更、安全/认证/权限/密钥、PII/隐私/合规、钱/支付、外部不可逆副作用、共享核心 API、复杂算法、并发/事务、生产配置/部署等）；guarded 信号（如有分支的新行为、公开/对外接口、跨模块契约等）；fast 为默认。命中 ≥2 个 guarded 信号或预估 diff > 150 行/触及 > 5 文件 → 升 audit。不确定时默认 guarded。

约束

阶段边界约束（最高优先级）：

  • 文档阶段不得产出实现代码（源代码、脚本、配置变更）。
  • Bash 工具仅用于只读操作。
  • 生成/更新文档须在顶部写入 generated_by / spec_version / generated_at 三字段 YAML frontmatter。

基础约束：必须指定任务依赖；必须按依赖排序，不能有循环依赖；文件路径必须具体；必须提供依赖关系图；优先级分 P0（阻塞）、P1（重要）、P2（次要）；任务编号格式 T-XX。

需求追溯约束：每个任务必须关联 (F-XXX + AC-XXX) 或 CON-XXX；编码类任务必须关联测试用例 (UT/IT/E2E-XXX)；非编码类任务不强制测试编号，但「测试方法」必须给出可复核的通过/失败判据，并标 TDD 模式 = ⚪ 不适用。

分层约束：任务文档必须按层级分组输出（基础设施→核心逻辑→接口层→UI 层）；每个任务的属性表必须包含 TDD 模式 行和 review_profile 行；测试断言必须引用 AC，禁止从实现代码反推测试。

执行约束：任务执行必须使用 /dev-workflow；禁止跳过 dev-workflow 直接写代码；任务完成后必须执行 /sync。

适用场景

  • 已完成系统设计与测试用例，需要拆分开发任务。
  • 需要迭代/Sprint 规划。
  • 处理来自 /feature、/bugfix、/insights 的增量需求。

限制

  • 不适合执行任务（应使用 /dev-workflow），也不适合设计尚未完成的情况（应使用 /system-design）。
  • 文档阶段不得产出实现代码。
  • 直接写代码而不使用 dev-workflow 会导致追溯矩阵的「变更来源」列不被写入，使 /sync 无法自动追溯，破坏文档↔代码的闭环。
  • 无 design_context 时，设计稿关联字段留空，不阻塞任务生成。

协作 Skill

  • 执行开发任务：/dev-workflow
  • 同步文档状态：/sync
  • 新增功能需求：/feature
  • 修复 Bug：/bugfix

完成后建议使用 /dev-workflow 执行开发任务；文档变更较大时，建议运行 /agent-memory 同步记忆文件。