Extending Claude Code with Plugins and Skills for AWS Development

In the previous posts, I covered how to set up Claude Code with Bedrock, use it in your IDE, teach it your conventions with CLAUDE.md, enforce them with hooks, and connect it to your AWS services with MCP servers. At this point, Claude Code can read your code, follow your rules, and talk to your AWS services. But you're still explaining the same workflows every session: how you deploy, what to check before a PR, which naming conventions to follow.

Skills and plugins fix that. Skills are markdown files that teach Claude your workflows once, so you don't repeat yourself. Plugins package skills (along with MCP servers, hooks, and agents) into installable units you can share with your team or the community.

Skills, Plugins, and How They Fit Together

If you've used the previous posts to set up CLAUDE.md, hooks, and MCP servers, you've already been configuring Claude Code piece by piece. Skills and plugins build on that foundation.

Skills

A skill is a markdown file (SKILL.md) with instructions that Claude follows. There are two flavors:

• Reference skills: Background knowledge Claude applies passively. Your team's naming conventions, IaC patterns, or tagging requirements. Claude reads these and applies them without you asking.
• Task skills: Step-by-step instructions for specific actions. Deploy to staging, review a PR, generate a CloudFormation template. You invoke these with /skill-name.

If you've used custom slash commands (.claude/commands/), skills are the evolution of that. Existing commands still work, but skills add frontmatter for controlling when and how they trigger, a directory structure for supporting files, and the ability for Claude to load them automatically based on context.

Skills follow the open Agent Skills standard, which means they're not locked to Claude Code. The same SKILL.md files work across any AI coding tool that supports the standard. Write your skills once, use them in Claude Code, Cursor, or whatever your team adopts next.

Plugins

A plugin is a directory that bundles one or more of these components:

• Skills (markdown instructions)
• MCP servers (external tool integrations)
• Hooks (lifecycle event handlers)
• Agents (specialized subagents)
• LSP servers (code intelligence)

Think of it this way: skills teach Claude a single workflow, plugins package an entire toolkit. The MCP servers post covered MCP servers as standalone tools. A plugin can bundle those same MCP servers with skills that know how to use them, hooks that validate the results, and agents that handle complex multi-step workflows.

How They Relate

Concept	What it is	How you get it
MCP server	Code-based tool server that gives Claude new capabilities	claude mcp add or bundled in a plugin
Skill	Markdown instructions that teach Claude a workflow	.claude/skills/ directory or bundled in a plugin
Plugin	Shareable package of skills, MCP servers, hooks, agents, LSP servers	Installed from a marketplace or loaded from a directory

Skills and MCP servers can exist standalone or inside a plugin. The plugin is the distribution mechanism.

Installing Plugins

The Marketplace

Claude Code uses a marketplace model for plugin discovery and installation. The official Anthropic marketplace is included automatically. No setup needed.

/plugin

This opens an interactive interface with four tabs: Discover (browse available plugins), Installed (manage what you have), Marketplaces (add or remove sources), and Errors (debug loading issues).

To install a plugin directly:

/plugin install plugin-name@marketplace-name

Scopes

Like MCP servers, plugins have scopes that control who can use them:

Scope	Stored in	Use case
user (default)	~/.claude/settings.json	Personal, across all projects
project	.claude/settings.json	Shared with team via version control
local	.claude/settings.local.json	Personal, current project only
managed	managed-settings.json	Admin-controlled, read-only

Project scope is the one that matters for teams. Add a plugin to your project settings and everyone on the team gets it when they clone the repo.

Adding Third-Party Marketplaces

The official marketplace covers the essentials, but anyone can create and host a marketplace. Sources can be GitHub repos, GitLab repos, local directories, or remote URLs.

/plugin marketplace add owner/repo
/plugin marketplace add https://gitlab.com/company/plugins.git
/plugin marketplace add ./local-marketplace

Managing Plugins

/plugin disable plugin-name@marketplace-name
/plugin enable plugin-name@marketplace-name
/plugin uninstall plugin-name@marketplace-name

The official marketplace auto-updates by default. Third-party marketplaces don't, which is a trust boundary worth noting.

Plugins That Improve Your AWS Workflow

The official marketplace has several categories of plugins. Here are the ones most relevant to AWS development.

Code Intelligence (LSP Plugins)

