Plan Skill

Plan Skill

Generate development plans with Sprint Contracts, dependency graphs, and task breakdowns.

Prerequisites

• CLAUDE.md should exist (run /forge:setup first if it does not)
• The skill reads CLAUDE.md to understand the stack and project type

Execution Flow

Run these 6 phases in order.

---

Phase 1: Pre-Check

1. Check if CLAUDE.md exists. If not, warn: "No CLAUDE.md found. Run /forge:setup first, or proceed with manual stack info?"
   • If user says proceed, ask for: frontend framework, backend framework, project type
2. Check if plans/ folder exists. If it does:
   • Read plans/README.md to get the current plan version
   • Ask: "Existing plans found (v{N}). Create v{N+1} or replace v{N}?"
3. Read CLAUDE.md to extract: project type, tech stack, existing features

---

Phase 2: Codebase Scan

Scan the codebase to understand what already exists. This determines which features are "done" vs "to build".

Frontend scan:

• app/ or src/app/ — existing pages and routes
• components/ — existing UI components
• hooks/ — custom hooks
• lib/ or utils/ — utility functions
• public/ — static assets

Backend scan:

• Controllers/ — existing API endpoints
• Models/ or Entities/ — data models
• Services/ — business logic
• Migrations/ — database state
• DTOs/ — data transfer objects

Infrastructure scan:

• Auth implementation status
• Database schema state
• CI/CD configuration
• Deployment setup

Build an internal ExistingState object:

{
  pages: ["home", "about", "contact"],
  components: ["Header", "Footer", "Navigation"],
  apiEndpoints: ["/api/auth", "/api/products"],
  models: ["User", "Product"],
  hasAuth: true,
  hasDatabase: true,
  hasCICD: false,
  hasDeployment: false
}

---

Phase 3: Archetype Proposal

1. Load the archetype from ${CLAUDE_PLUGIN_ROOT}/references/archetypes/{projectType}.md
2. Compare the archetype's full feature set against ExistingState
3. Mark features as:
   • DONE — already implemented
   • PARTIAL — started but incomplete
   • TODO — not yet started
4. Present the feature proposal:

## Feature Proposal

Based on your project type (Portfolio) and current state:

| # | Feature | Status | Sprint |
|---|---------|--------|--------|
| 1 | Foundation (layout, nav, theme) | DONE | - |
| 2 | Core Pages (home, about, work) | PARTIAL | Sprint 1 |
| 3 | Content System (Sanity CMS) | TODO | Sprint 2 |
| 4 | i18n (EN/KA) | TODO | Sprint 3 |
| 5 | Polish (animations, SEO, perf) | TODO | Sprint 4 |
| 6 | Launch (deploy, analytics, OG) | TODO | Sprint 5 |

Customize? (add / remove / reorder / proceed)

---

Phase 4: Feature Detailing

For each TODO/PARTIAL feature, generate a detailed breakdown:

1. Tasks — specific implementation tasks (5-15 per feature)
2. Dependencies — which features must be done first
3. Estimated effort — in hours (rough, based on complexity)
4. Acceptance criteria — how to know when it's done
5. Technical notes — implementation hints specific to the detected stack

Present each feature for user confirmation before generating:

## Feature: Content System (Sanity CMS)

**Dependencies:** Foundation (DONE), Core Pages (PARTIAL)
**Estimated effort:** 8-12 hours

### Tasks
1. Initialize Sanity project and configure studio
2. Define schemas (Project, BlogPost, SiteSettings)
3. Set up GROQ queries for each content type
4. Create content components (PortableText renderer, Image pipeline)
5. Connect pages to Sanity data source
6. Set up preview mode for draft content
7. Configure Sanity webhook for ISR/revalidation
8. Seed initial content

### Acceptance Criteria
- All pages render content from Sanity
- Images optimized through Sanity CDN pipeline
- Preview mode works for draft content
- Content editors can manage site from Sanity Studio

Approve? (yes / edit)

---

Phase 5: Generate Plans

Generate the following file structure:

plans/
├── README.md                    — Master plan with version, status table, timeline
└── v{N}/
    ├── DEPENDENCY_GRAPH.md      — ASCII dependency tree showing feature order
    ├── 01-{feature-slug}/
    │   ├── PLAN.md              — Sprint Contract
    │   └── dependencies.md      — Upstream and downstream dependencies
    ├── 02-{feature-slug}/
    │   ├── PLAN.md
    │   └── dependencies.md
    └── ...

README.md — Use template from ${CLAUDE_PLUGIN_ROOT}/templates/plan-md.md:

• Project name and version
• Status table (all features with status)
• Timeline estimate
• Link to dependency graph

DEPENDENCY_GRAPH.md — Use template from ${CLAUDE_PLUGIN_ROOT}/templates/dependency-graph.md:

• ASCII art showing feature dependencies
• Critical path highlighted
• Parallel tracks identified

Sprint Contract (PLAN.md) — Use template from ${CLAUDE_PLUGIN_ROOT}/templates/sprint-contract.md:

• Feature name and description
• Sprint rules (definition of done, testing requirements)
• Task checklist with estimates
• Dependencies (upstream: what must be done first; downstream: what this unlocks)
• Acceptance criteria
• Technical notes

dependencies.md — For each feature:

• Upstream dependencies (features this depends on)
• Downstream dependencies (features that depend on this)
• Shared resources (components, APIs, models used across features)

---

Phase 6: Summary

Print a final summary:

## Plan Generated

- Version: v{N}
- Features: {N} total ({done} done, {partial} partial, {todo} to build)
- Sprints: {N}
- Estimated total effort: {hours} hours
- Critical path: {feature} → {feature} → {feature}

Files created:
  plans/README.md
  plans/v{N}/DEPENDENCY_GRAPH.md
  plans/v{N}/01-{feature}/PLAN.md
  plans/v{N}/01-{feature}/dependencies.md
  ...

Start building with Sprint 1. Each Sprint Contract has a task checklist — work through them in order.

Error Handling

• If CLAUDE.md is missing and user declines manual input, abort with helpful message
• If archetype is "unknown", ask user to pick one before proceeding
• If codebase scan finds zero existing files, treat everything as TODO
• If user removes all features, warn that at least one feature is needed
• Never generate empty plan files — always include at least the template structure