migration-to-aws

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Migration to AWS Skill

迁移至AWS Skill

Philosophy

理念

Re-platform by default: Select AWS services that match GCP workload types (e.g., Cloud Run → Fargate, Cloud SQL → RDS).
Dev sizing unless specified: Default to development-tier capacity (e.g., db.t4g.micro, single AZ). Upgrade only on user direction.
Cost informed decisions: Always estimate costs before generating infrastructure code.
No human one-time migration costs: Do not present human labor, professional services, or people-time work as dollar estimates or "one-time migration cost" budget categories. Vendor charges grounded in data (for example GCP data transfer egress in the infra estimate when billing exists) are allowed.
Multi-signal approach: Design phase adapts based on available inputs — Terraform IaC for infrastructure, billing data for service mapping, and app code for AI workload detection.
Terraform generation preferred: Use Terraform as the default IaC tool for migration artifacts.
Architecture choice preservation: Preserve existing application architecture patterns during migration.
BigQuery /
google_bigquery_*
: The skill does not recommend a specific AWS analytics or warehouse service. During Clarify, if discovery shows BigQuery (IaC
```
google_bigquery_*
```
and/or billing rows for BigQuery), you must surface the specialist advisory before Design (see
```
references/phases/clarify/clarify.md
```
). Design output uses Deferred — specialist engagement
; keep directing the user to their AWS account team and/or a data analytics migration partner through Design, Estimate, and docs (see
```
references/phases/design/design-infra.md
```
BigQuery specialist gate).

默认采用重新平台化策略：选择与GCP工作负载类型匹配的AWS服务（例如：Cloud Run → Fargate、Cloud SQL → RDS）。
默认开发环境规格：默认使用开发级容量（例如：db.t4g.micro、单可用区）。仅在用户指示下升级规格。
基于成本的决策：生成基础设施代码前必须先估算成本。
不包含人工一次性迁移成本：不得将人工劳动力、专业服务或人力工时作为美元估算值或“一次性迁移成本”预算类别呈现。基于数据的供应商费用（例如当存在账单数据时，基础设施估算中包含GCP数据传输出口费用）是允许的。
多信号方法：设计阶段会根据可用输入进行调整——基础设施使用Terraform IaC，服务映射使用账单数据，AI工作负载检测使用应用代码。
优先生成Terraform：默认使用Terraform作为迁移工件的IaC工具。
保留架构选择：迁移期间保留现有应用架构模式。
BigQuery /
google_bigquery_*
：本Skill不推荐特定的AWS分析或数据仓库服务。在明确需求（Clarify）阶段，如果发现存在BigQuery（IaC中的
google_bigquery_*
和/或BigQuery的账单记录），必须在设计（Design）阶段之前告知用户需咨询专家（详见
references/phases/clarify/clarify.md
）。设计输出使用
延迟处理——需专家参与
；在设计、估算和文档阶段持续引导用户联系其AWS客户团队和/或数据分析迁移合作伙伴（详见
```
references/phases/design/design-infra.md
```
中的BigQuery专家对接说明）。

Definitions

定义

"Load" = Read the file using the Read tool and follow its instructions. Do not summarize or skip sections.
$MIGRATION_DIR
= The run-specific directory under
```
.migration/
```
(e.g.,
```
.migration/0226-1430/
```
). Set during Phase 1 (Discover).

"Load" = 使用读取工具读取文件并遵循其指令。不得总结或跳过任何章节。
$MIGRATION_DIR
=
```
.migration/
```
下的运行特定目录（例如：
```
.migration/0226-1430/
```
）。在第1阶段（发现）中设置。

Context Loading Rules

上下文加载规则

Each phase loads reference files on demand. To keep per-turn context manageable and prevent instruction-following degradation:

Budget: Each phase should load no more than ~800 lines of instructions (excluding user artifacts like JSON profiles and MCP tool results).
Conditional loading: Reference files with trigger conditions (e.g.,
```
agentic_profile.is_agentic == true
```
) MUST NOT be loaded unless the condition is met. Do not speculatively load files.
No duplication: Model mapping tables, pricing data, and shared warnings exist in one canonical file. Other files reference them; they do not copy them inline.
Progressive depth: Phase orchestrators (
```
design.md
```
,
```
generate.md
```
) contain short routing logic that points to detailed sub-files. Load the sub-file only when its path is selected.

Conditional reference files (load ONLY when condition is true):

File	Condition
`design-refs/ai-gemini-to-bedrock.md`	`ai-workload-profile.json` exists AND `summary.ai_source` = `"gemini"` or `"both"`
`design-refs/ai-openai-to-bedrock.md`	`ai-workload-profile.json` exists AND `summary.ai_source` = `"openai"` or `"both"`
`design-refs/ai.md`	`ai-workload-profile.json` exists AND `summary.ai_source` = `"other"`
`design-refs/design-ref-harness.md`	`agentic_profile.is_agentic == true` AND `ai_constraints.agentic.migration_approach == "harness"`
`design-refs/design-ref-agentic-to-agentcore.md`	`agentic_profile.is_agentic == true` AND `ai_constraints.agentic.migration_approach == "strands"`
`shared/retarget-gotchas.md`	`agentic_profile.is_agentic == true` AND `ai_constraints.agentic.migration_approach == "retarget"`

