Skill

full-migration-pipeline

Complete Angular migration pipeline that orchestrates all migration skills in sequence. Use when performing end-to-end page migration with analysis, implementation, quality checks, and QA verification.

From one-ui-migration
Install
1
Run in your terminal
$
npx claudepluginhub michael0520/milo-claudekit --plugin one-ui-migration
Tool Access

This skill uses the workspace's default tool permissions.

Skill Content

Full Migration Pipeline

Automated execution of the complete Angular migration workflow, orchestrating all related skills in sequence.

Arguments

  • $ARGUMENTS - Format: --from <source_path> --to <target_path> or --page <page_name>
    • --from: Legacy project path (e.g., /Users/jayden/f2e-networking-jayden/apps/mxsecurity-web/src/app/pages/account)
    • --to: New project path (e.g., libs/mxsecurity/account-page)
    • --page: GitLab page name (e.g., time, account) - When using this parameter, source code is automatically fetched from GitLab

Pipeline Workflow

┌─────────────────────────────────────────────────────────────────┐
│                    FULL MIGRATION PIPELINE                       │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  Phase 1: Analysis                                               │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ 1.1 Execute migrate-page (analysis + document generation)│    │
│  │ 1.2 Execute form-extraction (extract form structure)     │    │
│  │     Output: MIGRATION-ANALYSIS.md                         │    │
│  └─────────────────────────────────────────────────────────┘    │
│                           ↓                                      │
│  Phase 2: Implementation (Manual)                                │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ 2.1 Create Domain Layer (model, api, store, helper)      │    │
│  │ 2.2 Create UI Layer (tables, forms)                       │    │
│  │ 2.3 Create Features Layer (page, dialogs)                 │    │
│  │ 2.4 Create Shell Layer (routes)                           │    │
│  │     [Await user confirmation]                             │    │
│  └─────────────────────────────────────────────────────────┘    │
│                           ↓                                      │
│  Phase 3: Quality Assurance                                      │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ 3.1 Execute migration-lint (compliance check + auto-fix) │    │
│  │ 3.2 Execute migration-review (migration completeness)    │    │
│  │ 3.3 Execute compare-i18n-keys (translation key compare)  │    │
│  │ 3.4 Execute check-barrel-files (check redundant barrels) │    │
│  └─────────────────────────────────────────────────────────┘    │
│                           ↓                                      │
│  Phase 4: QA Verification                                        │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ 4.1 Execute generate-qa-test-cases (generate test cases) │    │
│  │ 4.2 Execute verify-legacy-with-qa-testcases (verify old) │    │
│  │     Output: QA-TEST-CASES.md, LEGACY-VERIFICATION-REPORT.md│   │
│  └─────────────────────────────────────────────────────────┘    │
│                           ↓                                      │
│  Phase 5: Final Report                                           │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ Output MIGRATION-SUMMARY.md (consolidate all results)    │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Execution Flow

Phase 1: Analysis

Automated Execution:

  1. Determine Source Type

    • If --page is provided: Use GitLab API to fetch source code
    • If --from is provided: Use local files
  2. Execute Migration Analysis

    Execute based on source type:
    - /migrate-page --from={source} --to={target}
    - /migrate-page-gitlab --page={page_name}
    
  3. Extract Form Structure (Auxiliary Analysis)

    • Read form definitions from source code
    • List all formControlName and validators

Output:

  • {target}/domain/src/lib/docs/MIGRATION-ANALYSIS.md

User Prompt:

Phase 1 analysis complete. Proceed to Phase 2 implementation?


Phase 2: Implementation

Implementation Guidelines:

Display pending implementation checklist (based on MIGRATION-ANALYSIS.md):

## Implementation Checklist

### Domain Layer
- [ ] Create `{feature}.model.ts` - API types, view models
- [ ] Create `{feature}.api.ts` - API service (inline URLs directly, do not use constants)
- [ ] Create `{feature}.store.ts` - SignalStore
- [ ] Create `{feature}.helper.ts` - Pure functions (if needed)

