home / skills / adaptationio / skrillz / planning-architect

planning-architect skill

/skills/planning-architect

npx playbooks add skill adaptationio/skrillz --skill planning-architect

Review the files below or copy the command above to add this skill to your agents.

Files (8)
SKILL.md
35.3 KB
---
name: planning-architect
description: Comprehensive skill development planning. Analyzes requirements, chooses organizational patterns (workflow/task/reference/capabilities), defines structure, estimates complexity, identifies dependencies, and creates detailed implementation plan. Use when planning new skills, converting documentation to skills, or architecting complex skill systems.
allowed-tools: Read, Write, Edit, Glob, Grep, Bash, WebSearch, WebFetch
---

# Planning Architect

## Overview

planning-architect systematically plans Claude Code skill development from initial concept to detailed implementation blueprint. It guides you through six sequential steps to create comprehensive skill plans that ensure successful development.

**Purpose**: Transform skill ideas into actionable implementation plans with clear structure, accurate estimates, and identified dependencies.

**Value**: Prevents rework, reduces development time, ensures consistency, and produces better-designed skills through systematic planning.

**When to Use**:
- Planning new skills from scratch
- Converting existing documentation into skills
- Architecting complex multi-file skills
- Planning skill improvements or refactoring
- Coordinating dependent skill development

## Prerequisites

Before planning a skill, gather:

1. **Problem Definition**: Clear understanding of what problem the skill solves
2. **Domain Knowledge**: Familiarity with the domain being captured
3. **User Context**: Understanding of who will use the skill and how
4. **Existing Resources**: Any documentation, examples, or patterns to reference
5. **Skill-Builder Context**: Familiarity with skill-builder-generic patterns

## Planning Workflow

### Step 1: Analyze Requirements

**Objective**: Clearly define what the skill must accomplish and its scope

**Process**:

1. **Define the Problem**
   - What specific problem does this skill solve?
   - What pain point does it address?
   - What would happen without this skill?

2. **Identify Target Users**
   - Who will use this skill? (You, team, community)
   - What is their expertise level?
   - What context will they invoke it in?

3. **Capture Domain Knowledge**
   - What domain expertise must be captured?
   - What workflows need documentation?
   - What best practices should be included?
   - What anti-patterns should be avoided?

4. **Determine Scope**
   - What is explicitly in scope?
   - What is explicitly out of scope?
   - What are the boundaries?
   - What is the minimum viable skill?

5. **Identify Existing Resources**
   - Are there similar skills to reference?
   - Is there existing documentation to convert?
   - Are there community patterns to follow?
   - Are there anti-patterns to avoid?

**Questions to Answer**:

```
Problem Definition:
- What problem does this skill solve?
- Who experiences this problem?
- How do they currently solve it (if at all)?
- What would success look like?

Scope:
- What is the primary objective?
- What are secondary objectives?
- What is explicitly out of scope?
- What is the minimum viable version?

Users:
- Who will use this skill?
- What is their expertise level?
- What context will they invoke it in?
- What other skills do they likely have?

Domain:
- What domain knowledge is required?
- What workflows exist in this domain?
- What terminology is standard?
- What are common pitfalls?

Resources:
- Are there similar skills to study?
- Is there documentation to convert?
- Are there examples to follow?
- What research is needed?
```

**Output**: Requirements document answering all questions above

**Example**:
```
Problem: Developers waste time debugging Railway deployments
Users: Development team with Node.js experience
Domain: Railway deployment, Docker, environment config
Scope: Railway-specific deployment workflow for Node.js + React
Out of Scope: Other platforms (Vercel, AWS), other languages
Resources: Railway docs, existing deployment notes
MVP: Basic deployment workflow with common troubleshooting
```

**See Also**: [references/pattern-selection-guide.md](references/pattern-selection-guide.md) includes requirements analysis templates

---

### Step 2: Select Organizational Pattern

**Objective**: Choose the optimal organizational pattern for this skill

**The 4 Organizational Patterns**:

#### Pattern 1: Workflow-Based
**Use When**: Sequential processes with clear steps where order matters

**Characteristics**:
- Linear progression (Step 1 → Step 2 → Step 3)
- Each step builds on previous steps
- Clear start and end points
- Dependencies between steps

**Examples**:
- Deployment workflows
- API integration processes
- Testing workflows
- Setup/configuration sequences

