Token导航 LogoToken导航TokenDH.com
研究检索只读github未标认证来源可访问许可证需确认审计通过

migration-planner移民规划师

Agent Skill

migration-planner 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

196

周安装

8

GitHub Stars

2

下载量

63
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:migration-planner(移民规划师)
来源仓库:https://github.com/monkey1sai/openai-cli
仓库路径:skills/migration-planner
安装命令:
npx skills add https://github.com/monkey1sai/openai-cli --skill migration-planner
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/monkey1sai/openai-cli --skill migration-planner

简介

用于查找、检索和筛选相关信息。migration-planner 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

  • 适合根据关键词或任务场景快速定位候选结果。
  • 通过 github 安装,适用于 Codex、Claude、Cursor 等宿主环境。
  • 建议结合原始 README 核验具体用法和参数设置。
  • 安装前需确认权限范围、维护状态及是否触发联网或命令执行。

SKILL.md

Migration Planner

Execute safe, zero-downtime migrations with validation and rollback plans.

Migration Patterns

1. Feature Flag Migration (Safest)

Phase 1: Deploy new code (disabled)
Phase 2: Enable for 1% traffic
Phase 3: Ramp to 10%, 50%, 100%
Phase 4: Remove old code

2. Dual Write Migration

Phase 1: Write to both old and new
Phase 2: Backfill old → new
Phase 3: Read from new (write both)
Phase 4: Stop writing to old
Phase 5: Decommission old

3. Blue-Green Deployment

Blue (current) → Green (new)
Switch traffic: Blue → Green
Rollback available: Green → Blue

Complete Migration Plan Template

# Migration Plan: MySQL → PostgreSQL

## Overview

**What:** Migrate user database from MySQL to PostgreSQL
**Why:** Better JSON support, improved performance
**When:** Q1 2024
**Owner:** Database Team
**Risk Level:** HIGH

## Current State

- MySQL 8.0
- 500GB data
- 100K users
- 1000 writes/min
- 10,000 reads/min

## Target State

- PostgreSQL 15
- Same data model
- No downtime
- Data validation 100% match

## Phases

### Phase 1: Dual Write (Week 1-2)

**Goal:** Write to both databases

**Steps:**

1. Deploy PostgreSQL cluster
2. Create schema in PostgreSQL
3. Deploy dual-write code
4. Enable dual writes (MySQL primary, PostgreSQL secondary)

**Code:**