When adding new reference files, verify the phase's total loaded instructions remain under budget. If a new file would exceed ~800 lines when combined with other loaded refs, split it or make it conditional.

每个阶段会按需加载参考文件。为保持每轮上下文可控并避免指令执行偏差：

预算限制：每个阶段加载的指令不应超过约800行（不包括用户工件如JSON配置文件和MCP工具结果）。
条件加载：带有触发条件的参考文件（例如：
```
agentic_profile.is_agentic == true
```
）仅在条件满足时加载。不得推测性加载文件。
无重复内容：模型映射表、定价数据和通用警告仅存在于一个标准文件中。其他文件仅引用它们，不复制内容。
渐进式深度：阶段编排器（
```
design.md
```
、
```
generate.md
```
）包含简短的路由逻辑，指向详细的子文件。仅当选择了子文件路径时才加载该子文件。

条件参考文件（仅在条件为真时加载）：

文件	条件
`design-refs/ai-gemini-to-bedrock.md`	存在 `ai-workload-profile.json` 且 `summary.ai_source` 等于 `"gemini"` 或 `"both"`
`design-refs/ai-openai-to-bedrock.md`	存在 `ai-workload-profile.json` 且 `summary.ai_source` 等于 `"openai"` 或 `"both"`
`design-refs/ai.md`	存在 `ai-workload-profile.json` 且 `summary.ai_source` 等于 `"other"`
`design-refs/design-ref-harness.md`	`agentic_profile.is_agentic == true` 且 `ai_constraints.agentic.migration_approach == "harness"`
`design-refs/design-ref-agentic-to-agentcore.md`	`agentic_profile.is_agentic == true` 且 `ai_constraints.agentic.migration_approach == "strands"`
`shared/retarget-gotchas.md`	`agentic_profile.is_agentic == true` 且 `ai_constraints.agentic.migration_approach == "retarget"`

添加新参考文件时，需验证阶段加载的总指令行数是否保持在预算内。如果新文件与其他已加载参考文件组合后超过约800行，请拆分文件或设置为条件加载。

Prerequisites

先决条件

User must provide at least one GCP source:

Terraform IaC:
```
.tf
```
files (with optional
```
.tfvars
```
,
```
.tfstate
```
)
Application code: Source files with GCP SDK or AI framework imports
Billing data: GCP billing/cost/usage export files (CSV or JSON)

If none of the above are found, stop and ask user to provide at least one source type.

用户必须提供至少一种GCP源：

Terraform IaC：
```
.tf
```
文件（可选包含
```
.tfvars
```
、
```
.tfstate
```
）
应用代码：包含GCP SDK或AI框架导入的源文件
账单数据：GCP账单/成本/使用情况导出文件（CSV或JSON格式）

如果未找到上述任何一种源，请停止操作并要求用户提供至少一种源类型。

State Machine

状态机

This is the execution controller. After completing each phase, consult this table to determine the next action.

Current State	Condition	Next Action
`discover`	`phases.discover != "completed"`	Load `references/phases/discover/discover.md`
`clarify`	`phases.discover == "completed"` AND `phases.clarify != "completed"`	Load `references/phases/clarify/clarify.md`
`design`	`phases.clarify == "completed"` AND `phases.design != "completed"`	Load `references/phases/design/design.md`
`estimate`	`phases.design == "completed"` AND `phases.estimate != "completed"`	Load `references/phases/estimate/estimate.md`
`generate`	`phases.estimate == "completed"` AND `phases.generate != "completed"`	Load `references/phases/generate/generate.md`
`complete`	`phases.generate == "completed"` AND `phases.feedback == "pending"`	Set `phases.feedback` to `"completed"` (user had two chances), then migration complete
`complete`	`phases.generate == "completed"` AND `phases.feedback == "completed"`	Migration planning complete

How to determine current state (deterministic):

Read
```
$MIGRATION_DIR/.phase-status.json
```
If
```
current_phase
```
exists, use it (must match one of: discover, clarify, design, estimate, generate, complete)
Otherwise use ordered phase evaluation:
```
discover
```
→
```
clarify
```
→
```
design
```
→
```
estimate
```
→
```
generate
```
Pick the first phase in that order where
```
phases.<phase> != "completed"
```
; if none, state is
```
complete
```

Phase gate checks: If prior phase incomplete, do not advance (e.g., cannot enter estimate without completed design).

Clarify is mandatory: Do not load

references/phases/design/design.md

references/phases/estimate/estimate.md

, or

references/phases/generate/generate.md

unless

$MIGRATION_DIR/.phase-status.json

exists and

phases.clarify

is exactly

"completed"

. A

preferences.json

file alone is not sufficient proof that Clarify ran. If the user asks to skip Clarify or jump straight to Design, cost estimate, or artifact generation, refuse briefly, then load

references/phases/clarify/clarify.md

and run Phase 2. There is no exception for "quick" or "obvious" migrations.

Feedback checkpoints: Feedback is not a sequential phase — it is offered at two interleaved checkpoints (after Discover and after Estimate). See the Feedback Checkpoints section below for details.

这是执行控制器。完成每个阶段后，请参考此表确定下一步操作。