These are the most immediately useful plugins. They connect Claude to Language Server Protocol servers, giving it real-time diagnostics and code navigation. Claude sees type errors, missing imports, and incorrect function signatures after every edit, without waiting for you to run a build.

For AWS development, two stand out:

TypeScript LSP (typescript-lsp): If you're writing CDK constructs, Lambda handlers in TypeScript, or AWS SDK v3 code, this gives Claude the same type checking your IDE has. Claude catches type mismatches in your CDK stack definitions, incorrect SDK client configurations, and missing required properties on construct props.

/plugin install typescript-lsp@claude-plugins-official

Python LSP (pyright-lsp): For Python Lambda functions, Boto3 code, and SAM applications. Claude gets type information from Boto3 stubs, catches incorrect service client method calls, and validates Pydantic models used in your data layer.

/plugin install pyright-lsp@claude-plugins-official

Both require the language server binary to be installed locally (typescript-language-server and pyright-langserver respectively). If you already have these installed globally for your IDE, Claude Code will usually detect them automatically. The plugins handle the rest.

LSP plugins can use significant memory. If you're not actively working in a language, disable its LSP plugin to free resources.

GitHub Integration

/plugin install github@claude-plugins-official

Full GitHub integration through OAuth: PRs, issues, code search, actions, and security alerts. If you added the GitHub MCP server from the previous post, the plugin wraps the same MCP server with preconfigured OAuth and a simpler install. If you're setting up from scratch, the plugin is the recommended approach.

What you can do:

> "Review PR #456 for security issues in the IAM policies"
> "Read issue #89, implement it, and open a PR"
> "Check if the CI workflow passed on my last push"

Development Workflow Plugins

Commit Commands (commit-commands): Standardized git workflows for committing, pushing, and creating PRs. Provides skills like /commit-commands:commit that follow your team's conventions.

/plugin install commit-commands@claude-plugins-official

What you can do:

> /commit-commands:commit
> /commit-commands:pr

PR Review Toolkit (pr-review-toolkit): Six specialized agents for reviewing pull requests. It reads your git diff, determines which reviews are relevant based on what changed, and runs the appropriate agents.

/plugin install pr-review-toolkit@claude-plugins-official

What you can do:

> /pr-review-toolkit:review-pr
> /pr-review-toolkit:review-pr tests errors
> /pr-review-toolkit:review-pr all parallel

The default command runs all applicable reviews: code quality, test coverage, error handling, type design, and comment accuracy. You can scope it to specific aspects (tests, errors, types, comments, code) or run everything in parallel for faster results. Findings are categorized as critical, important, or suggestions, with file and line references.

Requires git and the gh CLI.

Writing Your Own Skills

Plugins from the marketplace handle generic workflows. But every team building on AWS has its own deployment process, security requirements, and conventions. That's where custom skills come in.

A skill is a SKILL.md file in a directory under .claude/skills/. Here's the basic structure:

---
name: skill-name
description: When and why Claude should use this skill
---

Your instructions here.

The description field is important. Claude uses it to decide when to load the skill automatically. A vague description means the skill triggers when it shouldn't (or doesn't trigger when it should).

A Deployment Skill

This skill teaches Claude how to deploy your SAM application with the right flags and checks:

mkdir -p .claude/skills/deploy

---
name: deploy
description: Deploy the SAM application to a specified environment (dev, staging, prod)
argument-hint: "[environment]"
allowed-tools: Bash, Read
---

Deploy the application to the $ARGUMENTS environment.

## Pre-deployment checks

1. Run `sam validate` to check the template
2. Run the test suite with `npm test`
3. Check that `samconfig.toml` has a config block for the target environment
4. Verify no secrets or hardcoded credentials in the template

## Deploy

Run the SAM deployment:

- dev: `sam deploy --config-env dev`
- staging: `sam deploy --config-env staging`
- prod: `sam deploy --config-env prod --confirm-changeset`

Production deployments must use `--confirm-changeset`. Always show the changeset before proceeding.

## Post-deployment

1. Run `sam list stack-outputs --config-env $ARGUMENTS` and show the API endpoint
2. Check CloudWatch for any immediate errors in the first 30 seconds

Now /deploy staging runs this entire workflow. Here's what that looks like in practice:

> /deploy staging

I'll deploy the application to the staging environment.

Running pre-deployment checks...

✓ sam validate passed
✓ npm test: 47 tests passed, 0 failed
✓ samconfig.toml has a [staging] config block
✓ No hardcoded credentials found in template.yaml

