migrate-architecture
Skill2 starsChanged 9 months agoMITView on GitHub
Use when transforming a project's architecture pattern - e.g., Flat to Modular, MVC to Clean Architecture, Monolith to Modular Monolith.
In this repository22 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- auditSkill
- brainstormSkill
- checkpointSkill
- codereviewSkill
- commitSkill
- debugSkill
- estimateSkill
- finishSkill
- healthSkill
- learnSkill
- lintSkill
- migrate-frameworkSkill
- onboardSkill
- planSkill
- recallSkill
- rememberSkill
- tddSkill
- tutorialSkill
- verifySkill
- worktreeSkill
- write-skillSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
24 rules. About 0 are common, 19 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈19
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 57
Check for barrel exports (index.ts)
- Distinctive: line 58
Check import patterns between directories
- Distinctive: line 103
Start with the LEAST coupled module
- Distinctive: line 112
Update: all import paths:
- Distinctive: line 113
Use Grep to find all imports referencing moved files
- Distinctive: line 114
Update each import to the new path
- Distinctive: line 115
Use barrel exports where possible
- Distinctive: line 121
Verify: no broken imports:
- Very specific: line 158
Create modules/[feature]/components/ for each group
- Very specific: line 160
Create index.ts for each module
- Distinctive: line 168
Create service layer in each module
- Distinctive: line 174
Create use-case classes for each business operation
- Distinctive: line 183
Create use-cases from service methods
- Distinctive: line 189
Create core/ with domain/ and ports/
- Distinctive: line 209
Add aggregates/ with aggregate roots
- Distinctive: line 211
Create domain events for state changes
- Distinctive: line 212
Add command/query handlers in application layer
- Distinctive: line 216
Start with Modular structure
- Very specific: line 217
Add domain/application/infrastructure layers per module
- Distinctive: line 235
ALWAYS assess before migrating - understand current state first
- Distinctive: line 236
NEVER migrate without user confirmation
- Very specific: line 240
CREATE docs/ARCHITECTURE.md for the target pattern
- Distinctive: line 241
USE the appropriate variant (Full for established teams, Lite for small teams)
- Distinctive: line 242
If TypeScript errors appear, FIX them before continuing
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/migrate-architecture - Architecture Pattern Migration
Migrate a project's architecture from one pattern to another while preserving all functionality.
Arguments: $ARGUMENTS (e.g., "flat to modular full project", "mvc to clean lite src/modules/auth")
Supported Architecture Patterns
Frontend
| Pattern | Description |
| Flat / Component-Driven | Single components/ dir, minimal structure |
| Modular (Feature-Based) | Vertical slicing by feature with services/adapters/types |
| Feature-Sliced Design (FSD) | Strict layered: app > pages > features > entities > shared |
| Atomic Design | Components by granularity: atoms > molecules > organisms |
| Clean Architecture | Domain > Use Cases > Adapters > Frameworks |
| Hexagonal (Ports & Adapters) | Core with ports, infrastructure in adapters |
Backend / Fullstack
| Pattern | Description |
| MVC / Layered | Horizontal: controllers, services, repositories |
| Modular Monolith | Single deployment, strict module boundaries |
| Clean Architecture | Concentric layers, dependency rule inward |
| Hexagonal | Ports & Adapters, domain isolated |
| DDD | Bounded contexts, aggregates, domain events |
| CQRS | Separate command/query paths |
| Event-Driven | Async communication via events |
| Microservices | Independent services, own databases |
Variants
| Variant | Description |
| Full | Complete implementation with all layers and patterns |
| Lite (Simplified) | Fewer layers, same principles. For smaller teams |
Workflow
Phase 1: Assessment
- Read
docs/ARCHITECTURE.mdif it exists - Scan the project structure:
- List all directories under
src/(or root if nosrc/) - Identify current architecture pattern by matching directory names
- Count modules/features/components
- Check for barrel exports (index.ts)
- Check import patterns between directories
- List all directories under
- Identify the current architecture pattern and confidence level
- Report findings:
── Architecture Assessment ──
Current: [detected pattern] (confidence: high/medium/low)
Target: [requested pattern] ([variant])
Scope: [project | specific module/path]
Estimated files to move: X
Estimated files to create: X
Risk: low/medium/high- Ask for confirmation before proceeding
Phase 2: Planning
- Generate the target directory structure based on:
- Target architecture pattern
- Detected framework (React, Vue, Next.js, etc.)
- Chosen variant (Full or Lite)
- Map existing files to their new locations:
- Components → appropriate layer/module
- Services → service layer or domain layer
- Types → types layer
- Tests → co-located tests/
- Utils/Helpers → shared/
- Identify new files to create:
- Barrel exports (index.ts) per module
- Adapter layer (if Full variant)
- Type separation (.types.ts + .contracts.ts for Full)
- Create migration plan with ordered steps:
- Phase 2a: Create target directory structure
- Phase 2b: Move files (least coupled first)
- Phase 2c: Create new files (barrel exports, adapters)
- Phase 2d: Update imports
- Phase 2e: Validate
Phase 3: Execution
Execute the migration plan step by step:
- Create target directory structure (mkdir -p)
- Move files one module at a time:
- Start with the LEAST coupled module
- Move component files
- Move service files
- Move type files
- Move test files
- Create new architectural files:
- Barrel exports (index.ts) for each module
- Adapter files (if migrating to Modular Full, Clean, or Hexagonal)
- Type separation files (.types.ts + .contracts.ts)
- Update all import paths:
- Use Grep to find all imports referencing moved files
- Update each import to the new path
- Use barrel exports where possible
- Generate or update
docs/ARCHITECTURE.mdfor the target pattern
Phase 4: Validation
- Check directory structure matches target pattern
- Verify no broken imports:
npx tsc --noEmit 2>&1 | head -50 - Validate import rules:
- Modules don't import from each other (Modular)
- Dependencies point inward (Clean/Hexagonal)
- FSD layers import top-down only
- Run tests if they exist:
npm test 2>&1 | tail -20 - Report results:
── Architecture Migration Complete ──
From: [source pattern]
To: [target pattern] ([variant])
Files moved: X
Files created: X
Imports updated: X
Barrel exports created: X
Validation:
TypeScript: ✓ compiles
Import rules: ✓ no violations
Tests: ✓ passing (or N/A)
docs/ARCHITECTURE.md: ✓ generatedMigration Strategies by Pattern
Flat → Modular
- Group components by domain/feature
- Create
modules/[feature]/components/for each group - Move related services, types into module
- Create index.ts for each module
- Move shared components to
shared/components/
MVC → Modular
- For each controller+service pair, create a module
- Move controller logic to module's hooks/composables
- Move models to module's types/
- Create service layer in each module
- Move shared middleware to shared/
MVC → Clean Architecture
- Extract domain entities (pure business objects, no framework deps)
- Create use-case classes for each business operation
- Define port interfaces for external dependencies
- Move database/HTTP code to infrastructure/ as adapter implementations
- Wire use cases to ports in the composition root
Modular → Clean Architecture
- For each module, add domain/ and application/ sub-layers
- Extract entities from services into domain/entities/
- Create use-cases from service methods
- Define port interfaces for external deps
- Move HTTP/DB code to infrastructure/
Modular → Hexagonal
- Create core/ with domain/ and ports/
- Extract entities to core/domain/
- Define driving ports (use case interfaces) in core/ports/in/
- Define driven ports (repository interfaces) in core/ports/out/
- Move components to adapters/in/web/
- Move HTTP/DB to adapters/out/
Modular → Feature-Sliced Design
- Map modules to FSD layers:
- Shared components → shared/ui/
- Feature-specific → features/[feature]/
- Business entities → entities/[entity]/
- Page compositions → pages/
- Enforce top-down import rules
- Split cross-cutting features into widgets/
Modular → DDD
- Identify bounded contexts from modules
- Add aggregates/ with aggregate roots
- Extract value objects from entity properties
- Create domain events for state changes
- Add command/query handlers in application layer
Any → Modular Monolith
- Start with Modular structure
- Add domain/application/infrastructure layers per module
- Enforce module boundaries with barrel exports
- Validate no cross-module internal imports
- Each module = potential future microservice
Anti-Patterns to Avoid
| Mistake | Correct Approach |
| Moving files without updating imports | Use TypeScript compiler to verify after each move |
| Creating empty architectural layers | Only create layers with actual content |
| Migrating everything at once | One module at a time, least coupled first |
| Skipping barrel exports | Always create index.ts - it enforces boundaries |
| Copying patterns blindly | Adapt to the project's actual needs (Full vs Lite) |
| Ignoring existing tests | Move tests alongside their source files |
Rules
- ALWAYS assess before migrating - understand current state first
- NEVER migrate without user confirmation
- ONE module at a time - never parallel moves
- VALIDATE after each module migration (TypeScript + imports)
- PRESERVE all existing tests (move them, don't delete)
- CREATE docs/ARCHITECTURE.md for the target pattern
- USE the appropriate variant (Full for established teams, Lite for small teams)
- If TypeScript errors appear, FIX them before continuing
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