当前状态	条件	下一步操作
`discover`	`phases.discover != "completed"`	加载 `references/phases/discover/discover.md`
`clarify`	`phases.discover == "completed"` 且 `phases.clarify != "completed"`	加载 `references/phases/clarify/clarify.md`
`design`	`phases.clarify == "completed"` 且 `phases.design != "completed"`	加载 `references/phases/design/design.md`
`estimate`	`phases.design == "completed"` 且 `phases.estimate != "completed"`	加载 `references/phases/estimate/estimate.md`
`generate`	`phases.estimate == "completed"` 且 `phases.generate != "completed"`	加载 `references/phases/generate/generate.md`
`complete`	`phases.generate == "completed"` 且 `phases.feedback == "pending"`	将 `phases.feedback` 设置为 `"completed"` （用户有两次机会），然后迁移完成
`complete`	`phases.generate == "completed"` 且 `phases.feedback == "completed"`	迁移规划完成

如何确定当前状态（确定性规则）：

读取
```
$MIGRATION_DIR/.phase-status.json
```
如果存在
```
current_phase
```
，则使用该值（必须为以下值之一：discover、clarify、design、estimate、generate、complete）
否则使用有序阶段评估：
```
discover
```
→
```
clarify
```
→
```
design
```
→
```
estimate
```
→
```
generate
```
选择该顺序中第一个
```
phases.<phase> != "completed"
```
的阶段；如果所有阶段均已完成，则状态为
```
complete
```

阶段门检查：如果前一阶段未完成，则不得推进（例如：未完成设计阶段则无法进入估算阶段）。

明确需求阶段为必填项：除非

$MIGRATION_DIR/.phase-status.json

存在且

phases.clarify

恰好为

"completed"

，否则不得加载

references/phases/design/design.md

、

references/phases/estimate/estimate.md

或

references/phases/generate/generate.md

。仅存在

preferences.json

文件不足以证明明确需求阶段已执行。如果用户要求跳过明确需求阶段或直接进入设计、成本估算或工件生成阶段，请简短拒绝，然后加载

references/phases/clarify/clarify.md

并执行第2阶段。对于“快速”或“明显”的迁移也无例外。

反馈检查点：反馈不是顺序阶段——它在两个交错的检查点提供（发现阶段之后和估算阶段之后）。详情请见下文的反馈检查点部分。

State Validation

状态验证

When reading

$MIGRATION_DIR/.phase-status.json

, validate before proceeding:

Multiple sessions: If multiple directories exist under
```
.migration/
```
, list them with their phase status and ask: [A] Resume latest, [B] Start fresh, [C] Cancel.
Invalid JSON: If
```
.phase-status.json
```
fails to parse, STOP. Output: "State file corrupted (invalid JSON). Delete the file and restart the current phase."
Unrecognized phase: If
```
phases
```
object contains a phase not in {discover, clarify, design, estimate, generate, feedback}, STOP. Output: "Unrecognized phase: [value]. Valid phases: discover, clarify, design, estimate, generate, feedback."
Unrecognized status: If any
```
phases.*
```
value is not in {pending, in_progress, completed}, STOP. Output: "Unrecognized status: [value]. Valid values: pending, in_progress, completed."
Invalid
current_phase
(if present): If
```
current_phase
```
is not in {discover, clarify, design, estimate, generate, complete}, STOP. Output: "Unrecognized current_phase: [value]. Valid values: discover, clarify, design, estimate, generate, complete."
Out-of-order completion: For ordered phases [discover, clarify, design, estimate, generate], if any later phase is
```
"completed"
```
while an earlier phase is not
```
"completed"
```
, STOP. Output: "Inconsistent phase ordering detected. Reconcile
```
.phase-status.json
```
before resuming."
Multiple active phases: Across core phases {discover, clarify, design, estimate, generate}, at most one phase may be
```
"in_progress"
```
. If >1, STOP. Output: "Multiple phases are in_progress. Keep only one active phase before resuming."

读取

$MIGRATION_DIR/.phase-status.json

时，需先验证再继续：

多会话：如果
```
.migration/
```
下存在多个目录，请列出它们及其阶段状态并询问：[A] 恢复最新会话，[B] 开始新会话，[C] 取消。
无效JSON：如果
```
.phase-status.json
```
解析失败，请停止操作。输出："状态文件损坏（无效JSON）。删除该文件并重新启动当前阶段。"
未识别阶段：如果
```
phases
```
对象包含不在{discover, clarify, design, estimate, generate, feedback}中的阶段，请停止操作。输出："未识别阶段：[值]。有效阶段：discover、clarify、design、estimate、generate、feedback。"
未识别状态：如果任何
```
phases.*
```
的值不在{pending, in_progress, completed}中，请停止操作。输出："未识别状态：[值]。有效值：pending、in_progress、completed。"
无效
current_phase
（如果存在）：如果
```
current_phase
```
不在{discover, clarify, design, estimate, generate, complete}中，请停止操作。输出："未识别current_phase：[值]。有效值：discover、clarify、design、estimate、generate、complete。"
无序完成：对于有序阶段[discover, clarify, design, estimate, generate]，如果任何后续阶段为
```
"completed"
```
而前序阶段未
```
"completed"
```
，请停止操作。输出："检测到不一致的阶段顺序。恢复
```
.phase-status.json
```
后再继续。"
多个活跃阶段：在核心阶段{discover, clarify, design, estimate, generate}中，最多只能有一个阶段处于
```
"in_progress"
```
状态。如果超过一个，请停止操作。输出："多个阶段处于in_progress状态。请仅保留一个活跃阶段后再继续。"

