---
name: implementation-planning
description: Plan incremental implementation by breaking a plan, spec, PRD, Jira Epic, or Linear project or project milestone into vertical work slices. Use when the user wants to create implementation tasks or break down work into manageable tasks.
---

# Implementation Planning

Break a plan into independently actionable implementation tasks. Tasks are vertical slices of work with incremental value and left in a working and deployable state.

## Workflows

### Creating Tasks

1. **Gather context**
    - Work from existing context
    - Read [integrate-through-review](../principle-integrate-through-review/SKILL.md) and establish the project's completion gate and any explicit delivery exception.
    - If the user passes a github issue: fetch with `gh issue view <number>`
    - if the user references a spec: look up `.specs/<spec-name>/*.md`
    - If the user passes a Jira Epic: use it as the source and create Jira child work items by following [Jira Epic](resources/jira-epic.md)
    - If the user passes a Linear project or project milestone: use it as the source and create Linear issues by following [Linear Project and Milestone](resources/linear-project.md)

2. **Explore the codebase (optional)**
    - If not already in context, explore the codebase to understand the current state of the code

3. **Draft vertical slices**
    - Read [sequence-verifiable-slices](../principle-sequence-verifiable-slices/SKILL.md) for dependency order and [smallest-complete-change](../principle-smallest-complete-change/SKILL.md) for task and review boundaries.
    - Create tasks from thin vertical slices that implements through ALL integration layers end-to-end
    - Each slice delivers a narrow but complete path through every layer (tests, schema, api ,ui etc.) and is verifiable on its own, along with documentation and architecture diagrams.
    - Ensure that important or critical decisions are preserved and captured in ADRs during the task, using the `/decision-capture` skill.
    - For each slice, name its proposed PR boundary, dependency base, and verification recipe using the project's real checks. Identify any smaller passing commit increments within it.

4. **Confirm with the user**:
    - Present the proposed breakdown, for each task include:
        - Short descriptive title
        - User stories covered
        - Blocking relationships with other tasks
        - Proposed PR boundaries, stack order where dependent, and verification recipes
    - Confirm with the user:
        - Are the tasks set to the right granularity (too coarse / too fine). Highlight what could potentially be split / merged
        - Are the dependency links correct
    - Iterate until user approves

5. **Create the tasks**
    - Create the tasks in dependency order (blockers first) so that they can be referenced correctly in the related tasks
    - If the plan came from a github issue:
        - create tasks as github issues using `gh issue create` and reference parent github issue in related tasks
    - If the plan came from a spec in `.specs/<spec-name>/`:
        - create ordered tasks as markdown files in `.specs/<spec-name>/tasks/`
    - If the plan came from a Jira Epic:
        - create child work items by following [Jira Epic](resources/jira-epic.md)
    - If the plan came from a Linear project or project milestone:
        - create issues by following [Linear Project and Milestone](resources/linear-project.md)

## Features

### Task Template

```markdown
## Outcome

A concise description of what will be achieved by completing this task.

## Context

What has brought about this task and why.

### Related Tasks

Provide context of related work or omit section if none.

- Blocked by ... (if any)

## Delivery and Verification

- PR outcome and scope: ...
- Base: default branch, or the parent PR for dependent work.
- Verification: commands or observable checks, expected results, and known gaps.
- Completion gate: the project's agreed state for marking this task Done.

## Acceptance Criteria

Prioritized prefixed list of detailed scenarios, capturing measurable targets, edge cases, and technical or regulation requirements

Each A.C. should be in the format of:

AC# - **Given** <an action>, **when** <in a situation>, **then** <result>

<example>
AC1 - **Given** a registered user, **when** entering a valid username and password, **then** a session should be created.
</example>

## Further Notes

```

## Pitfalls

- Always rollup documentation along side implementation to avoid drift.