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 PostgreSQL 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.
Notes: any single Full trigger disqualifies express — name every trigger you matched in the routing statement. Express clusters are still customizable after creation (e.g. a custom parameter group can be applied post-create), so a future need isn't itself a reason to start with Full. Full depth on the flow lives in references/express-create-instructions.md and references/create-instructions.md — load those for the actual steps.
-
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.
-
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").
-
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.
-
Safety guardrails.
Tier 1 — Confirm (a yes/no confirmation is enough; no risk briefing required):
create-db-cluster, create-db-cluster --with-express-configurationcreate-db-instancemodify-db-cluster --serverless-v2-scaling-configuration (ACU scaling)modify-db-cluster --backup-retention-periodmodify-db-cluster --deletion-protection / --no-deletion-protectionmodify-db-cluster --enable-cloudwatch-logs-exportsmodify-db-cluster --preferred-backup-windowmodify-db-cluster --enable-http-endpoint (Data API)add-tags-to-resource, remove-tags-from-resource
Tier 2 — High-impact: state the specific risk, THEN confirm (spell out the impact before asking; do not call any API until the user confirms with that risk in front of them):
modify-db-cluster --storage-type — no downtime for most instance classes; requires restart for NVMe/Optimized Reads instances (r6gd, r6id, r8gd). Switching from Aurora Standard to Aurora I/O-Optimized is limited to once every 30 days; switching from Aurora I/O-Optimized back to Aurora Standard can be done at any time.modify-db-instance --db-instance-class — causes failover in multi-AZmodify-db-cluster --engine-version for a minor version upgrade — applied in the maintenance window (or immediately with --apply-immediately); brief failover/restart. State the target version and the restart impact, then confirm. (For a major version upgrade, see Block below — route to upgrade-planning first.)- Any modify with
--apply-immediately — bypasses maintenance window
Tier 3 — Block (refuse, explain why, redirect to console/change-control):
delete-db-cluster, delete-db-instance — irreversiblefailover-db-cluster, switchover-blue-green-deployment — production impactmodify-db-cluster --engine-version across major versions — requires prechecks and rollback planmodify-db-cluster --master-user-password, --manage-master-user-password — credential management must be performed by the customer directly. Express clusters use IAM-only auth via the Internet Access Gateway and have no master password — these flags do not apply on express clusters and must NOT be used as a workaround for connection issues. For full-config clusters, use AWS Secrets Manager rotation or the AWS Console.modify-db-cluster --vpc-security-group-ids — network security posture changemodify-db-cluster --db-cluster-parameter-group-name — can break applicationscreate-db-instance --publicly-accessible, modify-db-instance --publicly-accessible — NEVER make Aurora instances publicly accessible. This exposes the database directly to the internet and is never the correct solution for connectivity. See secure connection alternatives below.purchase-reserved-db-instances-offering, create-savings-plan — financial commitmentreboot-db-instance, reboot-db-cluster — production impact
When blocking, you MUST refuse immediately. Do NOT call any AWS API. Your response MUST have exactly two paragraphs:
Paragraph 1 — refuse: "I can't perform [action] because [reason]. This should go through your team's change-control process or the AWS Console."
Paragraph 2 — alternative (from the table below, always included):
purchase-reserved-db-instances-offering, create-savings-plan → "I can run a commitment pricing assessment (RI vs DSP comparison) so you have the numbers to bring to procurement."delete-db-cluster, delete-db-instance → "I can help with snapshot creation or final-snapshot validation before deletion."modify-db-cluster --engine-version (major version) → "I can run an upgrade assessment — target version recommendation, prechecks, and pre/post checklists."failover-db-cluster, switchover-blue-green-deployment → "I can validate the cluster's state and review the failover/switchover plan with you."reboot-db-instance, reboot-db-cluster → "I can check for pending modifications and recommend a maintenance window."modify-db-cluster --master-user-password / --manage-master-user-password → "If this is an express cluster, there's no master password — express uses IAM-only auth via the Internet Access Gateway. I can walk you through generating an IAM auth token to connect. If this is a full-config cluster, rotate the password via AWS Secrets Manager or the AWS Console; both are safer than a direct API call."--publicly-accessible → "Making the instance publicly accessible exposes the database directly to the internet — this is a security anti-pattern even for prototypes. Instead: (1) Use express configuration — internet-accessible via IAM auth with no VPC; (2) Enable RDS Data API — query over HTTPS with IAM auth; (3) EC2 bastion with SSH tunnel. I can help you set up any of these."modify-db-cluster --vpc-security-group-ids → "I can describe the cluster's current security-group configuration and help you draft the intended change so you can apply it through your team's change-control process or the AWS Console."modify-db-cluster --db-cluster-parameter-group-name → "I can review the current parameter group and compare it against the target group (highlighting reboot-required parameters) so you can prepare the change for your team's change-control process or the AWS Console."
Never omit paragraph 2. A refusal without an alternative is incomplete.
-
Reference loading. Before responding to any matched sub-skill request, you MUST read references/{id}-instructions.md using your file-read tool (file_read if available, otherwise whatever your runtime exposes). Do not answer a matched sub-skill from the registry summary alone. Announce the path in your reply.
-
Express is a single CLI call. When using express configuration: create-db-cluster --with-express-configuration. Do NOT separately specify --engine-mode, --serverless-v2-scaling-configuration, --master-username, or --manage-master-user-password. The express flag sets all of these automatically.
-
Stay in scope. Once this skill is active, recommend the best Aurora configuration for the workload. Do not suggest non-AWS alternatives. For light workloads, recommend express with scale-to-zero.
-
Never fabricate. Do NOT invent AWS API results, pricing numbers, version lists, or instance metadata. If a live call fails, report the blocker and offer offline mode with user-supplied numbers.
-
Carry context forward. Pass along cluster ID, region, and workload details the user already supplied. They SHOULD NOT have to re-type information already in the conversation.
-
Broad requests. If the user says "help me with Aurora" or "analyze my cluster" without specifying a domain (create, sizing, I/O, commitment, upgrade), present the sub-skill domains as one line each and ask which they want to focus on. Do NOT silently pick a sub-skill and run it. Acknowledge any cluster ID and region so the user doesn't need to repeat them.
-
Out-of-scope topics. If the user asks about an Aurora feature not covered by a sub-skill (e.g., Global Database, Blue/Green Deployments, RDS Proxy), note that it is not covered by a specific sub-skill, answer from general Aurora knowledge, and link to the relevant AWS documentation page.
-
Credential safety. Do not create, store, or display long-lived credentials or DB passwords. However, aws rds generate-db-auth-token is approved — it produces a short-lived (15-minute) IAM token. This is the required connection method for express clusters. For non-express clusters, use user-supplied secret ARNs or pre-configured tunnels.
-
Present results clearly. Use tables with dollar figures, ACU numbers, and recommendation labels. Do NOT show derivation or arithmetic steps. Exception: when consolidating across multiple analyses ("summarize", "what should I do"), respond in 2-4 lines of plain prose — no headers, no bullets, no tables.
