Planning Skill

When to Use This Skill

• Creating PRDs for new features or enhancements
• Generating detailed implementation plans from PRDs
• Breaking down long planning documents (>800 lines) into manageable files
• Setting up progress tracking for multi-phase work
• Optimizing existing plans for better AI agent consumption

Quick Start

Create PRD from Feature Request

# User provides feature description
User: "Create a PRD for advanced filtering on the prompts page"

# Skill generates PRD at:
# docs/project_plans/PRDs/[category]/advanced-filtering-v1.md

Create Implementation Plan from PRD

# Provide PRD path
User: "Create implementation plan for docs/project_plans/PRDs/harden-polish/advanced-filtering-v1.md"

# Skill generates:
# - Main plan: docs/project_plans/implementation_plans/harden-polish/advanced-filtering-v1.md
# - Phase files (if needed): docs/project_plans/implementation_plans/harden-polish/advanced-filtering-v1/phase-[N]-[name].md

Optimize Existing Plan

# Provide existing plan path
User: "Optimize docs/project_plans/implementation_plans/harden-polish/sidebar-polish-v1.md"

# Skill:
# 1. Analyzes plan length (e.g., 1200 lines)
# 2. Breaks into phase-specific files (~400 lines each)
# 3. Updates parent plan with links to phase files

Create Progress Tracking

# Provide PRD or Implementation Plan
User: "Create progress tracking for data-layer-fixes PRD"

# Skill generates:
# .claude/progress/[feature-name]/all-phases-progress.md
# With task breakdown, subagent assignments, completion tracking

Core Workflows

Workflow 1: Create PRD from Feature Request

Input: Feature description or request from user

Process:

1. Analyze Request

   • Extract feature name, scope, goals
   • Identify related systems and components
   • Determine priority and complexity

2. Structure PRD

   • Use template: ./templates/prd-template.md
   • Follow MP architecture patterns (see ./references/mp-architecture.md)
   • Include frontmatter with proper metadata
   • Organize into standard PRD sections

3. Add Implementation Context

   • Break into phased approach
   • Identify architectural layers involved
   • Note dependencies and risks
   • Define success criteria and acceptance tests

4. Determine Location

   • Category: docs/project_plans/PRDs/[category]/
   • Categories: harden-polish, features, enhancements, refactors
   • Naming: [feature-name]-v1.md (kebab-case)

5. Generate File

   • Write PRD to determined location
   • Include YAML frontmatter with metadata
   • Link to related docs (ADRs, guides, etc.)
   • Add to project tracking if needed

Output:

• PRD file at: docs/project_plans/PRDs/[category]/[feature-name]-v1.md
• Follows template structure
• Ready for implementation planning

Example:

Input: "Add real-time collaboration features to prompt editing"

Output Location: docs/project_plans/PRDs/features/realtime-collaboration-v1.md

Sections:
1. Executive Summary - Real-time collaborative editing
2. Context & Background - Current single-user editing limitations
3. Problem Statement - Users can't collaborate on prompts
4. Goals & Success Metrics - Multiple concurrent editors, conflict resolution
5. Requirements - WebSocket connections, operational transforms, presence indicators
6. Implementation Phases - Phase 1: Backend infrastructure, Phase 2: Frontend integration
... (full PRD structure)

Workflow 2: Create Implementation Plan from PRD

Input: Path to existing PRD or newly created PRD

Process:

1. Analyze PRD

   • Read full PRD content
   • Extract key requirements
   • Identify architectural layers needed
   • Determine phase breakdown strategy

2. Plan Phase Structure

   • Follow MP layered architecture: routers → services → repositories → DB
   • Group related tasks into phases
   • Common phases: Database → Repository → Service → API → UI → Testing → Docs → Deployment
   • Consider parallel work opportunities
   • Identify critical path

