/amazon-aurora-mysql

name: amazon-aurora-mysql
description: >-
  Amazon Aurora MySQL — creates, modifies, and advises on Aurora MySQL clusters specifically
  (MySQL-compatible engine, Aurora serverless, parallel query). Trigger for Aurora
  MySQL cluster operations, ACU sizing, I/O-Optimized storage, commitment pricing,
  or MySQL upgrade planning. Aurora MySQL uses full (VPC-based) configuration — express
  configuration is PostgreSQL-only. For Aurora PostgreSQL, use amazon-aurora-postgresql
  instead. Contains safety guardrails and response templates that override defaults.
version: 1

Amazon Aurora MySQL

A modular toolkit for **Aurora MySQL** organized as a registry of sub-skills. Each sub-skill handles one domain of Aurora MySQL work. The router matches user intent to the right sub-skill, then loads only the references needed. (For Aurora PostgreSQL — and its express-configuration quick-start — use the `amazon-aurora-postgresql` skill.)

Operating procedure (follow in order)

1. **Route** — match the request to a sub-skill using the **Trigger phrases** column (match on meaning, not exact wording), then confirm with the **When to route here** column. 2. **Load** — `file_read` the matched sub-skill's `references/{id}-instructions.md` and announce the path. Do not answer a matched sub-skill from general knowledge alone. 3. **Analyze / advise** — perform the sub-skill's work; run a bundled script when the user supplies the inputs (see Scripts). 4. **If a mutation is requested** — classify against the Safety guardrails tier, confirm with the user, apply resource tags, then execute (MCP-preferred, CLI fallback). 5. **Present results** — tables with dollar/ACU figures and a recommendation label; no derivation or arithmetic steps.

Edge cases: if the request spans multiple sub-skills, run them in sequence (load each instructions.md in turn). If **no** sub-skill matches, answer directly from Aurora MySQL knowledge. If a script or MCP/CLI call fails, show the error and suggest a fix before retrying. The numbered Global rules below are details that hang off these steps.

Sub-skill registry

**Column semantics:** **Trigger phrases** = the keyword index you match the request against (step 1). **When to route here** = the decision logic confirming the match. **Next steps** = sub-skills to *offer the user as a natural follow-up* after this one completes (not auto-chained); **Reached from** = sub-skills that typically route into this one. Next-steps/Reached-from are suggestions for guiding the user, never automatic execution.

| ID | Name | When to route here | Trigger phrases | Reached from | Next steps | |----|------|--------|---------------------|----------|------------| | `create` | Create Cluster | Routes Aurora MySQL cluster creation requests. Aurora MySQL uses full (VPC-based) configuration — collect VPC/subnet group, security group, KMS, parameter group, and engine version, present options, then create. (Express configuration is PostgreSQL-only and does not apply to Aurora MySQL.) | create a cluster, new database, set up Aurora MySQL, get started, need a MySQL database, provision | — | `serverless-advisory`, `io-optimized` | | `serverless-advisory` | Aurora serverless Advisory | All Aurora serverless questions: ACU sizing, scale-to-zero behavior and compatibility, provisioned→serverless migration, capacity planning, and feature constraints. | ACU sizing, Aurora serverless, scale-to-zero, provisioned to serverless, how many ACUs, capacity, auto-scaling, RDS Proxy compatibility, scale-to-zero incompatibility, serverless limitations | `create` (optional) | `commitment-pricing` | | `io-optimized` | I/O-Optimized Storage | Evaluates whether to switch from Aurora Standard to I/O-Optimized (aurora-iopt1). Uses the 25% I/O cost threshold rule. | I/O-Optimized, aurora-iopt1, storage type switch, 25% threshold, I/O costs too high, storage comparison | — | — | | `commitment-pricing` | Commitment Pricing | Compares Reserved Instances vs Database Savings Plans for provisioned clusters, and DSP-only for Aurora serverless. 1yr vs 3yr analysis. | Reserved Instance, RI, Savings Plan, DSP, 1yr vs 3yr, commitment, cost optimization, overpaying | `serverless-advisory` (optional) | — | | `upgrade-planning` | Upgrade Planning | Major and minor version upgrade planning for Aurora MySQL. LTS version guidance, pre/post-upgrade checklists, blue/green deployment recommendations. | upgrade, version, LTS, pre-upgrade checklist, post-upgrade, major version, minor version, end of life, deprecation | — | — |

Global rules (apply to every sub-skill)

1. **Execute, don't just suggest.** When the user requests an action and confirms, EXECUTE it rather than handing back a command to run. The AWS MCP server is the recommended execution path when available (sandboxed, IAM-authenticated, audit-logged) — prefer it. When MCP tools are not available (e.g. Claude Code, Cursor, or other non-MCP hosts), use the AWS CLI / SDK directly with the same `aws rds ...` operation. Only if execution is genuinely not possible in the current environment, present the complete CLI command for the user to run.

2. **Confirmation before mutation.** MUST confirm with the user before any create or modify operation. Do NOT execute without explicit confirmation ("yes", "proceed", "confirmed", "go ahead").

3. **Resource tagging (always apply on resource creation).** When creating any cluster or instance, ALWAYS include these tags: `--tags Key=created_by,Value=aurora-skill Key=generation_model,Value={your-model-id}` Use your model id if known; if you cannot reliably determine it, use `Value=unknown` — never let tagging block the create. Include these tags even if the user does not mention tagging. If the user provides additional tags, append these to their tags.

4. **Safety guardrails.**

**Tier 1 — Confirm (a yes/no confirmation is enough; no risk briefing required):**

• `create-db-cluster` (full/VPC configuration — Aurora MySQL does not suppo