Summary
Build an agent skill that stands up an eval-grade AgentCore Public Stack in a single AWS account with the fewest possible dependencies — domainless, no ACM certs, no Route 53, no GitHub fork — and, as a staged north star, eventually only the AWS CLI.
This tracks implementation of the proposal:
Why
The documented deploy (.github/docs/deploy/) is GitHub-Actions-driven and correct for production, but it requires a fork + repo admin + secrets before anything runs. We want a fast "see it running in my account today" path that is explicitly distinct from — and points back to — the production pipeline for multi-environment use.
Approach (from the proposal)
- Strategic split: production stays on GitHub Actions; the quick path drives the same maintained
scripts/*.sh locally (not a parallel deploy impl). Avoid the stale top-level scripts/deploy.sh.
- Domainless: SPA uses a relative
/api that CloudFront already routes to the ALB (platform-stack.ts:539), so the prebuilt SPA needs no per-deploy rebuild. The one wrinkle is the Cognito callback chicken-and-egg → two-pass finalize (deploy → read distributionDomainName → aws cognito-idp update-user-pool-client).
- Docker multi-arch / Apple-Silicon: recommend local
buildx + QEMU for v1; move to prebuilt published multi-arch images copied via crane as the end-state (removes emulation + unlocks AWS-CLI-only). See proposal §6.
Phased plan / acceptance
Notes / risks
- Account must have Bedrock model access for the seeded default models or inference fails.
cdk bootstrap required once per account/region (a CDK dep for T0/T1).- ALB is HTTP behind CloudFront when domainless; MCP-Apps sandbox iframe is disabled domainless. Acceptable for eval; documented.
- Related follow-up: latent
rag-ingestion image arch mismatch (ARM_64 Lambda built amd64 in CI) — should be its own issue.
See the proposal doc and #448 for full detail.
Summary
Build an agent skill that stands up an eval-grade AgentCore Public Stack in a single AWS account with the fewest possible dependencies — domainless, no ACM certs, no Route 53, no GitHub fork — and, as a staged north star, eventually only the AWS CLI.
This tracks implementation of the proposal:
docs/specs/quickstart-deploy-skill-plan.mdWhy
The documented deploy (
.github/docs/deploy/) is GitHub-Actions-driven and correct for production, but it requires a fork + repo admin + secrets before anything runs. We want a fast "see it running in my account today" path that is explicitly distinct from — and points back to — the production pipeline for multi-environment use.Approach (from the proposal)
scripts/*.shlocally (not a parallel deploy impl). Avoid the stale top-levelscripts/deploy.sh./apithat CloudFront already routes to the ALB (platform-stack.ts:539), so the prebuilt SPA needs no per-deploy rebuild. The one wrinkle is the Cognito callback chicken-and-egg → two-pass finalize (deploy → readdistributionDomainName→aws cognito-idp update-user-pool-client).buildx+ QEMU for v1; move to prebuilt published multi-arch images copied viacraneas the end-state (removes emulation + unlocks AWS-CLI-only). See proposal §6.Phased plan / acceptance
scripts/build/build-one.sh(correct local builds on Apple Silicon). (See related rag-ingestion arch issue.).claude/skills/quickstart-deploy/SKILL.mdorchestrating the 5 stages, two-pass finalize, preflight gates, and the required preface (prereqs required; eval-grade single-account; multi-env →.github/docs/deploy/). ← suggested first useful releaseprebuiltstrategy viacrane.Notes / risks
cdk bootstraprequired once per account/region (a CDK dep for T0/T1).rag-ingestionimage arch mismatch (ARM_64Lambda built amd64 in CI) — should be its own issue.See the proposal doc and #448 for full detail.