name: code-task-generator description: 从描述或PDD实施计划中生成结构化的.code-task.md文件。自动检测输入类型，创建格式正确的任务，并包括Given-When-Then验收标准。 type: anthropic-skill version: “1.1”

代码任务生成器

概述

从粗略描述或PDD实施计划中生成结构化的代码任务文件。自动检测输入类型并创建格式正确的.code-task.md文件。对于PDD计划，一次处理一个步骤，以允许步骤间的学习。

重要注意事项

这些规则适用于所有步骤：

需要用户批准： 在生成任何文件之前，展示任务分解计划并获得明确批准。
测试集成： 在每个任务的验收标准中包含单元测试要求。绝不创建单独的“添加测试”任务。
PDD模式引用： 始终将设计文档路径作为必读内容。仅在直接相关于特定任务时包括研究文档。

参数

input（必需）：任务描述、文件路径或PDD计划路径
step_number（可选，仅PDD模式）：要处理的特定步骤。如果省略，自动确定下一个未完成的步骤。
output_dir（可选，默认：specs/{task_name}/tasks/）：代码任务文件的输出目录
task_name（可选，仅描述模式）：覆盖自动生成的任务名称

约束：

您必须在单个提示中提前询问所有必需参数
您必须支持输入作为：直接文本、文件路径、目录路径（查找plan.md）或URL

步骤

1. 检测输入模式

检查输入是否为具有PDD计划结构（清单+编号步骤）的文件。将模式设置为“pdd”或“description”并通知用户。

2. 分析输入

PDD模式： 解析计划，提取步骤和清单状态，确定目标步骤（从step_number或第一个未完成的步骤）
描述模式： 识别核心功能、技术要求、复杂性级别（低/中/高）和技术领域

3. 结构化要求

PDD模式： 提取目标步骤的标题、描述、演示要求、约束以及与先前步骤的集成说明。识别相关的研究文档。
描述模式： 识别功能要求，推断技术约束和依赖关系。

对于两种模式：创建可测量的Given-When-Then格式的验收标准，并准备任务分解计划。

4. 计划任务

向用户展示提议的分解：

每个任务的一行摘要
提议的顺序和依赖关系
在用户明确批准之前，您绝不能生成文件

5. 生成任务

根据下面的代码任务格式创建文件。

PDD模式特定：

创建step{NN}/文件夹（零填充：step01、step02、step10）
按顺序命名文件：task-01-{title}.code-task.md、task-02-{title}.code-task.md
按功能组件分解，而不是测试阶段

所有任务：

您必须使用下面的确切代码任务格式结构
您必须包括YAML frontmatter，其中status: pending、created: YYYY-MM-DD、started: null、completed: null
您必须使用kebab-case名称和.code-task.md扩展名
您必须包括涵盖主要功能和单元测试的验收标准

6. 报告结果

列出生成的文件及其路径。对于PDD模式，包括步骤的演示要求。建议按顺序运行code-assist任务，或使用Ralph进行自主实现。

7. 提供Ralph集成

询问：“您希望我设置Ralph来自主实现这些任务吗？”

如果用户说：是，创建一个简洁的PROMPT.md，包含目标、规范目录引用、执行顺序和验收标准。建议适当的命令：

完整流水线：ralph run --config presets/pdd-to-code-assist.yml
更简单流程：ralph run --config presets/spec-driven.yml

代码任务格式规范

每个代码任务文件必须遵循此结构：

---
status: pending
created: YYYY-MM-DD
started: null
completed: null
---
# 任务：[任务名称]

## 描述
[需要实现什么以及为什么]

## 背景
[理解任务所需的上下文]

## 参考文档
**必读：**
- 设计：specs/{task_name}/design.md

**附加参考（如果与此任务相关）：**
- [特定研究文档或部分]

**注意：** 在开始实现之前阅读设计文档。

## 技术要求
1. [第一个要求]
2. [第二个要求]

## 依赖关系
- [依赖关系详细信息]

## 实现方法
1. [实现步骤或方法]

## 验收标准

1. **[标准名称]**
   - 给定 [前提条件]
   - 当 [操作]
   - 然后 [预期结果]

## 元数据
- **复杂性：** [低/中/高]
- **标签：** [逗号分隔的标签]
- **所需技能：** [需要的技能]

示例

描述模式输入： "I need a function that validates email addresses and returns detailed error messages"

描述模式输出： specs/email-validator/tasks/email-validator.code-task.md — 包含处理有效/无效电子邮件、错误消息和单元测试的验收标准的任务。

PDD模式输入： "specs/data-pipeline/plan.md"

PDD模式输出： specs/data-pipeline/tasks/step02/ 包含 task-01-create-data-models.code-task.md、task-02-implement-validation.code-task.md、task-03-add-serialization.code-task.md — 每个都有design.md引用、验收标准和演示要求。

故障排除

模糊描述： 询问澄清问题，建议常见模式，创建基本任务并提议优化。

复杂描述： 建议分解为更小的任务，首先专注于核心功能，提议创建相关任务。

缺少技术细节： 做出合理假设，包括多种方法，注明需要用户决策的领域。

计划文件未找到： 检查路径是否为目录（在其中查找plan.md），建议常见的PDD计划位置。

无效的计划格式： 识别缺少的部分，建议运行PDD生成适当的计划，提取可用内容。

所有步骤完成： 通知用户，询问他们是否想要特定步骤，建议检查新步骤。