Each card describes one complete requirement scope, leaving implementation judgment to the subsequent implementation process. Only organize the rules already present in the requirement materials, user confirmations, and loaded RULEs; do not write experience, conventions, template placeholders, or the current code state into new rules; keep unclear content undecided and do not fill it in on your own.
Process
1. Load project context
Use the loaded CONTEXT terminology and RULEs. If not yet loaded, follow the project knowledge protocol; if knowledge is unavailable, continue and state so truthfully.
2. Gather requirement sources
Use the requirement sources specified by the user; if none are specified, identify materials directly related to this requirement from the current conversation and the repository. Sources can be a PRD, an API list, other requirement documents, screenshots, or the current conversation.
3. Split requirements
First identify from all requirement materials the business outcomes that roles or systems can ultimately perceive, then organize tasks around these outcomes. Document sections, pages, interfaces, data tables, and technical layers are only clues for understanding the requirements and do not directly determine task boundaries.
Put in the same card
Put together content that together forms one business outcome. For example, within the same scenario, queries, operations, state changes, failure feedback, and internal triggers, even if scattered across different sections of the PRD and API list, can be fully handled by one card.
Split into different cards
When content targets different business goals, or when one outcome can still be independently described and accepted without the other, they are usually made into separate cards. Judge by combining roles, trigger scenarios, business states, and final outcomes, rather than by how many files are changed.
The following signs can be used to calibrate boundaries:
- A card needs to describe multiple unrelated trigger scenarios or final outcomes in parallel, and may be split too large.
- A card contains only field, interface, page, or technical-layer changes, and cannot explain business value without other cards, and may be split too finely.
- Multiple cards repeatedly describe the same operation and outcome, only corresponding to different interfaces respectively, and may should be merged.
After splitting is complete, each confirmed requirement should be able to find its place in some card; each card should also be able to independently explain the business outcome to be delivered. Functional rules and acceptance criteria can only come from confirmed requirement sources, and boundary conditions, exception handling, permissions, states, or interface constraints must not be added in pursuit of card completeness.
4. Write task cards
If the user specifies an output directory, use it directly; if a corresponding requirement directory already exists, create under that directory tasks/. Otherwise create docs/scratch/<下一个两位序号>-<中文需求名称>/tasks/。
Task files use NN-<中文任务名称>.md, where NN is from 01 the two-digit task number starting at 0, used only to identify the file and not to indicate dependency or implementation order.
Use the following template:
# <中文任务标题>
## 需求来源
<链接本卡使用的需求材料并指出相关部分；没有文档时简述需求来自当前对话。>
## 本次做什么
<用一段话概括本卡交付的业务结果；有明确处理过程时，继续使用有序列表写清。>
## 功能规则
1. **<规则主题>**：<会影响业务行为、数据口径、状态、权限或接口契约的规则>
<!-- 没有单独功能规则时删除本章节。 -->
## 验收标准
| 场景 | 操作 | 预期结果 |
| --- | --- | --- |
| <主流程或边界场景> | <用户操作或系统触发> | <可观察结果> |