---
description: "Guide for creating detailed task lists from PRDs and tech specs, including complexity analysis and phased generation workflow"
globs:
alwaysApply: false
---
# Rule: Generating a Task List from a PRD

<goal>
To guide an AI assistant in creating a detailed, step-by-step task list in Markdown format based on an existing Product Requirements Document (PRD `.md`) and its corresponding Technical Specification document (tech spec `.md`). The task list should guide a developer through implementation following both functional requirements and architectural decisions.
</goal>

<source_of_truth_policy>
**SINGLE SOURCE OF TRUTH: Taskmaster JSON**
- `tasks.json` (generated by taskmaster) is the authoritative task store
- `_tasks.md` and individual `<num>_task.md` files are **generated views** from the JSON
- All task status updates, modifications, and tracking must be done through taskmaster MCP tools
- Markdown files are for human readability and should be regenerated when JSON changes
- Never manually edit Markdown task files - use taskmaster commands for all task operations
</source_of_truth_policy>

<output_specification>
- **Format:** Markdown (`.md`)
- **Locations:**
  - **Feature folder:** `/tasks/prd-[feature-slug]/`
  - **Tasks summary file:** `/tasks/prd-[feature-slug]/_tasks.md` (generated from JSON)
  - **Individual task files:** `/tasks/prd-[feature-slug]/<num>_task.md` (generated from JSON)
  - **Authoritative source:** `/tasks/prd-[feature-slug]/tasks.json` (taskmaster managed)
  - **Complexity report:** `/tasks/prd-[feature-slug]/task-complexity-report.json`
  - **Merged file:** `/tasks/prd-[feature-slug]/merged_prd_techspec.md`
</output_specification>

## Process

<process_steps>
1.  **Receive PRD Reference:** The user points the AI to a specific PRD file
2.  **Verify Tech Spec:** Confirm that a corresponding tech spec document exists (`tasks/prd-[feature-slug]/_techspec.md`). If not, remind the user to create it using [prd-tech-spec.mdc](mdc:.cursor/rules/prd-tech-spec.mdc) before proceeding with task generation.
3.  **Generate Merged File:** Run `mf ./tasks/prd-[feature-slug]` to generate a merged file containing the PRD + techspec (`merged_prd_techspec.md`)
4.  **Create Taskmaster Tag:** Using the taskmaster MCP, create a tag for this feature implementation
5.  **Generate Taskmaster Tasks:** Use taskmaster's parse-prd functionality with the merged file to generate the initial task structure (`tasks.json`)
6.  **Generate Complexity Report:** Use taskmaster to analyze task complexity and generate the complexity report (`task-complexity-report.json`)
7.  **Generate Tasks Summary:** Based on the taskmaster output and complexity analysis, create the `_tasks.md` file following the established format
8.  **Parallel Agent Analysis:** ⚠️**MUST**: For each task under the prd-[slug], <critical>spin up parallel agents</critical> to provide a final analysis. Check based on the current architecture and files if we are duplicating stuff or forgetting something - a general analysis using our current architecture as review before starting the tasks
9.  **Wait for Confirmation:** Present the analysis results to the user and inform them: "I have completed the task generation and architectural analysis. Ready to proceed with implementation? Respond with 'Go' to start."
10. **Generate Individual Task Files:** Create separate files for each parent task in `/tasks/prd-[feature-slug]/<num>_task.md`
</process_steps>

<taskmaster_integration>
**Taskmaster Workflow:**
1. **Tag Creation:** Create a new tag using taskmaster MCP for the feature (e.g., `memory-system-v1`)
2. **Parse PRD:** Use `parse-prd` with the merged file to generate initial task structure
3. **Complexity Analysis:** Generate complexity report to identify tasks requiring subdivision
4. **Task Export:** Export tasks in the required format for integration with existing workflow

**Key Commands:**
- `mf ./tasks/prd-[feature-slug]` - Generate merged PRD + techspec file
- Taskmaster tag creation for feature isolation
- `parse-prd=<merged_file>` - Generate initial task structure
- Complexity analysis for task breakdown recommendations
</taskmaster_integration>

<parallel_analysis_requirements>
**Critical Parallel Agent Analysis:**
For each task identified in the prd-[slug], you MUST spin up parallel agents to conduct:

1. **Architecture Duplication Check:** Identify if the task duplicates existing functionality
2. **Missing Component Analysis:** Check if the task overlooks existing architectural patterns
3. **Integration Point Validation:** Verify the task properly integrates with current systems
4. **Dependency Analysis:** Ensure all required dependencies are identified and accounted for
5. **Standards Compliance:** Verify the task follows established project patterns and standards

**Analysis Output:** Each parallel agent should provide:
- Duplication risks and recommendations
- Missing components or integration points
- Architectural alignment assessment
- Dependency validation results
- Standards compliance verification
</parallel_analysis_requirements>

