resolve-bedrock-model-id

name	resolve-bedrock-model-id
description	Validate a plan-supplied Bedrock model ID against live inference profiles in the target AWS account and correct it if stale. Load this when a plan's target_model_id needs to be used for the first time (ai-code-analyzer §10), or when a Bedrock call returns "invalid model identifier".

Resolve Bedrock Model ID

Migration plans are authored ahead of execution. By the time the execute agent runs, plan-supplied Bedrock inference-profile IDs may be stale, use the wrong regional prefix (us. / global. / eu.), or never existed. This skill takes an input ID, lists live profiles, and returns a validated ID — asking the user to choose when the match is ambiguous.

Input

• plan_model_id: the target_model_id from the migration plan (e.g., anthropic.claude-sonnet-4-6-20250514-v1:0)
• region: the AWS region from your context (e.g., us-east-1)

Procedure

Step 1: List live inference profiles

aws bedrock list-inference-profiles \
  --region <region> \
  <add --profile <profile> when your context has an `AWS profile` line> \
  --query 'inferenceProfileSummaries[].[inferenceProfileId,inferenceProfileName]' \
  --output json

Parse the JSON. Each entry is a [id, name] pair.

Step 2: Try exact match

If plan_model_id appears verbatim in the list, return it. No user prompt needed.

Step 3: Token-based ranking when no exact match

Tokenize both the plan ID and each live ID by splitting on ., -, _, /. Drop tokens that match the regex ^v?\d{6,} or ^v\d+$ (these are date stamps like 20250514 or version tags like v1).

For each live profile, compute the size of the intersection of its token set with the plan ID's token set. Keep the top 3 by intersection size, breaking ties in this order:

1. Prefer profiles whose ID starts with us.
2. Then global.
3. Then no prefix
4. Then eu. / others

Step 4: Defer to the orchestration skill

The subagent that loads this skill is non-interactive and cannot prompt the user. When no exact match exists, return blocked with reason: model_unresolvable and put the plan's ID and the top candidates in detail, so the orchestration skill (main session) presents the choice. The candidate-selection logic above (Steps 1-3) defines what the orchestrator offers; format detail so it can render the choices:

The migration plan references Bedrock model '<plan_model_id>', but that ID is
not available in <region>. Closest matches found:
  - <candidate 1 id> (<candidate 1 name>)
  - <candidate 2 id> (<candidate 2 name>)
  - <candidate 3 id> (<candidate 3 name>)
The user may also supply a different inference profile ID, or abort to fix the
plan first.

Include fewer candidates if fewer exist. If zero candidates have token overlap

0, omit the candidate rows and note only that the user must supply a correct ID or abort.

Step 5: Return

ONLY an exact match (Step 2) returns an ID directly. Token ranking (Step 3) exists solely to produce the candidate list inside Step 4's blocked detail — a token-ranked match is NEVER auto-applied, because silently substituting a different model than the plan named would make every downstream eval and rewrite target the wrong model without the user knowing. Anything short of an exact match returns the blocked signal from Step 4 — the orchestration skill asks the user and re-invokes resolution with the chosen (or pasted) ID, or stops on abort.

Notes

• This skill is idempotent: calling it twice with the same already-validated ID will hit Step 2 and return immediately.
• Output of this skill should replace the plan's target_model_id in the caller's context — downstream phases (evaluator, rewriter) receive the validated ID only.