State Management

状态管理

Migration state lives in

$MIGRATION_DIR

(

.migration/[MMDD-HHMM]/

), created by Phase 1 and persisted across invocations.

.phase-status.json schema:

json

{
  "migration_id": "0226-1430",
  "last_updated": "2026-02-26T15:35:22Z",
  "current_phase": "design",
  "phases": {
    "discover": "completed",
    "clarify": "completed",
    "design": "in_progress",
    "estimate": "pending",
    "generate": "pending",
    "feedback": "pending"
  }
}

Status values:

"pending"

→

"in_progress"

→

"completed"

. Never goes backward. For core phases (discover, clarify, design, estimate, generate), at most one phase may be

"in_progress"

at any time.

current_phase

is optional but recommended; when present it is authoritative.

The

.migration/

directory is automatically protected by a

.gitignore

file created in Phase 1.

迁移状态存储在

$MIGRATION_DIR

（

.migration/[MMDD-HHMM]/

）中，由第1阶段创建并在多次调用中持久化。

.phase-status.json schema:

json

{
  "migration_id": "0226-1430",
  "last_updated": "2026-02-26T15:35:22Z",
  "current_phase": "design",
  "phases": {
    "discover": "completed",
    "clarify": "completed",
    "design": "in_progress",
    "estimate": "pending",
    "generate": "pending",
    "feedback": "pending"
  }
}

状态值：

"pending"

→

"in_progress"

→

"completed"

。状态不会回退。对于核心阶段（discover、clarify、design、estimate、generate），任何时候最多只能有一个阶段处于

"in_progress"

状态。

current_phase

为可选但推荐；如果存在则具有权威性。

.migration/

目录会在第1阶段自动创建

.gitignore

文件进行保护。

Phase Status Update Protocol

阶段状态更新协议

Use read-merge-write updates for

.phase-status.json

Read the current file before every update.
Change only the phase keys being advanced and
```
last_updated
```
.
Keep prior completed phases unchanged.
Set
```
current_phase
```
to the next deterministic phase (or
```
complete
```
after generate).
Write the full file in the same turn as your final phase work message.

Example — after completing the Clarify phase, write

$MIGRATION_DIR/.phase-status.json

with:

json

{
  "migration_id": "MMDD-HHMM",
  "last_updated": "2026-02-26T15:35:22Z",
  "current_phase": "design",
  "phases": {
    "discover": "completed",
    "clarify": "completed",
    "design": "pending",
    "estimate": "pending",
    "generate": "pending",
    "feedback": "pending"
  }
}

Replace

MMDD-HHMM

with the actual migration ID, generate the

last_updated

ISO 8601 UTC timestamp yourself, and set each phase to its correct status at that point.

对

.phase-status.json

使用读取-合并-写入更新：

每次更新前读取当前文件。
仅修改正在推进的阶段键和
```
last_updated
```
。
保持已完成的前序阶段不变。
将
```
current_phase
```
设置为下一个确定性阶段（或生成阶段完成后设置为
```
complete
```
）。
在阶段最终输出消息的同一轮中写入完整文件。

示例——完成明确需求阶段后，写入

$MIGRATION_DIR/.phase-status.json

：

json

{
  "migration_id": "MMDD-HHMM",
  "last_updated": "2026-02-26T15:35:22Z",
  "current_phase": "design",
  "phases": {
    "discover": "completed",
    "clarify": "completed",
    "design": "pending",
    "estimate": "pending",
    "generate": "pending",
    "feedback": "pending"
  }
}

将

MMDD-HHMM

替换为实际迁移ID，自行生成

last_updated

的ISO 8601 UTC时间戳，并将每个阶段设置为当时的正确状态。

Phase Summary Table

阶段总结表

Phase	Inputs	Outputs	Reference
Discover	`.tf` files, app source code, and/or billing exports (at least one required)	`gcp-resource-inventory.json` , `gcp-resource-clusters.json` , `ai-workload-profile.json` , `billing-profile.json` , `.phase-status.json` updated (outputs vary by input)	`references/phases/discover/discover.md`
Clarify	Discovery artifacts ( `gcp-resource-inventory.json` , `gcp-resource-clusters.json` , `ai-workload-profile.json` , `billing-profile.json` — whichever exist)	`preferences.json` , `.phase-status.json` updated	`references/phases/clarify/clarify.md`
Design	`preferences.json` + discovery artifacts	`aws-design.json` (infra), `aws-design-ai.json` (AI), `aws-design-billing.json` (billing-only)	`references/phases/design/design.md`
Estimate	`aws-design.json` or `aws-design-billing.json` or `aws-design-ai.json` , `preferences.json`	`estimation-infra.json` or `estimation-ai.json` or `estimation-billing.json` , `.phase-status.json` updated	`references/phases/estimate/estimate.md`
Generate	`estimation-infra.json` or `estimation-ai.json` or `estimation-billing.json` , `aws-design.json` or `aws-design-billing.json` or `aws-design-ai.json` , `preferences.json`	`generation-infra.json` or `generation-ai.json` or `generation-billing.json` + `terraform/` , `scripts/` , `ai-migration/` , `validation-report.json` (when infra route active), `MIGRATION_GUIDE.md` , `README.md` , `.phase-status.json` updated	`references/phases/generate/generate.md`
Feedback	`.phase-status.json` (discover completed minimum), all existing migration artifacts	`feedback.json` , `trace.json` , `.phase-status.json` updated	`references/phases/feedback/feedback.md`

