# To Task

> 将当前需求上下文切分为轻量任务卡。适用于用户要求拆任务、生成任务卡、to-task 或出开发计划。

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

---


# To Task

每张卡说明一个完整需求范围，把实现判断留给后续实现过程。只整理需求材料、用户确认和当前适用 RULE 中已有的规则，不把经验、惯例、模板占位或代码现状补写成新规则；未明确的内容保持未决，不自行补全。

## 流程

### 1. 加载项目上下文

按项目知识协议使用相关 CONTEXT 与适用 RULE；已有知识足够时复用，知识不可用时说明缺口并继续。

### 2. 汇总需求来源

使用用户指定的需求来源；没有指定时，从当前对话和仓库中识别与本次需求直接相关的材料。来源可以是 PRD、API 清单、其他需求文档、截图或当前对话。

### 3. 切分需求

先从全部需求材料中识别角色或系统最终能够感知的业务结果，再围绕这些结果组织任务。文档章节、页面、接口、数据表和技术层次只是理解需求的线索，不直接决定任务边界。

#### 放在同一张卡

共同形成一个业务结果的内容放在一起。例如，同一场景中的查询、操作、状态变化、失败反馈和内部触发，即使分散在 PRD 与 API 清单的不同章节，也可以由一张卡完整承接。

#### 分成不同卡

当内容面向不同业务目标，或其中一个结果脱离另一个仍然能够独立说明和验收时，通常分别成卡。可以结合角色、触发场景、业务状态和最终结果判断，而不是根据改动文件多少判断。

以下迹象可用于校准边界：

- 一张卡需要并列描述多个互不相关的触发场景或最终结果，可能拆得过大。
- 一张卡只剩字段、接口、页面或技术层改动，离开其他卡便无法说明业务价值，可能拆得过碎。
- 多张卡反复描述同一操作和结果，只是分别对应不同接口，可能应当合并。

切分完成后，每项已确认需求都应当能在某张卡中找到归属；每张卡也应当能够独立说明要交付的业务结果。功能规则和验收标准只能来自已确认的需求来源，不为追求卡片完整而增加边界条件、异常处理、权限、状态或接口约束。

### 4. 写入任务卡

用户指定输出目录时直接使用；已有对应需求目录时在该目录下创建 `tasks/`。否则创建 `docs/scratch/<下一个两位序号>-<中文需求名称>/tasks/`。

任务文件使用 `NN-<中文任务名称>.md`，其中 `NN` 是从 `01` 开始的两位任务编号，仅用于标识文件，不表示依赖或实施顺序。

使用以下模板：

```markdown
# <中文任务标题>

## 需求来源

<链接本卡使用的需求材料并指出相关部分；没有文档时简述需求来自当前对话。>

## 本次做什么

<用一段话概括本卡交付的业务结果；有明确处理过程时，继续使用有序列表写清。>

## 功能规则

1. **<规则主题>**：<会影响业务行为、数据口径、状态、权限或接口契约的规则>

<!-- 没有单独功能规则时删除本章节。 -->

## 验收标准

| 场景 | 操作 | 预期结果 |
| --- | --- | --- |
| <主流程或边界场景> | <用户操作或系统触发> | <可观察结果> |
```