aws-agent-skills: Add 18 AWS Service Skills to Claude Code

Claude Code already knows AWS in general; what it lacks is current, opinionated depth per service — the IAM policy patterns, the Lambda debugging checklists, the CloudFormation structures that match how AWS works today. aws-agent-skills is a plugin that ships that layer: cloud engineering skills across 18 core AWS services.

Why This Skill Matters

The README draws a deliberate line against "just use an MCP server". AWS MCP shines for live docs and API calls, but this plugin is built for reasoning first: a curated, LLM-optimized knowledge base with real-world patterns, edge cases, and best practices. Because everything is local and pre-compressed, it is token-efficient, keeps the context window small and predictable, and avoids MCP infrastructure, latency, and expanded credential exposure.

Coverage spans 18 skills: iam, lambda, dynamodb, s3, api-gateway, ec2, ecs, eks, cloudformation, cloudwatch, rds, sqs, sns, cognito, step-functions, secrets-manager, eventbridge, and bedrock. Each skill is a SKILL.md with core concepts, common patterns, a CLI reference, best practices, and troubleshooting, plus supplementary deep-dive files. The README also states the repo automatically checks AWS documentation weekly so the skills track service changes, and each skill carries metadata showing when its content was last updated.

Installation

Install as a Claude Code plugin from the marketplace:

/plugin marketplace add itsmostafa/aws-agent-skills
/plugin install aws-agent-skills

Or directly from GitHub:

/plugin install https://github.com/itsmostafa/aws-agent-skills

Codex CLI is supported too, per skill:

$skill-installer install https://github.com/itsmostafa/aws-agent-skills/<skill-name>

Real Workflow: Lock Down a Lambda-to-DynamoDB Access Pattern

1. Open Claude Code in your project and state the task in AWS terms:

Create an IAM policy for Lambda to access DynamoDB.

2. The matching iam skill's knowledge — policy patterns, CLI reference, best practices — grounds the answer, and the follow-ups stay in the same frame. The README's own example set is exactly this shape: "Set up cross-account access for S3", "Debug this access denied error".

3. Move up a layer the same way. "Create a Python Lambda function triggered by S3" runs through the lambda skill; "Write a CloudFormation template for a serverless API" through cloudformation. Because every skill follows the same SKILL.md template, you always get concepts, patterns, CLI commands, and troubleshooting in a consistent structure.

4. When something breaks at runtime, name the symptom: "Debug my Lambda timeout issues" or "Set up Lambda with VPC access" route into the troubleshooting sections of the relevant skill rather than generic guesses.

Tips

• Ask for one service at a time. Skills match per service, so a focused request loads the right knowledge instead of a blend.
• Check the metadata. Each skill records when its content was last updated — worth a glance before relying on it for a fast-moving service.
• Keep MCP in the toolbox anyway. The README's own framing: skills for reasoning, MCP for live docs and API calls. They solve different halves of the problem.
• Install selectively if you want a lean setup — the Codex path installs one named skill at a time, and the same per-service split applies to how you prompt.

When Not to Use This

A knowledge skill cannot see your AWS account. For live state — current resource configurations, real API responses, cost data — you need tool access, and this plugin by design stays out of that business. It also will not help outside its 18 services; if your stack centers on a service the repo does not cover, the skills simply do not load.

See the leaderboard for more skills.