阶段	输入	输出	参考文档
发现（Discover）	`.tf` 文件、应用源代码和/或账单导出（至少需要一种）	`gcp-resource-inventory.json` 、 `gcp-resource-clusters.json` 、 `ai-workload-profile.json` 、 `billing-profile.json` 、更新后的 `.phase-status.json` （输出因输入而异）	`references/phases/discover/discover.md`
明确需求（Clarify）	发现阶段工件（ `gcp-resource-inventory.json` 、 `gcp-resource-clusters.json` 、 `ai-workload-profile.json` 、 `billing-profile.json` ——存在的所有文件）	`preferences.json` 、更新后的 `.phase-status.json`	`references/phases/clarify/clarify.md`
设计（Design）	`preferences.json` + 发现阶段工件	`aws-design.json` （基础设施）、 `aws-design-ai.json` （AI）、 `aws-design-billing.json` （仅账单）	`references/phases/design/design.md`
估算（Estimate）	`aws-design.json` 或 `aws-design-billing.json` 或 `aws-design-ai.json` 、 `preferences.json`	`estimation-infra.json` 或 `estimation-ai.json` 或 `estimation-billing.json` 、更新后的 `.phase-status.json`	`references/phases/estimate/estimate.md`
生成（Generate）	`estimation-infra.json` 或 `estimation-ai.json` 或 `estimation-billing.json` 、 `aws-design.json` 或 `aws-design-billing.json` 或 `aws-design-ai.json` 、 `preferences.json`	`generation-infra.json` 或 `generation-ai.json` 或 `generation-billing.json` + `terraform/` 、 `scripts/` 、 `ai-migration/` 、 `validation-report.json` （当基础设施路由激活时）、 `MIGRATION_GUIDE.md` 、 `README.md` 、更新后的 `.phase-status.json`	`references/phases/generate/generate.md`
反馈（Feedback）	`.phase-status.json` （至少完成发现阶段）、所有现有迁移工件	`feedback.json` 、 `trace.json` 、更新后的 `.phase-status.json`	`references/phases/feedback/feedback.md`

MCP Servers

MCP服务器

awspricing (for cost estimation):

Provides

get_pricing

get_pricing_service_codes

get_pricing_service_attributes

tools

Only needed during Estimate phase. Discover and Design do not require it.
Primary pricing source:
```
references/shared/pricing-cache.md
```
(cached 2026 rates, ±5-10% for infrastructure, ±15-25% for AI models). MCP is secondary — used only for services not found in the cache.

awspricing（用于成本估算）：

提供

get_pricing

、

get_pricing_service_codes

、

get_pricing_service_attributes

工具

仅在估算阶段需要。发现和设计阶段不需要。
主要定价来源：
```
references/shared/pricing-cache.md
```
（缓存2026年费率，基础设施误差±5-10%，AI模型误差±15-25%）。MCP为次要来源——仅用于缓存中未找到的服务。

Files in This Skill

本Skill中的文件

