Create implementation tasks

Create Implementation Tasks

Outcome

Create a sequenced implementation plan from an existing PRD and technical specification, including:

• One tasks.md index file
• Individual task files (task-001-...md, task-002-...md, ...)

Each task must represent a functional, incremental deliverable and include its own test suite expectations.

When to Use

• User asks to create implementation tasks from an existing PRD and tech spec
• User asks to break down work into sequenced deliverables
• User asks for implementation planning artifacts without writing code

Do Not Use

• Creating PRDs
• Creating technical specifications
• Writing or modifying production code

Required Inputs

• Existing PRD content or path
• Existing tech spec content or path
• Optional constraints: team size, timeline, release boundaries, risk tolerance

Workflow

1) Validate Inputs and Alignment

Confirm both source documents are available and compatible.

Capture:

• PRD requirements (FR-*, NFR-*, goals, scope boundaries)
• Tech spec decisions, interfaces, data impacts, rollout constraints
• Explicit exclusions and open questions

Decision points:

• If PRD is missing, stop and request it.
• If tech spec is missing, stop and request it.
• If PRD and tech spec conflict, list conflicts and request resolution before final tasking.

2) Build Requirement-to-Decision Traceability

Create a planning matrix from requirements to technical decisions.

Include:

• Requirement coverage targets
• Non-functional validation requirements
• Dependencies and blockers

Decision points:

• If any major requirement lacks technical direction, create a prerequisite design-clarification task.
• If a technical decision has no PRD anchor, mark it as candidate scope creep and flag for confirmation.

3) Define Increments and Task Boundaries

Split implementation into functional increments that can be validated independently.

Task boundary rules:

• One task should deliver one meaningful slice of functionality.
• Each task must be testable on its own.
• Prefer vertical slices over layered-only splits when feasible.
• Keep risk-heavy changes isolated with explicit rollback notes.

Decision points:

• If a task is too large to validate safely, split it into smaller tasks.
• If a task depends on external teams/systems, mark it blocked and define unblocking criteria.
• If compliance/security constraints apply, add dedicated verification tasks.

4) Sequence Tasks and Dependencies

Order tasks by dependency and risk to create a practical delivery path.

Sequence rules:

• Place enabling foundations before dependents.
• Prioritize high-risk assumptions early.
• Include integration and hardening tasks before release readiness.
• Ensure each task has a clear predecessor set.

5) Draft Planning Outputs

1. Locate the project tasks directory using this priority:
   • Existing tasks/
   • Existing project-tasks/
   • Existing docs/tasks/
   • Existing .github/tasks/
   • If none exist, create tasks/
2. Create a feature planning folder:
   • <tasks-root>/implementation-<feature-slug>/
3. Create index file:
   • <tasks-root>/implementation-<feature-slug>/tasks.md
   • Use Tasks index template
4. Create individual task files:
   • <tasks-root>/implementation-<feature-slug>/task-001-<slug>.md
   • <tasks-root>/implementation-<feature-slug>/task-002-<slug>.md
   • Use Task template

Drafting rules:

• Keep language implementation-planning focused.
• Do not include code snippets or patch instructions.
• Include explicit test suite expectations per task.

6) Quality Check Before Finalizing

Completion checks:

• Every major FR-* and NFR-* is mapped to one or more tasks.
• Every task has:
  • clear objective
  • explicit dependencies
  • acceptance criteria
  • its own test suite section
  • definition of done
• Sequencing is dependency-correct and risk-aware.
• No tasks are outside confirmed scope.
• Open questions and blockers are explicit.

7) Return Result

Provide:

• Path to generated tasks.md
• List of generated task files
• Coverage summary (FR/NFR -> task IDs)
• Blocking open questions

Output Contract

The output must be a task planning bundle under one feature folder containing tasks.md plus individual task-###-<slug>.md files, with full PRD and tech spec traceability.