3. Generate Task Breakdown

   • Use template: ./templates/implementation-plan-template.md
   • Create tasks for each phase
   • Format: Task tables with ID, Name, Description, Acceptance Criteria, Estimate
   • Include quality gates for each phase

4. Assign Subagents

   • Use reference: ./references/subagent-assignments.md
   • Assign based on task type:
     • Database: data-layer-expert
     • Backend API: python-backend-engineer, backend-architect
     • Frontend: ui-engineer-enhanced, frontend-developer
     • UI Components: ui-designer, ui-engineer
     • Testing: appropriate testing agents
     • Docs: documentation-writer, documentation-complex
   • Add to each task: "Assigned Subagent(s): agent-1, agent-2"

5. Optimize for Token Efficiency

   • If total plan >800 lines: break into phase-specific files
   • Pattern: [feature-name]-v1/phase-[N]-[name].md
   • Parent plan links to phase files
   • Each phase file <800 lines
   • See ./references/optimization-patterns.md

6. Generate Files

   • Main plan: docs/project_plans/implementation_plans/[category]/[feature-name]-v1.md
   • Phase files (if needed): docs/project_plans/implementation_plans/[category]/[feature-name]-v1/phase-[N]-[name].md
   • Link phase files from parent plan

Output:

• Implementation Plan at determined location
• Phase breakdown with subagent assignments
• Linked phase files if plan >800 lines
• Quality gates and success criteria per phase

Example:

Input PRD: docs/project_plans/PRDs/features/realtime-collaboration-v1.md

Output:
Main Plan: docs/project_plans/implementation_plans/features/realtime-collaboration-v1.md

Phase Breakdown:
- Phase 1: Database Layer (websocket_sessions, edit_locks tables) - data-layer-expert
- Phase 2: Repository Layer (session management, lock management) - python-backend-engineer
- Phase 3: Service Layer (operational transforms, conflict resolution) - backend-architect
- Phase 4: API Layer (WebSocket endpoints, presence API) - python-backend-engineer
- Phase 5: UI Layer (collaborative editor, presence indicators) - ui-engineer-enhanced, frontend-developer
- Phase 6: Testing (unit, integration, E2E conflict scenarios) - testing agents
- Phase 7: Documentation (API docs, user guides) - documentation-writer
- Phase 8: Deployment (feature flags, monitoring) - DevOps

Phase Files (if plan >800 lines):
- realtime-collaboration-v1/phase-1-database.md
- realtime-collaboration-v1/phase-2-repository.md
- realtime-collaboration-v1/phase-3-5-backend.md (grouped related phases)
- realtime-collaboration-v1/phase-6-8-validation.md (grouped related phases)

Workflow 3: Optimize Existing Plans

Input: Path to existing PRD or Implementation Plan that's >800 lines

Process:

1. Analyze Plan

   • Read full plan
   • Count total lines
   • Identify natural break points (phases, sections)
   • Determine optimal split strategy

2. Determine Breakout Strategy

   • Primary: Break by phase (most common)
   • Secondary: Break by domain (backend vs frontend)
   • Tertiary: Break by task type (implementation vs testing)
   • Goal: Each file <800 lines, logically cohesive

3. Create Breakout Files

   • Pattern: [plan-name]/phase-[N]-[name].md
   • Alternative: [plan-name]/[domain]-tasks.md
   • Each file includes:
     • Phase/section overview
     • Relevant tasks with subagent assignments
     • Quality gates for that section
     • Links back to parent plan

4. Update Parent Plan

   • Add table of contents linking to breakout files
   • Keep executive summary and overview in parent
   • Replace detailed sections with links:

     ## Phase 2: Repository Layer
     See [Phase 2 Implementation Details](./[plan-name]/phase-2-repository.md)
     

   • Maintain quality gates summary in parent

5. Validate Optimization

   • Each file <800 lines ✓
   • All content preserved ✓
   • Links work correctly ✓
   • Logical grouping maintained ✓
   • Progressive disclosure achieved ✓