Deploying to staging...

$ sam deploy --config-env staging

  Deploying with following values
  ===============================
  Stack name                   : myapp-api-staging
  Region                       : us-east-1
  Confirm changeset            : False

  CloudFormation stack changeset
  ----------------------------------------------------------
  Operation  LogicalResourceId        ResourceType
  ----------------------------------------------------------
  + Add      GetOrdersFunction        AWS::Lambda::Function
  * Modify   ApiGateway               AWS::ApiGatewayV2::Api
  ----------------------------------------------------------

  Successfully created/updated stack - myapp-api-staging

Post-deployment checks...

API endpoint: https://abc123.execute-api.us-east-1.amazonaws.com/staging
CloudWatch: No errors in the first 30 seconds ✓

Claude validates the template, runs tests, deploys with the right flags, and checks for errors. One command instead of five.

A Security Review Skill

This skill checks your IaC templates for common security issues:

---
name: security-review
description: Review CloudFormation and SAM templates for security issues
allowed-tools: Read, Grep, Glob
---

Review all CloudFormation and SAM templates in this project for security issues.

## Check for these issues

1. **Overly permissive IAM policies**: Look for `Effect: Allow` with `Resource: "*"` or `Action: "*"`. Flag any use of managed policies like `AdministratorAccess` or `PowerUserAccess`.
2. **Public access**: Check for S3 buckets without `PublicAccessBlockConfiguration`, API Gateway endpoints without authorization, and Lambda function URLs without `AuthType: AWS_IAM`.
3. **Missing encryption**: DynamoDB tables without `SSESpecification`, S3 buckets without `BucketEncryption`, SQS queues without `KmsMasterKeyId`.
4. **Missing logging**: CloudTrail not enabled, S3 access logging not configured, API Gateway without access logging.
5. **Security groups**: Ingress rules allowing `0.0.0.0/0` on ports other than 80 and 443.

## Output format

For each issue found, report:
- File and line number
- What the issue is
- Why it matters
- The specific fix

If no issues are found, say so. Don't invent problems.

Run /security-review before any PR that touches your infrastructure templates.

A Conventions Skill (Reference Content)

Not all skills are tasks. Reference skills provide background knowledge Claude applies passively. These work best for conventions that only apply in specific contexts, not universally. (Universal conventions belong in CLAUDE.md, which is always loaded.)

For example, this skill only activates when Claude is working on public-facing API resources:

---
name: public-api-standards
description: Security and compliance standards for public-facing API Gateway endpoints
user-invocable: false
---

Apply these standards whenever creating or modifying API Gateway endpoints.

## Authentication

All public API Gateway endpoints must use either:
- Cognito user pool authorizer for end-user authentication
- IAM authorization with SigV4 for service-to-service calls

No API endpoints should be publicly accessible without an authorizer.

## Rate Limiting

- Default throttle: 1000 requests per second, burst 2000
- Per-client throttle via usage plans: required for all external consumers
- Return `429 Too Many Requests` with `Retry-After` header

## Response Standards

- All responses must include `X-Request-Id` header (from Lambda context.aws_request_id)
- Error responses follow RFC 7807 (Problem Details for HTTP APIs)
- No stack traces or internal error details in production responses

## CORS

- Allow only specific origins, never `*` in production
- Allowed methods and headers must be explicitly listed
- Max age: 3600 seconds

Setting user-invocable: false means this doesn't show up in the / menu. Claude sees the description, loads it when relevant (like when you're creating or modifying API Gateway resources), and applies the standards automatically.

Dynamic Context with Shell Commands

Skills can inject live data using the !`command` syntax. The command executes the moment the skill is invoked, and the output replaces the placeholder before Claude sees the content:

---
name: deploy-status
description: Check the current deployment status across all environments
---

## Current Stack Status

!`aws cloudformation describe-stacks --query "Stacks[?contains(StackName, 'myapp')].{Name:StackName,Status:StackStatus,Updated:LastUpdatedTime}" --output table`

## Recent Deployments

!`aws cloudformation list-stacks --stack-status-filter UPDATE_COMPLETE CREATE_COMPLETE --query "StackSummaries[?contains(StackName, 'myapp')]|sort_by(@, &LastUpdatedTime)|[-5:]" --output table`

This is preprocessing. Claude only sees the command output, not the commands themselves.

