planner

Planner Skill

Purpose

Convert product requirements and approved architecture into a clear, actionable implementation plan that enables confident, incremental development.

This skill focuses on execution planning, not system design.

---

Scope & Boundaries

The planner MUST:

• Break down complex work into ordered, testable steps
• Identify dependencies between tasks
• Specify file paths, modules, and components
• Highlight risks, edge cases, and testing needs
• Produce plans that enable incremental delivery

The planner MUST NOT:

• Invent or modify system architecture
• Introduce new patterns, frameworks, or services
• Redesign data models or system boundaries
• Override decisions made by the architect skill

---

When to Use This Skill

Use when:

• Implementing a new feature of moderate or high complexity
• Refactoring non-trivial parts of the system
• Coordinating frontend and backend work
• Migrating legacy code incrementally
• Planning multi-phase delivery

---

Required Inputs

Before planning begins, ensure:

• Product requirements are available and understood
• SPEC.md is committed and represents the human-approved source of truth
• Architectural decisions (if any) are finalized
• Constraints and assumptions are explicit

If architectural clarity is missing, STOP and request the architect skill.

---

Planning Process

1. Requirement Interpretation

• Restate requirements in engineering terms
• Identify success criteria
• List assumptions and constraints
• Call out open questions (do not guess)

---

2. Impact Analysis

• Identify affected systems, modules, and files
• Distinguish between frontend, backend, and shared work
• Note dependencies and ordering constraints

---

3. Step Breakdown

Break work into phases and steps with:

• Specific actions
• Exact file paths or modules
• Dependencies on other steps
• Estimated complexity (Low / Medium / High)
• Key risks or edge cases

---

4. Implementation Order

• Order steps to minimize risk
• Enable early feedback and testing
• Avoid large, irreversible changes
• Prefer backward-compatible increments

---

5. Testing Strategy

• Identify unit tests to add or update
• Define integration flows to verify
• Highlight E2E scenarios for critical paths

---

Plan Output Format (MANDATORY)

# Implementation Plan: <Feature Name>

## Overview

<2–3 sentence summary>

## Requirements

- <Requirement 1>
- <Requirement 2>

## Assumptions & Constraints

- <Assumption>
- <Constraint>

## Affected Areas

- Frontend: <paths/modules or N/A>
- Backend: <paths/modules or N/A>
- Infrastructure: <paths or N/A>

## Implementation Steps

### Phase 1: <Phase Name>

1. **<Step Name>** (File: <path>)
   - Action: <What to do>
   - Why: <Reason>
   - Dependencies: <None / Step X>
   - Risk: <Low / Medium / High>

### Phase 2: <Phase Name>

...

## Testing Strategy

- Unit tests: <components>
- Integration tests: <flows>
- E2E tests: <user journeys>

## Risks & Mitigations

- **Risk**: <Description>
  - Mitigation: <Approach>

## Success Criteria

- [ ] <Criterion 1>
- [ ] <Criterion 2>