This skill is a starting point, not a finished product. As you use it, you will encounter edge cases, develop preferences for how initiatives are named and scoped, and build up a better sense of what assumptions are right for your team. We encourage you to open the skill and edit it — add your own service mappings, adjust the default magnitude assumptions, refine the descriptions it writes. Skills get meaningfully better the more you put back into them.
Prerequisites
The skill requires access to both your project management tool and Cloud Capital via MCP. Install one of the following project management MCPs and the Cloud Capital MCP:| MCP | Purpose | Install guide |
|---|---|---|
| Linear MCP | Read and update Linear issues | linear.app/docs/mcp |
| Atlassian MCP | Read and update Jira tickets | github.com/atlassian/atlassian-mcp-server |
| Cloud Capital MCP | Create initiatives and look up service names | docs.cloudcapital.co/ai/mcp-server |
Installation
Claude Desktop
- Download aws-to-cloud-capital.skill.
- In Claude Desktop, open Settings and navigate to the Skills tab.
- Click Import Skill and select the downloaded file.
- The skill is immediately available in any conversation as
/aws-to-cloud-capital.
Claude Code
Copy the.skill file into your global Claude skills directory:
/aws-to-cloud-capital. No restart required.
To scope the skill to a single project instead, place it in that project’s .claude/skills/ directory.
How to use it
Once the skill and MCPs are installed, trigger it any time you are working with a Linear or Jira ticket that touches AWS spend. The skill can be run explicitly or fires automatically when a ticket describing AWS infrastructure work is being created. Explicit invocation:- ECS / Fargate task changes
- EC2 launches, resizes, or terminations
- RDS, Aurora, or managed database changes
- Lambda deployments
- S3 migrations or data movement
- Service deprecations or decommissions
- Right-sizing or optimisation projects
- New product launches on AWS
- On-prem to cloud or service-to-service migrations
- Capacity scaling plans
- Spot or Reserved Instance strategy changes
What happens
The skill works through five steps behind the scenes:- Extracts intent — reads the ticket title and description to identify affected AWS services, cost direction (increase or decrease), magnitude, and timeline.
- Resolves service names — maps plain-English references (“containers”, “Postgres”, “load balancer”) to exact Cloud Capital service identifiers, confirming against your org’s live data when needed.
- Creates an Engineering Initiative — calls Cloud Capital with the right impact type (relative percentage or absolute dollar amount), duration (temporary or permanent), and a description referencing the ticket.
- Creates the resource filter mapping — sets up the monthly cost effects tied to the correct AWS services.
- Updates the ticket — writes a Cloud Capital reference back to the Linear issue or Jira ticket so engineers always know the forecast impact has been modelled.
Examples
Right-sizing an ElastiCache cluster
“Right-size Redis cluster — targeting ~25% cost reduction, work starts August, completes by end of September.”The skill creates a single TEMPORARY initiative on
AmazonElastiCache with a relative -25% effect for August and September, then closes. The Linear or Jira ticket gets a Cloud Capital section appended.
New product launch adding EC2 capacity
“Launching Payments API in August — will require significant new EC2 capacity, estimating 40% growth over current EC2 spend.”The skill creates a PERMANENT initiative on
AmazonEC2 with a relative +40% effect starting August. Because this is ongoing spend, no end date is set.
Migration from EC2 to ECS Fargate
“Migrate worker fleet from EC2 to ECS Fargate over Q3. EC2 fleet fully decommissioned by end of September.”Because the two services have different impact profiles, the skill creates two initiatives:
- AmazonEC2 — TEMPORARY: ramps down to -100% by September
- AmazonECS — PERMANENT: ramps up to reflect the new Fargate workload
Decommissioning a legacy RDS cluster
“Decommission legacy Postgres RDS cluster at end of Q3. Workload migrating to DynamoDB — no like-for-like replacement.”The skill creates two initiatives:
- AmazonRDS — PERMANENT: -100% from October onwards
- AmazonDynamoDB — if DynamoDB spend is currently near zero, the skill uses an ABSOLUTE dollar estimate rather than a percentage (since a percentage of near-zero is meaningless), and flags the assumption clearly for you to update once you have real numbers.
Tips
- Uncertain magnitude? The skill uses a conservative default and makes the assumption explicit in the initiative description — a prompt to revisit once better numbers are available.
- No timeline in the ticket? The skill defaults to starting next calendar month. Open-ended work gets PERMANENT duration; bounded work defaults to 3 months with a note.
- Ticket already references an initiative? The skill updates the existing initiative rather than creating a duplicate.
- Purely operational work? IAM policy changes, config updates, and similar tickets with no material cost impact are skipped, and the skill explains why.