名称： code-task-generator
描述： 根据描述或PDD实施计划生成结构化的.code-task.md文件。自动检测输入类型，创建格式正确的任务文件，包含Given-When-Then验收标准。
type: anthropic-skill
版本： "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前置元数据，其中包含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.  **[标准名称]**
    *   给定 [前置条件]
    *   当 [执行操作]
    *   那么 [预期结果]

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

示例

描述模式输入： "我需要一个验证电子邮件地址并返回详细错误信息的函数"

描述模式输出： 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以生成正确的计划，提取可用的内容。

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