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>