llm-to-bedrock

Files (52)

• SKILL.md
• bedrock-known-fixes.md · references/helpers/bedrock-known-fixes/
• bedrock-iam-inference-profile.md · references/helpers/bedrock-known-fixes/references/
• bedrock-inference-profile-model-id.md · references/helpers/bedrock-known-fixes/references/
• bedrock-response-key-casing.md · references/helpers/bedrock-known-fixes/references/
• bedrock-vision.md · references/helpers/bedrock-known-fixes/references/
• bedrock-vision.py.template · references/helpers/bedrock-known-fixes/references/
• behavior-delta-detection.md · references/helpers/behavior-delta-detection/
• anthropic-to-bedrock.md · references/helpers/behavior-delta-detection/references/
• gemini-to-bedrock.md · references/helpers/behavior-delta-detection/references/
• openai-to-bedrock.md · references/helpers/behavior-delta-detection/references/
• dependency-conflict-resolution.md · references/helpers/dependency-conflict-resolution/
• resolve-bedrock-model-id.md · references/helpers/resolve-bedrock-model-id/
• run-source-model-baseline.md · references/helpers/run-source-model-baseline/
• PROTOCOL.md · references/vendored/telemetry/
• cli.py · references/vendored/telemetry/
• accept.py · references/vendored/telemetry/consent/
• cli.py · references/vendored/telemetry/consent/
• notice.py · references/vendored/telemetry/consent/
• opt_out.py · references/vendored/telemetry/consent/
• record.py · references/vendored/telemetry/consent/
• client.py · references/vendored/telemetry/metric_emission/
• migration.py · references/vendored/telemetry/metric_emission/
• migration_attributes.py · references/vendored/telemetry/metric_emission/
• version.json · references/vendored/telemetry/
• bedrock_pricing.py · scripts/
• iam_policy.py · scripts/
• image_input.py · scripts/
• model_identity.py · scripts/
• preflight_bedrock.py · scripts/
• pyproject.toml · scripts/
• render_report.py · scripts/
• resolve_source_model.py · scripts/
• analysis.json · scripts/schemas/
• delta-decisions.json · scripts/schemas/
• eval.json · scripts/schemas/
• ingestion.json · scripts/schemas/
• rewrite.json · scripts/schemas/
• source_baseline.py · scripts/
• test_astra_execution_contract.py · scripts/
• test_bedrock_pricing.py · scripts/
• test_delta_reference_schema.py · scripts/
• test_iam_policy.py · scripts/
• test_image_input.py · scripts/
• test_model_identity.py · scripts/
• test_preflight_bedrock.py · scripts/
• test_render_report.py · scripts/
• test_resolve_source_model.py · scripts/
• test_source_baseline.py · scripts/
• test_validate_result.py · scripts/
• uv.lock · scripts/
• validate_result.py · scripts/

SKILL.md (first lines)

# 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

```bash
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:

```bash
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 path — native plugin install
and `npx skills add --skill '*'` both place `gcp-to-aws`/`azure-to-aws` as siblings of this
skill's own directory. It does **not** depend on `${CLAUDE_PLUGIN_ROOT}`. **When both are
installed, `gcp-to-aws` wins** — it is this skill's original, more deeply tested integration,
so this preserves today's default behavior for every existing user with both skills installed.

- `$ASSESS_SKILL` resolved (either value) → proceed to Step 1.
- `ASSESS_SIBLING_MISSING` → **stop here — do not proceed.** Tell the user:

  > "This migration needs either the `gcp-to-aws` or the `azure-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. Both ship in the same `aws-startup-advisor`
  > plugin as this skill, so if you installed the whole plugin one of them should already be
  > next to me — it looks like only some of the plugin's skills were installed. Install the pair
  > together with:
  > `npx skills add aws/agent-toolkit-for-aws/plugins/aws-startup-advisor/skills --skill llm-to-bedrock --skill gcp-to-aws`
  > (or substitute `azure-to-aws` if your source infra runs on Azure; use the same `--agent` and
  > `--global`/project scope you used for this skill), or run that same `npx skills add` command
  > with `--skill '*'` instead of naming individual skills 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 `$ASSESS_SKILL`; 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.

From aws/agent-toolkit-for-aws, Apache-2.0.

More from aws/agent-toolkit-for-aws