/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, then rewrites SDK calls, evaluates output quality against Bedrock, and delivers a ready-to-merge git branch. Not for: agent runtime selection, agentic architecture decisions, or agent migration planning — use agent-advisor for those. Not for standalone Bedrock cost estimates or infrastructure-only migration. REQUIRES the gcp-to-aws skill installed alongside this one — Assess is delegated entirely to it via a cross-skill invocation, with no standalone fallback if gcp-to-aws is absent."

Migrate to Bedrock (Assess + Execute)

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

**Requires the `gcp-to-aws` skill installed alongside this one.** This skill has no standalone Assess implementation — Phase A below delegates Assess entirely to `gcp-to-aws` via a cross-skill invocation, and there is no fallback path that performs Assess itself if `gcp-to-aws` is missing. If you installed this skill on its own (e.g. a single-skill `npx skills add`), install `gcp-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)

---

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.

0b. Check that the gcp-to-aws sibling skill is installed

Phase A below delegates the entire Assess step to the `gcp-to-aws` skill via the Skill tool — there is no Assess logic in this skill to fall back to. `gcp-to-aws` is a **separate skill**, not bundled inside this one — a single-skill install (e.g. `npx skills add ... --skill llm-to-bedrock`) does not bring it along automatically. Check for it now, before promising the user an Assess phase this deployment cannot run:

[ -f "<SKILL_BASE>/../gcp-to-aws/SKILL.md" ] && echo GCP_TO_AWS_PRESENT || echo GCP_TO_AWS_MISSING

This checks the sibling directory relative to `<SKILL_BASE>` (defined above), which works under any install path — native plugin install and `npx skills add --skill '*'` both place `gcp-to-aws` as a sibling of this skill's own directory. It does **not** depend on `${CLAUDE_PLUGIN_ROOT}`.

• `GCP_TO_AWS_PRESENT` → proceed to Step 1.
• `GCP_TO_AWS_MISSING` → **stop here — do not proceed.** Tell the user:

> "This migration needs the `gcp-to-aws` skill installed alongside this one — it handles > code scanning, AI-workload detection, and Bedrock model design; I can't do that part myself > without it. `gcp-to-aws` ships in the same `aws-startup-advisor` plugin as this skill, so if > you installed the whole plugin it should already be next to me — it looks like only some of > the plugin's skills were installed. Add it with: > `npx skills add aws/agent-toolkit-for-aws/plugins/aws-startup-advisor/skills --skill gcp-to-aws` > (use the same `--agent` and `--global`/project scope you used for this skill), or reinstall the > `aws-startup-advisor` plugin to get every skill at once. Then restart your agent and ask me to > migrate again."

**Do not** perform the Assess phase yourself as a workaround — Phase A below is explicit that Assess logic lives only in `gcp-to-aws`; re-implementing it here would drift out of sync with that skill's Discover/Clarify/Design logic over time. There is no standalone Assess for this skill — this check exists to fail fast and clearly, not to unlock alternate behavior.

**Separately, invoking `gcp-to-aws` at all in Phase A requires your agent to support the Skill tool** (cross-skill invocation by name). This is confirmed for Claude Code; it has not been verified across every agent that supports `npx skills` installs (Cursor, Codex, etc.) — if you're on one of those and this fails, that is the likely cause. If the Skill tool call in Phase A's A1 step fails or no such mechanism exists on your agent, this skill still has no fallback: tell the user plainly that this agent cannot chain into `gcp-to-aws` automatically, and ask them to invoke `gcp-to-aws` themselves directly (e.g. "migrate my AI workload to AWS") to run Discover through Design (accepting the decision pack is enough — they do not need to generate infra Terraform), then come back to this skill once its Assess artifacts are ready (the decision pack is done, or `generate` is `completed`; checked in A2) to continue with the SDK rewrite. This is a manual two-step workaround for a missing agent capability, not an automated fallback — do not present it to the user as this skill "handling it."

---

Step 1 — Collect source code path

If `$ARGUMENTS` contains a path, use it as `$REPO`. Otherwise use **AskUserQuestion**: "Where is your source code? Enter a local path or GitHub URL."

If a GitHub URL, `git clone` it to a temp dir; use that path as `$REPO`.

**Checks on $REPO:**

1. **Git-root check** (compare resolved paths — on macOS `/tmp` resolves to `/private/tmp`, so a raw string comparison false-positives):

   [ "$(git -C <REPO> rev-parse --show-toplevel 2>/dev/null)" = "$(cd <REPO> && pwd -P)" ] && echo GIT_ROOT_OK || echo GIT_ROOT_MISMATCH

• `GIT_ROOT_OK` → proceed.
• `GIT_ROOT_MISMATCH` and the command errored (not a git repo at all) → tell the user the

path must be a git repository (the deliverable is a git branch); re-ask.

• `GIT_ROOT_MISMATCH` but inside a repo (user pointed at a subdirectory) → AskUserQuestion:

"Use the repo root instead" (recommended) / "Conti