Search across all documentation pages
An "agent skill" is not an AWS API. It is a practice: writing down, once, exactly how your team wants a repeatable task done, so an AI coding assistant (or a new hire) can carry it out the same way every time without re-deriving the conventions from scratch.
For AWS SDK work specifically, that means packaging things like "how we scaffold a new service client," "how we set up credentials for a new project," or "how we review a PR for expensive API-usage patterns" into a scoped, documented unit an assistant can invoke.
This page builds the mental model. The rest of this section walks through three concrete examples.
Think of a skill as a recipe card, not a new kitchen.
It does not introduce a new AWS capability. It packages a task your team already knows how to do - set up credentials for a new service integration, wire up a new client, flag an expensive call pattern in review - into a document an assistant can follow consistently.
A skill typically has four parts: a name (what to call it), a trigger (when to reach for it - a phrase, a file type, a situation), a body (the actual instructions, conventions, and worked examples), and an expected output (what "done" looks like: a file, a diff, a checklist result).
Here is the shape of a minimal skill document. This is a language-neutral instructions file, not runnable code, so it gets a plain fence rather than a <CodeGroup>.
---
name: service-client-scaffold
description: Scaffold a new AWS service client consistently in Python and TypeScript.
triggers:
- "add a new AWS service client"
- "wire up <service> in this project"
---
# Service Client Scaffold
1. Confirm the target service and required operations.
2. Reuse the project's existing credential chain - do not hardcode keys.
3. Create one client instance per service, scoped to the project's default region.
4. Emit both a boto3 client and an AWS SDK v3 client, matching the naming
convention already used in this repo.
5. Include a minimal smoke-test call (e.g. a list or describe operation).Nothing here is AWS-specific machinery. It is a written convention, the kind a senior engineer would otherwise repeat verbally to every new team member.
A skill only pays off if it stays narrow.
A skill scoped to "help with AWS" is too broad to be reliably followed - there is no single expected output, so an assistant (or a person) fills the gaps with guesses. A skill scoped to "scaffold a new service client, in both SDKs, using our existing credential pattern" has one job and one shape of output, so it is checkable: either the client was built consistently or it was not.
That narrowness is why the three skills profiled later in this section each target one task: credential setup for a new project, a cost-review pass over an SDK-heavy PR, and service-client scaffolding. Each references patterns this site already documents in depth - the credential provider chain, IAM least-privilege policies, pagination and batching, cost-aware usage - rather than re-explaining those mechanics inline. A skill is a thin, opinionated wrapper around conventions that already exist; it is not where those conventions get invented.
That also means a skill's own document is language-neutral. Whether the instructions are consumed by a Claude Code-style skill file, an internal team runbook, or a wiki page, the wrapper reads the same. It is only when the skill actually produces or checks SDK code that the dual-language treatment this site uses everywhere applies - the skill's output, not the skill's definition, needs both a Python (boto3) and TypeScript (AWS SDK v3) example.
Skills compose, but only loosely.
A credential-setup skill and a service-client scaffolding skill are naturally used back to back on a new integration: set up the role and local config first, then generate the client boilerplate that will use it. A cost-review skill sits downstream of both, run against a finished PR rather than at the start of a task. None of them assume the others ran - each documents its own inputs and produces its own checkable output, so they can be invoked independently.
The main risk with any skill is drift. If the credential provider chain changes, or a new pagination helper ships, a skill that still tells an assistant to hand-roll a ContinuationToken loop is now actively wrong, and worse than no skill at all because it looks authoritative. Treat a skill document the same way you would treat a runbook: owned by someone, reviewed when the underlying pattern changes, and versioned alongside the code it targets.
A second risk is over-scoping. A skill that tries to cover "all of AWS SDK development" collapses back into generic advice, which an assistant already has. The skills worth writing down are the ones with a specific, occasionally-missed convention baked in - the exact IAM actions a new integration needs, the exact batching threshold your team treats as "too many calls," the exact client-construction pattern your codebase expects.
No. It is a development practice: packaging a repeatable task's instructions and examples into a document an AI assistant or teammate can follow consistently. AWS does not ship a product called this.
A task your team repeats often enough that consistency matters, and one with a convention that is easy to get wrong or forget - like exact IAM scoping, or the exact shape of a scaffolded client.
Only if it produces or checks code. The skill's own instructions document is language-neutral; the illustrative examples inside it, when relevant, should show both boto3 and SDK v3.
Narrow enough to have one clear trigger and one checkable output. "Scaffold a new service client" is a good scope; "help with AWS" is not.
Credential setup and service-client scaffolding are typically used early on a new integration; a cost-review skill runs later, against a finished PR. Each stands alone with its own inputs and output.
The skill goes stale and can mislead. Review skill documents when the pattern they wrap - a credential chain, a pagination helper - changes upstream.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Reviewed by Chris St. John·Last updated Jul 23, 2026