agents-get-started
Use when a developer wants to create a new agent project or get started with AgentCore. Handles framework selection, project scaffolding, first deploy, and first invocation. Triggers on: "build an agent", "create an agent", "get started", "new project", "agentcore create", "which framework", "Strands vs LangGraph", "hello world agent", "first agent", "create MCP server", "host MCP server", "agentcore dev", "dev server", "what port", "local development". Not for adding capabilities to existing projects — use agents-build or agents-connect. Strands vs LangGraph in a migration context routes to agents-build, not here. Connecting to an existing MCP server routes to agents-connect, not here.
What this skill does
# get-started Walk a developer from zero to a running agent on AWS. ## When to use - Developer wants to build an agent on AWS and doesn't know where to start - Developer wants to create a new AgentCore project - Developer is choosing between frameworks (Strands, LangGraph, GoogleADK, OpenAI Agents) - Developer just ran `agentcore create` and wants to know what to do next Do NOT use for: - Environment/prerequisite issues (CLI not found, credentials broken) → use `agents-debug` - Adding capabilities to an existing project (memory, tools, policies) → use `agents-build` or `agents-connect` - Migrating an existing Bedrock Agent → use `agents-build` (loads [`references/migrate.md`](../agents-build/references/migrate.md)) ## Input `$ARGUMENTS` can be: - A framework preference: "using LangGraph", "with Strands" - A protocol: "MCP server", "A2A" - A description of what the agent should do: "a customer support agent" - Empty — the skill will guide framework selection ## Process ### Step 0: Verify CLI version ```bash agentcore --version ``` This skill requires v0.9.0 or later. If the version is older: > Your AgentCore CLI is out of date (found vX.Y.Z, need v0.9.0+). Offer to run the update: `agentcore update`. After the update completes, re-check the version to confirm it's ≥0.9.0 before continuing. Preserve any context the developer already provided (framework preference, project name, what they want to build) so they don't have to repeat themselves. If `agentcore` is not found: > The AgentCore CLI isn't installed. Run `npm install -g @aws/agentcore` (requires Node.js 20+). > If you're having trouble with installation, I can run the `agents-debug` skill (which loads [`references/doctor.md`](../agents-debug/references/doctor.md)) to diagnose your environment. ### Step 1: Determine intent — exploring or ready to create? Before jumping into framework selection, figure out where the developer is: **Ask the developer:** "Are you exploring options (comparing frameworks, understanding what AgentCore does) or ready to create a project?" - **Exploring** → Go to Step 2 (framework comparison). Present the options, answer questions, and wait. Do not construct a `create` command until they signal they're ready. - **Ready to create** → Skip to Step 3 (create the project). If they already specified a framework, skip Step 2 entirely. - **Already has a project** → Look for `agentcore/agentcore.json` in the current directory. If found, read it and skip to Step 5 (what to do next). Don't re-scaffold. If the developer's intent is clear from `$ARGUMENTS` (e.g., "create a Strands agent called MyBot"), skip straight to Step 3. ### Step 2: Framework selection **Check conversation context first.** If the developer already discussed frameworks earlier in this conversation (e.g., from a previous skill invocation), don't re-present the full table. Summarize what was discussed and ask if they've decided, or if anything changed. If this is the first time discussing frameworks, present the options: **Supported frameworks (CLI-scaffolded, Python):** | Framework | CLI value | Best for | |---|---|---| | Strands | `Strands` | AWS-native, simplest path, best AgentCore integration | | LangGraph | `LangChain_LangGraph` | Complex graph-based workflows, existing LangChain investment | | Google ADK | `GoogleADK` | Teams already using Google's agent toolkit | | OpenAI Agents | `OpenAIAgents` | Teams already using OpenAI's agent SDK | **Ask the developer to choose.** Present the options and wait for their selection. Don't assume a default unless they explicitly say they have no preference. > **Note on naming:** The CLI flag value is the exact string to pass to `--framework`. In prose use the shorter names. **Default recommendation** (only when the developer says "no preference" or "you pick"): Strands — AWS-native framework with the tightest AgentCore integration and the most samples/docs. **Key decision points to surface:** - "Do you have existing agent code in LangGraph or OpenAI Agents?" → use that framework - "Do you need complex graph-based workflows with conditional branching?" → LangGraph - "Starting fresh with no preference?" → Strands #### Framework not listed? If the developer asks about a framework not in the table above, handle it: | They ask about | What to say | |---|---| | **CrewAI, AutoGen, Semantic Kernel** | Not scaffolded by the CLI, but you can use them via the BYO Container path (below). AgentCore Runtime is framework-agnostic — any code that implements the HTTP contract works. | | **Anthropic SDK / Claude Agent SDK** | This is a model SDK, not an agent framework. You can use it inside any framework (Strands, LangGraph, etc.) or standalone. For standalone use, wrap it in a container with the Runtime contract. | | **Claude Code / Cursor / Copilot** | These are IDE tools, not agent frameworks. They're where you *write* agent code, not what you deploy. Pick a framework from the table above for the agent itself. | | **LangChain (without LangGraph)** | LangChain is a library, LangGraph is the agent framework built on it. The CLI scaffolds LangGraph. If you're using plain LangChain chains, the BYO Container path works. | | **Custom / homegrown framework** | BYO Container path — see below. | **BYO Container path (any framework, any language):** For frameworks or languages not scaffolded by the CLI, AgentCore Runtime accepts any container that implements the HTTP contract (`POST /invocations`, `GET /ping`). The workflow: 1. `agentcore create --name <ProjectName> --defaults` to scaffold the project structure 2. `agentcore add agent --type byo --build Container --language <Language> --code-location <path>` to register your code 3. Write a `Dockerfile` that builds and runs your agent 4. `agentcore deploy` handles ECR push, CDK infra, and runtime creation **Language-specific notes:** | Language | Recommended path | |---|---| | Java (Spring Boot) | [Spring AI SDK for AgentCore](https://aws.amazon.com/blogs/machine-learning/spring-ai-sdk-for-amazon-bedrock-agentcore-is-now-generally-available) — handles the Runtime contract, SSE streaming, and health checks. Use `--language Other --build Container`. | | JavaScript / TypeScript | Implement the Runtime contract in Express/Fastify/etc. Use `--language TypeScript --build Container`. | | Go, Rust, .NET, other | Implement the Runtime HTTP contract. Use `--language Other --build Container`. | The rest of this skill (deploy, status, logs, invoke) applies once the container builds correctly. #### Framework vs. model provider — a common confusion The framework is how your agent orchestrates (Strands, LangGraph, etc.). The model provider is which LLM it calls (Bedrock, Anthropic, OpenAI, Gemini). These are independent choices: - Strands + Bedrock (default) — AWS-native everything - Strands + Anthropic — Strands orchestration, direct Anthropic API for the model - LangGraph + Bedrock — LangGraph orchestration, Bedrock for the model - OpenAI Agents + OpenAI — OpenAI everything If the developer says "I want to use Claude" they mean the model provider (Bedrock or Anthropic), not the framework. If they say "I want to use LangGraph" they mean the framework. ### Step 3: Create the project Build the `agentcore create` command based on the developer's choices. **Before constructing the command — validate the project name.** The CLI fails late: if the name is invalid, you'll see the error *after* walking through prompts or building the full command. Save the round-trip and check these rules up front. Reject the name and ask for a new one if any rule fails: - **Length ≤ 23 characters** (this is shorter than most developers assume — `MyCustomerSupportAgent` is 22 chars and fits; `CustomerSupportChatbot` is 22 and fits; `MyCustomerSupportBotApp` is 23 and just fits; `MyCustomerSupportChatBot` is 24 and **fails**) - **Alphanumeric only** — no hyphens, underscores, dots, or spaces - **Must start with a letter** Say the co
Related in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.