Output:

• Optimized parent plan (summary + links)
• Breakout files for detailed content
• Improved token efficiency (95%+ reduction in single-load context)

Example:

Input: docs/project_plans/implementation_plans/harden-polish/sidebar-polish-v1.md (1200 lines)

Analysis:
- 8 phases, ~150 lines each
- Can group related phases: 1-3 (backend), 4-5 (frontend), 6-8 (validation)

Output:
Parent: sidebar-polish-v1.md (200 lines - summary + links)
Phase Files:
- sidebar-polish-v1/phase-1-3-backend.md (450 lines)
- sidebar-polish-v1/phase-4-5-frontend.md (400 lines)
- sidebar-polish-v1/phase-6-8-validation.md (350 lines)

Token Efficiency:
- Before: Load 1200 lines for any query
- After: Load 200-line summary, then specific phase (450 max) = 67% reduction

Workflow 4: Create Progress Tracking

Input: PRD or Implementation Plan

Process:

Utilize artifact-tracking skill to create progress tracking and context artifacts per the skill instructions.

You should NOT create these files from this skill, as there are specific optimizations and structures required by the artifact-tracking skill.

Templates Reference

prd-template.md

Location: ./templates/prd-template.md

Based On: /docs/docs-v2/templates/PRD-TEMPLATE.md

Purpose: Standard PRD structure for MeatyPrompts features

Key Sections:

• Feature Brief & Metadata (name, date, author, related docs)
• Executive Summary (1-2 paragraphs)
• Context & Background (problem space, current state)
• Problem Statement (clear gap or pain point)
• Goals & Success Metrics (measurable outcomes)
• Requirements (functional and non-functional)
• Scope (in-scope vs out-of-scope)
• Dependencies & Assumptions
• Risks & Mitigations
• Target State (post-implementation)
• Acceptance Criteria (definition of done)
• Implementation (phased breakdown with tasks)

When to Use: Creating any new PRD

implementation-plan-template.md

Location: ./templates/implementation-plan-template.md

Based On: /claude-export/templates/pm/implementation-plan-template.md

Purpose: Detailed phased implementation with task breakdown

Key Sections:

• Executive Summary (approach, milestones, success criteria)
• Implementation Strategy (architecture sequence, parallel work, critical path)
• Phase Breakdown (8 standard phases with task tables)
• Risk Mitigation (technical and schedule risks)
• Resource Requirements (team composition, skills, infrastructure)
• Success Metrics (delivery, business, technical)
• Communication Plan (status reporting, escalation)
• Post-Implementation Plan (monitoring, maintenance)

When to Use: Creating implementation plan from PRD

phase-breakdown-template.md

Location: ./templates/phase-breakdown-template.md

Purpose: Template for individual phase files when breaking up long plans

Key Sections:

• Phase overview (duration, dependencies, team)
• Task breakdown table (ID, name, description, acceptance criteria, estimate, assignee)
• Subagent assignments
• Quality gates
• Key files and integration points
• Link back to parent plan

When to Use: Breaking long implementation plans into phase-specific files

Scripts Reference

All scripts are in ./scripts/ directory and use Node.js (NOT Python).

generate-prd.sh

Purpose: Generate PRD from feature request

Usage:

./scripts/generate-prd.sh "Feature description" "category"

Process:

1. Parse feature description
2. Determine category and filename
3. Load PRD template
4. Generate PRD content
5. Write to docs/project_plans/PRDs/[category]/[feature-name]-v1.md

Output: PRD file path

generate-impl-plan.sh

Purpose: Generate implementation plan from PRD

Usage:

./scripts/generate-impl-plan.sh "path/to/prd.md"

Process:

1. Read PRD content
2. Extract requirements and phases
3. Generate task breakdown
4. Add subagent assignments
5. Determine if plan needs breakout (>800 lines)
6. Write main plan and phase files

