Code Task Generator

Overview

Generate structured code task files from rough descriptions or PDD implementation plans. Auto-detects input type and creates properly formatted

.code-task.md

files. For PDD plans, processes one step at a time to allow learning between steps.

Important Notes

These rules apply across ALL steps:

• User approval required: Present the task breakdown plan and get explicit approval before generating any files.
• Tests are integrated: Include unit test requirements in each task's acceptance criteria. Never create separate "add tests" tasks.
• PDD mode references: Always include the design document path as required reading. Only include research docs if directly relevant to the specific task.

Parameters

• input (required): Task description, file path, or PDD plan path
• step_number (optional, PDD only): Specific step to process. Auto-determines next uncompleted step if omitted.
• output_dir (optional, default:

  specs/{task_name}/tasks/

  ): Output directory for code task files
• task_name (optional, description mode only): Override auto-generated task name

Constraints:

• You MUST ask for all required parameters upfront in a single prompt
• You MUST support input as: direct text, file path, directory path (looks for plan.md), or URL

Steps

1. Detect Input Mode

Check if input is a file with PDD plan structure (checklist + numbered steps). Set mode to "pdd" or "description" and inform the user.

2. Analyze Input

• PDD mode: Parse the plan, extract steps and checklist status, determine target step (from step_number or first uncompleted)
• Description mode: Identify core functionality, technical requirements, complexity level (Low/Medium/High), and technology domain

3. Structure Requirements

• PDD mode: Extract the target step's title, description, demo requirements, constraints, and integration notes with previous steps. Identify relevant research documents.
• Description mode: Identify functional requirements, infer technical constraints and dependencies.

For both modes: create measurable acceptance criteria in Given-When-Then format and prepare a task breakdown plan.

4. Plan Tasks

Present the proposed breakdown to the user:

• One-line summary per task
• Proposed sequence and dependencies
• You MUST NOT generate files until the user explicitly approves

5. Generate Tasks

Create files following the Code Task Format below.

PDD mode specifics:

• Create

  step{NN}/

  folder (zero-padded: step01, step02, step10)
• Name files sequentially:

  task-01-{title}.code-task.md

  ,

  task-02-{title}.code-task.md

• Break down by functional components, not testing phases

All tasks:

• You MUST use the exact Code Task Format structure below
• You MUST include YAML frontmatter with

  status: pending

  ,

  created: YYYY-MM-DD

  ,

  started: null

  ,

  completed: null

• You MUST use kebab-case names with

  .code-task.md

  extension
• You MUST include acceptance criteria covering main functionality and unit tests

6. Report Results

List generated files with paths. For PDD mode, include the step's demo requirements. Suggest running code-assist on tasks in sequence, or using Ralph for autonomous implementation.

7. Offer Ralph Integration

Ask: "Would you like me to set up Ralph to implement these tasks autonomously?"

If yes, create a concise PROMPT.md with objective, spec directory reference, execution order, and acceptance criteria. Suggest the appropriate command:

• Full pipeline:

  ralph run --config presets/pdd-to-code-assist.yml

• Simpler flow:

  ralph run -c ralph.yml -H builtin:code-assist

Code Task Format Specification

Each code task file MUST follow this structure:

---
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]

Examples

Description mode input:

"I need a function that validates email addresses and returns detailed error messages"

Description mode output:

specs/email-validator/tasks/email-validator.code-task.md

— task with acceptance criteria for valid/invalid email handling, error messages, and unit tests.

PDD mode input:

"specs/data-pipeline/plan.md"

PDD mode output:

specs/data-pipeline/tasks/step02/

containing

task-01-create-data-models.code-task.md

,

task-02-implement-validation.code-task.md

,

task-03-add-serialization.code-task.md

— each with design.md reference, acceptance criteria, and demo requirements.

Troubleshooting

Vague description: Ask clarifying questions, suggest common patterns, create a basic task and offer to refine.

Complex description: Suggest breaking into smaller tasks, focus on core functionality first, offer to create related tasks.

Missing technical details: Make reasonable assumptions, include multiple approaches, note areas needing user decisions.

Plan file not found: Check if path is a directory (look for plan.md within), suggest common PDD plan locations.

Invalid plan format: Identify missing sections, suggest running PDD to generate a proper plan, extract what's available.

All steps complete: Inform user, ask if they want a specific step anyway, suggest reviewing for new steps.