Frontmatter Reference

Field	What it does
name	Display name and / command name. Lowercase, hyphens, max 64 chars.
description	When to use this skill. Claude uses this for automatic invocation.
argument-hint	Shown in autocomplete, e.g., [environment].
allowed-tools	Tools Claude can use without permission prompts.
disable-model-invocation	true prevents Claude from auto-loading. Manual /name only.
user-invocable	false hides from the / menu. For background knowledge only.
context	Set to fork to run in an isolated subagent.

Sharing Skills with Your Team

Project Scope

Commit your .claude/skills/ directory to version control. Everyone who clones the repo gets the same skills:

.claude/
  skills/
    deploy/
      SKILL.md
    security-review/
      SKILL.md
    aws-conventions/
      SKILL.md

This is the simplest approach and works well when your skills are specific to one project.

When to Graduate to a Plugin

If you find yourself copying the same skills across multiple repos, it's time to make a plugin. A plugin wraps your skills into an installable package:

my-aws-plugin/
  .claude-plugin/
    plugin.json
  skills/
    deploy/
      SKILL.md
    security-review/
      SKILL.md
    aws-conventions/
      SKILL.md

The plugin.json manifest is minimal:

{
  "name": "my-aws-plugin",
  "version": "1.0.0",
  "description": "AWS deployment and security skills for the platform team"
}

Test locally with:

claude --plugin-dir ./my-aws-plugin

Skills inside plugins are namespaced: /my-aws-plugin:deploy instead of /deploy. This prevents conflicts when multiple plugins define skills with the same name.

Helpful Plugins for Building

The official marketplace includes a plugin that helps with plugin and skill development:

/plugin install plugin-dev@claude-plugins-official

It provides tools for scaffolding plugins, creating skills, and testing your work.

Things to Watch Out For

Context budget: Skill descriptions are loaded into Claude's context so it knows what's available. There's a budget of 2% of the context window (about 16,000 characters as a fallback). If you have many skills, some may be excluded. Check with /context for warnings. You can override the budget with the SLASH_COMMAND_TOOL_CHAR_BUDGET environment variable.

Description quality: A skill's description determines when Claude loads it automatically. Too vague and it triggers for unrelated tasks. Too narrow and it never triggers. Write descriptions the way you'd describe the task in conversation: "Deploy the SAM application to a specified environment" is better than "deployment helper."

Skill vs CLAUDE.md: CLAUDE.md is always in context. Skills load on demand. Put universally applicable conventions (naming, tagging, Lambda defaults) in CLAUDE.md and context-specific standards in reference skills. Your public API security standards only matter when working on API Gateway resources, so they're a skill. Your deployment workflow is a specific action, so it's a task skill.

Plugin trust: The official Anthropic marketplace is maintained by Anthropic. Third-party marketplaces have no formal review process. Since plugins can contain executable hooks and MCP servers, review the plugin.json manifest and any scripts before installing from a third-party source. The trust model is "trust the publisher," not "trust the marketplace."

LSP memory: Language server plugins like rust-analyzer and pyright can use significant memory. Disable LSP plugins for languages you're not actively working in.

Namespacing: Plugin skills are always namespaced (/plugin-name:skill). Standalone skills in .claude/skills/ use short names (/skill). If you have both, the standalone skill takes precedence for the short name.

Getting Started

Start with two things:

1. Install one LSP plugin for your primary language. If you write TypeScript CDK or Lambda handlers, install typescript-lsp. If you write Python, install pyright-lsp. The immediate payoff is Claude catching type errors after every edit.

2. Write one task skill for the workflow you repeat most often. Deployment is the common choice. Create a /deploy skill with your team's specific steps and flags.

Once those are working, add a reference skill for your team's conventions and share the .claude/skills/ directory through version control.

In the next post, I'll walk through building a full AWS serverless plugin from scratch: bundling MCP servers, skills, hooks, and agents into one installable package.

Additional Resources

• Claude Code Skills Documentation
• Claude Code Plugins Documentation
• Discovering Plugins
• Agent Skills Standard
• Previous: Improving Your AWS Development Workflow with MCP Servers
• Previous: Automating Your Workflow with Claude Code Hooks
• Previous: Teaching Claude Code How You Work
• Previous: Claude Code with Bedrock in VS Code and JetBrains
• Previous: Claude Code with Bedrock

What skills are you building for your team? Let me know in the comments!