**Structure**:
```markdown
## Workflow
### Step 1: [Action]
### Step 2: [Action]
### Step 3: [Action]
```

**Choose This When**:
- Process has clear sequential steps
- Order of operations matters
- Steps have dependencies
- There's a defined goal at the end

---

#### Pattern 2: Task-Based
**Use When**: Independent operations without order dependency

**Characteristics**:
- Tasks can be performed in any order
- No dependencies between tasks
- Quick reference format
- Each task is self-contained

**Examples**:
- Troubleshooting guides
- Utility collections
- Command references
- Independent operations

**Structure**:
```markdown
## Tasks
### Task A: [Action]
### Task B: [Action]
### Task C: [Action]
```

**Choose This When**:
- Operations are independent
- Order doesn't matter
- Users will perform subset of tasks
- Quick lookup is primary use case

---

#### Pattern 3: Reference/Guidelines
**Use When**: Standards, patterns, design systems, best practices

**Characteristics**:
- Reference material (look-up)
- Guidelines and standards
- Comprehensive coverage
- Examples and specifications

**Examples**:
- Design systems
- Coding standards
- API documentation
- Style guides

**Structure**:
```markdown
## Guidelines
### Guideline 1: [Concept]
### Guideline 2: [Concept]

## Reference
### Component A
### Component B
```

**Choose This When**:
- Documenting standards or patterns
- Creating reference material
- Establishing guidelines
- Comprehensive coverage needed

---

#### Pattern 4: Capabilities-Based
**Use When**: Integrated feature suites with multiple entry points

**Characteristics**:
- Multiple interconnected features
- Various entry points
- Features work together
- Complex integrations

**Examples**:
- Complex systems
- Platforms with multiple features
- Toolkits with related capabilities

**Structure**:
```markdown
## Capabilities
### Capability A: [Feature]
### Capability B: [Feature]

## Integration
How capabilities work together
```

**Choose This When**:
- Multiple related features
- Features can be used independently or together
- Multiple valid starting points
- Complex system with many capabilities

---

**Decision Process**:

```
START
↓
Does the skill describe a sequential process?
├─ YES → Is order important?
│         ├─ YES → WORKFLOW-BASED
│         └─ NO → TASK-BASED
│
└─ NO → Is it primarily reference material?
         ├─ YES → REFERENCE/GUIDELINES
         └─ NO → Does it have multiple integrated features?
                  ├─ YES → CAPABILITIES-BASED
                  └─ NO → Re-examine requirements (likely TASK-BASED)
```

**Pattern Selection Factors**:

| Factor | Workflow | Task | Reference | Capabilities |
|--------|----------|------|-----------|--------------|
| Order matters | ✓ | ✗ | ✗ | ~ |
| Dependencies | ✓ | ✗ | ✗ | ✓ |
| Quick lookup | ✗ | ✓ | ✓ | ~ |
| Sequential process | ✓ | ✗ | ✗ | ~ |
| Standards/guidelines | ✗ | ✗ | ✓ | ✗ |
| Multiple features | ~ | ✗ | ✗ | ✓ |
| Integration complexity | ~ | ✗ | ✗ | ✓ |

**Output**: Selected organizational pattern with justification

**Example**:
```
Pattern: Workflow-Based
Justification: Railway deployment is sequential (prepare → configure → deploy → verify)
Alternative Considered: Task-based rejected because order matters
```

**See Also**: [references/pattern-selection-guide.md](references/pattern-selection-guide.md) for comprehensive decision tree and examples

---

### Step 3: Plan File Structure

**Objective**: Define complete file structure using progressive disclosure

**Progressive Disclosure Architecture**:

