home / skills / shotaiuchi / dotclaude / context-aws-sam
This skill helps you manage AWS SAM projects by guiding template design, local testing, and API Gateway integrations.
npx playbooks add skill shotaiuchi/dotclaude --skill context-aws-samReview the files below or copy the command above to add this skill to your agents.
---
name: context-aws-sam
description: >-
AWS SAM serverless development context. Apply when working with
template.yaml, Lambda handler files, samconfig.toml,
API Gateway integrations, sam local commands.
user-invocable: false
---
# AWS SAM Context Rule
Auto-applied context when working on AWS SAM serverless development.
## When to Apply
Apply this context when:
- Creating Lambda functions
- Designing SAM templates (template.yaml)
- Setting up API Gateway integrations
- Running local tests with sam local
## Reference Documents
Read and apply patterns from:
| Document | Purpose |
|----------|---------|
| [AWS Conventions](../../references/services/aws/conventions.md) | Project structure, naming |
| [SAM Architecture](../../references/services/aws/sam-architecture-patterns.md) | Lambda/API patterns |
## External References
| Resource | URL |
|----------|-----|
| AWS SAM | https://docs.aws.amazon.com/serverless-application-model/ |
| AWS Lambda | https://docs.aws.amazon.com/lambda/ |
| API Gateway | https://docs.aws.amazon.com/apigateway/ |
| Lambda Powertools (Python) | https://docs.powertools.aws.dev/lambda/python/ |
This skill provides a focused development context for AWS SAM serverless projects, applied when working with template.yaml, Lambda handlers, samconfig.toml, API Gateway integrations, and sam local commands. It captures conventions, common patterns, and practical checks to streamline building, testing, and deploying SAM-based applications. Use it to enforce consistent structure, naming, and local testing practices across serverless services.
The skill inspects project files and workflow signals to surface SAM-specific guidance: template.yaml structure, Lambda handler files, samconfig.toml settings, and local invocation commands. It highlights best practices for resource naming, function configuration, API Gateway integration shapes, and local debugging with sam local. It also references architecture and conventions to suggest adjustments or optimizations during development.
When should I use sam local start-api vs sam local invoke?
Use sam local start-api to emulate API Gateway and test HTTP endpoints end-to-end. Use sam local invoke for focused function testing with specific event payloads.
How do I keep SAM templates maintainable as the project grows?
Modularize by using nested stacks or separate templates per service, use Parameters and Globals, and keep resource logical IDs and names consistent.