## Output Format

### Tasks Summary File Format
<tasks_summary_format>
The tasks summary file (`_tasks.md`) serves as the central index for the feature implementation, containing the relevant files and parent task checklist. This file should be generated AFTER the taskmaster analysis and parallel agent review.
</tasks_summary_format>

### Individual Task File Format
<individual_task_format>
Each individual task file (`<num>_task.md`) must follow this structure:

```markdown
---
status: pending  # Options: pending, in-progress, completed, excluded
---

<task_context>
<domain>engine/infra/[subdomain]</domain>
<type>implementation|integration|testing|documentation</type>
<scope>core_feature|middleware|configuration|performance</scope>
<complexity>low|medium|high</complexity>
<dependencies>external_apis|database|temporal|http_server</dependencies>
</task_context>

# Task X.0: [Parent Task Title]

## Overview
[Brief description of what this task accomplishes]

<critical>
**MANDATORY REQUIREMENTS:**
- **ALWAYS** check dependent files APIs before write tests to avoid write wrong code
- **ALWAYS** verify against PRD and tech specs - NEVER make assumptions
- **NEVER** use workarounds, especially in tests - implement proper solutions
- **MUST** follow all established project standards:
    - Architecture patterns: `.cursor/rules/architecture.mdc`
    - Go coding standards: `.cursor/rules/go-coding-standards.mdc`
    - Testing requirements: `.cursor/rules/testing-standards.mdc`
    - API standards: `.cursor/rules/api-standards.mdc`
    - Security & quality: `.cursor/rules/quality-security.mdc`
- **MUST** run `make lint` and `make test` before completing ANY subtask
- **MUST** follow `.cursor/rules/task-review.mdc` workflow for parent tasks
**Enforcement:** Violating these standards results in immediate task rejection.
</critical>

## Subtasks

- [ ] X.1 [Subtask description]
- [ ] X.2 [Subtask description]
- [ ] X.3 [Subtask description]

## Implementation Details

[Extract relevant sections from the tech spec that apply to this task]

### Relevant Files

> List of relevant files that this task will touch

### Dependent Files

> List of dependencies that this task will need to handle

## Success Criteria
- [Clear definition of when this task is complete]
- [Measurable outcomes]
- [Quality requirements]
- [Components impacted by this task per Tech Spec Impact Analysis]
```
</individual_task_format>

### Tasks File Format
<tasks_file_format>
The tasks file (`_tasks.md`) must follow this structure and be generated AFTER taskmaster analysis:

```markdown
# [Feature] Implementation Task Summary

## Relevant Files

### Core Implementation Files
- `path/to/file.go` - Description
- `path/to/file_test.go` - Tests

### Integration Points
- `path/to/integration.go` - Description

### Documentation Files
- `docs/feature.md` - User documentation

### Notes

- Unit tests should be placed alongside the implementation files (e.g., `monitoring.go` and `monitoring_test.go` in the same directory)
- Use `go test ./...` to run all tests or `go test -v ./path/to/package` for specific package tests
- Always run `make fmt && make lint && make test` before committing changes
- Follow project testing standards with `t.Run("Should...")` pattern

## Tasks

- [ ] 1.0 Parent Task Title
- [ ] 2.0 Parent Task Title
- [ ] 3.0 Parent Task Title
```
</tasks_file_format>

## Interaction Model

<interaction_model>
**Workflow with Clear Source of Truth Management:**

1. **After Merged File Generation**: Verify the merged file contains both PRD and techspec content
2. **After Taskmaster Analysis**: Review the generated tasks.json (authoritative) and complexity report
3. **After Parallel Agent Analysis**: Review architectural analysis results from all parallel agents
4. **Generate Markdown Views**: Create `_tasks.md` and individual task files from the authoritative JSON
5. **Before Implementation**: Get user confirmation ("Go") after presenting complete analysis

**Critical Workflow Notes:**
- All task modifications use taskmaster MCP tools (never edit Markdown directly)
- Markdown files are regenerated whenever JSON changes
- Task status tracking happens through taskmaster commands
- Individual task files are created from JSON for development reference
</interaction_model>

<target_audience>
Assume the primary reader of the task list is a **junior developer** who will implement the feature, supported by the architectural analysis from parallel agents.
</target_audience>

**Tag Creation Policy:**
- **Automatic Tag Creation**: For features with >5 parent tasks or high complexity score (>7), create a tag automatically
- **Suggested Tag Creation**: For smaller features (≤5 tasks, complexity ≤7), suggest tag creation to user but don't force
- **Tag Naming**: Use format `[feature-slug]-v1` for consistency
- **Integration**: Tags isolate feature work and enable focused development cycles