Decomposition Planning RoadmapSAFE

From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: decomposition-planning-roadmap
description: Creates step-by-step decomposition plans and migration roadmaps for breaking apart monolithic applications. Use when asking "what order should I extract services?", "plan my migration", "create a decomposition roadmap", "prioritize what to split", "monolith to microservices strategy", or tracking decomposition progress. Do NOT use for domain analysis (use domain-analysis) or component sizing (use component-identification-sizing).
---

# Decomposition Planning and Roadmap

This skill creates structured decomposition plans and roadmaps to guide the migration from monolithic to distributed architectures, prioritizing work and tracking progress through decomposition patterns.

## How to Use

### Quick Start

Request creation of a decomposition plan:

- **"Create a decomposition roadmap for this codebase"**
- **"Plan the decomposition migration strategy"**
- **"Prioritize decomposition work based on component analysis"**
- **"Create a step-by-step decomposition plan"**

### Usage Examples

**Example 1: Complete Roadmap**

```
User: "Create a decomposition roadmap for this codebase"

The skill will:
1. Analyze current codebase state
2. Identify decomposition patterns to apply
3. Prioritize work based on risk and value
4. Create phased roadmap
5. Generate architecture stories
6. Estimate effort and dependencies
```

**Example 2: Prioritized Plan**

```
User: "Prioritize decomposition work based on component analysis"

The skill will:
1. Review component inventory and dependencies
2. Assess risk and value for each pattern
3. Prioritize patterns by impact
4. Create prioritized work plan
```

**Example 3: Phase Planning**

```
User: "Create a phased decomposition plan"

The skill will:
1. Group decomposition patterns into phases
2. Identify dependencies between phases
3. Create phase timeline
4. Define phase success criteria
```

### Step-by-Step Process

1. **Assess Current State**: Analyze codebase and identify what's been done
2. **Identify Patterns**: Determine which decomposition patterns to apply
3. **Prioritize Work**: Rank patterns by risk, value, and dependencies
4. **Create Roadmap**: Build phased plan with milestones
5. **Generate Stories**: Create architecture stories for tracking
6. **Track Progress**: Monitor progress through decomposition phases

## When to Use

Apply this skill when:

- Starting a decomposition effort
- Planning migration from monolith to distributed architecture
- Prioritizing decomposition work
- Creating architecture stories for decomposition
- Tracking progress through decomposition patterns
- Need structured approach to decomposition
- Want to estimate effort and dependencies

## Core Concepts

### Decomposition Pattern Sequence

The six component-based decomposition patterns should be applied in sequence:

1. **Identify and Size Components** - Understand what you have
2. **Gather Common Domain Components** - Find duplicates
3. **Flatten Components** - Remove orphaned classes
4. **Determine Component Dependencies** - Assess coupling
5. **Create Component Domains** - Group into domains
6. **Create Domain Services** - Extract to services

### Phased Approach

Decomposition typically follows phases:

**Phase 1: Analysis & Preparation** (Patterns 1-4)

- Component identification and sizing
- Common component detection
- Component flattening
- Dependency analysis

**Phase 2: Domain Organization** (Pattern 5)

- Domain identification
- Component grouping
- Namespace refactoring

**Phase 3: Service Extraction** (Pattern 6)

- Domain service creation
- Service extraction
- API boundary definition

### Prioritization Factors

When prioritizing decomposition work, consider:

- **Risk**: Low risk = easier to extract, fewer dependencies
- **Value**: High value = business-critical, high impact
- **Dependencies**: Can this be done independently?
- **Complexity**: Simple = fewer components, clear boundaries
- **Coupling**: Low coupling = easier to extract

## Analysis Process

### Phase 1: Assess Current State

Analyze what's already been done:

1. **Check Component Inventory**
   - Have components been identified and sized?
   - Is there a component inventory document?
   - Are oversized components identified?

2. **Check Common Component Analysis**
   - Have common domain components been identified?
   - Are consolidation opportunities documented?
   - Has coupling impact been analyzed?

3. **Check Component Structure**
   - Have components been flattened?
   - Are there orphaned classes?
   - Is component structure clean?

4. **Check Dependency Analysis**
   - Have component dependencies been mapped?
   - Is coupling analysis complete?
   - Is feasibility assessed?

5. **Check Domain Identification**
   - Have domains been identified?
   - Are components grouped into domains?
   - Are namespaces aligned with domains?

6. **Check Service Extraction**
   - Have any services been extracted?
   - Are domain services created?
   - Is service-based architecture in place?

**Output**: Current state assessment showing what's done and what's remaining

### Phase 2: Identify Patterns to Apply

Determine which decomposition patterns need to be applied:

1. **Review Pattern Prerequisites**
   - Pattern 1: Always needed (foundation)
   - Pattern 2: Needed if common components exist
   - Pattern 3: Needed if components have hierarchy
   - Pattern 4: Always needed (feasibility check)
   - Pattern 5: Needed before service extraction
   - Pattern 6: Final step (service extraction)

2. **Check Pattern Completion**
   - Which patterns are complete?
   - Which patterns are in progress?
   - Which patterns haven't started?

3. **Identify Missing Patterns**
   - What patterns still need to be applied?
   - What's blocking pattern application?
   - What dependencies exist?

**Output**: List of patterns to apply with status

### Phase 3: Prioritize Work

Prioritize decomposition patterns and work items:

1. **Assess Risk**
   - Low Risk: Infr

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (1)

CLAUDE.md

Gates applied: no_behavioural_pass.