### Features Layer (Implement First)
- [ ] Create Page component
- [ ] Create Dialog components (if applicable)
- [ ] Verify store injection

### UI Layer (Extract from Features)
- [ ] Extract Table components to UI layer
- [ ] Extract Form components to UI layer
- [ ] Verify input()/output() usage, no store injection

### Shell Layer
- [ ] Create routes
- [ ] Register in app.routes.ts

Important: Form/Table Extraction to UI Layer

Implementation Order:

  1. First complete page functionality in Features Layer
  2. Then extract Form and Table to UI Layer
  3. Features Layer should only retain orchestration code

Extraction Criteria:

  • <form> containing <mat-form-field> -> Extract to UI
  • Tables -> Prefer common-table pattern (reference libs/mxsecurity/shared/ui/src/lib/common-table)
  • Dialogs remain in Features (but forms inside Dialogs can be extracted to UI)

Table Implementation Approach:

  • Prefer using CommonTableComponent with MxColumnDef[] for column definitions
  • Only create standalone table component in UI layer for complex customization requirements

Exceptions (No Extraction Required):

  • Extremely simple pages (e.g., only radio group without form validation)
  • Components used by a single page without complex form logic

Patterns to Avoid

// DO NOT use TRANSLOCO_SCOPE
providers: [{ provide: TRANSLOCO_SCOPE, useValue: { scope: 'xxx' } }]

// DO NOT use endpoint constants
readonly #ENDPOINTS = { API: '/api/xxx' };

// CORRECT: Inline URLs directly
this.#rest.get('/api/xxx');

Chunked Migration Strategy (Reducing Omission Risk)

Principle: Process from large sections to small units, completing each before proceeding

Page Structure Analysis:
┌─────────────────────────────────────┐
│ Page                                │
│ ┌─────────────────────────────────┐ │
│ │ mat-tab-group                   │ │
│ │ ┌───────────┬───────────┐       │ │
│ │ │  Tab 1    │  Tab 2    │       │ │
│ │ ├───────────┴───────────┤       │ │
│ │ │ mat-card / section 1  │       │ │
│ │ ├───────────────────────┤       │ │
│ │ │ mat-card / section 2  │       │ │
│ │ └───────────────────────┘       │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────┘

Step 1: Segment by mat-tab

  • First identify the number of tabs on the page
  • Process each tab independently, completing one before proceeding to the next
  • Create a checklist corresponding to each tab

Step 2: Segment by mat-card / content-wrapper

  • Within each tab, identify all cards/sections
  • Treat each card as an independent migration unit
  • Verify immediately after completing each card

Step 3: Migrate and Verify Incrementally

  • Migration order: top to bottom, left to right
  • Execute /migration-lint after completing each segment
  • Compare with legacy code to confirm no omissions

Example Checklist:

## Chunked Migration Progress

### Tab 1: General Settings
- [x] Card 1.1: Basic Info
- [x] Card 1.2: Network Config
- [ ] Card 1.3: Advanced Options

### Tab 2: Security
- [ ] Card 2.1: Authentication
- [ ] Card 2.2: Certificates

Generate Library Structure:

nx g @one-ui/one-plugin:library mxsecurity {page-name} all

Await User Confirmation:

After completing the above implementation, enter "done" or "continue" to proceed to Phase 3. For pattern queries, use /migration-patterns <keyword>


Phase 3: Quality Assurance

Automated Execution:

  1. Compliance Check + Auto-fix

    /migration-lint {target}
    
    • Auto-fix: mat-raised-button -> mat-flat-button
    • Auto-fix: *ngIf -> @if
    • Auto-fix: Validators -> OneValidators
    • Generate compliance report
  2. Migration Completeness Check

    /migration-review --from={source} --to={target}
    
    • Compare form controls
    • Compare validators
    • Compare translation keys
    • Compare event bindings
  3. Translation Key Comparison (For primary HTML files)

    /compare-i18n-keys --from={source}/*.html --to={target}/**/*.html
    
  4. Check Redundant Barrel Files

    /check-barrel-files {target}
    