migration-to-aws/
├── SKILL.md                                    ← You are here (orchestrator + state machine)
│
├── references/
│   ├── phases/
│   │   ├── discover/
│   │   │   ├── discover.md                     # Phase 1: Discover orchestrator
│   │   │   ├── discover-iac.md                 # Terraform/IaC discovery
│   │   │   ├── discover-app-code.md            # App code discovery
│   │   │   └── discover-billing.md             # Billing data discovery
│   │   ├── clarify/
│   │   │   ├── clarify.md                     # Phase 2: Clarify orchestrator
│   │   │   ├── clarify-global.md              # Category A: Global/Strategic (Q1-Q7)
│   │   │   ├── clarify-compute.md             # Categories B+C: Config Gaps + Compute (Q8-Q11)
│   │   │   ├── clarify-database.md            # Category D: Database (Q12-Q13)
│   │   │   ├── clarify-ai.md                  # Category F: AI/Bedrock (Q14-Q22)
│   │   │   └── clarify-ai-only.md             # Standalone AI-only migration flow
│   │   ├── design/
│   │   │   ├── design.md                       # Phase 3: Design orchestrator
│   │   │   ├── design-infra.md                 # Infrastructure design (IaC-based)
│   │   │   ├── design-ai.md                    # AI workload design (Bedrock)
│   │   │   └── design-billing.md               # Billing-only design (fallback)
│   │   ├── estimate/
│   │   │   ├── estimate.md                     # Phase 4: Estimate orchestrator
│   │   │   ├── estimate-infra.md               # Infrastructure cost analysis
│   │   │   ├── estimate-ai.md                  # AI workload cost analysis
│   │   │   └── estimate-billing.md             # Billing-only cost analysis
│   │   ├── generate/
│   │   │   ├── generate.md                     # Phase 5: Generate orchestrator
│   │   │   ├── generate-infra.md               # Infrastructure migration plan
│   │   │   ├── generate-ai.md                  # AI migration plan
│   │   │   ├── generate-billing.md             # Billing-only migration plan
│   │   │   ├── generate-artifacts-infra.md     # Terraform configurations
│   │   │   ├── generate-artifacts-scripts.md  # Migration scripts
│   │   │   ├── generate-artifacts-ai.md        # Provider adapter + test harness
│   │   │   ├── generate-artifacts-billing.md   # Skeleton Terraform
│   │   │   └── generate-artifacts-docs.md      # MIGRATION_GUIDE.md + README.md
│   │   └── feedback/
│   │       ├── feedback.md                     # Phase 6: Feedback orchestrator
│   │       └── feedback-trace.md               # Anonymized trace builder
│   │
│   ├── design-refs/
│   │   ├── index.md                            # Lookup table: GCP type → design-ref file
│   │   ├── fast-path.md                        # Deterministic 1:1 mappings (Pass 1)
│   │   ├── compute.md                          # Compute mappings (Cloud Run, GCE, GKE, etc.)
│   │   ├── database.md                         # Database mappings (Cloud SQL, Spanner, etc.)
│   │   ├── storage.md                          # Storage mappings (GCS, Filestore, etc.)
│   │   ├── networking.md                       # Networking mappings (VPC, LB, DNS, etc.)
│   │   ├── messaging.md                        # Messaging mappings (Pub/Sub, etc.)
│   │   └── ai.md                               # AI mappings (Vertex AI → Bedrock)
│   │
│   ├── clustering/terraform/
│   │   ├── classification-rules.md             # Primary/secondary classification
│   │   ├── clustering-algorithm.md             # Cluster formation rules
│   │   ├── depth-calculation.md                # Topological depth calculation
│   │   └── typed-edges-strategy.md             # Edge type assignment
│   │
│   └── shared/
│       ├── schema-phase-status.md              # .phase-status.json schema (canonical reference)
│       ├── schema-discover-iac.md              # gcp-resource-inventory + clusters schemas (loaded by discover-iac.md)
│       ├── schema-discover-ai.md               # ai-workload-profile schema (loaded by discover-app-code.md and discover-iac.md Step 7d)
│       ├── schema-discover-billing.md          # billing-profile schema (loaded by discover-billing.md)
│       ├── schema-estimate-infra.md            # estimation-infra.json schema (loaded by estimate-infra.md at write time)
│       ├── migration-complexity.md             # Complexity tier definitions (small/medium/large) for timeline scaling
│       ├── pricing-cache.md                    # Cached AWS + source provider pricing (±5-25%, primary source)
│       └── bedrock-quotas.md                   # Bedrock TPM/RPM quota awareness, burndown rates, capacity planning

Condition	Action
No GCP sources found (no `.tf` , no app code, no billing data)	Stop. Output: "No GCP sources detected. Provide at least one source type (Terraform files, application code, or billing exports) and try again."
`.phase-status.json` missing phase gate	Stop. Output: "Cannot enter Phase X: Phase Y-1 not completed. Start from Phase Y or resume Phase Y-1."
awspricing unavailable after 3 attempts	Display user warning about ±5-25% accuracy. Use `pricing-cache.md` . Add `pricing_source: "cached_fallback"` to the applicable `estimation-*.json` file.
User skips questions or says "use defaults for the rest"	Apply documented defaults for remaining questions in the current batch and all subsequent batches. Phase 2 completes either way.
`aws-design.json` missing required clusters	Stop Phase 4. Output: "Re-run Phase 3 to generate missing cluster designs."

