Generated banner for Agent Advisor
Generated logo for Agent Advisor

Agent Advisor

AWSOfficialPublished by AWS

  • Skill
  • Workflow
  • Cloud and DevOps
  • Apache-2.0
  • Low risk
  • Has scripts

From the author

Entry point for AI-agent work on AWS: pick a runtime, plan a migration for existing workloads, and build an executable POC — one phased flow. Triggers on: which runtime for my agent, AgentCore vs ECS vs EKS vs Lambda, AgentCore vs Lambda MicroVMs, deploy an AI agent on AWS, agent architecture on AWS, I have an agent idea what do I build, move/migrate my agents to AWS, agent migration plan, add AgentCore services (memory, gateway, identity, policy, observability) to an agent already on AWS, Temporal on AWS (migrate/run Temporal workers on AWS, a service orchestrated by Temporal, Temporal Cloud vs self-hosted). Temporal Workflow code is never rewritten into Step Functions. Requires at least one agentic component — a purely non-agent system (plain services, batch jobs, HTTP endpoints, non-agent Temporal Activities) is out of scope, redirected to gcp-to-aws / heroku-to-aws / llm-to-bedrock. Not for: compute/data migration with no AI agent; pure LLM SDK rewrite (use llm-to-bedrock); per-model pricing.
— the description by AWS

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Agent Advisor provides a structured, multi-phase workflow to help users determine the optimal AWS runtime for their AI agents. It uses a deterministic scoring engine to evaluate requirements and guides users through a process that includes discovery, architectural design, cost estimation, and the creation of an executable proof-of-concept. The skill supports various AWS compute options, including AgentCore, ECS, EKS, and Lambda, and integrates with migration engines for existing workloads.

What it does

  • Recommends AWS runtimes for AI agents based on technical requirements.
  • Generates migration plans for existing AI workloads moving to AWS.
  • Provides architectural guidance for agentic systems.
  • Assembles executable proof-of-concept scaffolding.
  • Estimates coarse cost magnitudes for proposed agent deployments.
  • Integrates with external migration engines for workload transitions.

When to use it

  • When you need to decide which AWS runtime is best for a new AI agent.
  • When migrating an existing AI agent workload to AWS.
  • When you need to add services like memory, identity, or observability to an existing AWS agent.
  • When you require a structured plan and POC for deploying agents on AWS.

Advantages

  • Provides a deterministic, repeatable recommendation process.
  • Supports a wide range of AWS compute environments.
  • Offers a unified flow from initial idea to executable POC.
  • Adapts to both technical and business-focused user backgrounds.

Usage examples

“I have an agent idea, what do I build?”
The agent initiates the intake process to clarify your requirements and recommend an appropriate AWS architecture.
“Move my agents to AWS.”
The agent triggers the migration workflow to assess your existing workload and plan the transition to an AWS runtime.
“Which runtime for my agent, AgentCore vs ECS vs EKS vs Lambda?”
The agent runs a scoring analysis to compare these runtimes against your specific agentic needs.
“Add AgentCore services to an agent already on AWS.”
The agent enters the add-capabilities branch to guide you through integrating memory, gateway, and observability services.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/aws/agent-advisor/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip agent-advisor.zip -d .agents/skills

Documentation by AWS

AWS Agent Advisor

Helps startups decide how and where to run AI agents on AWS. Deterministic scoring recommends a runtime; the conversation adapts to the user's technical background.

Definitions

  • "Load" = Read the file with the Read tool and follow it. Do not summarize or skip.

  • $RUN_DIR = the run directory under .agent-advisor/ (e.g. .agent-advisor/0630-1430/), created in Intake.

  • $PLUGIN = ${CLAUDE_PLUGIN_ROOT} (the installed plugin root). On Claude Code this token substitutes inline. If ${CLAUDE_PLUGIN_ROOT} does not resolve (some Cursor/Codex builds, or a literal ${CLAUDE_PLUGIN_ROOT} string showing up in a path error), fall back to the skill's own directory: this SKILL.md lives at <plugin>/skills/agent-advisor/SKILL.md, so the engine and its data are all inside this skill — scripts at ./scripts/..., runtime profiles at ./references/runtimes/..., and decision refs at ./references/decision-refs/... relative to it. Prefer ${CLAUDE_PLUGIN_ROOT}/skills/agent-advisor/...; use the relative fallback only when it fails to resolve.