The key principle: **Keep SKILL.md lean, bundle details in references/**

**Three-Level System**:

1. **SKILL.md** (Always Loaded)
   - Target: <5,000 words (~1,000-1,500 lines)
   - Content: Overview, quick start, key workflows, core concepts
   - Purpose: Provides essential context without overwhelming Claude's context window

2. **references/** (Loaded On-Demand)
   - Target: 10,000+ words okay per file
   - Content: Comprehensive guides, detailed explanations, extensive examples
   - Purpose: Deep details available when needed without bloating main skill

3. **scripts/** (Loaded When Executed)
   - Target: Any size
   - Content: Automation helpers, validation tools, generators
   - Purpose: Executable tools that extend skill capabilities

4. **templates/** (Loaded When Needed)
   - Target: Any size
   - Content: Reusable patterns, boilerplate code, scaffolds
   - Purpose: Starting points for common patterns

**File Structure Planning**:

```
skill-name/
├── SKILL.md (required)
│   ├── YAML frontmatter
│   ├── Overview
│   ├── Prerequisites (if needed)
│   ├── Main content (workflow/tasks/guidelines/capabilities)
│   ├── Quick Start
│   ├── Examples (brief)
│   └── References (links to references/)
│
├── references/ (optional but recommended)
│   ├── detailed-guide-1.md (comprehensive guide)
│   ├── detailed-guide-2.md (another detailed guide)
│   └── advanced-topics.md (deep dive content)
│
├── scripts/ (optional)
│   ├── helper-script.py (automation)
│   └── validation-script.py (validation)
│
└── templates/ (optional)
    ├── template-1.md (reusable pattern)
    └── template-2.md (another pattern)
```

**SKILL.md Content Allocation**:

**Include in SKILL.md**:
- Problem overview (why skill exists)
- Prerequisites
- Core workflow/tasks/guidelines/capabilities
- Quick start instructions
- Brief examples (1-3)
- Links to references for details

**Move to references/**:
- Comprehensive step-by-step guides
- Extensive examples (4+)
- Detailed explanations
- Advanced topics
- Troubleshooting guides
- Deep dives into concepts
- Long reference tables

**Move to scripts/**:
- Automation helpers
- Validation tools
- Code generators
- Analysis tools
- Interactive wizards

**Move to templates/**:
- Boilerplate files
- Configuration templates
- Code scaffolds
- Reusable patterns

**Reference File Naming**:

Use descriptive hyphen-case names:
- `pattern-selection-guide.md` (not `guide1.md`)
- `complexity-estimation-techniques.md` (not `complexity.md`)
- `advanced-workflows.md` (not `advanced.md`)

**Reference Organization Strategies**:

1. **By Topic** (Most Common)
   ```
   references/
   ├── authentication-guide.md
   ├── data-fetching-guide.md
   └── error-handling-guide.md
   ```

2. **By Depth** (Progressive Learning)
   ```
   references/
   ├── basics-guide.md
   ├── intermediate-guide.md
   └── advanced-guide.md
   ```

3. **By Workflow Step** (For Workflow-Based)
   ```
   references/
   ├── step1-preparation-guide.md
   ├── step2-execution-guide.md
   └── step3-validation-guide.md
   ```

4. **By Use Case** (For Task-Based)
   ```
   references/
   ├── use-case-api-integration.md
   ├── use-case-database-setup.md
   └── use-case-testing.md
   ```

**Linking to References**:

Always use relative paths with descriptive link text:

```markdown
Good:
See [Pattern Selection Guide](references/pattern-selection-guide.md) for detailed decision tree.

Bad:
See references/pattern-selection-guide.md for details.
```

**Output**: Complete file structure plan with file names and content allocation

**Example**:
```
railway-deployment/
├── SKILL.md (~1,200 lines)
│   - Overview of Railway deployment
│   - Prerequisites
│   - 4-step deployment workflow
│   - Quick start example
│   - Links to references
│
├── references/
│   ├── environment-configuration-guide.md (~800 lines)
│   ├── docker-setup-guide.md (~600 lines)
│   ├── troubleshooting-common-issues.md (~1,000 lines)
│   └── railway-pricing-optimization.md (~400 lines)
│
├── scripts/
│   └── validate-config.py (~150 lines)
│
└── templates/
    └── railway-config-template.json (~50 lines)
```

**See Also**: [references/structure-planning-guide.md](references/structure-planning-guide.md) for comprehensive progressive disclosure planning

---

### Step 4: Estimate Complexity

**Objective**: Estimate development time and effort required

**Complexity Factors**:

1. **Skill Size**
   - Minimal (SKILL.md only): 2-4 hours
   - Small (SKILL.md + 1-2 references): 6-10 hours
   - Medium (SKILL.md + 3-5 references): 12-18 hours
   - Large (SKILL.md + 6+ references + scripts): 20-30 hours
   - Very Large (Multiple scripts, templates, extensive docs): 30+ hours

2. **Pattern Complexity**
   - Workflow-based: Medium (need to document each step clearly)
   - Task-based: Low-Medium (independent tasks easier to document)
   - Reference/Guidelines: Medium-High (requires comprehensive coverage)
   - Capabilities-based: High (complex interactions to document)

3. **Domain Complexity**
   - Familiar domain: 1x multiplier
   - Some learning needed: 1.5x multiplier
   - Significant research needed: 2x multiplier
   - Novel/complex domain: 2.5x+ multiplier

4. **Automation Requirements**
   - No scripts: 0 additional hours
   - Simple scripts (1-2): +4-6 hours
   - Complex scripts (3+): +10-15 hours
   - Interactive tools: +15-20 hours

5. **Research Requirements**
   - Existing documentation: 1x
   - Some research needed: +2-4 hours
   - Extensive research: +8-12 hours
   - No existing resources: +15+ hours

**Estimation Formula**:

```
Base Time = Skill Size (from factor 1)
Pattern Multiplier = Factor 2
Domain Multiplier = Factor 3
Automation Add = Factor 4
Research Add = Factor 5

Total Estimate = (Base Time × Pattern Multiplier × Domain Multiplier) + Automation Add + Research Add
```

**Estimation Examples**:

**Example 1: Simple Troubleshooting Skill**
```
Base: Small (6-10h) = 8h
Pattern: Task-based (1x)
Domain: Familiar (1x)
Automation: None (0h)
Research: Existing docs (0h)

Total: 8h × 1 × 1 + 0 + 0 = 8 hours
```

**Example 2: Complex Deployment Workflow**
```
Base: Large (20-30h) = 25h
Pattern: Workflow-based (1.2x)
Domain: Some learning (1.5x)
Automation: Simple scripts (5h)
Research: Some needed (3h)

Total: 25h × 1.2 × 1.5 + 5 + 3 = 53 hours
```

**Example 3: Design System Reference**
```
Base: Medium (12-18h) = 15h
Pattern: Reference/Guidelines (1.3x)
Domain: Familiar (1x)
Automation: None (0h)
Research: Existing docs (0h)

Total: 15h × 1.3 × 1 + 0 + 0 = 19.5 hours
```

**Estimation Checklist**:

- [ ] Counted number of reference files needed
- [ ] Assessed domain knowledge gap
- [ ] Identified automation needs
- [ ] Determined research requirements
- [ ] Applied pattern complexity multiplier
- [ ] Added buffer for iteration (10-20%)
- [ ] Validated estimate seems reasonable

**Output**: Time estimate with breakdown by component

**Example**:
```
Estimated Development Time: 42-48 hours

Breakdown:
- SKILL.md: 8 hours
- references/ (4 files): 20 hours
  - pattern-selection-guide.md: 6h
  - structure-planning-guide.md: 6h
  - complexity-estimation-guide.md: 4h
  - dependency-analysis-guide.md: 4h
- scripts/plan-skill.py: 10 hours
- templates/: 2 hours
- Validation & testing: 4 hours

Total: 44 hours (42-48 hour range)
```

**See Also**: [references/complexity-estimation-guide.md](references/complexity-estimation-guide.md) for detailed estimation techniques and calibration data

---

### Step 5: Identify Dependencies

**Objective**: Identify what this skill depends on and what depends on it

**Dependency Types**:

#### 1. Skill Dependencies
Skills this skill relies on or references

**Identification Questions**:
- Does this skill assume other skills exist?
- Does this skill reference other skills in examples?
- Would this skill be more effective with other skills available?

**Example**:
```
planning-architect depends on:
- skill-builder-generic (for skill patterns)
- No hard dependencies, but enhanced by:
  - task-development (for breaking down implementation)
  - complexity-estimation (for time estimates)
```

#### 2. Tool Dependencies
External tools or MCPs this skill requires

**Identification Questions**:
- Does this skill use specific Claude Code tools? (WebSearch, WebFetch, Bash, etc.)
- Does this skill require MCPs? (Context7, GitHub, etc.)
- Are there external services needed? (APIs, databases, etc.)

**Example**:
```
skill-researcher depends on:
- WebSearch tool (for latest patterns)
- WebFetch tool (for documentation)
- Context7 MCP (optional, for deep context)
- GitHub API (for community skill analysis)
```

#### 3. Knowledge Dependencies
Domain knowledge or prerequisites users must have

**Identification Questions**:
- What knowledge must users have before using this skill?
- What terminology must users understand?
- What concepts are assumed as known?

**Example**:
```
railway-deployment requires users know:
- Basic Node.js and npm
- Git basics
- Command line usage
- HTTP concepts (for API deployments)
```

#### 4. File Dependencies
Files in the project this skill references

**Identification Questions**:
- Does this skill reference specific file paths?
- Does it assume certain project structure?
- Does it expect configuration files to exist?

**Example**:
```
deployment-guide assumes:
- package.json exists
- .env.example exists (for environment variables)
- Dockerfile exists (or provides template)
```

#### 5. Reverse Dependencies (What Depends On This)
Other skills that will depend on this skill

**Identification Questions**:
- What skills will be built after this one?
- What skills might reference this skill?
- Who is the downstream consumer?

**Example**:
```
planning-architect will be depended on by:
- task-development (uses planning output)
- skill-researcher (feeds into planning)
- All future skill development (planning is first step)
```

**Dependency Documentation Format**:

```markdown
## Dependencies

### Required
- skill-builder-generic: Core patterns and templates
- WebSearch tool: For researching similar skills

### Optional
- Context7 MCP: Enhanced context for complex planning
- skill-researcher: For comprehensive research phase

### User Prerequisites
- Familiarity with skill-builder-generic
- Understanding of progressive disclosure
- Basic markdown knowledge

### Reverse Dependencies
- task-development (will use planning output)
- skill-composer (for multi-skill workflows)
```

**Output**: Complete dependency list with all five types

**Example**:
```
Dependencies for planning-architect:

Skill Dependencies:
- Required: skill-builder-generic
- Optional: skill-researcher, analysis

Tool Dependencies:
- None (uses only standard Claude Code capabilities)

Knowledge Dependencies:
- Familiarity with Claude Code skills
- Understanding of progressive disclosure
- Markdown knowledge

File Dependencies:
- skill-builder-package/examples/* (for reference examples)

Reverse Dependencies:
- task-development (next in bootstrap sequence)
- todo-management (uses planning structure)
- All future skills (planning is foundation)
```

**See Also**: [references/dependency-analysis-guide.md](references/dependency-analysis-guide.md) for dependency mapping techniques

---

### Step 6: Define Validation Criteria

**Objective**: Establish how to validate the skill works correctly

**Validation Categories**:

#### 1. Structure Validation
Does the skill have correct file structure?

**Criteria**:
- [ ] SKILL.md exists with valid YAML frontmatter
- [ ] Directory structure matches plan
- [ ] All reference files exist
- [ ] All scripts are executable
- [ ] All templates are present

**Validation Method**: Run `validate-skill.py` script

---

#### 2. Content Validation
Is the content complete and correct?

**Criteria**:
- [ ] Overview clearly states purpose
- [ ] Prerequisites are documented
- [ ] Main content follows chosen pattern
- [ ] Examples are provided
- [ ] References are linked correctly
- [ ] Writing uses imperative voice
- [ ] No TODO placeholders (except in templates)
- [ ] Trigger keywords present in description

**Validation Method**: Manual review + automated checks

---

#### 3. Functional Validation
Does the skill actually work?

**Criteria**:
- [ ] Can invoke skill by name
- [ ] Skill loads without errors
- [ ] References load when requested
- [ ] Scripts execute successfully
- [ ] Templates can be used
- [ ] Examples produce expected results

**Validation Method**: Test invocation + script execution

---

#### 4. Usability Validation
Is the skill easy to use?

**Criteria**:
- [ ] Quick start is actually quick (<5 min)
- [ ] Examples are clear and relevant
- [ ] Instructions are unambiguous
- [ ] Terminology is consistent
- [ ] Navigation is intuitive
- [ ] Context window impact is minimal

**Validation Method**: User testing + feedback

---

#### 5. Completeness Validation
Does the skill cover everything it should?

**Criteria**:
- [ ] All requirements from Step 1 are addressed
- [ ] All workflows are documented
- [ ] Edge cases are covered
- [ ] Troubleshooting is included
- [ ] Best practices are captured
- [ ] Anti-patterns are noted

**Validation Method**: Requirements traceability matrix

---

**Validation Plan Template**:

```markdown
## Validation Plan

### Structure Validation
Method: Automated script
Tool: validate-skill.py
Pass Criteria: Zero errors, max 1 warning

### Content Validation
Method: Manual review
Checklist: 50-point validation checklist
Pass Criteria: All checklist items pass

### Functional Validation
Method: Test invocation
Test Cases:
1. Invoke skill in clean session
2. Request reference file
3. Execute scripts with test input
4. Use templates in sample project
Pass Criteria: All test cases succeed

### Usability Validation
Method: User testing
Testers: 2-3 developers
Pass Criteria: Users can complete quick start in <5 min

### Completeness Validation
Method: Requirements review
Process: Check each requirement has corresponding content
Pass Criteria: 100% requirements coverage
```

**Output**: Comprehensive validation plan with test cases

**Example**:
```
Validation Plan for planning-architect:

Structure:
- Run validate-skill.py
- Verify 4 reference files present
- Verify plan-skill.py is executable

Content:
- Review all 6 workflow steps
- Verify examples in each step
- Check imperative voice usage
- Validate trigger keywords

Functional:
- Invoke planning-architect
- Follow workflow for test skill
- Run plan-skill.py with test input
- Verify generates complete plan

Usability:
- Ask developer to plan simple skill
- Time quick start completion
- Gather feedback on clarity

Completeness:
- Verify all planning aspects covered
- Check all 4 patterns documented
- Ensure estimation methods present
- Validate dependency analysis included
```

---

## Quick Start: Plan a Skill in 30 Minutes

### 1. Analyze Requirements (10 minutes)

Answer these questions:
- **Problem**: What problem does this skill solve?
- **Users**: Who will use it?
- **Domain**: What knowledge to capture?
- **Scope**: What's in/out of scope?

### 2. Select Pattern (5 minutes)

Use decision tree:
- Sequential process with dependencies? → **Workflow-based**
- Independent operations? → **Task-based**
- Standards/reference? → **Reference/Guidelines**
- Multiple integrated features? → **Capabilities-based**

### 3. Plan Structure (5 minutes)

```
skill-name/
├── SKILL.md (always)
├── references/ (if detailed guides needed)
├── scripts/ (if automation needed)
└── templates/ (if reusable patterns needed)
```

### 4. Estimate Time (5 minutes)

- Count reference files: ____
- Automation needed?: ____
- Research required?: ____
- Rough estimate: ____ hours

### 5. List Dependencies (3 minutes)

- Skill dependencies: ____
- Tool dependencies: ____
- Knowledge prerequisites: ____

### 6. Define Validation (2 minutes)

- Structure: validate-skill.py
- Functional: Test invoke + scripts
- Complete: Requirements coverage

**Result**: Complete plan ready for implementation!

---

## Examples

### Example 1: Simple Troubleshooting Skill

**Requirements**:
- Problem: Railway deployment errors are cryptic
- Users: Dev team with Railway experience
- Domain: Railway troubleshooting
- Scope: Common errors + solutions

**Pattern**: Task-based (independent error cases)

**Structure**:
```
railway-troubleshooting/
├── SKILL.md (task-based format)
└── references/
    └── advanced-troubleshooting.md
```

**Estimate**: 8-10 hours (small, familiar domain)

**Dependencies**:
- Knowledge: Basic Railway concepts
- No skill dependencies

**Validation**: Test each troubleshooting case

---

### Example 2: Complex API Integration

**Requirements**:
- Problem: FHIR API integration is complex
- Users: Medical dev team
- Domain: FHIR, OAuth, REST
- Scope: Complete integration workflow

**Pattern**: Workflow-based (sequential integration steps)

**Structure**:
```
fhir-integration/
├── SKILL.md (workflow format)
├── references/
│   ├── fhir-resources-guide.md
│   ├── oauth-setup-guide.md
│   └── error-handling-guide.md
├── scripts/
│   └── validate-fhir-response.py
└── templates/
    └── fhir-request-template.json
```

**Estimate**: 35-40 hours (large, some research needed)

**Dependencies**:
- Skill: oauth-integration
- Tool: WebFetch (for API testing)
- Knowledge: REST APIs, JSON

**Validation**: Full integration test with FHIR server

---

### Example 3: Design System Reference

**Requirements**:
- Problem: Inconsistent UI components
- Users: Frontend team
- Domain: Design system
- Scope: Colors, typography, components

**Pattern**: Reference/Guidelines (design standards)

**Structure**:
```
design-system/
├── SKILL.md (reference format)
├── references/
│   ├── color-palette-guide.md
│   ├── typography-guide.md
│   └── component-library.md
└── assets/
    ├── colors.png
    └── typography-examples.png
```

**Estimate**: 18-22 hours (medium, design domain)

**Dependencies**:
- Knowledge: Design principles, CSS
- No skill dependencies

**Validation**: Apply design system to sample component

---

## Planning Output

After completing the 6-step workflow, you should have:

1. **Requirements Document**
   - Problem statement
   - User profile
   - Domain knowledge scope
   - Explicit scope boundaries
   - Resource inventory

2. **Pattern Selection**
   - Chosen pattern with justification
   - Rejected patterns with reasons

3. **File Structure Plan**
   - Complete directory tree
   - File names for all files
   - Content allocation (what goes where)
   - Progressive disclosure strategy

4. **Time Estimate**
   - Overall estimate with range
   - Breakdown by component
   - Complexity factors applied
   - Buffer included

5. **Dependency Map**
   - Skill dependencies (required + optional)
   - Tool dependencies
   - Knowledge prerequisites
   - Reverse dependencies

6. **Validation Plan**
   - Structure validation method
   - Content validation checklist
   - Functional test cases
   - Usability testing approach
   - Completeness criteria

**Format**: See [templates/skill-plan-template.md](templates/skill-plan-template.md) for structured output format

---

## Best Practices

### Planning Best Practices

1. **Start with Why**
   - Clearly articulate the problem
   - Validate the need before planning
   - Consider if skill is the right solution

2. **Choose Pattern Carefully**
   - Pattern drives entire structure
   - Consider user mental model
   - Validate pattern with examples

3. **Plan for Evolution**
   - Skills will grow over time
   - Structure should accommodate additions
   - Leave room for future enhancements

4. **Optimize Context Usage**
   - Keep SKILL.md lean
   - Move details to references
   - Every word costs context tokens

5. **Validate Early**
   - Review plan before implementation
   - Get feedback from potential users
   - Adjust based on feedback

### Common Planning Mistakes

1. **Scope Creep**
   - Problem: Planning too much at once
   - Solution: Define MVP, plan iterations

2. **Wrong Pattern**
   - Problem: Choosing workflow for independent tasks
   - Solution: Use decision tree carefully

3. **Poor Progressive Disclosure**
   - Problem: Putting everything in SKILL.md
   - Solution: Follow <5,000 word guideline

4. **Underestimating Complexity**
   - Problem: Unrealistic time estimates
   - Solution: Use formula, add buffer

5. **Ignoring Dependencies**
   - Problem: Missing prerequisite skills
   - Solution: Complete dependency analysis

---

## References

Comprehensive guides for each planning step:

- **[Pattern Selection Guide](references/pattern-selection-guide.md)** - Complete decision tree with detailed examples for choosing between workflow, task, reference, and capabilities patterns. Includes edge cases and combination patterns.

- **[Structure Planning Guide](references/structure-planning-guide.md)** - Deep dive into progressive disclosure, file organization strategies, content allocation techniques, and context optimization methods.

- **[Complexity Estimation Guide](references/complexity-estimation-guide.md)** - Detailed estimation techniques, calibration data from real skills, estimation worksheets, and accuracy improvement methods.

- **[Dependency Analysis Guide](references/dependency-analysis-guide.md)** - Comprehensive dependency identification techniques, dependency mapping strategies, circular dependency resolution, and version management.

---

## Automation

Use the planning automation script for guided planning:

```bash
# Interactive planning wizard
python scripts/plan-skill.py --interactive

# Plan from description file
python scripts/plan-skill.py --description skill-description.txt

# Generate plan with specific pattern
python scripts/plan-skill.py --pattern workflow --name my-skill

# Output plan to file
python scripts/plan-skill.py --interactive --output skill-plan.md
```

See script help for all options:
```bash
python scripts/plan-skill.py --help
```

---

## Success Criteria

A successful skill plan includes:

✅ **Clear Requirements**
- Problem clearly stated
- Users identified
- Scope explicitly defined
- Resources inventoried

✅ **Justified Pattern Selection**
- Pattern chosen with clear reasoning
- Alternatives considered and rejected
- Pattern fits user mental model

✅ **Complete Structure Plan**
- All files identified
- Content allocated appropriately
- Progressive disclosure optimized
- Naming follows conventions

✅ **Realistic Estimate**
- Breakdown by component
- Complexity factors applied
- Range provided (not single number)
- Buffer included

✅ **Comprehensive Dependencies**
- All dependency types covered
- Prerequisites documented
- Reverse dependencies identified

✅ **Validation Strategy**
- Multiple validation types
- Clear pass/fail criteria
- Test cases defined
- Validation plan is actionable

---

## Next Steps

After completing skill planning:

1. **Review Plan**
   - Validate completeness
   - Get feedback if team skill
   - Adjust based on feedback

2. **Proceed to Implementation**
   - Use skill-builder-generic for implementation
   - Follow file structure from plan
   - Reference estimates for time management

3. **Track Progress**
   - Use task-development to break down implementation
   - Use todo-management to track progress
   - Adjust plan if significant deviations

4. **Validate Continuously**
   - Run validations frequently
   - Test as you build
   - Iterate based on findings

---

## Quick Reference

### The 6-Step Planning Process

| Step | Focus | Key Output | Time |
|------|-------|------------|------|
| 1. Analyze Requirements | Problem, users, scope, domain | Requirements document | 30-60m |
| 2. Choose Pattern | Workflow/task/reference/capabilities | Pattern selection with rationale | 15-30m |
| 3. Design Structure | Files, sections, progressive disclosure | File structure plan | 30-45m |
| 4. Plan Content | Section-by-section content outline | Content plan | 45-90m |
| 5. Estimate Complexity | Time, dependencies, risks | Effort estimate | 20-30m |
| 6. Create Plan Document | Consolidated implementation plan | Complete skill plan | 30-45m |

**Total Planning Time**: 3-5 hours for comprehensive plan

### The 4 Organizational Patterns

| Pattern | When to Use | Structure | Example |
|---------|-------------|-----------|---------|
| **Workflow** | Sequential dependencies, process with steps | Numbered steps (Step 1→2→3) | deployment-guide, development-workflow |
| **Task** | Independent operations, no required order | Unnumbered operations | railway-troubleshooting, review-multi |
| **Reference** | Standards, guidelines, design systems | Topic-based sections | botanical-design, common-patterns |
| **Capabilities** | Multiple related features used together | Integrated capabilities | Complex multi-feature skills |

### Pattern Selection Decision Tree

```
Do steps have sequential dependencies?
├─ Yes → WORKFLOW (use numbered steps)
└─ No → Are operations independent?
    ├─ Yes → TASK (use unnumbered operations)
    └─ No → Is it standards/guidelines?
        ├─ Yes → REFERENCE (topic-based organization)
        └─ No → CAPABILITIES (integrated features)
```

### Complexity Estimation Guidelines

| Complexity | Files | Lines | Time | Characteristics |
|------------|-------|-------|------|-----------------|
| **Simple** | 1-3 | 400-800 | 2-4h | Single file or minimal references |
| **Medium** | 4-8 | 1,500-3,000 | 8-15h | Multiple references, maybe scripts |
| **Complex** | 9-15+ | 3,000-5,000+ | 20-40h | Extensive references, automation scripts |

### Progressive Disclosure Rules

- **SKILL.md**: <1,200 lines ideal (overview + essentials)
- **references/**: 300-600 lines per file (detailed guides)
- **scripts/**: Automation tools (loaded when needed)

**Decision**: If content >1,000 lines → move detailed content to references/

### Common Planning Outputs

**Requirements Document**:
- Problem definition
- User analysis
- Scope boundaries
- Domain knowledge capture

**Structure Plan**:
- File organization
- Section outline
- Progressive disclosure strategy
- Naming conventions

**Implementation Plan**:
- Complete file-by-file breakdown
- Content specifications
- Time estimates
- Dependencies identified
- Validation criteria

### Quick Planning Checklist

- [ ] Problem clearly defined (what, who, why)
- [ ] Users identified (expertise level, context)
- [ ] Scope boundaries established (in/out of scope)
- [ ] Pattern selected with rationale
- [ ] File structure designed
- [ ] Content planned section-by-section
- [ ] Complexity estimated (simple/medium/complex)
- [ ] Dependencies identified
- [ ] Time budget allocated
- [ ] Plan document created

### For More Information

- **Requirements analysis**: See Step 1
- **Pattern selection**: See Step 2 + references/pattern-selection-guide.md
- **Structure design**: See Step 3 + references/structure-planning-guide.md
- **Content planning**: See Step 4 + references/content-specification-guide.md
- **Complexity estimation**: See Step 5 + references/complexity-assessment-guide.md

---

**planning-architect** is the foundation of systematic skill development. Use it to transform ideas into actionable implementation plans that lead to high-quality, well-structured Claude Code skills.