migration-to-aws/
├── SKILL.md                                    ← 当前位置（编排器 + 状态机）
│
├── references/
│   ├── phases/
│   │   ├── discover/
│   │   │   ├── discover.md                     # 第1阶段：发现编排器
│   │   │   ├── discover-iac.md                 # Terraform/IaC发现
│   │   │   ├── discover-app-code.md            # 应用代码发现
│   │   │   └── discover-billing.md             # 账单数据发现
│   │   ├── clarify/
│   │   │   ├── clarify.md                     # 第2阶段：明确需求编排器
│   │   │   ├── clarify-global.md              # A类：全局/战略问题（Q1-Q7）
│   │   │   ├── clarify-compute.md             # B+C类：配置缺口 + 计算资源（Q8-Q11）
│   │   │   ├── clarify-database.md            # D类：数据库（Q12-Q13）
│   │   │   ├── clarify-ai.md                  # F类：AI/Bedrock（Q14-Q22）
│   │   │   └── clarify-ai-only.md             # 独立AI迁移流程
│   │   ├── design/
│   │   │   ├── design.md                       # 第3阶段：设计编排器
│   │   │   ├── design-infra.md                 # 基础设施设计（基于IaC）
│   │   │   ├── design-ai.md                    # AI工作负载设计（Bedrock）
│   │   │   └── design-billing.md               # 仅账单设计（备选方案）
│   │   ├── estimate/
│   │   │   ├── estimate.md                     # 第4阶段：估算编排器
│   │   │   ├── estimate-infra.md               # 基础设施成本分析
│   │   │   ├── estimate-ai.md                  # AI工作负载成本分析
│   │   │   └── estimate-billing.md             # 仅账单成本分析
│   │   ├── generate/
│   │   │   ├── generate.md                     # 第5阶段：生成编排器
│   │   │   ├── generate-infra.md               # 基础设施迁移计划
│   │   │   ├── generate-ai.md                  # AI迁移计划
│   │   │   ├── generate-billing.md             # 仅账单迁移计划
│   │   │   ├── generate-artifacts-infra.md     # Terraform配置
│   │   │   ├── generate-artifacts-scripts.md  # 迁移脚本
│   │   │   ├── generate-artifacts-ai.md        # 提供商适配器 + 测试工具
│   │   │   ├── generate-artifacts-billing.md   # 骨架Terraform
│   │   │   └── generate-artifacts-docs.md      # MIGRATION_GUIDE.md + README.md
│   │   └── feedback/
│   │       ├── feedback.md                     # 第6阶段：反馈编排器
│   │       └── feedback-trace.md               # 匿名追踪构建器
│   │
│   ├── design-refs/
│   │   ├── index.md                            # 查找表：GCP类型 → 设计参考文件
│   │   ├── fast-path.md                        # 确定性1:1映射（第一轮）
│   │   ├── compute.md                          # 计算资源映射（Cloud Run、GCE、GKE等）
│   │   ├── database.md                         # 数据库映射（Cloud SQL、Spanner等）
│   │   ├── storage.md                          # 存储映射（GCS、Filestore等）
│   │   ├── networking.md                       # 网络映射（VPC、LB、DNS等）
│   │   ├── messaging.md                        # 消息服务映射（Pub/Sub等）
│   │   └── ai.md                               # AI映射（Vertex AI → Bedrock）
│   │
│   ├── clustering/terraform/
│   │   ├── classification-rules.md             # 主/次分类规则
│   │   ├── clustering-algorithm.md             # 集群形成规则
│   │   ├── depth-calculation.md                # 拓扑深度计算
│   │   └── typed-edges-strategy.md             # 边缘类型分配策略
│   │
│   └── shared/
│       ├── schema-phase-status.md              # .phase-status.json schema（标准参考）
│       ├── schema-discover-iac.md              # gcp-resource-inventory + clusters schema（由discover-iac.md加载）
│       ├── schema-discover-ai.md               # ai-workload-profile schema（由discover-app-code.md和discover-iac.md第7d步加载）
│       ├── schema-discover-billing.md          # billing-profile schema（由discover-billing.md加载）
│       ├── schema-estimate-infra.md            # estimation-infra.json schema（由estimate-infra.md在写入时加载）
│       ├── migration-complexity.md             # 迁移复杂度层级定义（小/中/大），用于时间线缩放
│       ├── pricing-cache.md                    # 缓存的AWS + 源提供商定价（误差±5-25%，主要来源）
│       └── bedrock-quotas.md                   # Bedrock TPM/RPM配额感知、消耗率、容量规划

条件	操作
未找到GCP源（无 `.tf` 、无应用代码、无账单数据）	停止操作。输出："未检测到GCP源。请提供至少一种源类型（Terraform文件、应用代码或账单导出）后重试。"
`.phase-status.json` 缺少阶段门验证	停止操作。输出："无法进入X阶段：Y-1阶段未完成。请从Y阶段开始或恢复Y-1阶段。"
尝试3次后awspricing仍不可用	向用户显示警告，说明成本估算误差为±5-25%。使用 `pricing-cache.md` 。在相应的 `estimation-*.json` 文件中添加 `pricing_source: "cached_fallback"` 。
用户跳过问题或表示"其余使用默认值"	对当前批次及后续批次的剩余问题应用文档中规定的默认值。第2阶段无论如何都会完成。
`aws-design.json` 缺少必要的集群	停止第4阶段。输出："重新运行第3阶段以生成缺失的集群设计。"

Defaults

默认值

IaC output: Terraform configurations, migration scripts, AI migration code, and documentation
Region:
```
us-east-1
```
(unless user specifies, or GCP region → AWS region mapping suggests otherwise)
Sizing: Development tier (e.g.,
```
db.t4g.micro
```
for databases, 0.5 CPU for Fargate)
Migration mode: Adapts based on available inputs (infrastructure, AI, or billing-only)
Cost currency: USD
Timeline assumption: 2-16 weeks depending on migration complexity — small (2-6 weeks), medium (6-12 weeks), large (12-18 weeks). See
```
references/shared/migration-complexity.md
```
for tier definitions.

IaC输出：Terraform配置、迁移脚本、AI迁移代码和文档
区域：
```
us-east-1
```
（除非用户指定，或GCP区域→AWS区域映射建议其他区域）
规格：开发级（例如：数据库使用
```
db.t4g.micro
```
，Fargate使用0.5 CPU）
迁移模式：根据可用输入调整（基础设施、AI或仅账单）
成本货币：USD
时间线假设：根据迁移复杂度为2-16周——小型（2-6周）、中型（6-12周）、大型（12-18周）。层级定义详见
```
references/shared/migration-complexity.md
```
。

Workflow Execution

工作流执行

When invoked, the agent MUST follow this exact sequence:

Load phase status: Read
```
.phase-status.json
```
from
```
.migration/*/
```
.
- If missing: Initialize for Phase 1 (Discover)
- If exists: Determine current phase using deterministic rules in State Machine
Determine phase to execute:
- If
```
current_phase
```
  exists: execute that phase.
