home / skills / shotaiuchi / dotclaude / context-aws-sam

context-aws-sam skill

/dotclaude/skills/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-sam

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
1.1 KB
---
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/ |

Overview

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.

How this skill works

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 to use it

  • Creating or updating Lambda functions and their handler files
  • Designing or editing template.yaml (SAM template) resources and transforms
  • Configuring API Gateway integrations and HTTP APIs
  • Running local tests, invoking functions, or debugging with sam local
  • Tuning deployment settings in samconfig.toml and CI/CD pipelines

Best practices

  • Keep template.yaml organized by grouping resources and using meaningful logical IDs
  • Define clear memory/timeout settings per function and set Policies minimally
  • Use environment variables and parameter mappings for stage-specific configuration
  • Prefer small, single-purpose Lambdas and separate concerns across functions
  • Test locally with sam local invoke and sam local start-api, mirroring production event shapes
  • Use Lambda Powertools (for supported runtimes) for tracing, logging, and standardized utilities

Example use cases

  • Create a new HTTP endpoint: add AWS::Serverless::Function and AWS::Serverless::Api entries in template.yaml and test with sam local start-api
  • Debug a failing handler locally using sam local invoke with a sample event and attached environment variables from samconfig.toml
  • Migrate an existing function to SAM: extract resource settings into template.yaml and validate IAM policies and permissions
  • Configure stage-specific settings: use samconfig.toml or template parameters to manage dev/staging/prod differences
  • Integrate Lambda responses with API Gateway mapping templates for custom response formats

FAQ

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.