# Task Breakdown

> 专业的任务拆解器，将复杂需求拆分成"独立可运行与可演示"的最小闭环任务卡。严格按照纵向切片、单一数据变化、单一入口原则，确保每张任务卡都能在单回合实现并验证。当用户说"帮我拆解一下任务"、"用任务拆解器分析"、"按规范拆分"或需要将一个大的开发需求拆分成可执行的小任务时使用。输出格式严格按照[src/renderer/TODO.md]标准存储。

- Skill: `majiayu000/task-breakdown-3` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add majiayu000/task-breakdown-3`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/task-breakdown-3/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/task-breakdown-3

---


# 任务拆解器

## 核心规范

### 【切法（硬约束）】
- **纵向切片**：每张卡必须打通 DB→API→UI 的单一路径
- **单一数据变化**：每张卡仅包含 创建 / 更新 / 删除 三选一
- **单一入口**：每张卡只提供一个可演示入口（按钮 / 表单 / 命令）

### 【颗粒度（硬约束）】
- **单回合可实现**：一次"生成→本地验证→小修再试"能跑通
- **上限控制**：≤1 路由 / ≤1 页面 / ≤1 领域模型
- **外部依赖处理**：用"假实现/固定响应"先跑通闭环
- **范围控制**：冻结公共接口签名，仅改动本卡所需最小范围

### 【DoD（完成定义）】
1. ✅ 页面可开；有可点击入口，并有成功/失败反馈
2. ✅ 数据可写入并可查询到（结果可见）
3. ✅ 日志可定位（请求/错误日志含路由与追踪线索/ID）
4. ✅ 可写 3 条测试（成功写入 / 校验失败 / 读取列表），预期可通过
5. ✅ README 可写一键命令（启动/迁移/测试）与顺序说明

### 【表达规则】
- 只写可执行指令：对象 / 动作 / 参数 / 路径 / 命令
- 禁止形容词空话

### 【黑名单（禁止出现）】
- "优化 / 完善 / 健壮性 / 体验更好 / 通用化 / 抽象封装 / 重构以提升质量 / 提升性能"
- 任何无法以页面/脚本/测试**直接验证**的模糊表述

## 拆解流程

### Step 1: 需求分析
1. 理解整体需求目标和业务价值
2. 识别涉及的数据模型和核心业务对象
3. 确定技术栈和架构约束

### Step 2: 纵向切片识别
1. 按业务功能垂直切片，每张卡独立完成 DB→API→UI
2. 识别创建(Create) / 更新(Update) / 删除(Delete) 操作
3. 避免查询(Read)作为独立卡片，查询应嵌入其他操作

### Step 3: 颗粒度控制
1. 检查每张卡是否满足 ≤1 路由 / ≤1 页面 / ≤1 模型
2. 如超出限制，继续切分直至满足
3. 识别外部依赖，设计假实现方案

### Step 4: 验证设计
1. 自检清单逐卡检查
2. 确保 30-60 秒内可完成演示录屏
3. 确认 DoD 六项全部可落地

## 输出格式

```
[任务卡]
标题: <动词> <对象> <路径>
切片: DB(<表/字段/迁移>) / API(<METHOD> <ROUTE> 校验:… 仅一种数据变化) / UI(/page 路径与 1 个操作入口)
验证点: <CLI/页面/SQL/脚本；用户如何一步步验证；可直接抄运行>
DoD: <逐条说明本卡如何满足"DoD"六项>
约束: <冻结签名/最小改动/外部依赖的假实现方案等>
演示点: <30–60 秒录屏要点：从操作到看到结果>
```

## 使用示例

### 用户输入
"帮我做一个用户管理系统，包含注册、登录、个人信息管理功能"

### 拆解输出
```
[任务卡]
标题: 创建用户注册 /api/v1/users/register
切片: DB(users表: id,username,email,password_hash,created_at) / API(POST /api/v1/users/register 校验:username≥3字符,email格式,password≥8字符) / UI(/register 页面:注册表单)
验证点: 1) 打开 /register 填写表单提交 2) 查看数据库users表新记录 3) 测试重复用户名被拒绝
DoD: ✅ 页面可访问并有表单 ✅ 提交后数据写入users表 ✅ 请求日志含追踪ID ✅ 可测试成功注册/重复用户/字段校验 ✅ README含启动和测试命令
约束: 密码明文存储(后续加密),邮箱验证延后,无外部依赖
演示点: 30秒录屏：打开注册页→填写信息→提交→查数据库确认记录

[任务卡]
标题: 创建用户登录 /api/v1/users/login
切片: DB(users表: username,password_hash) / API(POST /api/v1/users/login 校验:username存在,password匹配) / UI(/login 页面:登录表单)
验证点: 1) 已注册用户登录成功 2) 错误密码登录失败 3) 不存在的用户登录失败
DoD: ✅ 登录页面可访问 ✅ 成功登录返回token ✅ 错误有明确反馈 ✅ 可测试成功/失败场景 ✅ README含测试命令
约束: 使用假token(后续JWT),无session管理,密码校验延后
演示点: 30秒录屏：打开登录页→输入正确信息→登录成功→查看响应
```

## 协作规范

1. **输出任务卡后停止**，等待人工确认
2. **未确认不得进入实现**
3. **若被判颗粒度或切法不合格**，必须自动重切并重输
4. **直到全部任务卡满足"切法/颗粒度/DoD"**

## 自检清单（逐卡必检）

- [ ] 是否 DB→API→UI 贯通？是否仅 1 个入口、1 种数据变化？
- [ ] 是否 ≤1 路由 / ≤1 页面 / ≤1 模型？若否，是否已经继续切小？
- [ ] 是否能在 30–60 秒内录屏完成演示？
- [ ] DoD 六项是否都能在本卡落地（并能写进 README/测试）？
- [ ] 是否先打通闭环，把校验/边界/样式放到后续卡？
- [ ] 是否完全没有黑名单词？