- Otherwise execute the first non-completed phase in ordered list: discover → clarify → design → estimate → generate.
- If all ordered phases are completed: migration is complete (with feedback finalization rule).
Read phase reference: Load the full reference file for the target phase.
Execute ALL steps in order: Follow every numbered step in the reference file. Do not skip, optimize, or deviate.
Validate outputs: Confirm all required output files exist with correct schema before proceeding.
Update phase status: Use the Phase Status Update Protocol (read-merge-write) in the same turn as the phase's final output message.
Feedback checkpoint: After a phase completes, check if feedback is due (see rules below). This runs before advancing to the next phase.
- After Discover (if
```
phases.feedback
```
  is
```
"pending"
```
  ): Output to user: "Would you like to share quick feedback (5 optional questions + anonymized usage data) to help improve this tool? Your data never includes resource names, file paths, or account IDs. [A] Send feedback now [B] Wait until after the Estimate phase"
  - If user picks A → Load
```
references/phases/feedback/feedback.md
```
    , execute it, then continue to Clarify.
  - If user picks B → Continue to Clarify (feedback stays
```
"pending"
```
    ).
- After Estimate (if
```
phases.feedback
```
  is
```
"pending"
```
  ): Output to user: "Would you like to share quick feedback now? (5 optional questions + anonymized usage data) [A] Yes, share feedback [B] No thanks, continue to Generate"
  - If user picks A → Load
```
references/phases/feedback/feedback.md
```
    , execute it, then continue to Generate.
  - If user picks B → Use the Phase Status Update Protocol to set
```
phases.feedback
```
    to
```
"completed"
```
    . Continue to Generate.
- After Generate: No feedback offer. If
```
phases.feedback
```
  is still
```
"pending"
```
  , use the Phase Status Update Protocol to set it to
```
"completed"
```
  (user had two chances and chose to defer/skip).
Display summary: Show user what was accomplished, highlight next phase, or confirm migration completion.

Critical constraint: Agent must strictly adhere to the reference file's workflow. If unable to complete a step, stop and report the exact step that failed.

User can invoke the skill again to resume from

current_phase

(or deterministic ordered evaluation when

current_phase

is absent).

调用时，代理必须严格遵循以下顺序：

加载阶段状态：从
```
.migration/*/
```
读取
```
.phase-status.json
```
。
- 如果缺失：初始化第1阶段（发现）
- 如果存在：使用状态机中的确定性规则确定当前阶段
确定要执行的阶段：
- 如果存在
```
current_phase
```
  ：执行该阶段。
- 否则执行有序列表中第一个未完成的阶段：discover → clarify → design → estimate → generate。
- 如果所有有序阶段均已完成：迁移完成（遵循反馈最终化规则）。
读取阶段参考文档：加载目标阶段的完整参考文件。
按顺序执行所有步骤：遵循参考文件中的每个编号步骤。不得跳过、优化或偏离。
验证输出：继续之前确认所有必要的输出文件存在且schema正确。
更新阶段状态：在阶段最终输出消息的同一轮中使用阶段状态更新协议（读取-合并-写入）。
反馈检查点：阶段完成后，检查是否需要收集反馈（见下文规则）。这一步在推进到下一阶段之前执行。
- 发现阶段之后（如果
```
phases.feedback
```
  为
```
"pending"
```
  ）：向用户输出： "您是否愿意分享快速反馈（5个可选问题 + 匿名使用数据）以帮助改进此工具？您的数据绝不会包含资源名称、文件路径或账户ID。 [A] 立即发送反馈 [B] 等到估算阶段之后"
  - 如果用户选择A → 加载
```
references/phases/feedback/feedback.md
```
    并执行，然后继续到明确需求阶段。
  - 如果用户选择B → 继续到明确需求阶段（反馈状态保持
```
"pending"
```
    ）。
- 估算阶段之后（如果
```
phases.feedback
```
  为
```
"pending"
```
  ）：向用户输出： "您现在是否愿意分享快速反馈？（5个可选问题 + 匿名使用数据） [A] 是，分享反馈 [B] 不用了，继续到生成阶段"
  - 如果用户选择A → 加载
```
references/phases/feedback/feedback.md
```
    并执行，然后继续到生成阶段。
  - 如果用户选择B → 使用阶段状态更新协议将
```
phases.feedback
```
    设置为
```
"completed"
```
    。继续到生成阶段。
- 生成阶段之后：不提供反馈选项。如果
```
phases.feedback
```
  仍为
```
"pending"
```
  ，使用阶段状态更新协议将其设置为
```
"completed"
```
  （用户有两次机会选择延迟/跳过）。
显示摘要：向用户展示已完成的工作，突出下一阶段，或确认迁移完成。

关键约束：代理必须严格遵守参考文件的工作流。如果无法完成某一步，请停止并报告失败的具体步骤。

用户可以再次调用该Skill以从

current_phase

恢复（或当

current_phase

不存在时使用确定性有序评估）。

Scope Notes

范围说明

v1.0 includes:

Terraform infrastructure discovery
App code scanning (AI workload detection)
Billing data import from GCP
User requirement clarification (adaptive questions by category)
Multi-path Design (infrastructure, AI workloads, billing-only fallback)
AWS cost estimation (from pricing API or fallback)
Migration artifact generation (Terraform, scripts, AI adapters, documentation)
Optional feedback collection with anonymized telemetry

v1.0包含：

Terraform基础设施发现
应用代码扫描（AI工作负载检测）
GCP账单数据导入
用户需求明确（按类别自适应提问）
多路径设计（基础设施、AI工作负载、仅账单备选方案）
AWS成本估算（来自定价API或备选方案）
迁移工件生成（Terraform、脚本、AI适配器、文档）
可选的匿名遥测反馈收集