Output: Implementation plan file path(s)

optimize-plan.sh

Purpose: Break long plan into phase-specific files

Usage:

./scripts/optimize-plan.sh "path/to/plan.md"

Process:

1. Read plan and count lines
2. Determine optimal breakout strategy
3. Create phase-specific files
4. Update parent plan with links
5. Validate all content preserved

Output: List of created phase files

References

subagent-assignments.md

Location: ./references/subagent-assignments.md Purpose: Mapping of task types to appropriate subagents Used By: Implementation planning, progress tracking creation

file-structure.md

Location: ./references/file-structure.md Purpose: Directory structure conventions for plans and progress Naming Conventions:

• PRDs: [feature-name]-v1.md (kebab-case)
• Implementation Plans: [feature-name]-v1.md
• Phase Files: phase-[N]-[name].md or phase-[N]-[M]-[name].md (grouped) Used By: File creation, optimization

optimization-patterns.md

Location: ./references/optimization-patterns.md

Purpose: Patterns for breaking up long files into token-efficient chunks

Content:

Pattern 1: Break by Phase (Most Common)

• Split implementation plan by phase (1-3, 4-5, 6-8)
• Each phase file <800 lines
• Parent links to phase files
• Progressive disclosure: Load summary, then specific phase

Pattern 2: Break by Domain

• Backend phases (Database, Repository, Service, API)
• Frontend phases (UI, Components, State)
• Validation phases (Testing, Docs, Deployment)

Pattern 3: Break by Task Type

• Implementation tasks
• Testing tasks
• Documentation tasks
• Deployment tasks

Pattern 4: Keep Together

• Always keep in parent plan:
  • Executive summary
  • Phase overview table
  • Risk mitigation summary
  • Success metrics overview
• Move to phase files:
  • Detailed task breakdowns
  • Specific acceptance criteria
  • Technical implementation notes

Token Efficiency Gains:

• Before: Load entire 1200-line plan
• After: Load 200-line summary + 400-line phase = 50% reduction
• For targeted queries: Load only relevant phase = 67%+ reduction

Used By: Plan optimization workflow

Best Practices

File Size Management

Guideline: No file should exceed ~800 lines

Rationale:

• Optimal token efficiency for AI context loading
• Enables progressive disclosure pattern
• Reduces cognitive load for agents
• Faster file parsing and analysis

Strategies:

1. Break plans by phase when >800 lines
2. Group short related phases (1-3, 4-5)
3. Keep summaries in parent, details in phase files
4. Use links for cross-references

Naming Conventions

PRDs: [feature-name]-v1.md

• Use kebab-case (lowercase with hyphens)
• Include version number (-v1, -v2)
• Descriptive name (e.g., advanced-filtering-v1.md)

Implementation Plans: [feature-name]-v1.md

• Match PRD naming
• Same category as PRD
• Version synchronized with PRD

Phase Files: phase-[N]-[name].md

• Sequential numbering (phase-1, phase-2)
• Can group: phase-1-3-backend.md
• Descriptive name (database, repository, frontend)

Directory Organization

PRDs:

• docs/project_plans/PRDs/[category]/
• Categories: harden-polish, features, enhancements, refactors

Implementation Plans:

• docs/project_plans/implementation_plans/[category]/
• Match PRD category
• Phase breakouts in subdirectory: [plan-name]/

Token Efficiency Tips

Progressive Disclosure:

1. Summary in parent plan (200 lines)
2. Link to detailed phase files (400 lines each)
3. Agent loads summary first, then specific phase as needed
4. 50-67% token reduction

Structured References:

• Link to ADRs instead of duplicating architecture info
• Reference existing docs rather than repeating
• Use relative paths for phase file links

Chunk by Logical Units:

• Keep related tasks together
• Don't split mid-phase
• Group short phases if logical
• Maintain quality gates with phases

YAML Frontmatter

PRDs:

---