async function createUser(data: CreateUserDto) { // Write to MySQL (primary) const mysqlUser = await mysql.users.create(data);

// Write to PostgreSQL (secondary, fire and forget) postgres.users.create(data).catch((err) => { logger.error("PostgreSQL write failed", err); });

return mysqlUser; // Still trust MySQL }

Validation:

  • Monitor PostgreSQL write success rate
  • Compare row counts daily
  • Alert if drift >0.1%

Rollback: Disable PostgreSQL writes

Phase 2: Backfill (Week 3-4)

Goal: Copy historical data

Steps:

  1. Take MySQL snapshot
  2. Run backfill script in batches
  3. Validate data integrity
  4. Resume from failure automatically

Script:

def backfill():
    last_id = get_last_migrated_id()
    batch_size = 1000

    while True:
        users = mysql.query(
            "SELECT * FROM users WHERE id > %s LIMIT %s",
            [last_id, batch_size]
        )

        if not users:
            break

        postgres.bulk_insert(users)
        last_id = users[-1]['id']
        save_checkpoint(last_id)

        time.sleep(0.1)  # Rate limit

Validation:

  • Row count match
  • Random sample comparison (1000 rows)
  • Checksum comparison

Rollback: Delete PostgreSQL data

Phase 3: Dual Read (Week 5)

Goal: Validate PostgreSQL reads

Steps:

  1. Deploy shadow read code
  2. Read from both (MySQL primary)
  3. Compare results
  4. Log mismatches

Code:

async function getUser(id: string) {
  const mysqlUser = await mysql.users.findById(id);

  // Shadow read from PostgreSQL
  postgres.users.findById(id).then((pgUser) => {
    if (!deepEqual(mysqlUser, pgUser)) {
      logger.warn("Data mismatch", { id, mysqlUser, pgUser });
      metrics.increment("migration.mismatch");
    }
  });

  return mysqlUser; // Still trust MySQL
}

Validation:

  • Mismatch rate <0.01%
  • PostgreSQL query performance acceptable

Rollback: Remove shadow reads

Phase 4: Flip Read Traffic (Week 6)

Goal: Read from PostgreSQL

Steps:

  1. Feature flag: read from PostgreSQL (1% traffic)
  2. Monitor errors, latency
  3. Ramp: 1% → 10% → 50% → 100%
  4. Still writing to both

Code:

async function getUser(id: string) {
  if (featureFlags.readFromPostgres) {
    return postgres.users.findById(id);
  }
  return mysql.users.findById(id);
}

Validation:

  • Error rate unchanged
  • Latency p95 <500ms
  • No user complaints

Rollback: Flip feature flag off

Phase 5: Stop MySQL Writes (Week 7)

Goal: PostgreSQL is now primary

Steps:

  1. Stop writing to MySQL
  2. Keep MySQL running (read-only)
  3. Monitor for issues

Code:

async function createUser(data: CreateUserDto) {
  return postgres.users.create(data);
  // No longer writing to MySQL
}

Validation:

  • All operations working
  • MySQL not receiving writes

Rollback: Re-enable MySQL writes

Phase 6: Decommission (Week 8)

Goal: Remove MySQL

Steps:

  1. Archive MySQL data
  2. Shutdown MySQL cluster
  3. Remove MySQL client code

Rollback: Not available (point of no return)

Validation Strategy

Data Integrity Checks

def validate_migration():
    # Row counts
    mysql_count = mysql.query("SELECT COUNT(*) FROM users")[0]
    pg_count = postgres.query("SELECT COUNT(*) FROM users")[0]
    assert mysql_count == pg_count

    # Random sampling
    sample = mysql.query("SELECT * FROM users ORDER BY RAND() LIMIT 1000")
    for row in sample:
        pg_row = postgres.query("SELECT * FROM users WHERE id = %s", [row['id']])
        assert row == pg_row

    # Checksums
    mysql_checksum = mysql.query("SELECT MD5(GROUP_CONCAT(id, email)) FROM users")
    pg_checksum = postgres.query("SELECT MD5(STRING_AGG(id::text || email, '')) FROM users")
    assert mysql_checksum == pg_checksum

Rollback Plans

Phase 1-3 Rollback (Easy)

  • Disable PostgreSQL writes
  • No impact to users
  • Data in MySQL still valid

Phase 4 Rollback (Medium)

  • Flip feature flag
  • Route reads back to MySQL
  • Minor user impact (seconds)

Phase 5+ Rollback (Hard)

  • Must re-enable MySQL writes
  • Potential data loss (writes since phase 5)
  • Requires dual-write resumption

Risk Mitigation

Risk 1: Data Loss

Mitigation:

  • Dual writes until validated
  • Transaction logs captured
  • Continuous backups

Risk 2: Performance Degradation

Mitigation:

  • Load test PostgreSQL
  • Query optimization
  • Connection pooling

Risk 3: Schema Differences

Mitigation:

  • Schema validation script
  • Test migrations in staging
  • Document data type differences

Communication Plan

Stakeholder Updates

**Week 0:** Migration announced
**Week 2:** Phase 1 complete (dual writes)
**Week 4:** Backfill complete
**Week 6:** Traffic shifted to PostgreSQL
**Week 8:** Migration complete

Status Dashboard

  • Current phase
  • Data sync status (%)
  • Validation results
  • Error rates

Testing Plan

Pre-Migration Testing

  1. Test in development
  2. Full migration in staging
  3. Load test PostgreSQL
  4. Validate rollback procedures

During Migration

  1. Continuous monitoring
  2. Automated validation
  3. Manual spot checks
  4. User acceptance testing

Best Practices

  1. Small batches: Migrate incrementally
  2. Dual write: Keep both systems synchronized
  3. Feature flags: Control rollout
  4. Validate continuously: Don't trust, verify
  5. Rollback ready: Plan for worst case
  6. Monitor closely: Track metrics
  7. Communicate often: Keep stakeholders informed

Output Checklist

  • Migration phases defined (5-7 phases)
  • Dual write implementation
  • Backfill script ready
  • Validation strategy
  • Feature flags configured
  • Rollback plans per phase
  • Risk mitigation strategies
  • Communication plan
  • Monitoring dashboard
  • Testing checklist

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

35.54%
按下载量换算22

Claude

31.64%
按下载量换算20

Cursor

17.97%
按下载量换算11

Gemini CLI

10.59%
按下载量换算7

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills