code-task-generator

コードタスクジェネレーター

概要

大まかな説明やPDD実装計画から、構造化されたコードタスクファイルを生成します。入力の種類を自動検出し、適切にフォーマットされた .code-task.md ファイルを作成します。PDD計画の場合は、各ステップの間に学びを反映できるよう、一度に1つのステップを処理します。

重要な注意事項

以下のルールはすべてのステップに適用されます。

• ユーザーの承認が必要です： タスクの分解計画を提示し、ファイルを生成する前に明示的な承認を得てください。
• テストは統合します： 各タスクの受け入れ基準に単体テストの要件を含めてください。「テストを追加する」だけのタスクは作成しないでください。
• PDD モードでの参照： 設計ドキュメントのパスを必読資料として必ず含めてください。調査ドキュメントは、そのタスクに直接関係する場合にのみ含めてください。

パラメーター

• input（必須）：タスクの説明、ファイルパス、またはPDD計画のパス
• step_number（任意、PDDのみ）：処理する特定のステップ。省略された場合は、未完了の次のステップを自動的に特定します。
• output_dir（任意、既定値：specs/{task_name}/tasks/）：コードタスクファイルの出力ディレクトリ
• task_name（任意、説明モードのみ）：自動生成されるタスク名を上書きします。

制約：

• 必須パラメーターはすべて、1回のプロンプトで最初に確認する必要があります。
• 次の形式の入力に対応する必要があります：直接入力テキスト、ファイルパス、ディレクトリパス（plan.mdを検索）、またはURL

手順

1. 入力モードを検出する

入力がPDD計画の構造（チェックリスト＋番号付きステップ）を持つファイルかどうかを確認します。モードを「pdd」または「description」に設定し、ユーザーに通知します。

2. 入力を分析する

• PDDモード： 計画を解析し、ステップとチェックリストの状態を抽出して、対象ステップ（step_numberで指定されたもの、または最初の未完了ステップ）を特定します。
• 説明モード： 中核となる機能、技術要件、複雑さのレベル（低／中／高）、技術領域を特定します。

3. 要件を整理する

• PDDモード： 対象ステップのタイトル、説明、デモ要件、制約、前のステップとの統合に関する注記を抽出します。関連する調査ドキュメントを特定します。
• 説明モード： 機能要件を特定し、技術的制約と依存関係を推定します。

どちらのモードでも、Given-When-Then形式の測定可能な受け入れ基準を作成し、タスク分解計画を用意します。

4. タスクを計画する

提案する分解内容をユーザーに提示します。

• タスクごとの1行の概要
• 提案する実行順序と依存関係
• ユーザーが明示的に承認するまで、ファイルを生成してはなりません。

5. タスクを生成する

以下のコードタスク形式に従ってファイルを作成します。

PDDモード固有の要件：

• step{NN}/ フォルダーを作成します（ゼロ埋め：step01、step02、step10）。
• ファイル名は連番にします：task-01-{title}.code-task.md、task-02-{title}.code-task.md
• テスト工程ではなく、機能コンポーネントごとに分解します。

すべてのタスク：

• 以下のコードタスク形式を正確に使用する必要があります。
• status: pending、created: YYYY-MM-DD、started: null、completed: null を含むYAMLフロントマターを必ず記述します。
• .code-task.md 拡張子を使用し、kebab-caseの名前にする必要があります。
• 主な機能と単体テストを網羅する受け入れ基準を必ず含めてください。

6. 結果を報告する

生成したファイルをパスとともに一覧表示します。PDDモードでは、ステップのデモ要件も含めてください。タスクを順番に code-assist で実行するか、自律的な実装に Ralph を使うことを提案します。

7. Ralphとの連携を提案する

次のように尋ねます：「これらのタスクを自律的に実装するようにRalphを設定しますか？」

はいの場合は、目的、specディレクトリへの参照、実行順序、受け入れ基準を含む簡潔な PROMPT.md を作成します。適切なコマンドを提案します。

• フルパイプライン：ralph run --config presets/pdd-to-code-assist.yml
• シンプルなフロー：ralph run -c ralph.yml -H builtin:code-assist

コードタスク形式の仕様

各コードタスクファイルは、必ず次の構造に従ってください。

---
status: pending
created: YYYY-MM-DD
started: null
completed: null
---
# Task: [Task Name]

## Description
[What needs to be implemented and why]

## Background
[Context needed to understand the task]

## Reference Documentation
**Required:**
- Design: specs/{task_name}/design.md

**Additional References (if relevant to this task):**
- [Specific research document or section]

**Note:** Read the design document before beginning implementation.

## Technical Requirements
1. [First requirement]
2. [Second requirement]

## Dependencies
- [Dependency with details]

## Implementation Approach
1. [Implementation step or approach]

## Acceptance Criteria

1. **[Criterion Name]**
   - Given [precondition]
   - When [action]
   - Then [expected result]

## Metadata
- **Complexity**: [Low/Medium/High]
- **Labels**: [Comma-separated labels]
- **Required Skills**: [Skills needed]

例

説明モードの入力： "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 の実行を提案し、利用可能な内容を抽出します。

すべてのステップが完了している場合： ユーザーにその旨を伝え、特定のステップが必要か尋ね、新しいステップがないか確認するよう提案します。