Arquitecto de migracion

Plan, execute and validate zero-downtime system migrations. Use when migrating databases (schema evolution, data transfer, CDC), services (strangler-fig, can...

Security Scan

The skill's code and instructions match its stated purpose (migration planning and rollback generation), but there are coherence issues — notably the SKILL.md requires Python and runs CLI-style templates (kubectl, aws, pg_restore, curl, terraform) while the registry metadata declares no required binaries or credentials, which is inconsistent and worth caution.

Purpose & Capability

Name, description, SKILL.md, and the included scripts/references all focus on migration planning, compatibility analysis, and rollback generation — the requested capabilities align with the stated purpose.

Instruction Scope

SKILL.md instructs the agent to run the included Python scripts and to load local reference files (references/*.md). That stays within the migration domain. However the runbooks/templates embedded in scripts include concrete CLI commands (kubectl, aws, terraform, pg_restore, curl, nslookup, etc.) that, if executed, perform cloud or system actions outside pure plan generation. The instructions do not themselves attempt to read unrelated system files or exfiltrate data, but they do encourage running commands that in a real environment require credentials and system access.

Install Mechanism

There is no install spec (instruction-only), which minimizes installer risk, but SKILL.md explicitly requires Python 3.8+ to run scripts. Registry metadata lists no required binaries — that is inconsistent. Additionally, many templates assume availability of external CLIs (kubectl, aws, terraform, pg_restore, curl) but these are not declared as required; this mismatch could lead to silent failures or unexpected attempts to invoke system CLIs.

Credentials

The skill declares no required environment variables or credentials, which is proportionate for a planner/generator. However the code contains many templates and example commands that would need cloud credentials (AWS CLI, kubectl access to clusters, Terraform state, DB restore tools). Because the skill does not request credentials, running those commands would rely on existing environment credentials — the skill itself does not appear to exfiltrate or request secrets, but operators should be aware it produces scripts that will need privileged credentials to execute.

Persistence & Privilege

The skill is not always-enabled and does not request autonomous elevation or modify other skills' configurations. It does not request persistent presence or unusual privileges in the provided metadata.

What to consider before installing

This skill appears to be what it says — it generates migration plans, compatibility reports, and rollback runbooks and includes working Python scripts and rich reference docs. However: 1) SKILL.md requires Python 3.8+ but the registry metadata does not declare any required binary — ensure the runtime has Python before running scripts. 2) The scripts emit and reference commands that, when executed (kubectl, aws, terraform, pg_restore, curl, etc.), require privileged credentials and can change infrastructure or databases; the skill does not request those credentials, so be careful not to run generated commands in production without review. 3) Review the full script contents in a safe environment before executing; run the planner/analysis in a sandbox or on sample inputs first. 4) If you do not want the agent to run scripts automatically, avoid granting autonomous invocation or run the skill only on-demand. If you want to proceed, verify Python is available and inspect any generated commands and placeholders for sensitive values before executing them.

Migration Architect

Convert a migration request into a structured, zero-downtime plan with tested rollback procedures.

Activation

Use this skill when the user asks to:

• migrate a database schema, data set, or storage layer
• move a service or API to a new implementation or platform
• migrate infrastructure between clouds or from on-prem
• assess migration risk, compatibility, or rollback options
• generate runbooks, checklists, or stakeholder comms for a migration

Workflow

1. Classify the migration type: database | service | infrastructure | hybrid.
2. Load patterns for that type from {baseDir}/references/migration_patterns_catalog.md.
3. Run compatibility check if schemas or APIs are provided:

   python {baseDir}/scripts/compatibility_checker.py --before=<old> --after=<new>
   

4. Identify dominant zero-downtime technique (expand-contract, dual-write, CDC, strangler-fig, blue-green, canary). Load {baseDir}/references/zero_downtime_techniques.md if the best technique is unclear.
5. Generate migration plan with phased execution:

   python {baseDir}/scripts/migration_planner.py --config=<config.json>
   

6. Generate rollback procedures for each phase:

   python {baseDir}/scripts/rollback_generator.py --plan=<plan.json>
   

7. Define validation checkpoints: row counts, checksums, business-logic queries. Load {baseDir}/references/data_reconciliation_strategies.md for reconciliation patterns.
8. Emit output: phased plan + rollback procedures + runbook checklists + success metrics.

Output Contract

• Open with migration classification and dominant risk.
• Emit one phased plan with explicit rollback trigger per phase.
• Include pre/during/post checklists as Markdown task lists.
• Declare Functor Information Loss (or equivalent: Irreversible Data Loss Risk) when a phase cannot be rolled back.
• Close with success metrics (technical + business) and monitoring window recommendation.

Risk Tiers

Tier	Criteria	Required before execution
LOW	additive schema changes, no data transformation	staging validation
MEDIUM	data transformation, dual-write window, service cutover	staging + load test + rollback drill
HIGH	destructive changes, cross-cloud, compliance scope	all above + stakeholder sign-off

Guardrails

• Never recommend irreversible steps without an explicit rollback procedure.
• Always separate migration phases so each can be independently rolled back.
• Flag when the target system cannot express all constraints of the source (Information Loss).
• Do not generate feature-flag code or circuit-breaker implementations unless explicitly asked — reference the patterns in references/ instead.

Self Check

Before emitting the plan, verify:

• each phase has a rollback procedure;
• validation checkpoints are defined between phases;
• risk tier is declared and prerequisites are listed;
• no phase assumes success of a prior phase without a checkpoint.