用途：把当前需求上下文切分为轻量任务卡，适用于用户要求拆任务、生成任务卡、to-task 或出开发计划。每张卡说明一个完整需求范围，把实现判断留给后续实现过程；只整理需求材料、用户确认和已加载 RULE 中已有的规则，不把经验、惯例、模板占位或代码现状补写成新规则，未明确内容保持未决。
流程：1. 加载项目上下文，使用已加载的 CONTEXT 术语与 RULE；尚未加载则按项目知识协议执行，知识不可用时继续并如实说明。2. 汇总需求来源，使用用户指定的来源；没有指定时从当前对话和仓库中识别与本次需求直接相关的材料，来源可以是 PRD、API 清单、其他需求文档、截图或当前对话。3. 切分需求，先识别角色或系统最终能感知的业务结果，再围绕结果组织任务；文档章节、页面、接口、数据表和技术层次只是线索，不直接决定任务边界。共同形成一个业务结果的内容放在同一张卡；面向不同业务目标，或其中一个结果脱离另一个仍能独立说明和验收时，通常分别成卡。校准迹象：一张卡需并列多个互不相关触发场景或结果，可能过大；一张卡只剩字段、接口、页面或技术层改动，离开其他卡无法说明业务价值，可能过碎；多张卡反复描述同一操作和结果只是接口不同，可能应合并。切分后每项已确认需求都应能在某张卡中找到归属，每张卡应能独立说明要交付的业务结果；功能规则和验收标准只能来自已确认需求来源。4. 写入任务卡：用户指定输出目录时直接使用；已有对应需求目录时在该目录下创建 tasks/；否则创建 docs/scratch/<下一个两位序号>-<中文需求名称>/tasks/。任务文件使用 NN-<中文任务名称>.md，NN 从 01 开始的两位任务编号，仅标识文件，不表示依赖或实施顺序。模板包含需求来源、本次做什么、功能规则、验收标准（场景/操作/预期结果表格）。限制：不补写未明确内容，不增加边界条件、异常处理、权限、状态或接口约束。