Search across all documentation pages
Adding a new AWS service to a project always starts with the same handful of decisions: which package to install, how to construct the client, what region and timeout conventions to apply, and how to name the resulting variable so it matches the rest of the codebase.
None of that is hard, but it is exactly the kind of small, repeatable decision set that drifts across a codebase when everyone makes it slightly differently. A service-client scaffolding skill packages that procedure once, so every new client - in both boto3 and AWS SDK v3 - gets built the same way.
This is a development-practice skill layered on top of mechanics this site already documents: client construction, region and endpoint resolution, and how to choose the right SDK package. The skill does not reinvent any of that; it makes sure it gets applied consistently.
Fix the procedure - identify the service and package, construct one client per service scoped to the project's default region and timeout settings, name it per house convention, and verify with one smoke-test call - and produce matching output in both SDKs.
---
name: service-client-scaffold
description: Generate a new AWS service client consistently in boto3 and AWS SDK v3.
triggers:
- "add a new AWS service client"
- "wire up <service> in this project"
---
# Service Client Scaffold
1. Confirm the service (e.g. SQS, S3, DynamoDB) and the operations needed.
2. For SDK v3, name the exact per-service package to install
(e.g. @aws-sdk/client-sqs); boto3 needs no new install.
3. Construct one client, reusing the project's existing credential
chain and default region - do not hardcode either.
4. Apply the project's standard timeout/retry config if one exists.
5. Name the client variable per this project's convention
(lowercase service abbreviation, e.g. `sqs`, `ddb`).
6. Add one smoke-test call (a cheap read operation) to confirm the
client is wired correctly.Running the skill to add SQS to a project produces the install step plus matching client construction.
Step 2's output (SDK v3 only - boto3 ships every service already):
npm install @aws-sdk/client-sqsSteps 3 through 6's output, in both SDKs:
# --- Python (boto3) ---
import boto3
# Step 3: existing credential chain, project's default region.
# Step 5: house naming convention.
sqs = boto3.client("sqs", region_name="us-east-1")
# Step 6: smoke test.
sqs.get_queue_url(QueueName="order-events")// --- TypeScript (AWS SDK v3) ---
import { SQSClient, GetQueueUrlCommand } from "@aws-sdk/client-sqs";
// Step 3: existing credential chain, project's default region.
// Step 5: house naming convention.
const sqs = new SQSClient({ region: "us-east-1" });
// Step 6: smoke test.
await sqs.send(new GetQueueUrlCommand({ QueueName: "order-events" }));What this demonstrates:
boto3 ships one package covering every service, so step 2 is a no-op in Python. AWS SDK v3 is modular by design, one package per service, specifically to keep bundles small.
A scaffolding skill that only knows "construct a client" and skips naming the exact package leaves an assistant guessing at an npm package name, which is an easy place to introduce a typo or pull in more than intended. Naming the install target explicitly is as much a part of the procedure as the construction code.
The skill's step 3 and step 4 - credential chain, region, timeout config - are not something this skill defines; they come from the project's existing client-construction and region/endpoint conventions, which already have dedicated pages on this site.
The skill's value is entirely in making sure a new client always follows those conventions, rather than a new client occasionally being built with an inline region string or a bespoke timeout that quietly diverges from the rest of the codebase.
This skill assumes a working credential chain already exists for the project. When a brand-new project has neither, the credential-setup skill runs first, and this one uses whatever role or profile that produced.
Running them in the wrong order does not break anything - the scaffolding skill just falls back to whatever default credentials happen to be present, which may not be scoped correctly yet. Sequencing them is a team habit worth writing down alongside the skills themselves.
The main long-term risk is not that this skill produces wrong code once, it is that a project's naming or timeout conventions shift over time and the skill's template does not follow.
A skill that still names every client with an outdated convention, or omits a timeout setting the team later standardized on, produces boilerplate that is technically correct but locally inconsistent with newer code. Review the template when house conventions change.
@aws-sdk/client-* package.| Alternative | Use When | Don't Use When |
|---|---|---|
| Service-client scaffolding skill | Adding a new AWS service to an existing project's conventions | The project has no established client-construction conventions yet |
| Copying an existing client's code by hand | A single, one-off addition with no expectation of reuse | You want every new client built the same checkable way |
| IaC-generated SDK config | Client config should be derived from provisioned infrastructure | You need a quick, one-off client for application code, not infra state |
| Framework-provided client factory | Your stack already has a shared client factory abstraction | No such abstraction exists yet, or it does not cover this service |
No, it assumes that understanding and instead fixes the repeatable procedure - package, construction, naming, verification - so every new client follows it the same way.
Because AWS SDK v3 is modular, one package per service. Naming the exact package is part of getting the scaffold right, unlike boto3 which needs no new install.
Whatever the project's existing chain resolves - a profile or role, typically set up by a prior credential-setup skill run. The scaffolding skill does not create new credentials.
Yes in this skill's procedure - it is what distinguishes "the client compiles" from "the client actually works with the credentials and permissions in place."
Update the skill's template. Older clients built under the previous convention are not automatically renamed; only new scaffolds follow the updated skill.
No, it assumes the SDK choice (boto3, SDK v3, or both) is already made and scaffolds the client for whichever is in scope.
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