Prerequisites

Phase Structure (frontmatter)

Phase, fragment, and assembler files carry a YAML frontmatter block that declares how each phase is composed — its inputs, triggers, fragments, assembler, artifacts, gates, and ordering. The execution contract is the vendored references/vendored/dsl/INTERPRETER.md: it defines every frontmatter key, the fragment/assembler model, the gate protocol (HANDOFF_OK / GATE_FAIL), and the interpreter loop. Load it first (once, at the start of a run), then execute each phase file's prose body. Elsewhere in this skill, INTERPRETER.md (without a path) refers to this loaded contract.

Execution

This skill is driven by the interpreter loop in INTERPRETER.md (§ The interpreter loop): it reads .phase-status.json, determines the current phase, runs each phase's _preconditions / fragments / _assemble / _postconditions, advances on HANDOFF_OK via _advances_to, and validates state. The backbone (intake → discover → clarify → confirm → design → estimate → generate → migration-plan → poc → complete) and the one sidebar branch (add-capabilities) are derived from the phase files' frontmatter — they are not restated here.

Cold start (entry phase). With no run under .agent-advisor/ carrying a .phase-status.json, begin at references/phases/intake/intake.md — this skill's entry phase (the one carrying _init: true). On a warm start, current_phase in .phase-status.json is authoritative (INTERPRETER.md § The interpreter loop).

Skill bindings (INTERPRETER.md § Skill bindings). This skill declares:

  • Run root: .agent-advisor/ — $RUN_DIR is this skill's name for the run directory (.agent-advisor/[MMDD-HHMM]/). Intake's own prose performs the _init bootstrap.

  • State shape: § State file below (advisor-specific keys such as entry_point, audience, recommendation_reviewed, migration_plan_ctx, migration_plan_unavailable); the shared state schema is not vendored.

  • Run seed (optional): $RUN_DIR/seed.json, else .agent-advisor/seed.json at the run root (schema scripts/schemas/seed.json) supplies machine-readable answers for a non-interactive run — the Clarify dimensions, the two gate answers, the POC mode, the live-probe answer, and a co_recommend tie-break. It is the HIGHEST-precedence source for every value it carries (clarify.md Step 2.5), which is what makes a repeated run's score comparable: the deterministic engine gets byte-identical input. A gate the seed omits is declined; a dimension the seed omits falls through to detection, then prose, then an assumed value that MUST be recorded in $RUN_DIR/UNANSWERED.md. With no seed, the interactive flow is unchanged.

  • Resolved statuses: skipped (routing resolved the phase without running it), plus not_applicable for migration_plan only.

  • Conditional backbone routing: the entry-point routing below. When a routing rule marks a phase not-applicable, set it skipped and advance through its _advances_to in the same state write.

Routing & gates (orchestration)

Sidebar placement and conditional backbone routing are orchestration prose owned by this file (INTERPRETER.md § Skill bindings, § Backbone vs sidebar).

Entry-point routing:

  • build_scratch → skip Discover; Clarify → Confirm → Design → Estimate → Generate → Gate 2 → POC (any winning runtime). No migration plan (nothing existing to migrate).

  • build_deploy → Discover (if code) → Clarify → Confirm → Design → Estimate → Generate → Gate 1 → Migration Plan (if existing non-AWS AI workload detected and user confirms) → Gate 2 → POC (any winning runtime).

  • migrate → Discover (if code) → Clarify → Confirm → Design → Estimate (target-state run cost; migration TCO comparison stays with the Migration Plan engine) → Generate → Gate 1 → Migration Plan (in-skill, reusing the sibling gcp-to-aws skill) → Gate 2 → POC (any winning runtime, when the plan was produced). Declining Gate 1 keeps the classic handoff: pointer to /aws-startup-advisor:llm-to-bedrock with handoff-summary.md.

  • add_capabilities → load references/phases/add-capabilities/add-capabilities.md and follow it (no runtime scoring; writes capabilities-recommendation.md). This is a self-contained branch — it does NOT pass through Clarify / Confirm / Design / Estimate / Generate, so the phase gate below never applies to it.

  • Temporal detection routes into migrate with temporal units pre-seeded (see discover).

