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
Download the skill as a ZIP:
https://autogineer.com/agent-skills/aws/agent-advisor/downloadUnzip 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
uvavailable (for scoring). Check:uv --version. If missing, tell the user to install it from the official install guide (https://docs.astral.sh/uv/getting-started/installation/ — e.g.brew install uvorpipx install uv) and stop.
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_DIRis this skill's name for the run directory (.agent-advisor/[MMDD-HHMM]/). Intake's own prose performs the_initbootstrap.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.jsonat the run root (schemascripts/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 aco_recommendtie-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 anassumedvalue 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), plusnot_applicableformigration_planonly.Conditional backbone routing: the entry-point routing below. When a routing rule marks a phase not-applicable, set it
skippedand advance through its_advances_toin 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 siblinggcp-to-awsskill) → 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-bedrockwithhandoff-summary.md.add_capabilities→ loadreferences/phases/add-capabilities/add-capabilities.mdand follow it (no runtime scoring; writescapabilities-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
migratewith temporal units pre-seeded (see discover).
Gate semantics (backbone tail):
Gate 1 →
migration_planruns only whengenerateis done ANDrecommendation_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) orskipped(declined) — and advance.Gate 2 →
pocruns only whenphases.poc == "in_progress"(set when the user answers Gate 2 "yes" — asked in generate.md Step 7 or migration-plan.md Step 6) ANDrecommendation_reviewed == true. Any winning runtime (agentcore / ecs / eks / lambda / lambda_microvms) — the POC shape follows the verdict (poc.md Step 3 dispatch onreferences/decision-refs/poc-shapes.md). Gate 2 is only offered whenmigration_plan∈ {completed, skipped, not_applicable} — orin_progresson build_deploy only (Stage 2 failed/aborted; fallback POC from design.json per migration-plan.md failure handling); for entry pointmigrate, only whenmigration_plan == "completed"(the POC implements the plan) OR when the stage resolvednot_applicablewithmigration_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-enterspocwithout re-asking. (A declared deviation fromINTERPRETER.md§ The interpreter loop step 5's gate-then-in_progressordering — 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
| File | Purpose |
|---|---|
references/vendored/dsl/INTERPRETER.md | Vendored DSL execution contract (interpreter loop + gate protocol) |
references/phases/intake/intake.md | Entry point + technical background + open context |
references/phases/discover/discover.md | Lightweight code detection |
references/phases/clarify/clarify.md | Clarify orchestrator + answer mapping to scoring keys |
references/phases/clarify/clarify-technical.md | Technical-background question wording |
references/phases/clarify/clarify-business.md | Business-background question wording |
references/phases/confirm/confirm.md | Winner-specific follow-ups |
references/phases/design/design.md | Assemble recommendation; Migrate handoff branch |
references/phases/estimate/estimate.md | Coarse cost magnitude |
references/phases/generate/generate.md | Layered recommendation doc + scaffolding |
references/phases/migration-plan/migration-plan.md | Stage 2: full migration plan via the sibling gcp-to-aws engine |
references/decision-refs/temporal.md | Temporal rules: Tier 1/2 tables, adapter, runbooks, commercials (consumed by discover/clarify/design/generate) |
references/decision-refs/poc-shapes.md | Per-runtime POC deploy shapes (ECS/EKS/Lambda/MicroVMs/Temporal) |
references/decision-refs/*.md | Runtime service cards, model defaults, freshness |
references/decision-refs/workload-classes.md | Deterministic verdicts for non-agent workload units (batch/service/io) |
references/runtimes/*.json | Runtime registry (read by scoring.py) |
scripts/scoring.py | Deterministic scoring engine |
scripts/test_temporal_decision_refs.py | Content lock for the Temporal decision reference |
scripts/test_poc_shapes.py | Content lock for the POC deploy shapes |
scripts/test_workload_classes.py | Content lock for workload-classes.md (verdicts table) |
scripts/test_unit_grouping.py | Unit grouping + pattern matching (workload-class assignment) |
scripts/test_collapse_invariant.py | Collapse-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.
Read
../knowledge-base-for-startups/references/offers.md— the offer index (Offer · Summary · Keywords), one row per offer.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).
If (and only if) one offer clears the bar, open only its detail file
../knowledge-base-for-startups/references/offers/<slug>.mdand 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 canonicalsource_urlplus asourceattribution 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 genericide-startupAdvisorwhen 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
- ATTRIBUTION.mdAdded by AutoGineer907 B
- LICENSELicence file added by AutoGineer9.9 KiB
- NOTICELicence file added by AutoGineer67 B
- SKILL.md19.2 KiB
- references/decision-refs/agentcore.md5.4 KiB
- references/decision-refs/batch.md2.3 KiB
- references/decision-refs/cost-levers.md1.8 KiB
- references/decision-refs/ecs.md1.4 KiB
- references/decision-refs/eks.md1.1 KiB
- references/decision-refs/freshness.md10.7 KiB
- references/decision-refs/lambda-microvms.md1.9 KiB
- references/decision-refs/lambda.md1.1 KiB
- references/decision-refs/managed-alternatives.md1.9 KiB
- references/decision-refs/maturity-readiness.md2.8 KiB
- references/decision-refs/model-selection.md4.2 KiB
- references/decision-refs/poc-shapes.md15.5 KiB
- references/decision-refs/temporal.md17.5 KiB
- references/decision-refs/workload-classes.md2.2 KiB
- references/diagram/build-diagram.md5.1 KiB
- references/handoff/handoff-migration.md2.1 KiB
- references/output-templates/recommendation-doc.md5.1 KiB
- references/phases/add-capabilities/add-capabilities-assemble.md951 B
- references/phases/add-capabilities/add-capabilities.md4.6 KiB
- references/phases/clarify/clarify-assemble.md1.4 KiB
- references/phases/clarify/clarify-business.md3.3 KiB
- references/phases/clarify/clarify-technical.md2.7 KiB
- references/phases/clarify/clarify.md26.5 KiB
- references/phases/confirm/confirm-assemble.md1019 B
- references/phases/confirm/confirm.md15.1 KiB
- references/phases/design/design-assemble.md1.7 KiB
- references/phases/design/design.md26.9 KiB
- references/phases/discover/discover-assemble.md1.2 KiB
- references/phases/discover/discover.md10.0 KiB
- references/phases/estimate/estimate-assemble.md780 B
- references/phases/estimate/estimate.md19.0 KiB
- references/phases/generate/generate-assemble.md1.0 KiB
- references/phases/generate/generate-report.md45.6 KiB
- references/phases/generate/generate.md15.7 KiB
- references/phases/intake/intake-assemble.md991 B
- references/phases/intake/intake.md5.6 KiB
- references/phases/migration-plan/migration-plan-assemble.md1.2 KiB
- references/phases/migration-plan/migration-plan-gcp-constraints.md3.9 KiB
- references/phases/migration-plan/migration-plan.md32.1 KiB
- references/phases/model-recommend/model-recommend-assemble.md937 B
- references/phases/model-recommend/model-recommend.md17.2 KiB
- references/phases/poc/poc-assemble.md1.0 KiB
- references/phases/poc/poc-report.md12.6 KiB
- references/phases/poc/poc.md44.8 KiB
- references/report-help-banner.md6.0 KiB
- references/report-shell.md12.3 KiB
- references/runtimes/agentcore.json3.1 KiB
- references/runtimes/ecs.json1.5 KiB
- references/runtimes/eks.json1.4 KiB
- references/runtimes/lambda.json2.4 KiB
- references/runtimes/lambda_microvms.json3.3 KiB
- references/vendored/README.md2.0 KiB
- references/vendored/ai/bedrock-pricing-cache.md57.2 KiB
- references/vendored/ai/models/anthropic-bedrock.json8.6 KiB
- references/vendored/ai/models/openai-bedrock.json28.0 KiB
- references/vendored/dsl/INTERPRETER.md51.8 KiB
- scripts/anthropic_model_recommendation.pyScript35.0 KiB
- scripts/build_diagram.pyScript21.2 KiB
- scripts/model_recommendation.pyScript8.8 KiB
- scripts/openai_model_recommendation.pyScript58.1 KiB
- scripts/pyproject.toml170 B
- scripts/schemas/current-run-verifications.json1.1 KiB
- scripts/schemas/model-recommendation-input.json5.4 KiB
- scripts/schemas/model-recommendation.json13.1 KiB
- scripts/schemas/model-verification.json2.5 KiB
- scripts/schemas/scoring-result.json3.5 KiB
- scripts/schemas/seed.json5.6 KiB
- scripts/score_units.pyScript2.9 KiB
- scripts/scoring.pyScript16.5 KiB
- scripts/test_build_diagram.pyScript21.8 KiB
- scripts/test_collapse_invariant.pyScript2.0 KiB
- scripts/test_cost_levers.pyScript1.7 KiB
- scripts/test_model_recommendation.pyScript13.9 KiB
- scripts/test_openai_model_recommendation.pyScript46.5 KiB
- scripts/test_opus55_generation_contracts.pyScript20.8 KiB
- scripts/test_opus55_integration.pyScript21.5 KiB
- scripts/test_poc_shapes.pyScript14.2 KiB
- scripts/test_scoring.pyScript35.3 KiB
- scripts/test_temporal_decision_refs.pyScript7.4 KiB
- scripts/test_unit_grouping.pyScript71.7 KiB
- scripts/test_verify_model_path.pyScript25.8 KiB
- scripts/test_workload_classes.pyScript5.2 KiB
- scripts/uv.lock97.8 KiB
- scripts/verify_model_path.pyScript10.9 KiB
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-bedrockskill 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.jsonskeleton with the selected services. Include the exactinvocation_model_idonly whenlive_verification.status == "passed"; otherwise useTODO: verify model idand state that account access is unverified.AgentCore + Framework / other runtimes → write a minimal framework starter note (entrypoint contract:
/invocationsPOST +/pingGET 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 unlesslive_verification.status == "passed".Any
warningsfrom the scoring result (e.g. 5 TPS).If
design.jsonhasio_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), andcris_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-opencommand fails (no GUI): printReport ready — open: file://$RUN_DIR/recommendation-report.htmland 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, orbedrock→ 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 loadsreferences/phases/migration-plan/migration-plan.md.No → set
phases.migration_plan = "skipped". Formigrate, keep the classic pointer: follow handoff-migration.md Steps 2–4 (direct the user to/aws-startup-advisor:llm-to-bedrockorgcp-to-awswithhandoff-summary.md).
Step 7 — Write state and branch
Set phases.generate = completed (read-merge-write). Then branch:
Gate 1 answered Yes → next phase is
migration_plan: loadreferences/phases/migration-plan/migration-plan.md. Gate 2 is offered from that phase's Step 6.Otherwise, if entry_point ∈ {
build_scratch,build_deploy}: ask Gate 2 for the primary unit'seffective_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 loadreferences/phases/poc/poc.md(it asks which POC mode first).No → set
phases.poc = "skipped"; the advisor flow is complete.
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