agentleFS
NoaiRoxNoaiRox/specialist-agent/skills/migrate-architecture/SKILL.md

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.

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
  1. Very specific:

    Check for barrel exports (index.ts)

    line 57
  2. Distinctive:

    Check import patterns between directories

    line 58
  3. Distinctive:

    Start with the LEAST coupled module

    line 103
  4. Distinctive:

    Update: all import paths:

    line 112
  5. Distinctive:

    Use Grep to find all imports referencing moved files

    line 113
  6. Distinctive:

    Update each import to the new path

    line 114
  7. Distinctive:

    Use barrel exports where possible

    line 115
  8. Distinctive:

    Verify: no broken imports:

    line 121
  9. Very specific:

    Create modules/[feature]/components/ for each group

    line 158
  10. Very specific:

    Create index.ts for each module

    line 160
  11. Distinctive:

    Create service layer in each module

    line 168
  12. Distinctive:

    Create use-case classes for each business operation

    line 174
  13. Distinctive:

    Create use-cases from service methods

    line 183
  14. Distinctive:

    Create core/ with domain/ and ports/

    line 189
  15. Distinctive:

    Add aggregates/ with aggregate roots

    line 209
  16. Distinctive:

    Create domain events for state changes

    line 211
  17. Distinctive:

    Add command/query handlers in application layer

    line 212
  18. Distinctive:

    Start with Modular structure

    line 216
  19. Very specific:

    Add domain/application/infrastructure layers per module

    line 217
  20. Distinctive:

    ALWAYS assess before migrating - understand current state first

    line 235
  21. Distinctive:

    NEVER migrate without user confirmation

    line 236
  22. Very specific:

    CREATE docs/ARCHITECTURE.md for the target pattern

    line 240
  23. Distinctive:

    USE the appropriate variant (Full for established teams, Lite for small teams)

    line 241
  24. Distinctive:

    If TypeScript errors appear, FIX them before continuing

    line 242

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/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

PatternDescription
Flat / Component-DrivenSingle 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 DesignComponents by granularity: atoms > molecules > organisms
Clean ArchitectureDomain > Use Cases > Adapters > Frameworks
Hexagonal (Ports & Adapters)Core with ports, infrastructure in adapters

Backend / Fullstack

PatternDescription
MVC / LayeredHorizontal: controllers, services, repositories
Modular MonolithSingle deployment, strict module boundaries
Clean ArchitectureConcentric layers, dependency rule inward
HexagonalPorts & Adapters, domain isolated
DDDBounded contexts, aggregates, domain events
CQRSSeparate command/query paths
Event-DrivenAsync communication via events
MicroservicesIndependent services, own databases

Variants

VariantDescription
FullComplete implementation with all layers and patterns
Lite (Simplified)Fewer layers, same principles. For smaller teams

Workflow

Phase 1: Assessment

  1. Read docs/ARCHITECTURE.md if it exists
  2. Scan the project structure:
    • List all directories under src/ (or root if no src/)
    • Identify current architecture pattern by matching directory names
    • Count modules/features/components
    • Check for barrel exports (index.ts)
    • Check import patterns between directories
  3. Identify the current architecture pattern and confidence level
  4. 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
  1. Ask for confirmation before proceeding

Phase 2: Planning

  1. Generate the target directory structure based on:
    • Target architecture pattern
    • Detected framework (React, Vue, Next.js, etc.)
    • Chosen variant (Full or Lite)
  2. 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/
  3. Identify new files to create:
    • Barrel exports (index.ts) per module
    • Adapter layer (if Full variant)
    • Type separation (.types.ts + .contracts.ts for Full)
  4. 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:

  1. Create target directory structure (mkdir -p)
  2. 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
  3. 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)
  4. 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
  5. Generate or update docs/ARCHITECTURE.md for the target pattern

Phase 4: Validation

  1. Check directory structure matches target pattern
  2. Verify no broken imports:
    npx tsc --noEmit 2>&1 | head -50
  3. Validate import rules:
    • Modules don't import from each other (Modular)
    • Dependencies point inward (Clean/Hexagonal)
    • FSD layers import top-down only
  4. Run tests if they exist:
    npm test 2>&1 | tail -20
  5. 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: ✓ generated

Migration Strategies by Pattern

Flat → Modular

  1. Group components by domain/feature
  2. Create modules/[feature]/components/ for each group
  3. Move related services, types into module
  4. Create index.ts for each module
  5. Move shared components to shared/components/

MVC → Modular

  1. For each controller+service pair, create a module
  2. Move controller logic to module's hooks/composables
  3. Move models to module's types/
  4. Create service layer in each module
  5. Move shared middleware to shared/

MVC → Clean Architecture

  1. Extract domain entities (pure business objects, no framework deps)
  2. Create use-case classes for each business operation
  3. Define port interfaces for external dependencies
  4. Move database/HTTP code to infrastructure/ as adapter implementations
  5. Wire use cases to ports in the composition root

Modular → Clean Architecture

  1. For each module, add domain/ and application/ sub-layers
  2. Extract entities from services into domain/entities/
  3. Create use-cases from service methods
  4. Define port interfaces for external deps
  5. Move HTTP/DB code to infrastructure/

Modular → Hexagonal

  1. Create core/ with domain/ and ports/
  2. Extract entities to core/domain/
  3. Define driving ports (use case interfaces) in core/ports/in/
  4. Define driven ports (repository interfaces) in core/ports/out/
  5. Move components to adapters/in/web/
  6. Move HTTP/DB to adapters/out/

Modular → Feature-Sliced Design

  1. Map modules to FSD layers:
    • Shared components → shared/ui/
    • Feature-specific → features/[feature]/
    • Business entities → entities/[entity]/
    • Page compositions → pages/
  2. Enforce top-down import rules
  3. Split cross-cutting features into widgets/

Modular → DDD

  1. Identify bounded contexts from modules
  2. Add aggregates/ with aggregate roots
  3. Extract value objects from entity properties
  4. Create domain events for state changes
  5. Add command/query handlers in application layer

Any → Modular Monolith

  1. Start with Modular structure
  2. Add domain/application/infrastructure layers per module
  3. Enforce module boundaries with barrel exports
  4. Validate no cross-module internal imports
  5. Each module = potential future microservice

Anti-Patterns to Avoid

MistakeCorrect Approach
Moving files without updating importsUse TypeScript compiler to verify after each move
Creating empty architectural layersOnly create layers with actual content
Migrating everything at onceOne module at a time, least coupled first
Skipping barrel exportsAlways create index.ts - it enforces boundaries
Copying patterns blindlyAdapt to the project's actual needs (Full vs Lite)
Ignoring existing testsMove tests alongside their source files

Rules

  1. ALWAYS assess before migrating - understand current state first
  2. NEVER migrate without user confirmation
  3. ONE module at a time - never parallel moves
  4. VALIDATE after each module migration (TypeScript + imports)
  5. PRESERVE all existing tests (move them, don't delete)
  6. CREATE docs/ARCHITECTURE.md for the target pattern
  7. USE the appropriate variant (Full for established teams, Lite for small teams)
  8. If TypeScript errors appear, FIX them before continuing

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.