Gate semantics (backbone tail):

  • Gate 1 → migration_plan runs only when generate is done AND recommendation_reviewed == true (generate.md Step 5.5) AND entry point ∈ {migrate, build_deploy} AND the run is migration-eligible (generate.md Step 6) AND the user confirmed Gate 1. Otherwise resolve it: not_applicable (build_scratch / no migratable workload) or skipped (declined) — and advance.

  • Gate 2 → poc runs only when phases.poc == "in_progress" (set when the user answers Gate 2 "yes" — asked in generate.md Step 7 or migration-plan.md Step 6) AND recommendation_reviewed == true. Any winning runtime (agentcore / ecs / eks / lambda / lambda_microvms) — the POC shape follows the verdict (poc.md Step 3 dispatch on references/decision-refs/poc-shapes.md). Gate 2 is only offered when migration_plan ∈ {completed, skipped, not_applicable} — or in_progress on build_deploy only (Stage 2 failed/aborted; fallback POC from design.json per migration-plan.md failure handling); for entry point migrate, only when migration_plan == "completed" (the POC implements the plan) OR when the stage resolved not_applicable with migration_plan_unavailable == "engine_absent" — a standalone deployment that does not bundle the migration engine, where Gate 2 is offered by migration-plan.md Step -1 and the POC is design-backed. A migrate-POC with no plan for any OTHER reason (the user declined) has nothing to implement.

  • Persisting Gate 2 as phases.poc = "in_progress" BEFORE poc.md loads makes the confirmation resumable: if the session breaks between the "yes" and the load, the interpreter re-enters poc without re-asking. (A declared deviation from INTERPRETER.md § The interpreter loop step 5's gate-then-in_progress ordering — the user's confirmation is the entry event worth persisting.)

Phase gate: Do NOT load design.md / estimate.md / generate.md unless $RUN_DIR/.phase-status.json exists and BOTH phases.clarify == "completed" AND phases.confirm == "completed". Confirm confirms the deployment model, the service set, and (for a co_recommend tie) the user's chosen_runtime — Design and the diagram depend on its confirm.json output, so it must not be skipped. If the user asks to skip Clarify or Pass 2, refuse briefly and run it.

State file (.phase-status.json)

{
  "run_id": "0630-1430",
  "entry_point": "build_scratch",
  "audience": "technical",
  "current_phase": "clarify",
  "phases": {
    "intake": "completed",
    "discover": "skipped",
    "clarify": "in_progress",
    "confirm": "pending",
    "design": "pending",
    "estimate": "pending",
    "generate": "pending",
    "migration_plan": "pending",
    "poc": "pending"
  }
}

Status values: pending → in_progress → completed, plus skipped. Use read-merge-write: read before each update, change only the advancing keys, keep prior phases.

recommendation_reviewed (top level, boolean) is set to true by generate.md Step 5.5 when the user explicitly confirms they have seen the recommendation. Gate 1, Gate 2, and the migration_plan / poc states all require it — no gate may be asked while it is absent.

migration_plan additionally uses not_applicable (build_scratch, or no migratable workload detected). When Stage 2 runs, migration_plan_ctx is added at the top level: {"repo": "<abs path to target repo>", "migration_dir": "<abs path to .migration/<id>/>"} — Stage 3 reads gcp-to-aws artifacts ONLY via this recorded path, never by re-globbing.

Files