Output:

  • Reports for each check (displayed in conversation)
  • List of auto-fixed changes

User Prompt:

Phase 3 quality assurance complete. X issues auto-fixed, Y issues require manual intervention. Proceed to Phase 4 QA verification?


Phase 4: QA Verification

Automated Execution:

  1. Generate QA Test Cases

    /generate-qa-test-cases {target}
    
    • Extract test cases from new code
    • Generate structured test report
  2. Verify Legacy Code

    /verify-legacy-with-qa-testcases {source}
    
    • Verify legacy code using test cases
    • Confirm functional consistency

Output:

  • {target}/domain/src/lib/docs/QA-TEST-CASES.md
  • {target}/domain/src/lib/docs/LEGACY-VERIFICATION-REPORT.md

Phase 5: Final Report

Auto-generate MIGRATION-SUMMARY.md:

# {Feature Name} Migration Summary Report

**Migration Date:** {date}
**Source:** {source_path}
**Target:** {target_path}

## Migration Status

| Phase | Status | Notes |
|-------|--------|-------|
| Phase 1: Analysis | Complete | |
| Phase 2: Implementation | Complete | |
| Phase 3: Quality Assurance | Complete | X items auto-fixed |
| Phase 4: QA Verification | Complete | |

## Generated Documents

- [x] MIGRATION-ANALYSIS.md
- [x] QA-TEST-CASES.md
- [x] LEGACY-VERIFICATION-REPORT.md
- [x] MIGRATION-SUMMARY.md (this document)

## Compliance Report Summary

### Auto-fixed Items
{List of auto-fixed items}

### Items Requiring Manual Intervention
{List of items requiring manual intervention}

## Migration Completeness

| Category | Source | Target | Completeness |
|----------|--------|--------|--------------|
| Form Controls | X | X | 100% |
| Validators | X | X | 100% |
| Translation Keys | X | X | 100% |
| Event Bindings | X | X | 100% |

## Next Steps

1. [ ] Execute comprehensive testing
2. [ ] Code Review
3. [ ] Merge to main branch

Output Location: {target}/domain/src/lib/docs/MIGRATION-SUMMARY.md


Usage Examples

Migration from Local Source

/full-migration-pipeline --from=/Users/jayden/f2e-networking-jayden/apps/mxsecurity-web/src/app/pages/account --to=libs/mxsecurity/account-page

Migration from GitLab

/full-migration-pipeline --page=account

Interruption and Resumption

If the workflow is interrupted, continue from a specific phase:

# Execute Phase 3 quality assurance only
/migration-lint libs/mxsecurity/account-page

# Execute Phase 4 QA verification only
/generate-qa-test-cases libs/mxsecurity/account-page
/verify-legacy-with-qa-testcases /path/to/legacy

Auxiliary Skills

Available for use at any point during pipeline execution:

SkillPurpose
/migration-patterns <keyword>Query migration patterns
/icon-replacement <icon>Find replacement icons
/ui-layout-guide <query>UI layout guidelines
Similar Skills
cache-components

Expert guidance for Next.js Cache Components and Partial Prerendering (PPR). **PROACTIVE ACTIVATION**: Use this skill automatically when working in Next.js projects that have `cacheComponents: true` in their next.config.ts/next.config.js. When this config is detected, proactively apply Cache Components patterns and best practices to all React Server Component implementations. **DETECTION**: At the start of a session in a Next.js project, check for `cacheComponents: true` in next.config. If enabled, this skill's patterns should guide all component authoring, data fetching, and caching decisions. **USE CASES**: Implementing 'use cache' directive, configuring cache lifetimes with cacheLife(), tagging cached data with cacheTag(), invalidating caches with updateTag()/revalidateTag(), optimizing static vs dynamic content boundaries, debugging cache issues, and reviewing Cache Component implementations.

138.5k
Stats
Parent Repo Stars0
Parent Repo Forks0
Last CommitJan 24, 2026