Detects misplaced classes and fixes component hierarchy problems — finds code that should belong inside a component but sits at the root level. Use when asking "clean up component structure", "find orphaned classes", "fix module hierarchy", "flatten nested components", or analyzing why namespaces have misplaced code. Do NOT use for dependency analysis (use coupling-analysis) or domain grouping (use domain-identification-grouping).
SKILL.md
Component Flattening Analysis
This skill identifies component hierarchy issues and ensures components exist only as leaf nodes in directory/namespace structures, removing orphaned classes from root namespaces.
How to Use
Quick Start
Request analysis of your codebase:
"Find orphaned classes in root namespaces"
"Flatten component hierarchies"
"Identify components that need flattening"
"Analyze component structure for hierarchy issues"
Usage Examples
Example 1: Find Orphaned Classes
User: "Find orphaned classes in root namespaces"
The skill will:
1. Scan component namespaces for hierarchy issues
2. Identify orphaned classes in root namespaces
3. Detect components built on top of other components
4. Suggest flattening strategies
5. Create refactoring plan
Example 2: Flatten Components
User: "Flatten component hierarchies in this codebase"
The skill will:
1. Identify components with hierarchy issues
2. Analyze orphaned classes
3. Suggest consolidation or splitting strategies
4. Create refactoring plan
5. Estimate effort
Example 3: Component Structure Analysis
User: "Analyze component structure for hierarchy issues"
The skill will:
1. Map component namespace structure
2. Identify root namespaces with code
3. Find components built on components
4. Flag hierarchy violations
5. Provide recommendations
Shared Code: Common utilities, interfaces, abstract classes
Domain Code: Business logic that should be in component
Mixed: Combination of shared and domain code
Assess Impact
How many files are orphaned?
What functionality do they contain?
What components depend on them?
Example Orphaned Class Detection:
## Orphaned Classes Found
### Root Namespace: ss.survey
**Orphaned Files** (5 files):
- Survey.js (domain code - survey creation)
- SurveyProcessor.js (domain code - survey processing)
- SurveyValidator.js (shared code - validation)
- SurveyFormatter.js (shared code - formatting)
- SurveyConstants.js (shared code - constants)
**Classification**:
- Domain Code: 2 files (should be in components)
- Shared Code: 3 files (should be in .shared component)
**Dependencies**: Used by ss.survey.templates component
Phase 3: Analyze Flattening Options
Determine best flattening strategy for each root namespace:
Option 1: Consolidate Down
Move leaf node code into root namespace
Makes root namespace the component
Use when: Leaf nodes are small, related functionality
Option 2: Split Up
Move root namespace code into new leaf nodes
Creates multiple components from root
Use when: Root namespace has distinct functional areas
Option 3: Move Shared Code
Extract shared code to .shared component
Keep domain code in root or split
Use when: Root namespace has shared utilities
Example Flattening Analysis:
## Flattening Options Analysis
### Root Namespace: ss.survey
**Current State**:
- Root namespace: 5 orphaned files
- Leaf component: ss.survey.templates (7 files)
**Option 1: Consolidate Down** ✅ Recommended
- Move templates code into ss.survey
- Result: Single component ss.survey
- Effort: Low (7 files to move)
- Rationale: Templates are small, related to survey functionality
**Option 2: Split Up**
- Create ss.survey.create (2 files)
- Create ss.survey.process (1 file)
- Create ss.survey.shared (3 files)
- Keep ss.survey.templates (7 files)
- Effort: High (multiple components to create)
- Rationale: More granular, but may be over-engineering
**Option 3: Move Shared Code**
- Create ss.survey.shared (3 shared files)
- Keep domain code in root (2 files)
- Keep ss.survey.templates (7 files)
- Effort: Medium
- Rationale: Separates shared from domain, but still has hierarchy
Phase 4: Create Flattening Plan
Generate refactoring plan for each root namespace:
Select Strategy
Choose best flattening option
Consider effort, complexity, maintainability
Plan Refactoring Steps
List files to move
Identify target namespaces
Note dependencies to update
Estimate Effort
Time to refactor
Risk assessment
Testing requirements
Example Flattening Plan:
## Flattening Plan
### Priority: High
**Root Namespace: ss.survey**
**Strategy**: Consolidate Down
**Steps**:
1. Move files from ss.survey.templates/ to ss.survey/
- EmailTemplate.js
- SMSTemplate.js
- [5 more files]
2. Update imports in dependent components
- Update references from ss.survey.templates._ to ss.survey._
3. Remove ss.survey.templates/ directory
4. Update namespace declarations
- Change namespace from ss.survey.templates to ss.survey
5. Run tests to verify changes
**Effort**: 2-3 days
**Risk**: Low (templates are self-contained)
**Dependencies**: None