/llm-to-bedrock

name: llm-to-bedrock
description: "Use when the user wants to migrate code that calls OpenAI, Gemini/Google AI, or the Anthropic API to Amazon Bedrock — a pure model/SDK rewrite. End-to-end: assesses the codebase, optionally captures aggregate OpenAI, OpenRouter, or Anthropic cost and token usage through consent-gated provider APIs, rewrites SDK calls, evaluates output quality against Bedrock, and delivers a ready-to-merge git branch. Also has an access-only mode for checking or enabling Bedrock model access for specific models (e.g. 'request access to Claude on Bedrock', 'which models do I turn on') with no code migration — it checks each model and walks the right access step, then stops. Not for agent runtime selection or agent migration planning (use agent-advisor), nor standalone cost estimates or infra-only migration. The full migration REQUIRES gcp-to-aws OR azure-to-aws installed alongside this skill (gcp-to-aws preferred when both are present); access-only mode needs neither."

Migrate to Bedrock (Assess + Execute)

Single-command AI migration: OpenAI / Gemini / Anthropic → Amazon Bedrock.

**Requires the `gcp-to-aws` OR the `azure-to-aws` skill installed alongside this one.** This skill has no standalone Assess implementation — Phase A below runs Assess by directly reading and executing whichever of those two skills is present's own phase instruction files in this same session (the same inline-execution pattern `agent-advisor` uses for its `migration-plan` phase: no cross-skill tool call, no turn boundary, and no dependency on your agent supporting a Skill/subagent dispatch mechanism — reading a file works on any agent). There is no fallback path that performs Assess itself if neither sibling is present. If you installed this skill on its own (e.g. a single-skill `npx skills add`), install `gcp-to-aws` or `azure-to-aws` too before using it.

The skill base directory is given in the "Base directory for this skill: X" line the harness emits at load time. Call it `<SKILL_BASE>`. Derived paths:

• `$SCRIPTS` = `<SKILL_BASE>/scripts`
• `$HELPERS` = `<SKILL_BASE>/references/helpers` (the former helper skills, now references)
• `$ASSESS_SKILL` / `$ASSESS_BASE` — resolved once, in Step 0b: `$ASSESS_SKILL` is whichever of

`gcp-to-aws` / `azure-to-aws` is installed alongside this skill (`gcp-to-aws` preferred when both are present), and `$ASSESS_BASE` = `<SKILL_BASE>/../$ASSESS_SKILL` — that sibling skill's own directory. Phase A reads its instruction files directly off this path; every relative reference inside an `$ASSESS_SKILL` file (`references/shared/...`, `references/phases/...`, etc.) resolves under `$ASSESS_BASE`, exactly as it would if `$ASSESS_SKILL` were running standalone.

---

Optional usage telemetry

Before starting or resuming, load `references/vendored/telemetry/PROTOCOL.md` and run its read-only status check. Use the returned reporting mode rather than the model's identity. Complete the existing notice exchange only when that protocol requires it; unavailable or declined telemetry never blocks this skill.

Step 0 — Check prerequisites

0a. Check that `uv` is available

uv --version 2>/dev/null || echo "MISSING"

If missing: "Install uv first — see the official install guide: https://docs.astral.sh/uv/getting-started/installation/ (e.g. `brew install uv` or `pipx install uv`)". Stop.

0a-bis. Route: full migration vs. access-only

This skill has two modes. Decide which the user wants **before** the Assess-sibling check (0b) — the access-only mode does not use `gcp-to-aws`/`azure-to-aws` at all, so requiring one of them there would block a user who only wants access enablement.

Route to **Access-only mode** (jump to the "## Access-only mode" section below, skip 0b and Steps 1+) when either is true:

• `$ARGUMENTS` contains an explicit access-request phrase — `model access`, `request access`,

`enable model access`, `just access`, or `preflight` (and no source-code path). Do **not** route on the bare words `enable` or `access` alone — "enable the Bedrock rewrite" is a full migration, not an access request. When in doubt, use the AskUserQuestion below rather than the keyword. **Or**

• the user's request is about *getting Bedrock model access enabled* rather than rewriting code —

e.g. "help me request access to Claude on Bedrock", "enable GPT models on Bedrock", "which models do I need to turn on", "I just want access, my engineers will do the migration".

If it is ambiguous (the user mentions both a codebase and access), **AskUserQuestion**:

> "Two things I can do — which do you want? > [Full migration] Rewrite your OpenAI/Gemini/Anthropic calls for Bedrock end-to-end. > [Just model access] Check and walk you through enabling Bedrock access for specific models, > no code changes."

`[Just model access]` → Access-only mode. `[Full migration]` → continue to 0b.

Otherwise (a code path / clear rewrite intent) → continue to 0b for the full migration.

0b. Check that a gcp-to-aws or azure-to-aws sibling skill is installed

Phase A below runs Assess by directly reading and executing `$ASSESS_SKILL`'s own phase instruction files (Discover → Clarify → Design → Estimate, AI-only path) in this same session — there is no Assess logic in this skill to fall back to. `gcp-to-aws` and `azure-to-aws` are **separate skills**, not bundled inside this one — a single-skill install (e.g. `npx skills add ... --skill llm-to-bedrock`) does not bring either along automatically. Check for them now, before promising the user an Assess phase this deployment cannot run:

if [ -f "<SKILL_BASE>/../gcp-to-aws/SKILL.md" ]; then
  ASSESS_SKILL=gcp-to-aws
elif [ -f "<SKILL_BASE>/../azure-to-aws/SKILL.md" ]; then
  ASSESS_SKILL=azure-to-aws
else
  echo ASSESS_SIBLING_MISSING
fi

`$ASSESS_BASE` = `<SKILL_BASE>/../$ASSESS_SKILL`. This checks the sibling directories relative to `<SKILL_BASE>` (defined above), which works under any install