Skill: Plan and Scope
Purpose
Guide the creation of a structured, phased implementation plan before any code is written.
When to Use
At the start of any new feature, refactor, or project. Always plan before executing.
Process
1. Clarify the Goal
- What is the end-user outcome?
- What are the constraints (time, tech, compatibility)?
- What already exists that we're building on?
- If a PRD exists (
*-prd.md), read it — scope and goals are already defined. Focus on dependencies, risks, and phasing.
- If a UX spec exists (
*-ux-spec.md), read it — reference states, flows, and affordances when defining phase tasks.
2. Define the Scope
- List what IS in scope (be specific)
- List what is NOT in scope (be explicit — this prevents creep)
- Identify assumptions that need validation
3. Map Dependencies
- What existing code/APIs/services does this touch?
- Are there cross-repo dependencies (backend ↔ frontend)?
- What needs to exist before this can start?
- Repo strategy: Will this be a monorepo (single
fullstack profile) or separate repos per concern (e.g., django-api + nextjs)? Ask the user — this affects how /scaffold creates sub-projects and how phases are organized.
4. Identify Risks
- What could go wrong?
- What are we unsure about technically?
- Where might the plan need to change?
5. Produce the Plan Document
Output a plan.md with this structure:
# Plan: [Feature Name]
## Goal
One paragraph describing the desired outcome.
## Scope
### In Scope
- ...
### Out of Scope
- ...
## Phases
Grouping and ordering only. Each phase's internal structure — objective, input,
tasks, output, suggested skills, branch, verification checklist — follows the
`phase-breakdown` skill; don't duplicate those fields here. Tag every phase with
its `[directory/]` and mark parallel groups and sync points.
## Parallel Group A (Phases 1-2)
### Phase 1: [Backend — Name] [server/]
### Phase 2: [Frontend — Name] [web/]
## Sync Point: [e.g., Integration Summary]
## Phase 3: [Name] [directory/]
...
## Repo Strategy
Monorepo / Separate repos: [choice]
Sub-projects: [e.g., api (django-api), web (nextjs)]
## Dependencies
- ...
## Risks & Open Questions
- ...
## Cross-Repo Notes
- Backend contract changes needed: Y/N
- Frontend integration summary required: Y/N
Key Principles
- Plans are living documents — update them as you learn
- Each phase should be independently reviewable (own branch, own PR)
- A plan that's too detailed upfront is as bad as no plan — aim for clarity on WHAT, flexibility on HOW
- Keep phases small — the
phase-breakdown skill owns the sizing rule (target: 1-3 hours of focused execution, reviewable in a single PR). If a phase feels too big, split it.
1---2name: plan-and-scope3description: Creating a structured, phased implementation plan before coding: goals, in/out scope, dependencies, risks. Apply at the start of any new feature, refactor, or project.4---56# Skill: Plan and Scope78## Purpose9Guide the creation of a structured, phased implementation plan before any code is written.1011## When to Use12At the start of any new feature, refactor, or project. Always plan before executing.1314## Process1516### 1. Clarify the Goal17- What is the end-user outcome?18- What are the constraints (time, tech, compatibility)?19- What already exists that we're building on?20- If a PRD exists (`*-prd.md`), read it — scope and goals are already defined. Focus on dependencies, risks, and phasing.21- If a UX spec exists (`*-ux-spec.md`), read it — reference states, flows, and affordances when defining phase tasks.2223### 2. Define the Scope24- List what IS in scope (be specific)25- List what is NOT in scope (be explicit — this prevents creep)26- Identify assumptions that need validation2728### 3. Map Dependencies29- What existing code/APIs/services does this touch?30- Are there cross-repo dependencies (backend ↔ frontend)?31- What needs to exist before this can start?32- **Repo strategy:** Will this be a monorepo (single `fullstack` profile) or separate repos per concern (e.g., `django-api` + `nextjs`)? Ask the user — this affects how `/scaffold` creates sub-projects and how phases are organized.3334### 4. Identify Risks35- What could go wrong?36- What are we unsure about technically?37- Where might the plan need to change?3839### 5. Produce the Plan Document40Output a `plan.md` with this structure:4142```markdown43# Plan: [Feature Name]4445## Goal46One paragraph describing the desired outcome.4748## Scope49### In Scope50- ...5152### Out of Scope53- ...5455## Phases56Grouping and ordering only. Each phase's internal structure — objective, input,57tasks, output, suggested skills, branch, verification checklist — follows the58`phase-breakdown` skill; don't duplicate those fields here. Tag every phase with59its `[directory/]` and mark parallel groups and sync points.6061## Parallel Group A (Phases 1-2)62### Phase 1: [Backend — Name] [server/]63### Phase 2: [Frontend — Name] [web/]6465## Sync Point: [e.g., Integration Summary]6667## Phase 3: [Name] [directory/]68...6970## Repo Strategy71Monorepo / Separate repos: [choice]72Sub-projects: [e.g., api (django-api), web (nextjs)]7374## Dependencies75- ...7677## Risks & Open Questions78- ...7980## Cross-Repo Notes81- Backend contract changes needed: Y/N82- Frontend integration summary required: Y/N83```8485## Key Principles86- Plans are living documents — update them as you learn87- Each phase should be independently reviewable (own branch, own PR)88- A plan that's too detailed upfront is as bad as no plan — aim for clarity on WHAT, flexibility on HOW89- Keep phases small — the `phase-breakdown` skill owns the sizing rule (target: 1-3 hours of focused execution, reviewable in a single PR). If a phase feels too big, split it.
theyoungastronauts