返回 Skill 列表
extension
分类: 开发与工程无需 API Key

tasks-generator

根据项目规范生成结构化的任务路线图。当用户要求基于产品需求文档(PRD)、技术规范或UI/UX规范创建任务、冲刺计划、路线图或工作分解时使用。触发条件包括诸如“从PRD生成任务”、“创建冲刺计划”、“将此规范分解为任务”、“创建路线图”或“规划实施”等请求。

person作者: jakexiaohubgithub

Tasks Generator

Generate structured, actionable task roadmaps from project specifications (PRD, Tech Specs, UI/UX Specs).

Workflow

  1. Gather inputs - Locate and read PRD, Tech Specs, and UI/UX specs
  2. Analyze specifications - Extract features, requirements, and dependencies
  3. Generate task breakdown - Create hierarchical tasks organized by phase/sprint
  4. Apply template - Format output using assets/tasks-template.md
  5. Review dependencies - Validate task sequencing and parallel opportunities

Input Requirements

Locate specification documents in these common paths:

  • PRD: .claude/docs/specs/prd.md or docs/prd.md
  • Tech Specs: .claude/docs/specs/tech-specs.md or docs/tech-specs.md
  • UI/UX: .claude/docs/specs/ui-ux.md or docs/ui-ux.md

If documents are missing, prompt user for their locations.

Task Generation Process

Step 1: Extract from PRD

Parse the PRD for:

  • Core features and user stories → become sprint goals
  • MVP requirements → Phase 1/2 priority tasks
  • Non-functional requirements → infrastructure/foundation tasks
  • Success metrics → verification criteria

Step 2: Extract from Tech Specs

Parse Tech Specs for:

  • Architecture decisions → foundation phase setup tasks
  • Data models/schemas → type definition tasks (SPRINT-002)
  • API contracts → integration tasks
  • Technology stack → environment setup tasks (SPRINT-001)
  • Performance requirements → optimization tasks

Step 3: Extract from UI/UX Specs

Parse UI/UX for:

  • Component specifications → UI development tasks
  • User flows → feature integration tasks
  • Design system requirements → styling/theming tasks
  • Accessibility requirements → QA tasks

Step 4: Organize into Phases

Phase 1: Foundation (Always required)

  • SPRINT-001: Environment Setup - tooling, dependencies, project structure
  • SPRINT-002: Define Contracts/Types - interfaces, schemas, validation

Phase 2: Build (Feature development)

  • Group related features into sprints
  • Order by dependency chain
  • Mark parallel tasks with [P]

Phase 3: Deployment

  • CI/CD pipeline setup
  • Environment configuration
  • Monitoring and observability

Task ID Convention

Use sequential numbering: T001, T002, T003...

Alternative: Decade-based per sprint: SPRINT-001: T001-T009, SPRINT-002: T010-T019

Choose one approach consistently.

Parallel Task Rules

Mark tasks with [P] when:

  • Task has NO dependencies on other tasks in same sprint
  • Task can start immediately when sprint begins
  • Multiple [P] tasks can run simultaneously

Example:

- T001 [P]: Initialize project structure
- T002 [P]: Configure linting
- T003: Install dependencies (depends on T001)

Acceptance Criteria Guidelines

Each sprint must include:

  1. Acceptance Criteria - Checklist of completion requirements
  2. Verification - Concrete steps to validate completion

Pattern:

**Acceptance Criteria:**
- [ ] [Specific measurable outcome]
- [ ] [Tests pass / coverage requirement]
- [ ] [Integration verified]

**Verification:**
- Run [specific command] and confirm [expected result]
- Demo [specific feature] to verify [behavior]

Output Format

Use the template at assets/tasks-template.md for consistent formatting.

Key sections:

  • Overview with project metadata
  • Roadmap organized by Phase → Sprint → Tasks
  • Dependencies and Execution Order
  • Parallel Opportunities
  • Risks & Blockers

Task Estimation Heuristics

When specs don't provide estimates:

  • Type definitions: 1-2 tasks per domain
  • API endpoints: 1 task per endpoint + integration
  • UI components: 1 task per major component
  • Environment setup: 3-5 tasks standard
  • Testing: ~30% of implementation tasks

References

  • For detailed task analysis patterns: see references/task-analysis.md
  • For output template: see assets/tasks-template.md