FilePurpose
references/vendored/dsl/INTERPRETER.mdVendored DSL execution contract (interpreter loop + gate protocol)
references/phases/intake/intake.mdEntry point + technical background + open context
references/phases/discover/discover.mdLightweight code detection
references/phases/clarify/clarify.mdClarify orchestrator + answer mapping to scoring keys
references/phases/clarify/clarify-technical.mdTechnical-background question wording
references/phases/clarify/clarify-business.mdBusiness-background question wording
references/phases/confirm/confirm.mdWinner-specific follow-ups
references/phases/design/design.mdAssemble recommendation; Migrate handoff branch
references/phases/estimate/estimate.mdCoarse cost magnitude
references/phases/generate/generate.mdLayered recommendation doc + scaffolding
references/phases/migration-plan/migration-plan.mdStage 2: full migration plan via the sibling gcp-to-aws engine
references/decision-refs/temporal.mdTemporal rules: Tier 1/2 tables, adapter, runbooks, commercials (consumed by discover/clarify/design/generate)
references/decision-refs/poc-shapes.mdPer-runtime POC deploy shapes (ECS/EKS/Lambda/MicroVMs/Temporal)
references/decision-refs/*.mdRuntime service cards, model defaults, freshness
references/decision-refs/workload-classes.mdDeterministic verdicts for non-agent workload units (batch/service/io)
references/runtimes/*.jsonRuntime registry (read by scoring.py)
scripts/scoring.pyDeterministic scoring engine
scripts/test_temporal_decision_refs.pyContent lock for the Temporal decision reference
scripts/test_poc_shapes.pyContent lock for the POC deploy shapes
scripts/test_workload_classes.pyContent lock for workload-classes.md (verdicts table)
scripts/test_unit_grouping.pyUnit grouping + pattern matching (workload-class assignment)
scripts/test_collapse_invariant.pyCollapse-invariant ordering enforcement (A→B implies [B] ⊆ [A] outputs)

Maturity and readiness contract

Intake persists target_maturity (prototype, private_beta, or production) in run state. Clarify carries it and the readable readiness record into answers.json. Current-run verification evidence remains exclusively in the sibling $RUN_DIR/current-run-verifications.json artifact: never copy it into seed.json or answers.json. Design and Generate may consume that artifact only after validating its schema and matching run_id, and may carry forward verified outcomes but not the raw evidence records. Load references/decision-refs/maturity-readiness.md whenever target maturity is selected. A cached volatile fact may inform discovery, but only a record verified in this run can make a verification-required constraint final; otherwise the score remains provisional with deferred verification requirements.

Contextual offers (final step)

Before you finish: your answer is not complete until you have run the Contextual offers (final step) below.

This is a mandatory closing step of every final recommendation — complete it before you consider your answer done. Run this offer check inline yourself; do not depend on loading another skill. The recommendation is decided on merit first; this step never changes, re-ranks, or re-opens it, and the offer is looked up only after the advice is final.

  1. Read ../knowledge-base-for-startups/references/offers.md — the offer index (Offer · Summary · Keywords), one row per offer.

  2. Judge relevance against what the founder actually surfaced this session. Surface an offer only if one holds: a named-product match (you recommended a specific partner product by name and it has a row); a direct intent/component match (an offer's Keywords directly serve a concrete workload, a component in the final recommendation, or a need the founder raised). Keep a high bar — if the match is weak, or you would be inferring an unstated need, append nothing. Never surface an offer that competes with a product or provider the founder already uses or decided to keep (e.g. existing auth provider → no Auth0 unless they are already on Auth0, and then only as a credit on it; existing vector DB such as Pinecone → no Qdrant).

  3. If (and only if) one offer clears the bar, open only its detail file ../knowledge-base-for-startups/references/offers/<slug>.md and append exactly one quiet, dismissible italic line — stating the value and condensing eligibility faithfully from that file (drop no qualifying criterion; never fabricate), with the redeem link built from the canonical source_url plus a source attribution param — append ?source=ide-startupAdvisor-<host> (or &source=... if the url already has a query string), filling <host> from your execution environment (Claude Code → claude; AWS Startup Advisor IDE extension / VS Code → vscode; Cursor → cursor; Kiro → kiro; Codex → codex), or the generic ide-startupAdvisor when you cannot tell. Only append the query param; never change the destination. When an offer clears the bar you MUST append that single offer line as the last step; do not omit it. The offer is never the pick — only a line under the AWS pick — and stage gates in the references apply (e.g. no Datadog line for an early-stage founder; see ../architect-for-startups/references/observability.md). For a single-service pick (auth, payments, vector DB, observability, etc.) where missing budget/team/traffic inputs would not change the pick, assume an early-stage (pre-PMF) startup unless the founder says otherwise and answer in one turn without a stage-only question; this only removes a stage-only question and never skips the Intake/Clarify/Confirm gates before final advice or the POC. Show exactly one, never a list. If none clears the bar, append nothing and do not mention offers, partner alternatives, or why none appeared.

Standard line:

***<Offer>** has an exclusive offer via AWS Activate — <value>, <eligibility>. [Redeem →](<source_url>?source=ide-startupAdvisor-<host>)*

Caps and control: at most one offer per response and often none; no more than one per five messages and two per session; show a given offer at most once per session and never one already shown, claimed, or dismissed; if the founder has muted offers, skip this step entirely. These per-five-messages, per-session, and already-shown caps are session-state limits; in a fresh session with no prior offers they are non-binding, so do not withhold an otherwise-qualifying offer merely because you cannot verify session history. See ../contextual-offers-for-startups/SKILL.md for the full rules — but perform the check inline; it must not depend on that skill being loaded.

Files

references/phases/generate/generate.md


_phase: generate _title: "Generate — Recommendation Doc + Scaffolding" _requires_phase: estimate _input:

  • design.json

  • confirm.json _fragments:

  • _id: generate-report _trigger: { _always: true } _file: phases/generate/generate-report.md _assemble: _file: phases/generate/generate-assemble.md _produces:

  • diagram.md

  • recommendation.md

  • mini-brief.md

  • recommendation-report.html _advances_to: migration-plan _preconditions:

  • _check_phase_completed: estimate _on_failure: _halt_and_inform

  • _check_file_exists: design.json _on_failure: _unrecoverable

  • _validate_json: design.json _on_failure: _unrecoverable _postconditions:

  • _check_file_exists: [diagram.md, recommendation.md, mini-brief.md, recommendation-report.html] _on_failure: _halt_and_inform

  • _assert: "recommendation.md fills all 12 sections (business summary first, technical detail after) with the freshness footer; mini-brief.md carries the recommendation, top-3 signals, eliminated, model, and any io_wait/fedramp/region/cris notes set in design.json (a non-agent unit in a mixed system may show 'no model' when its model_recommendation is null); recommendation-report.html was generated (Step 5 is not optional); when design.json has >1 unit, recommendation.md contains the System topology section and the report one unit card per unit; every unit card whose design.json unit has a non-null model_recommendation contains the 'Why this model' card (rationale paragraph + collapsed 'Full model & migration detail' details block) rendered from unit.model_recommendation values, not invented" _on_failure: _halt_and_inform

  • _assert: "recommendation.md's architecture-diagram section carries diagram.md's content INLINE — the Mermaid fenced block itself (and the ASCII fallback when build_diagram.py produced one), copied verbatim. A pointer such as 'see diagram.md' does not satisfy it: the recommendation doc is read on its own, often as the only artifact a reader opens, and the diagram is the section's whole content" _on_failure: _halt_and_inform

  • _assert: "every score reported in recommendation.md, mini-brief.md, and the report is the engine's own number, exactly as scoring-result.json states it — no derived total, percentage, or invented denominator (scoring-result.json carries no maximum, so a form like '40/56' is a number the engine never produced)" _on_failure: _halt_and_inform

  • _assert: "recommendation-report.html follows the v3 section spec from generate-report.md Step R1 — its numbered top-level sections are, in order: Summary, Assessment inputs, Recommendation(s), Target architecture, then (Temporal migration only when temporal units exist), Cost summary, Next steps, Generated artifacts, with the dynamic numbering R1 defines; an html whose top-level section structure was invented instead of taken from the template (a known failure mode after a mid-phase context compaction) fails this phase — re-read generate-report.md and regenerate" _on_failure: _halt_and_inform


Phase: Generate — Recommendation Doc + Scaffolding

Step 1 — Read inputs

Read $RUN_DIR/design.json. Read $RUN_DIR/estimate.json if it exists (all entry points except add_capabilities produce estimate.json; if it is absent — failure, or add_capabilities — Generate notes the absence in the report instead of inventing numbers). Load the winning runtime's service card and ${CLAUDE_PLUGIN_ROOT}/skills/agent-advisor/references/decision-refs/model-selection.md. (Same exception as Design Step 2: a serverless_workers unit has NO <verdict>.md card — do not attempt to load one; derive its content from temporal.md + poc-shapes.md.)

Step 2 — Build the architecture diagram

Load references/diagram/build-diagram.md and follow it to produce $RUN_DIR/diagram.md (Mermaid + ASCII), then embed it into Section 4 of the recommendation doc.

Embed means paste the content, not link to it. Copy diagram.md's fenced Mermaid block (and its ASCII fallback) into Section 4 verbatim. "See diagram.md" leaves the section empty for anyone reading recommendation.md on its own, which is how it is usually read — it is the artifact that gets forwarded, and the diagram is that section's entire content.

Step 3 — Fill the recommendation document

Load references/output-templates/recommendation-doc.md. Fill ALL 12 sections. Business summary first, technical detail after (single layered doc — do not fork by audience). Write to $RUN_DIR/recommendation.md. Append the freshness footer.

For migrate: also fill Section 9 (Bedrock model) with the coarse family mapping (e.g. "GPT-4o → Claude Sonnet 5 family") and a note that detailed pricing/TCO come from the migration plugins — no dollar figures. Section 10 (cost magnitude) presents the per-unit target-state bands from estimate.json and notes that the migration TCO comparison and current-spend delta are produced by the migration plugins.

Section 3c — Temporal migration (conditional: only if ANY design.json.units[].workload_class == "temporal_worker_poll" — the temporal block has no units field, so gate on the unit list, matching generate-report.md's TEMPORAL_UNITS_PRESENT): orchestrate §3c content from design.json.temporal + decision-refs/temporal.md. Load the commercials/runbook text from decision-refs/temporal.md (never restate). The Bedrock follow-up gate runs HERE conditionally:

  • AskUserQuestion: "Move Activity LLM calls to Bedrock as part of this migration?"

  • Yes → append "Bedrock migration" section to recommendation.md §3c: (a) point to /aws-startup-advisor:llm-to-bedrock skill as follow-up, (b) REQUIRE replay safety per decision-refs/temporal.md runbook 3 (keep Workflow determinism against recorded history, or isolate via Worker Versioning / new task queue). If deeply-coupled AI integrations flagged, note the rewrite must respect the shim.

  • No → append "Later, optional: Bedrock" section with the same replay-safety pointer.

No Step Functions comparison section — the scope note at the top of the plan already states the orchestration layer stays on Temporal. If the user asks why, answer in chat per decision-refs/temporal.md ("If the user asks") — do not add it to the plan.

Step 4 — Lightweight scaffolding (Build paths only)

Skip this step entirely for migrate (execution artifacts belong to the downstream plugins). For Build paths:

  • AgentCore + Harness → write a minimal harness.json skeleton with the selected services. Include the exact invocation_model_id only when live_verification.status == "passed"; otherwise use TODO: verify model id and state that account access is unverified.

  • AgentCore + Framework / other runtimes → write a minimal framework starter note (entrypoint contract: /invocations POST + /ping GET for AgentCore) + the same verified invocation ID or explicit TODO placeholder. Write scaffolding under $RUN_DIR/scaffold/. Keep it minimal — heavy IaC hands off.

Step 4.5 — Write the mini-brief to $RUN_DIR/mini-brief.md (delivered by the Step 5.5 sidebar)

Compose the mini-brief — it is the deliverable of the whole advisor flow — and WRITE IT TO $RUN_DIR/mini-brief.md (a file, not just chat text; Step 5.5 re-reads it):

  • Recommendation (runtime + deployment model), Why (top 3 signals), Eliminated, Model, and a pointer to $RUN_DIR/recommendation.md.

  • For each model-bearing unit, include API path, path-specific model ID, CRIS/invocation status, [BLOCKS], evaluation mode, and live verification status. Never describe model access as runnable unless live_verification.status == "passed".

  • Any warnings from the scoring result (e.g. 5 TPS).

  • If design.json has io_wait_tco_note == true: the I/O-wait TCO point (AgentCore bills $0 during model/human waits — a cost edge for spiky/HITL traffic; no dollar figures).

  • When set: fedramp_note (FedRAMP WIP — verify + GovCloud fallback), region_availability_note (runtime not in the user's region — nearest supported), and cris_note (geo-CRIS vs global-CRIS data-residency choice for EU/GDPR).

Step 5 — Generate HTML recommendation report

You MUST produce $RUN_DIR/recommendation-report.html — it is a required output of this phase, not optional. Load references/phases/generate/generate-report.md and follow it to write the file, then open it in the user's browser.

Scope of "non-blocking": only the browser-opening and a genuine build failure are non-blocking — NOT the generation itself. So:

  • If the open/xdg-open command fails (no GUI): print Report ready — open: file://$RUN_DIR/recommendation-report.html and continue.

  • If writing the HTML genuinely errors: log the specific warning and continue.

  • Never SKIP this step to reach Step 5.5 faster. Step 5.5 checks that the file exists (below) — if it is missing, you skipped Step 5 and must come back and do it.

Step 5.5 — Recommendation review sidebar (BLOCKING — the user must see and confirm the recommendation before any gate)

Precondition check (do this FIRST, before composing the sidebar): confirm $RUN_DIR/recommendation-report.html exists on disk. If it does NOT, Step 5 was skipped — go back and run Step 5 now (generate the report + open it) before proceeding. Do not present this sidebar without the report having been generated.

This is its own turn, separate from every gate. Send ONE message whose body is the full mini-brief pasted from $RUN_DIR/mini-brief.md, followed in the SAME message by an AskUserQuestion:

[contents of $RUN_DIR/mini-brief.md]

"This is the recommendation. Take a moment to review it (full detail in $RUN_DIR/recommendation.md) — does it look right before we talk about next steps?"

  • Looks good — continue → record the confirmation (below) and proceed to Step 6.

  • Explain more first → answer the user's questions on the recommendation (from recommendation.md / design.json — no new scoring), then re-ask this sidebar.

  • Something's off — revisit an answer → identify which clarify answer changed, update answers.json, re-run scoring, and redo Design → Generate. Do NOT proceed on a recommendation the user disputes.

On "Looks good — continue": read-merge-write .phase-status.json and set top-level "recommendation_reviewed": true.

Mechanical gate rule: Steps 6 and 7 MUST NOT ask Gate 1 or Gate 2 unless .phase-status.json has recommendation_reviewed == true. If it is absent, you skipped this sidebar — go back and run it. This ordering is not optional and does not collapse into the gate question: the user confirms they have SEEN the recommendation first, and only then is asked what to do next. (Resume-safe: if the session breaks after confirmation, the flag survives and the sidebar is not re-asked.)

Because the sidebar delivered the brief, the gates below only need a one-line recap (runtime + deployment model + model), not the full brief.

Step 6 — Migration-plan gate (Gate 1)

Precondition: .phase-status.json.recommendation_reviewed == true (set by Step 5.5). Absent → run Step 5.5 first; never ask this gate without it.

Applicability (skip this step when none applies — mark phases.migration_plan = "not_applicable"):

  • entry_point == migrate → always offer.

  • entry_point == build_deploy → offer ONLY if Discover ran and $RUN_DIR/context-signals.json.model_provider ∈ {openai, anthropic, google-genai} — i.e. something real exists to migrate. Key absent, none, or bedrock → not applicable.

  • entry_point == build_scratch → never (nothing existing to migrate).

For migrate, FIRST load references/handoff/handoff-migration.md and follow its Step 1 to write $RUN_DIR/handoff-summary.md (it is both the human-readable handoff artifact and the Stage 2 injection payload source). Then ask Gate 1 — a one-line recap (runtime + deployment model + model; the full brief was confirmed at Step 5.5), followed by the AskUserQuestion in the same message:

Recommended: <runtime> + <deployment model>, model <model> (details: recommendation.md).

"Do you want a complete migration plan for this workload? I'll generate it here using this plugin's migration engine, reusing the decisions we already made (runtime, deployment model, memory). It will analyze your code and may ask a few extra questions."

  • Yes — generate the migration plan → set phases.migration_plan = "pending"; after Step 7 the state machine loads references/phases/migration-plan/migration-plan.md.

  • No → set phases.migration_plan = "skipped". For migrate, keep the classic pointer: follow handoff-migration.md Steps 2–4 (direct the user to /aws-startup-advisor:llm-to-bedrock or gcp-to-aws with handoff-summary.md).

Step 7 — Write state and branch

Set phases.generate = completed (read-merge-write). Then branch:

  1. Gate 1 answered Yes → next phase is migration_plan: load references/phases/migration-plan/migration-plan.md. Gate 2 is offered from that phase's Step 6.

  2. Otherwise, if entry_point ∈ {build_scratch, build_deploy}: ask Gate 2 for the primary unit's effective_runtime — any of agentcore / ecs / eks / lambda / lambda_microvms (the primary is always an agent unit per Clarify's scope gate). In a MULTI-unit system, each non-primary unit still gets its own POC per poc.md Step 3 dispatch (incl. batch / fargate / serverless_workers, and a model-less non-agent unit omits Bedrock wiring). Precondition unchanged (recommendation_reviewed == true). Give a one-line recap (runtime + deployment model + model), followed by the AskUserQuestion in the same message:

    Recommended: <runtime> + <deployment model>, model <model> (details: recommendation.md).

    "Do you want a deployable proof-of-concept for this recommendation on <runtime>? I'll generate the agent code, deployment plan, and scripts."

    • Yes → set phases.poc = "in_progress" (persist the confirmation), then load references/phases/poc/poc.md (it asks which POC mode first).

    • No → set phases.poc = "skipped"; the advisor flow is complete.

  3. Otherwise (migrate without a plan): the Step 5.5 sidebar already delivered the brief; close with a short completion message pointing at recommendation.md — the advisor flow is complete.

Non-interactive runs (seeded). When $RUN_DIR/seed.json exists (clarify.md Step 2.5), its gates block answers these gates instead of AskUserQuestion: gates.migration_plan and gates.poc, each accept or decline. A gate the seed does not mention is DECLINED — never accept a gate on the user's behalf, because both gates spend real time and money. Persist the resolved status exactly as the interactive path does (phases.poc = "in_progress" before poc.md loads on accept, "skipped" on decline) so a resumed run does not re-ask. Record in $RUN_DIR/UNANSWERED.md that the gate was resolved from the seed default rather than by a human whenever the seed was silent.

Note: for migrate WITH a completed migration plan, Gate 2 is asked at the end of migration-plan.md (its Step 6), using the same wording as point 2 above.

Maturity/readiness output extension

Recommendation.md and mini-brief.md must state target maturity, readiness status, concrete gaps, tier-appropriate release/evaluation gates, recommendation status, and every deferred verification requirement. Label the mini-brief Provisional whenever design.json.recommendation_status == "provisional"; it must say that no runtime decision, pricing claim, or launch gate relying on deferred evidence is final. Include the AgentCore I/O-wait billing benefit only when Design recorded current-run verification; otherwise report the check as pending without a static billing result.

Requirements and compatibility

Written for: Claude Code

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Names Claude Code tools, Needs Python

Security

What our scanner noticed· Low risk

  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
AWS
Publisher
AWS (Official)
Source
aws/agent-toolkit-for-aws · plugins/aws-startup-advisor/skills/agent-advisor · commit 0a218f8
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • NOTICE (added by AutoGineer from NOTICE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by AWS or AWS.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download agent-advisor.zip