AWS Serverless workflow skill. Use this skill when the user needs Specialized skill for building production-ready serverless and the operator should preserve the upstream workflow, copied support files, and provenance before merging or handing off.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
AWS Serverless workflow skill. Use this skill when the user needs Specialized skill for building production-ready serverless and the operator should preserve the upstream workflow, copied support files, and provenance before merging or handing off.
This public intake copy packages plugins/antigravity-awesome-skills-claude/skills/aws-serverless from https://github.com/sickn33/antigravity-awesome-skills into the native Omni Skills editorial shape without hiding its origin.
Use it when the operator needs the upstream workflow, support files, and repository context to stay intact while the public validator and private enhancer continue their normal downstream flow.
This intake keeps the copied upstream files intact and uses the external_source block in metadata.json plus ORIGIN.md as the provenance anchor for review.
AWS Serverless Specialized skill for building production-ready serverless applications on AWS. Covers Lambda functions, API Gateway, DynamoDB, SQS/SNS event-driven patterns, SAM/CDK deployment, and cold start optimization.
Imported source sections that did not map cleanly to the public headings are still preserved below or in the support files. Notable imported sections: Patterns, 1. Optimize Package Size, 2. Use SnapStart (Java/.NET), 3. Right-size Memory, 5. Keep Init Light, Sharp Edges.
When to Use This Skill
Use this section as the trigger filter. It should make the activation boundary explicit before the operator loads files, runs commands, or opens a pull request.
Access to RDS/ElastiCache in VPC
Access to private EC2 instances
Compliance requirements
Unresolved setTimeout/setInterval
Dangling database connections
Pending callbacks
Operating Table
Situation
Start here
Why it matters
First-time use
metadata.json
Confirms repository, branch, commit, and imported path through the external_source block before touching the copied workflow
Provenance review
ORIGIN.md
Gives reviewers a plain-language audit trail for the imported source
Workflow execution
SKILL.md
Starts with the smallest copied file that materially changes execution
Supporting context
SKILL.md
Adds the next most relevant copied source file without loading the entire package
Handoff decision
## Related Skills
Helps the operator switch to a stronger native skill when the task drifts
Workflow
This workflow is intentionally editorial and operational at the same time. It keeps the imported source useful to the operator while still satisfying the public intake standards that feed the downstream enhancer flow.
!Ref LambdaSecurityGroup
!Ref PrivateSubnet1
!Ref PrivateSubnet2 # Multiple AZs
IpProtocol: tcp
Confirm the user goal, the scope of the imported workflow, and whether this skill is still the right router for the task.
Read the overview and provenance files before loading any copied upstream support files.
Load only the references, examples, prompts, or scripts that materially change the outcome for the current request.
Initialize clients outside handler (reused across warm invocations)
Always return proper API Gateway response format
Log with structured JSON for CloudWatch Insights
Include request ID in error logs for tracing
API Gateway Integration Pattern
REST API and HTTP API integration with Lambda
When to use: Building REST APIs backed by Lambda,Need HTTP endpoints for functions
# template.yaml (SAM)AWSTemplateFormatVersion:'2010-09-09'Transform:AWS::Serverless-2016-10-31Globals:Function:Runtime:nodejs20.xTimeout:30MemorySize:256Environment:Variables:TABLE_NAME:!RefItemsTableResources:# HTTP API (recommended for simple use cases)HttpApi:Type:AWS::Serverless::HttpApiProperties:StageName:prodCorsConfiguration:AllowOrigins:-"*"AllowMethods:-GET-POST-DELETEAllowHeaders:-"*"# Lambda FunctionsGetItemFunction:Type:AWS::Serverless::FunctionProperties:Handler:src/handlers/get.handlerEvents:GetItem:Type:HttpApiProperties:ApiId:!RefHttpApiPath:/items/{id}Method:GETPolicies:-DynamoDBReadPolicy:TableName:!RefItemsTableCreateItemFunction:Type:AWS::Serverless::FunctionProperties:Handler:src/handlers/create.handlerEvents:CreateItem:Type:HttpApiProperties:ApiId:!RefHttpApiPath:/itemsMethod:POSTPolicies:-DynamoDBCrudPolicy:TableName:!RefItemsTable# DynamoDB TableItemsTable:Type:AWS::DynamoDB::TableProperties:AttributeDefinitions:-AttributeName:idAttributeType:SKeySchema:-AttributeName:idKeyType:HASHBillingMode:PAY_PER_REQUESTOutputs:ApiUrl:Value:!Sub"https://${HttpApi}.execute-api.${AWS::Region}.amazonaws.com/prod"
When to use: Latency-sensitive applications,User-facing APIs,High-traffic functions
Examples
Example 1: Ask for the upstream workflow directly
Use @aws-serverless to handle <task>. Start from the copied upstream workflow, load only the files that change the outcome, and keep provenance visible in the answer.
Explanation: This is the safest starting point when the operator needs the imported workflow, but not the entire repository.
Example 2: Ask for a provenance-grounded review
Review @aws-serverless against metadata.json and ORIGIN.md, then explain which copied upstream files you would load first and why.
Explanation: Use this before review or troubleshooting when you need a precise, auditable explanation of origin and file selection.
Example 3: Narrow the copied support files before execution
Use @aws-serverless for <task>. Load only the copied references, examples, or scripts that change the outcome, and name the files explicitly before proceeding.
Explanation: This keeps the skill aligned with progressive disclosure instead of loading the whole copied package by default.
Example 4: Build a reviewer packet
Review @aws-serverless using the copied upstream files plus provenance, then summarize any gaps before merge.
Explanation: This is useful when the PR is waiting for human review and you want a repeatable audit packet.
Treat the generated public skill as a reviewable packaging layer around the upstream repository. The goal is to keep provenance explicit and load only the copied source material that materially improves execution.
Right-size memory and timeout (measure before optimizing)
Minimize cold starts for latency-sensitive workloads
Use SnapStart for Java/.NET functions
Prefer HTTP API over REST API for simple use cases
Design for failure with DLQs and retries
Keep deployment packages small
Use environment variables for configuration
Imported Operating Notes
Imported: Principles
Right-size memory and timeout (measure before optimizing)
Minimize cold starts for latency-sensitive workloads
Use SnapStart for Java/.NET functions
Prefer HTTP API over REST API for simple use cases
Design for failure with DLQs and retries
Keep deployment packages small
Use environment variables for configuration
Implement structured logging with correlation IDs
Troubleshooting
Problem: The operator skipped the imported context and answered too generically
Symptoms: The result ignores the upstream workflow in plugins/antigravity-awesome-skills-claude/skills/aws-serverless, fails to mention provenance, or does not use any copied source files at all.
Solution: Re-open metadata.json, ORIGIN.md, and the most relevant copied upstream files. Check the external_source block first, then restate the provenance before continuing.
Problem: The imported workflow feels incomplete during review
Symptoms: Reviewers can see the generated SKILL.md, but they cannot quickly tell which references, examples, or scripts matter for the current task.
Solution: Point at the exact copied references, examples, scripts, or assets that justify the path you took. If the gap is still real, record it in the PR instead of hiding it.
Problem: The task drifted into a different specialization
Symptoms: The imported skill starts in the right place, but the work turns into debugging, architecture, design, security, or release orchestration that a native skill handles better.
Solution: Use the related skills section to hand off deliberately. Keep the imported provenance visible so the next skill inherits the right context instead of starting blind.
Related Skills
@00-andruia-consultant - Use when the work is better handled by that native specialization after this imported skill establishes context.
@00-andruia-consultant-v2 - Use when the work is better handled by that native specialization after this imported skill establishes context.
@10-andruia-skill-smith - Use when the work is better handled by that native specialization after this imported skill establishes context.
@10-andruia-skill-smith-v2 - Use when the work is better handled by that native specialization after this imported skill establishes context.
Additional Resources
Use this support matrix and the linked files below as the operator packet for this imported skill. They should reflect real copied source material, not generic scaffolding.
Resource family
What it gives the reviewer
Example path
references
copied reference notes, guides, or background material from upstream
references/n/a
examples
worked examples or reusable prompts copied from upstream
examples/n/a
scripts
upstream helper scripts that change execution or validation
scripts/n/a
agents
routing or delegation notes that are genuinely part of the imported package
agents/n/a
assets
supporting assets or schemas copied from the source package
assets/n/a
Imported Reference Notes
Imported: 1. Optimize Package Size
// Use modular AWS SDK v3 imports// GOOD - only imports what you needconst { DynamoDBClient } = require('@aws-sdk/client-dynamodb');
const { DynamoDBDocumentClient, GetCommand } = require('@aws-sdk/lib-dynamodb');
// BAD - imports entire SDKconstAWS = require('aws-sdk'); // Don't do this!
# More memory = more CPU = faster initResources:FastFunction:Type:AWS::Serverless::FunctionProperties:MemorySize:1024# 1GB gets full vCPUTimeout:30
Imported: 5. Keep Init Light
# GOOD - Lazy initialization
_table = Nonedefget_table():
global _table
if _table isNone:
dynamodb = boto3.resource('dynamodb')
_table = dynamodb.Table(os.environ['TABLE_NAME'])
return _table
defhandler(event, context):
table = get_table() # Only initializes on first use# ...
Optimization_priority
1: Reduce package size (biggest impact)
2: Use SnapStart for Java/.NET
3: Increase memory for faster init
4: Delay heavy imports
5: Provisioned concurrency (last resort)
SAM Local Development Pattern
Local testing and debugging with SAM CLI
When to use: Local development and testing,Debugging Lambda functions,Testing API Gateway locally
# Install SAM CLI
pip install aws-sam-cli
# Initialize new project
sam init --runtime nodejs20.x --name my-api
# Build the project
sam build
# Run locally
sam local start-api
# Invoke single function
sam local invoke GetItemFunction --event events/get.json
# Local debugging (Node.js with VS Code)
sam local invoke --debug-port 5858 GetItemFunction
# Deploy
sam deploy --guided
// .vscode/launch.json (for debugging){"version":"0.2.0","configurations":[{"name":"Attach to SAM CLI","type":"node","request":"attach","address":"localhost","port":5858,"localRoot":"${workspaceRoot}/src","remoteRoot":"/var/task/src","protocol":"inspector"}]}
Commands
Sam_build: Build Lambda deployment packages
Sam_local_start_api: Start local API Gateway
Sam_local_invoke: Invoke single function
Sam_deploy: Deploy to AWS
Sam_logs: Tail CloudWatch logs
CDK Serverless Pattern
Infrastructure as code with AWS CDK
When to use: Complex infrastructure beyond Lambda,Prefer programming languages over YAML,Need reusable constructs
// lib/api-stack.tsimport * as cdk from'aws-cdk-lib';
import * as lambda from'aws-cdk-lib/aws-lambda';
import * as apigateway from'aws-cdk-lib/aws-apigateway';
import * as dynamodb from'aws-cdk-lib/aws-dynamodb';
import { Construct } from'constructs';
exportclassApiStackextendscdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
// DynamoDB Tableconst table = new dynamodb.Table(this, 'ItemsTable', {
partitionKey: { name: 'id', type: dynamodb.AttributeType.STRING },
billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
removalPolicy: cdk.RemovalPolicy.DESTROY, // For dev only
});
// Lambda Functionconst getItemFn = new lambda.Function(this, 'GetItemFunction', {
runtime: lambda.Runtime.NODEJS_20_X,
handler: 'get.handler',
code: lambda.Code.fromAsset('src/handlers'),
environment: {
TABLE_NAME: table.tableName,
},
memorySize: 256,
timeout: cdk.Duration.seconds(30),
});
// Grant permissions
table.grantReadData(getItemFn);
// API Gatewayconst api = new apigateway.RestApi(this, 'ItemsApi', {
restApiName: 'Items Service',
defaultCorsPreflightOptions: {
allowOrigins: apigateway.Cors.ALL_ORIGINS,
allowMethods: apigateway.Cors.ALL_METHODS,
},
});
const items = api.root.addResource('items');
const item = items.addResource('{id}');
item.addMethod('GET', new apigateway.LambdaIntegration(getItemFn));
// Output API URLnew cdk.CfnOutput(this, 'ApiUrl', {
value: api.url,
});
}
}
Symptoms:
Unexplained increase in Lambda costs (10-50% higher).
Bill includes charges for function initialization.
Functions with heavy startup logic cost more than expected.
Why this breaks:
As of August 1, 2025, AWS bills the INIT phase the same way it bills
invocation duration. Previously, cold start initialization wasn't billed
for the full duration.
This affects functions with:
Heavy dependency loading (large packages)
Slow initialization code
Frequent cold starts (low traffic or poor concurrency)
Cold starts now directly impact your bill, not just latency.
Recommended fix:
Imported: Measure your INIT phase
# Check CloudWatch Logs for INIT_REPORT# Look for Init Duration in milliseconds# Example log line:# INIT_REPORT Init Duration: 423.45 ms
Imported: Reduce INIT duration
// 1. Minimize package size// Use tree shaking, exclude dev dependencies// npm prune --production// 2. Lazy load heavy dependencieslet heavyLib = null;
functiongetHeavyLib() {
if (!heavyLib) {
heavyLib = require('heavy-library');
}
return heavyLib;
}
// 3. Use AWS SDK v3 modular importsconst { S3Client } = require('@aws-sdk/client-s3');
// NOT: const AWS = require('aws-sdk');
Situation: Running Lambda functions, especially with external calls
Symptoms:
Function times out unexpectedly.
"Task timed out after X seconds" in logs.
Partial processing with no response.
Silent failures with no error caught.
Why this breaks:
Default Lambda timeout is only 3 seconds. Maximum is 15 minutes.
Common timeout causes:
Default timeout too short for workload
Downstream service taking longer than expected
Network issues in VPC
Infinite loops or blocking operations
S3 downloads larger than expected
Lambda terminates at timeout without graceful shutdown.
Recommended fix:
Imported: Set appropriate timeout
# template.yamlResources:MyFunction:Type:AWS::Serverless::FunctionProperties:Timeout:30# Seconds (max 900)# Set to expected duration + buffer
Imported: Implement timeout awareness
exports.handler = async (event, context) => {
// Get remaining timeconst remainingTime = context.getRemainingTimeInMillis();
// If running low on time, fail gracefullyif (remainingTime < 5000) {
console.warn('Running low on time, aborting');
thrownewError('Insufficient time remaining');
}
// For long operations, check periodicallyfor (const item of items) {
if (context.getRemainingTimeInMillis() < 10000) {
// Save progress and exit gracefullyawaitsaveProgress(processedItems);
thrownewError('Timeout approaching, saved progress');
}
awaitprocessItem(item);
}
};
Situation: Lambda functions in VPC accessing private resources
Symptoms:
Extremely slow cold starts (was 10+ seconds, now ~100ms).
Timeouts on first invocation after idle period.
Functions work in VPC but slow compared to non-VPC.
Why this breaks:
Lambda functions in VPC need Elastic Network Interfaces (ENIs).
AWS improved this significantly with Hyperplane ENIs, but:
First cold start in VPC still has overhead
NAT Gateway issues can cause timeouts
Security group misconfig blocks traffic
DNS resolution can be slow
Recommended fix:
Imported: Use VPC endpoints for AWS services
# Avoid NAT Gateway for AWS service callsDynamoDBEndpoint:Type:AWS::EC2::VPCEndpointProperties:ServiceName:!Subcom.amazonaws.${AWS::Region}.dynamodbVpcId:!RefVPCRouteTableIds:-!RefPrivateRouteTableVpcEndpointType:GatewayS3Endpoint:Type:AWS::EC2::VPCEndpointProperties:ServiceName:!Subcom.amazonaws.${AWS::Region}.s3VpcId:!RefVPCVpcEndpointType:Gateway
Imported: Tell Lambda not to wait for event loop
exports.handler = async (event, context) => {
// Don't wait for event loop to clear
context.callbackWaitsForEmptyEventLoop = false;
// Your code hereconst result = awaitprocessRequest(event);
return {
statusCode: 200,
body: JSON.stringify(result)
};
};
Imported: Close connections properly
// For database connections, use connection pooling// or close connections explicitlyconst mysql = require('mysql2/promise');
exports.handler = async (event, context) => {
context.callbackWaitsForEmptyEventLoop = false;
const connection = await mysql.createConnection({...});
try {
const [rows] = await connection.query('SELECT * FROM users');
return { statusCode: 200, body: JSON.stringify(rows) };
} finally {
await connection.end(); // Always close
}
};
API Gateway Payload Size Limits
Severity: MEDIUM
Situation: Returning large responses or receiving large requests
Symptoms:
"413 Request Entity Too Large" error
"Execution failed due to configuration error: Malformed Lambda proxy response"
Response truncated or failed
Why this breaks:
API Gateway has hard payload limits:
REST API: 10 MB request/response
HTTP API: 10 MB request/response
Lambda itself: 6 MB sync response, 256 KB async
Exceeding these causes failures that may not be obvious.
Symptoms:
Runaway costs.
Thousands of invocations in minutes.
CloudWatch logs show repeated invocations.
Lambda writing to source bucket/table that triggers it.
Why this breaks:
Lambda can accidentally trigger itself:
S3 trigger writes back to same bucket
DynamoDB trigger updates same table
SNS publishes to topic that triggers it
Step Functions with wrong error handling
Recommended fix:
Imported: Use different buckets/prefixes
# S3 trigger with prefix filterEvents:S3Event:Type:S3Properties:Bucket:!RefInputBucketEvents:s3:ObjectCreated:*Filter:S3Key:Rules:-Name:prefixValue:uploads/# Only trigger on uploads/# Output to different bucket or prefix# OutputBucket or processed/ prefix
Imported: Add idempotency checks
exports.handler = async (event) => {
for (const record of event.Records) {
const key = record.s3.object.key;
// Skip if this is a processed fileif (key.startsWith('processed/')) {
console.log('Skipping already processed file:', key);
continue;
}
// Process and write to different locationawaitprocessFile(key);
awaitwriteToS3(`processed/${key}`, result);
}
};
Imported: Set reserved concurrency as circuit breaker
Resources:RiskyFunction:Type:AWS::Serverless::FunctionProperties:ReservedConcurrentExecutions:10# Max 10 parallel# Limits blast radius of runaway invocations
Imported: Monitor with CloudWatch alarms
InvocationAlarm:Type:AWS::CloudWatch::AlarmProperties:MetricName:InvocationsNamespace:AWS/LambdaStatistic:SumPeriod:60EvaluationPeriods:1Threshold:1000# Alert if >1000 invocations/minComparisonOperator:GreaterThanThreshold
Imported: Validation Checks
Hardcoded AWS Credentials
Severity: ERROR
AWS credentials must never be hardcoded
Message: Hardcoded AWS access key detected. Use IAM roles or environment variables.
AWS Secret Key in Source Code
Severity: ERROR
Secret keys should use Secrets Manager or environment variables
Message: Hardcoded AWS secret key. Use IAM roles or Secrets Manager.
Overly Permissive IAM Policy
Severity: WARNING
Avoid wildcard permissions in Lambda IAM roles
Message: Overly permissive IAM policy. Use least privilege principle.
Lambda Handler Without Error Handling
Severity: WARNING
Lambda handlers should have try/catch for graceful errors
Message: Lambda handler without error handling. Add try/catch.
Missing callbackWaitsForEmptyEventLoop
Severity: INFO
Node.js handlers should set callbackWaitsForEmptyEventLoop
