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://mp-staging.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
scripts/test_build_diagram.py
import build_diagram
def test_resolve_runtime_single_winner():
assert build_diagram.resolve_runtime(
{"verdict": "agentcore"}, {}) == "agentcore"
def test_resolve_runtime_co_recommend_uses_confirm_choice():
result = {"verdict": "co_recommend", "co_recommend": ["ecs", "eks"]}
assert build_diagram.resolve_runtime(result, {"chosen_runtime": "eks"}) == "eks"
def test_resolve_runtime_co_recommend_falls_back_to_first():
result = {"verdict": "co_recommend", "co_recommend": ["ecs", "eks"]}
assert build_diagram.resolve_runtime(result, {}) == "ecs"
def test_resolve_runtime_no_viable():
assert build_diagram.resolve_runtime(
{"verdict": "no_viable_runtime"}, {}) == "none"
def test_labels_cover_all_runtimes():
for rid in ("agentcore", "lambda_microvms", "ecs", "eks", "lambda"):
assert rid in build_diagram.RUNTIME_LABELS
def test_service_labels_include_payments_and_registry():
# Conditional AgentCore services (SA feedback: relevant but not always).
assert build_diagram.SERVICE_LABELS["payments"] == "Payments"
assert build_diagram.SERVICE_LABELS["registry"] == "Registry"
def test_payments_registry_render_in_diagram():
out = build_diagram.render_mermaid(
"agentcore", ["identity", "payments", "registry"], "claude_sonnet_5", "harness")
assert "Payments" in out and "Registry" in out
def test_resolve_services_prefers_confirm():
result = {"agentcore_services": ["identity", "observability"]}
confirm = {"agentcore_services": ["identity", "memory", "gateway"]}
assert build_diagram.resolve_services(result, confirm) == [
"identity", "memory", "gateway"]
def test_resolve_services_falls_back_to_result():
result = {"agentcore_services": ["identity", "observability"]}
assert build_diagram.resolve_services(result, {}) == [
"identity", "observability"]
def test_resolve_services_filters_unknown_and_dedupes():
confirm = {"agentcore_services": ["identity", "identity", "bogus", "memory"]}
assert build_diagram.resolve_services({}, confirm) == ["identity", "memory"]
def test_mermaid_has_runtime_model_and_services():
out = build_diagram.render_mermaid(
"agentcore", ["identity", "memory"], "claude_sonnet_5", "harness")
assert out.startswith("flowchart TD")
assert "AgentCore Runtime" in out
assert "harness" in out.lower()
assert "claude_sonnet_5" in out
assert "Identity" in out and "Memory" in out
assert "migration skill" not in out # no handoff for agentcore
def test_mermaid_model_is_solid_edge_services_are_dotted():
# Topology: the model is a downstream call (solid invoke edge); services are
# cross-cutting capabilities attached with a dotted edge into a subgraph.
out = build_diagram.render_mermaid(
"agentcore", ["identity", "memory"], "claude_sonnet_5", "harness")
assert "rt -->|invoke| model" in out # model = solid data-flow edge
assert 'subgraph svcs["AgentCore services"]' in out
assert "rt -.-> svcs" in out # services = dotted attachment
# Services must NOT be flat solid children of the runtime anymore.
assert "rt --> svc_identity" not in out
def test_mermaid_no_services_no_subgraph():
out = build_diagram.render_mermaid(
"agentcore", [], "claude_sonnet_5", "harness")
assert "subgraph" not in out
assert "rt -->|invoke| model" in out
def test_mermaid_adds_handoff_note_for_ecs():
out = build_diagram.render_mermaid("ecs", [], "claude_sonnet_5", None)
assert "Amazon ECS (Fargate)" in out
assert "migration skill" in out
def test_mermaid_deterministic():
a = build_diagram.render_mermaid("agentcore", ["identity", "memory"],
"claude_sonnet_5", "harness")
b = build_diagram.render_mermaid("agentcore", ["identity", "memory"],
"claude_sonnet_5", "harness")
assert a == b
def test_ascii_contains_runtime_model_services():
out = build_diagram.render_ascii(
"agentcore", ["identity", "memory"], "claude_sonnet_5", "harness")
assert "AgentCore Runtime" in out
assert "harness" in out.lower()
assert "claude_sonnet_5" in out
assert "- Identity" in out and "- Memory" in out
assert "migration skill" not in out
# Model is on the primary flow; services are attached, not call targets.
assert "invoke" in out
assert "attached AgentCore services" in out
def test_ascii_handoff_for_ecs():
out = build_diagram.render_ascii("ecs", [], "claude_sonnet_5", None)
assert "Amazon ECS" in out
assert "migration skill" in out
def test_ascii_no_handoff_for_standard_lambda():
# Standard Lambda is a self-contained Build target (function skeleton), not a
# heavy-infrastructure handoff — no migration skill note.
out = build_diagram.render_ascii("lambda", [], "claude_sonnet_5", None)
assert "AWS Lambda" in out
assert "migration skill" not in out
def test_ascii_deterministic():
a = build_diagram.render_ascii("eks", ["identity"], "claude_sonnet_5", None)
b = build_diagram.render_ascii("eks", ["identity"], "claude_sonnet_5", None)
assert a == b
def test_build_diagram_end_to_end():
result = {"verdict": "agentcore", "deployment_model": "harness",
"agentcore_services": ["identity"],
"model_recommendation": {"model": "claude_sonnet_5"}}
out = build_diagram.build_diagram(result, {})
assert "flowchart TD" in out["mermaid"]
assert "AgentCore Runtime" in out["ascii"]
def test_build_diagram_no_viable():
out = build_diagram.build_diagram({"verdict": "no_viable_runtime"}, {})
assert "No viable runtime" in out["mermaid"]
assert "No viable runtime" in out["ascii"]
def test_golden_agentcore_full():
result = {"verdict": "agentcore", "deployment_model": "framework_on_runtime",
"agentcore_services": ["identity", "observability", "memory", "gateway"],
"model_recommendation": {"model": "claude_sonnet_5"}}
out = build_diagram.build_diagram(result, {})
# runtime + deployment model + all four services + model, no handoff
assert "framework_on_runtime" in out["mermaid"]
for svc in ("Identity", "Observability", "Memory", "Gateway"):
assert svc in out["mermaid"] and svc in out["ascii"]
assert "migration skill" not in out["mermaid"]
def test_golden_lambda_microvms_no_services_no_handoff():
result = {"verdict": "lambda_microvms", "deployment_model": None,
"agentcore_services": [],
"model_recommendation": {"model": "claude_sonnet_5"}}
out = build_diagram.build_diagram(result, {})
assert "Lambda MicroVMs" in out["mermaid"]
assert "migration skill" not in out["mermaid"] # MicroVMs is not a handoff runtime
def test_golden_ecs_has_handoff():
result = {"verdict": "ecs", "deployment_model": None,
"agentcore_services": ["identity"],
"model_recommendation": {"model": "claude_sonnet_5"}}
out = build_diagram.build_diagram(result, {})
assert "migration skill" in out["mermaid"]
assert "migration skill" in out["ascii"]
def test_golden_co_recommend_renders_chosen():
result = {"verdict": "co_recommend", "co_recommend": ["ecs", "eks"],
"deployment_model": None, "agentcore_services": [],
"model_recommendation": {"model": "claude_sonnet_5"}}
out = build_diagram.build_diagram(result, {"chosen_runtime": "eks"})
assert "Amazon EKS" in out["mermaid"]
assert "migration skill" in out["mermaid"] # eks is a handoff runtime
def _two_unit_design():
return {
"units": [
{"id": "chat-agent", "workload_class": "agent_session",
"verdict": "agentcore",
"model_recommendation": {"model": "claude_sonnet_5"}},
{"id": "summarizer", "workload_class": "batch", "verdict": "batch",
"model_recommendation": None},
],
"platform": {"mode": "split", "runtime": None, "interconnect": "queue",
"shared_services": []},
}
def test_multi_unit_renders_subgraph_per_unit():
out = build_diagram.build_diagram({}, {}, design=_two_unit_design())
assert "chat-agent" in out["mermaid"] and "summarizer" in out["mermaid"]
assert out["mermaid"].count("subgraph") >= 2
def test_multi_unit_interconnect_edge():
out = build_diagram.build_diagram({}, {}, design=_two_unit_design())
assert "queue" in out["mermaid"].lower()
def _consolidated_design():
# Codex #2: consolidated onto ECS — the diagram must render each unit on its
# effective_runtime (ecs), NOT its raw verdict (agentcore/batch).
return {
"units": [
{"id": "chat-agent", "workload_class": "agent_session",
"verdict": "agentcore", "effective_runtime": "ecs",
"model_recommendation": {"model": "claude_sonnet_5"}},
{"id": "summarizer", "workload_class": "batch",
"verdict": "batch", "effective_runtime": "ecs",
"model_recommendation": None},
],
"platform": {"mode": "consolidated", "runtime": "ecs", "interconnect": "none",
"shared_services": []},
}
def test_consolidated_diagram_renders_effective_runtime_not_verdict():
out = build_diagram.build_diagram({}, {}, design=_consolidated_design())
m = out["mermaid"]
# Both units render as ECS (the consolidated target)...
assert m.count("Amazon ECS (Fargate)") >= 2
# ...not their raw best-fit verdicts.
assert "AgentCore Runtime" not in m
assert "AWS Batch" not in m
def _mixed_coupling_design():
# Codex #5: interconnect == queue means "at least one queue coupling exists", not
# "every unit is on the queue". The independent (coupling none) unit must NOT be wired.
return {
"units": [
{"id": "producer", "workload_class": "service", "verdict": "fargate",
"coupling": {"mode": "queue", "interacts_with": ["consumer"]},
"model_recommendation": None},
{"id": "consumer", "workload_class": "light_io", "verdict": "lambda",
"coupling": {"mode": "none", "interacts_with": []},
"model_recommendation": None},
{"id": "loner", "workload_class": "batch", "verdict": "batch",
"coupling": {"mode": "none", "interacts_with": []},
"model_recommendation": None},
],
"platform": {"mode": "split", "runtime": None, "interconnect": "queue",
"shared_services": []},
}
def test_queue_interconnect_follows_one_way_coupling():
# Codex round-3 #4: a one-way coupling is producer mode:queue interacts_with [consumer],
# consumer mode:none. BOTH ends must be on the queue; the truly independent unit must not.
out = build_diagram.build_diagram({}, {}, design=_mixed_coupling_design())
m = out["mermaid"]
assert "producer -.-> queue" in m
# The consumer is mode:none but is the target of the producer's queue coupling — wired.
assert "consumer -.-> queue" in m
# The independent unit (neither queue nor a coupling target) is drawn but NOT wired.
assert "loner" in m
assert "loner -.-> queue" not in m
def _mixed_gateway_design():
# Codex round-4 #2: gateway must filter like queue — connect only api/a2a-coupled units
# (and their interacts_with targets), never independent mode:none units.
return {
"units": [
{"id": "orchestrator", "workload_class": "agent_session", "verdict": "agentcore",
"coupling": {"mode": "a2a", "interacts_with": ["tool-agent"]},
"model_recommendation": {"model": "claude_sonnet_5"}},
{"id": "tool-agent", "workload_class": "agent_session", "verdict": "agentcore",
"coupling": {"mode": "none", "interacts_with": []},
"model_recommendation": {"model": "claude_sonnet_5"}},
{"id": "loner", "workload_class": "batch", "verdict": "batch",
"coupling": {"mode": "none", "interacts_with": []},
"model_recommendation": None},
],
"platform": {"mode": "split", "runtime": None, "interconnect": "gateway",
"shared_services": []},
}
def test_gateway_interconnect_only_wires_gateway_coupled_units():
out = build_diagram.build_diagram({}, {}, design=_mixed_gateway_design())
m = out["mermaid"]
# Node ids are sanitized (hyphens → underscores).
assert "orchestrator -.-> gateway" in m
# tool-agent is mode:none but is the a2a target — wired.
assert "tool_agent -.-> gateway" in m
# The independent unit must NOT be wired to the gateway.
assert "loner" in m
assert "loner -.-> gateway" not in m
def _mixed_queue_and_gateway_design():
# Codex round-5 #1: a system can mix couplings — an api pair AND a queue pair. Design records
# only the dominant platform.interconnect (gateway wins), but BOTH must be drawn; the queue
# relationship must not vanish just because a gateway coupling also exists.
return {
"units": [
{"id": "api-a", "workload_class": "agent_session", "verdict": "agentcore",
"coupling": {"mode": "api", "interacts_with": ["api-b"]},
"model_recommendation": {"model": "claude_sonnet_5"}},
{"id": "api-b", "workload_class": "service", "verdict": "fargate",
"coupling": {"mode": "none", "interacts_with": []},
"model_recommendation": None},
{"id": "q-producer", "workload_class": "service", "verdict": "fargate",
"coupling": {"mode": "queue", "interacts_with": ["q-consumer"]},
"model_recommendation": None},
{"id": "q-consumer", "workload_class": "batch", "verdict": "batch",
"coupling": {"mode": "none", "interacts_with": []},
"model_recommendation": None},
],
# gateway wins as the single dominant interconnect value...
"platform": {"mode": "split", "runtime": None, "interconnect": "gateway",
"shared_services": []},
}
def test_mixed_queue_and_gateway_both_rendered():
out = build_diagram.build_diagram({}, {}, design=_mixed_queue_and_gateway_design())
m = out["mermaid"]
# Gateway pair wired.
assert "api_a -.-> gateway" in m and "api_b -.-> gateway" in m
# Queue pair must ALSO be wired — not lost to the exclusive branch.
assert 'queue["Queue"]' in m
assert "q_producer -.-> queue" in m and "q_consumer -.-> queue" in m
# Cross-wiring must not happen (queue units not on gateway, api units not on queue).
assert "q_producer -.-> gateway" not in m
assert "api_a -.-> queue" not in m
def test_single_unit_design_falls_back_to_legacy_render():
d = {"units": [_two_unit_design()["units"][0]],
"platform": {"mode": "split", "runtime": None,
"interconnect": "in_process", "shared_services": []}}
legacy = build_diagram.build_diagram(
{"verdict": "agentcore",
"agentcore_services": [],
"model_recommendation": {"model": "claude_sonnet_5"}}, {})
unitized = build_diagram.build_diagram(
{"verdict": "agentcore",
"agentcore_services": [],
"model_recommendation": {"model": "claude_sonnet_5"}}, {}, design=d)
assert unitized["mermaid"] == legacy["mermaid"], \
"collapse invariant: one unit renders exactly the legacy diagram"
def _temporal_design():
return {
"units": [
{"id": "worker-fleet", "workload_class": "temporal_worker_poll",
"verdict": "ecs", "queues": ["agent-tasks", "batch-tasks"],
"model_recommendation": None},
{"id": "doc-chat", "workload_class": "agent_session",
"verdict": "agentcore",
"model_recommendation": {"model": "claude_sonnet_5"},
"task_queue": "agent-tasks"},
{"id": "ocr", "workload_class": "batch", "verdict": "batch",
"model_recommendation": None,
"task_queue": "batch-tasks"},
],
"platform": {"mode": "split", "runtime": None, "interconnect": "none",
"shared_services": []},
"temporal": {"way": "cloud", "server": "Temporal Cloud"},
}
def _temporal_design_multi_fleet():
# Two fleets, each polling its OWN queue; each Activity runs on exactly one queue.
# A correct diagram connects fleet-a -> chat (agent-tasks) and fleet-b -> ocr
# (batch-tasks), NEVER the cartesian product (fleet-a -> ocr, fleet-b -> chat).
return {
"units": [
{"id": "fleet-a", "workload_class": "temporal_worker_poll",
"verdict": "ecs", "queues": ["agent-tasks"], "model_recommendation": None},
{"id": "fleet-b", "workload_class": "temporal_worker_poll",
"verdict": "ecs", "queues": ["batch-tasks"], "model_recommendation": None},
{"id": "chat", "workload_class": "agent_session", "verdict": "agentcore",
"model_recommendation": {"model": "claude_sonnet_5"},
"task_queue": "agent-tasks"},
{"id": "ocr", "workload_class": "batch", "verdict": "batch",
"model_recommendation": None, "task_queue": "batch-tasks"},
],
"platform": {"mode": "split", "runtime": None, "interconnect": "none",
"shared_services": []},
"temporal": {"way": "self_hosted", "server": "self-hosted"},
}
def test_temporal_self_hosted_not_labeled_cloud():
# #4: a self_hosted Way must not be rendered as "Temporal Cloud".
out = build_diagram.build_diagram({}, {}, design=_temporal_design_multi_fleet())
assert "Temporal Cloud" not in out["mermaid"]
assert "Temporal Cloud" not in out["ascii"]
assert "self-hosted" in out["mermaid"]
assert "self-hosted" in out["ascii"]
def test_temporal_multi_fleet_no_cartesian_product():
# #3: each fleet connects ONLY to the Activity on its own queue.
out = build_diagram.build_diagram({}, {}, design=_temporal_design_multi_fleet())
m = out["mermaid"]
# Correct edges present.
assert "fleet_a -->|agent-tasks| chat" in m
assert "fleet_b -->|batch-tasks| ocr" in m
# Cross edges (cartesian product) must NOT appear.
assert "fleet_a -->|batch-tasks| ocr" not in m
assert "fleet_a --> ocr" not in m
assert "fleet_b --> chat" not in m
assert "fleet_b -->|agent-tasks| chat" not in m
def test_temporal_topology_renders_temporal_cloud_node():
out = build_diagram.build_diagram({}, {}, design=_temporal_design())
assert "Temporal Cloud" in out["mermaid"]
assert "orchestrator" in out["mermaid"]
assert "Temporal Cloud" in out["ascii"]
def test_temporal_topology_connects_worker_poll_unit():
out = build_diagram.build_diagram({}, {}, design=_temporal_design())
# Temporal Cloud should connect to worker-fleet
assert "temporal_cloud --> worker_fleet" in out["mermaid"]
# Worker should connect to activity units
assert "worker_fleet -->" in out["mermaid"]
assert "doc_chat" in out["mermaid"] or "doc-chat" in out["mermaid"]
def test_temporal_topology_no_user_edge():
out = build_diagram.build_diagram({}, {}, design=_temporal_design())
# Should NOT have user -> agent edge in Temporal systems
assert 'user["User' not in out["mermaid"]
assert "User / Client" not in out["ascii"] or "Temporal Cloud" in out["ascii"]
def test_temporal_topology_no_inter_unit_queue_chain():
out = build_diagram.build_diagram({}, {}, design=_temporal_design())
# Should NOT have a separate queue node chaining units
assert 'queue["Queue"]' not in out["mermaid"]
assert "Interconnect: Queue" not in out["ascii"]
def test_temporal_topology_with_task_queue_labels():
out = build_diagram.build_diagram({}, {}, design=_temporal_design())
# Should label edges with task queue names when available
assert "agent-tasks" in out["mermaid"] or "batch-tasks" in out["mermaid"]
def test_multi_unit_handoff_node_for_ecs_units():
# Audit finding #2: the multi-unit diagram must show the "configured by migration skill"
# handoff indicator for units on a HANDOFF_RUNTIME — same as the single-unit path — instead
# of silently dropping it. Consolidated-onto-ECS is the canonical case.
out = build_diagram.build_diagram({}, {}, design=_consolidated_design())
assert "migration skill" in out["mermaid"], \
"multi-unit Mermaid must render the handoff node for ECS/EKS/Fargate/Batch units"
assert "migration skill" in out["ascii"], \
"multi-unit ASCII must render the handoff note (twin of the Mermaid path)"
def test_multi_unit_no_handoff_for_self_contained_units():
# The inverse: an all-Lambda/AgentCore multi-unit system needs NO handoff indicator.
design = {
"units": [
{"id": "a", "workload_class": "agent_session", "verdict": "agentcore",
"effective_runtime": "agentcore", "model_recommendation": None},
{"id": "b", "workload_class": "light_io", "verdict": "lambda",
"effective_runtime": "lambda", "model_recommendation": None},
],
"platform": {"mode": "split", "runtime": None, "interconnect": "none",
"shared_services": []},
}
out = build_diagram.build_diagram({}, {}, design=design)
assert "migration skill" not in out["mermaid"]
assert "migration skill" not in out["ascii"]
def test_units_needing_handoff_covers_all_four_runtimes():
# units_needing_handoff must key on the same set as HANDOFF_RUNTIMES (ecs/eks/fargate/batch).
units = [
{"id": "e", "effective_runtime": "ecs"},
{"id": "k", "effective_runtime": "eks"},
{"id": "f", "effective_runtime": "fargate"},
{"id": "b", "effective_runtime": "batch"},
{"id": "l", "effective_runtime": "lambda"},
{"id": "a", "effective_runtime": "agentcore"},
{"id": "m", "effective_runtime": "lambda_microvms"},
]
got = {u["id"] for u in build_diagram.units_needing_handoff(units)}
assert got == {"e", "k", "f", "b"}, \
"handoff set must be exactly ecs/eks/fargate/batch; lambda/agentcore/microvms self-contained"
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.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download agent-advisor.zip