[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7AB2D18Q1SWGPZXWMHTDX3S":3,"skill-same:01M7AB2D18Q1SWGPZXWMHTDX3S":137},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":6,"ownerDescription":48,"updatedAt":49,"install":50,"resources":63},"01M7AB2D18Q1SWGPZXWMHTDX3S","rds-parameter-group-deployer",null,"Provisions RDS DB parameter groups with correct production defaults: family selection (postgres15, mysql8.0, aurora-postgresql15), static vs dynamic parameters (static requires DB instance reboot), ApplyMethod (immediate vs pending-reboot), PostgreSQL tuning (max_connections, shared_buffers, work_mem, wal_buffers, checkpoint_completion_target), MySQL tuning (innodb_buffer_pool_size, max_connections, slow_query_log), Aurora-specific parameters, Aurora Serverless v2 capacity parameters, and parameter group association with DB instances and clusters. Emits a READY_TO_DEPLOY checklist. Use when creating a DB parameter group, tuning PostgreSQL\u002FMySQL parameters, configuring Aurora Serverless v2, or associating a parameter group with a DB instance. Triggers: create RDS parameter group, DB parameter group family, postgres parameter group, mysql parameter group, Aurora parameter group, static vs dynamic parameters, shared_buffers, innodb_buffer_pool_size, max_connections, ApplyMethod, pending-reboot.","jhkchan\u002Faws-agent-skills","jhkchan","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1083902?v=4","01M7A2SVQYP9GQTPTDXP5JKYQ4","Jacky Chan","01M7A2SVS117YWCTZABB75HZR1",4,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: rds-parameter-group-deployer\ndescription: 'Provisions RDS DB parameter groups with correct production defaults: family selection (postgres15, mysql8.0, aurora-postgresql15), static vs dynamic parameters (static requires DB instance reboot), ApplyMethod (immediate vs pending-reboot), PostgreSQL tuning (max_connections, shared_buffers, work_mem, wal_buffers, checkpoint_completion_target), MySQL tuning (innodb_buffer_pool_size, max_connections, slow_query_log), Aurora-specific parameters, Aurora Serverless v2 capacity parameters, and parameter group association with DB instances and clusters. Emits a READY_TO_DEPLOY checklist. Use when creating a DB parameter group, tuning PostgreSQL\u002FMySQL parameters, configuring Aurora Serverless v2, or associating a parameter group with a DB instance. Triggers: create RDS parameter group, DB parameter group family, postgres parameter group, mysql parameter group, Aurora parameter group, static vs dynamic parameters, shared_buffers, innodb_buffer_pool_size, max_connections, ApplyMethod, pending-reboot.'\nlicense: Apache-2.0\ncompatibility: 'Requires an LLM agent runtime (Claude Code, Cursor, Windsurf, Codex, Gemini). For live deployment: AWS CLI v2 with rds access. Works with Terraform aws_db_parameter_group \u002F aws_rds_cluster_parameter_group resources, CloudFormation AWS::RDS::DBParameterGroup \u002F AWS::RDS::DBClusterParameterGroup, and SAM templates.'\nmetadata:\n  domain: aws-cloudops\n  complexity: high\n  requires_llm: 'true'\n  phase: '1'\n  supports_pipeline: 'true'\n  entry_point: 'false'\n  family: Databases\n  task_type: deploy\n  skill_class: capability\n  lifecycle_status: active\n  verdict_shape: READY_TO_DEPLOY | PREREQUISITES_MISSING\n  version: 0.1.0\n  author: Jacky Chan — AWS Community Builder\n  tags: aws, rds, aurora, databases, cloudops, deploy, parameter-group, postgres, mysql\n  dependencies: aws-orchestrator\n  keywords: aws, rds, aurora, databases, cloudops, deploy, provisioning, parameter-group, postgres, mysql, tuning, static-dynamic, apply-method, aurora-serverless-v2\n  when_to_use: Invoke when the user wants to create a new RDS DB parameter group or DB cluster parameter group, tune PostgreSQL or MySQL parameters, configure Aurora-specific parameters, set up Aurora Serverless v2 capacity settings, or associate a parameter group with a DB instance or Aurora cluster. Do NOT invoke for option groups (use the option-group skill), for DB instance class changes (use the instance-deployer skill), or for RDS Proxy configuration.\n---\n\n# RDS Parameter Group Deployer\n\nAn AWS CloudOps agent skill that provisions RDS DB parameter groups\nand DB cluster parameter groups with correct production defaults.\nThe skill walks the operator through a 9-step provisioning\nprocedure, explains why each default matters, and emits a\nREADY_TO_DEPLOY checklist verifying every configuration item.\n\n## Quick navigation\n\n| Need | Section |\n|---|---|\n| What MUST be in the response | \"STRICT output contract\" |\n| Why the provisioning order matters | \"Reasoning framework\" |\n| What to verify before provisioning | \"Prerequisites\" |\n| The ordered provisioning steps | \"Deployment procedure\" |\n| Common silent-failure pitfalls | \"NEVER\" |\n| Choosing family, parameters, ApplyMethod | \"Expert heuristic\" |\n| Workload-specific defaults | \"Workload matrix\" |\n| 2024-2026 feature changes | \"Recent AWS features\" |\n| Deep CLI sequences | `references\u002Fdeployment-cli-commands.md` |\n| PostgreSQL\u002FMySQL\u002FAurora tuning reference | `references\u002Fdatabase-tuning-guide.md` |\n\n## Activation keywords\n\ncreate RDS parameter group, DB parameter group, DB parameter group\nfamily, DB cluster parameter group, postgres parameter group,\nmysql parameter group, aurora parameter group, static vs dynamic\nparameters, ApplyMethod immediate, pending-reboot, shared_buffers,\nwork_mem, wal_buffers, checkpoint_completion_target,\nmax_connections, innodb_buffer_pool_size, slow_query_log,\nlong_query_time, aurora_enable_repl_bin_log_filter,\naurora serverless v2, RDS parameter tuning, ModifyDBParameterGroup,\nModifyDBClusterParameterGroup.\n\n## STRICT output contract\n\nWhen this skill is invoked with an RDS parameter group provisioning\nrequest (group name, family, engine, parameter list, or a partial\nexisting configuration), the agent MUST respond with the\nREADY_TO_DEPLOY checklist defined in \"Output format\" using the\nliteral all-caps labels `GROUP:`, `VERDICT:`, `CHECKLIST:`, and\n`VERIFICATION_COMMANDS:`. Do NOT preface the checklist with prose,\nheadings, or disclaimers — emit the block as the first lines of\nthe response.\n\n### Required output structure\n\n1. `GROUP: \u003Cparameter-group-name>` — the parameter group being\n   provisioned.\n2. `VERDICT: READY_TO_DEPLOY` OR `VERDICT: PREREQUISITES_MISSING` —\n   nothing else.\n3. `CHECKLIST:` followed by indented lines, each prefixed with a\n   status marker (`[✓]`, `[✗]`, `[OPTIONAL]`, `[INPUT NEEDED]`).\n4. `VERIFICATION_COMMANDS:` followed by indented `aws rds ...`\n   commands the operator can run.\n\n### 6 FORBIDDEN output patterns (each silently breaks automation)\n\n1. **FORBIDDEN — prose preamble before `GROUP:`.** The first\n   non-empty line MUST be `GROUP:`. No \"Here is your parameter\n   group checklist…\".\n2. **FORBIDDEN — markdown variants of the labels.** Write\n   `VERDICT:`, not `**VERDICT:**`, `### Verdict`, `Verdict =`, or\n   `\\`VERDICT\\``. The labels are case-sensitive all-caps keywords.\n3. **FORBIDDEN — swapping verdict tokens.** The verdict is exactly\n   `READY_TO_DEPLOY` or `PREREQUISITES_MISSING` — not \"ready\",\n   \"missing\", \"BLOCKED\", \"OK\", or \"needs review\".\n4. **FORBIDDEN — omitting `VERIFICATION_COMMANDS:`.** Even when\n   the verdict is `PREREQUISITES_MISSING`, include the commands\n   the operator needs to verify the gaps.\n5. **FORBIDDEN — extra sections after `VERIFICATION_COMMANDS:`.**\n   The checklist block is the entire response. Put deeper\n   explanation in `references\u002F` files, not after the block.\n6. **FORBIDDEN — status marker drift.** Use only `[✓]`, `[✗]`,\n   `[OPTIONAL]`, `[INPUT NEEDED]`. Do not invent `[?]`, `[!]`,\n   `[WARN]`, or emoji markers.\n\n### Perfect example (copy the shape exactly)\n\n```text\nGROUP: payments-pg15-params\nVERDICT: READY_TO_DEPLOY\nCHECKLIST:\n  [✓]      Family — postgres15\n  [✓]      Type — DBParameterGroup\n  [✓]      max_connections — 200 (dynamic, immediate)\n  [✓]      shared_buffers — {6GB} (static, PENDING REBOOT required)\n  [✓]      work_mem — 8MB (dynamic, immediate)\n  [✓]      wal_buffers — 16MB (dynamic, immediate)\n  [✓]      checkpoint_completion_target — 0.9 (dynamic, immediate)\n  [✓]      Association — DB instance payments-db-pg15 (pending reboot for static params)\n  [✓]      Tags — Environment=production, Application=payments\nVERIFICATION_COMMANDS:\n  aws rds describe-db-parameters --db-parameter-group-name payments-pg15-params\n  aws rds describe-db-instances --db-instance-identifier payments-db-pg15\n  aws rds describe-pending-maintenance-actions --db-instance-identifier payments-db-pg15\n```\n\n## Reasoning framework (why the provisioning order matters)\n\nRDS parameter group provisioning has **family, static-vs-dynamic,\nand association constraints** that make the procedure non-trivial.\nApplying configurations in the wrong order causes parameters that\nsilently don't take effect, unnecessary reboots, or Aurora cluster\ndisconnects:\n\n1. **Family FIRST — the DB parameter group family is immutable.**\n   The family (`postgres15`, `mysql8.0`, `aurora-postgresql15`,\n   `sqlserver-se-15.00`, `oracle-ee-19`) determines which\n   parameters are available and their defaults. The family MUST\n   match the DB engine version. A `postgres14` parameter group\n   cannot be associated with a `postgres15` instance. The family\n   CANNOT be changed after creation — you must create a new group.\n\n2. **DBParameterGroup vs DBClusterParameterGroup — two types.**\n   A `DBParameterGroup` applies to individual DB instances. A\n   `DBClusterParameterGroup` applies to all instances in an Aurora\n   cluster (and is the ONLY type accepted by Aurora clusters).\n   Regular RDS (non-Aurora) uses DBParameterGroup only. Aurora\n   uses BOTH — the cluster parameter group sets cluster-level\n   defaults, and each instance can override via its own\n   DBParameterGroup.\n\n> Moved verbatim to [`references\u002Fadvanced-patterns.md`](references\u002Fadvanced-patterns.md) — load on demand.\n\n\n## Prerequisites (verify before deployment)\n\n| Prerequisite | Why it matters | How to verify |\n|---|---|---|\n| **DB engine and version** | The parameter group family MUST match the engine version. `postgres15` ≠ `postgres14`. | `aws rds describe-db-instances --db-instance-identifier \u003Cid>` |\n| **Parameter group family** | Derived from the engine version. Immutable after creation. | `aws rds describe-db-engine-versions --engine postgres --query 'DBEngineVersions[].DBParameterGroupFamily'` |\n| **DB instance or cluster identifier** (for association) | The parameter group must be associated with an existing instance or cluster. | `aws rds describe-db-instances` \u002F `aws rds describe-db-clusters` |\n| **Parameter data types** | Each parameter has a `DataType` (string, integer, boolean) and `AllowedValues`. Setting the wrong type fails at ModifyDBParameterGroup time. | `aws rds describe-db-parameters --db-parameter-group-name \u003Cfamily-default>` |\n| **Static vs dynamic awareness** | Static parameters require a reboot. Plan reboot windows accordingly. | `DescribeDBParameters` — check `ApplyType: static` |\n| **Aurora cluster type** (if Aurora) | Aurora Serverless v2 uses `ServerlessV2ScalingConfiguration`, not parameter values, for capacity. Parameter group tuning complements the ACU range. | `aws rds describe-db-clusters --db-cluster-identifier \u003Cid>` |\n| **IAM permissions** | Caller needs `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`, `rds:ModifyDBInstance` or `rds:ModifyDBCluster`. | `aws sts get-caller-identity` |\n\n## Deployment procedure (apply in order)\n\n### Step 1: Family selection\n\nThe parameter group family is determined by the DB engine and\nversion. It is immutable after creation.\n\n> Moved verbatim to [`references\u002Fadvanced-patterns.md`](references\u002Fadvanced-patterns.md) — load on demand.\n\n\n### Step 2: DBParameterGroup vs DBClusterParameterGroup\n\n| Type | Used by | Scope |\n|---|---|---|\n| `DBParameterGroup` | RDS instances, Aurora instance-level overrides | Single DB instance |\n| `DBClusterParameterGroup` | Aurora clusters ONLY | All instances in an Aurora cluster |\n\n**Rule:** if the target is an Aurora cluster, create a\n`DBClusterParameterGroup`. If the target is a regular RDS instance,\ncreate a `DBParameterGroup`. Aurora clusters can use BOTH — cluster\ngroup for cluster-level defaults, instance group for overrides.\n\n### Step 3: Static vs dynamic parameters\n\nEvery RDS parameter has an `ApplyType` of either `static` or\n`dynamic`:\n\n- **Dynamic** — the parameter takes effect immediately (for\n  `ApplyMethod: immediate`) or at the next connection. No reboot\n  required.\n- **Static** — the parameter requires a DB instance reboot to take\n  effect. `ApplyMethod` is always `pending-reboot` regardless of\n  what you specify.\n\n> Moved verbatim to [`references\u002Fdeployment-cli-commands.md`](references\u002Fdeployment-cli-commands.md) — load on demand.\n\n\n> Moved verbatim to [`references\u002Fdatabase-tuning-guide.md`](references\u002Fdatabase-tuning-guide.md) — load on demand.\n\n\n### Step 4: ApplyMethod (immediate vs pending-reboot)\n\nThe `ApplyMethod` controls when a parameter change takes effect:\n\n> Moved verbatim to [`references\u002Fdeployment-cli-commands.md`](references\u002Fdeployment-cli-commands.md) — load on demand.\n\n\n| ApplyMethod | Effect | Works for |\n|---|---|---|\n| `immediate` | Applies as soon as possible (typically within seconds for dynamic params) | Dynamic parameters only |\n| `pending-reboot` | Applies after the next DB instance reboot | Static AND dynamic parameters |\n\n**Rule:** always use `immediate` for dynamic parameters (unless you\nwant to batch changes at the next maintenance window). Always use\n`pending-reboot` for static parameters (it is the only option, but\nexplicitly stating it documents the reboot requirement).\n\nSetting `ApplyMethod: immediate` on a static parameter does NOT\nforce immediate application. RDS silently treats it as\n`pending-reboot`. This is a common source of confusion.\n\n### Step 5: Common PostgreSQL tuning parameters\n\n> Moved verbatim to [`references\u002Fdatabase-tuning-guide.md`](references\u002Fdatabase-tuning-guide.md) — load on demand.\n\n\n### Step 6: Common MySQL tuning parameters\n\n> Moved verbatim to [`references\u002Fdatabase-tuning-guide.md`](references\u002Fdatabase-tuning-guide.md) — load on demand.\n\n\n### Step 7: Aurora-specific parameters\n\n> Moved verbatim to [`references\u002Fdatabase-tuning-guide.md`](references\u002Fdatabase-tuning-guide.md) — load on demand.\n\n\n### Step 8: Aurora Serverless v2 capacity\n\n> Moved verbatim to [`references\u002Fdatabase-tuning-guide.md`](references\u002Fdatabase-tuning-guide.md) — load on demand.\n\n\n### Step 9: Create + associate + apply\n\n> Moved verbatim to [`references\u002Fdeployment-cli-commands.md`](references\u002Fdeployment-cli-commands.md) — load on demand.\n\n\nFor Aurora clusters, use `create-db-cluster-parameter-group` \u002F\n`modify-db-cluster-parameter-group` \u002F `modify-db-cluster`.\n\n## Workload matrix\n\n| Workload | Engine | Key parameters | Notes |\n|---|---|---|---|\n| OLTP (high-throughput) | PostgreSQL | `shared_buffers=25%`, `work_mem=8MB`, `max_connections=200`, `checkpoint_completion_target=0.9` | Use RDS Proxy for connection pooling |\n| Read-heavy analytics | PostgreSQL | `work_mem=64MB`, `maintenance_work_mem=1GB`, `effective_cache_size=75%`, `random_page_cost=1.1` | Higher work_mem for large sorts\u002Fhashes |\n| MySQL web app | MySQL | `innodb_buffer_pool_size=75%`, `max_connections=300`, `slow_query_log=1`, `long_query_time=1` | Enable slow query logging in production |\n| Aurora Serverless v2 | Aurora PG\u002FMySQL | Use formula values (`{DBInstanceClassMemory\u002FN}`), conservative `work_mem` | Never set absolute memory values |\n| Migration staging | PostgreSQL | Source DB's exact parameter values | Match source to validate query plans |\n| High-availability replica | Aurora MySQL | `aurora_enable_repl_bin_log_filter=1`, `binlog_format=ROW` | ROW format for reliable replication |\n\n## Recent AWS features (2024-2026)\n\n> Moved verbatim to [`references\u002Fadvanced-patterns.md`](references\u002Fadvanced-patterns.md) — load on demand.\n\n\n## NEVER (anti-patterns)\n\n- NEVER create a parameter group with the wrong family. The family\n  is immutable. A `postgres15` parameter group cannot attach to a\n  `postgres14` instance. Always verify the engine version before\n  creating.\n\n- NEVER set `ApplyMethod: immediate` on a static parameter and\n  assume it will apply without a reboot. RDS silently treats it as\n  `pending-reboot`. Static parameters ALWAYS require a reboot.\n  Check `ApplyType` via `DescribeDBParameters` before setting.\n\n- NEVER set absolute memory values (`shared_buffers = 6GB`) on\n  Aurora Serverless v2. The instance class changes dynamically\n  with ACU scaling — an absolute value tuned for 16 ACU causes OOM\n  at 2 ACU. Always use `{DBInstanceClassMemory\u002FN}` formula syntax.\n\n- NEVER modify a production DB parameter group without planning a\n  reboot window for static parameters. Static parameters (like\n  `shared_buffers`, `max_connections` on some engines) require a\n  reboot. Schedule during a maintenance window.\n\n- NEVER disable `autovacuum` on PostgreSQL in production. Without\n  autovacuum, dead tuples accumulate, bloat increases, and\n  performance degrades. Tune autovacuum settings\n  (`autovacuum_naptime`, `autovacuum_vacuum_threshold`) instead.\n\n- NEVER exceed `max_connections` beyond what the instance class can\n  handle. Each connection consumes memory (thread stack + work_mem +\n  sort buffers). Formula: `(RAM - shared_buffers) \u002F (work_mem × 2)`\n  gives a safe ceiling. Use RDS Proxy or PgBouncer for pooling.\n\n- NEVER set `innodb_flush_log_at_trx_commit=0` or `sync_binlog=0`\n  in production if data durability matters. These settings trade\n  crash safety for throughput — you can lose committed transactions\n  on a crash. Use `1` for both unless you explicitly accept the risk.\n\n- NEVER change a parameter group on an Aurora cluster without\n  understanding that the DBClusterParameterGroup applies to ALL\n  instances. Instance-level overrides via DBParameterGroup can\n  conflict — test the interaction in staging.\n\n- NEVER forget to associate the parameter group with the DB\n  instance after creating it. Creating the group alone has no\n  effect. Call `ModifyDBInstance` or `ModifyDBCluster`.\n\n- NEVER deviate from the checklist output format. Substituting\n  `Verdict` \u002F `**VERDICT**` \u002F `### Verdict:` for the literal\n  `VERDICT:` label silently breaks downstream deployment pipelines\n  and assertion-based evals.\n\n## Expert heuristic — choosing family, parameters, and ApplyMethod\n\n**Family — match the engine version exactly:** the family is\n`\u003Cengine>\u003Cmajor-version>` (e.g., `postgres15`, `mysql8.0`). For\nAurora, prefix with `aurora-` (e.g., `aurora-postgresql15`). Use\n`DescribeDBEngineVersions` to find the family for a specific engine\nversion. When in doubt, check the existing default group name\n(`default.postgres15`).\n\n**Parameters — start with memory and connections, then planner:**\nthe highest-impact parameters are `shared_buffers` \u002F \n`innodb_buffer_pool_size` (25-75% of RAM), `max_connections`\n(scale with instance class), `work_mem` (4-16MB per query), and\nplanner hints (`effective_cache_size`, `random_page_cost`). These\nhave more impact than micro-tuning dozens of minor parameters.\n\n**ApplyMethod — immediate for dynamic, pending-reboot for static:**\nalways check the parameter's `ApplyType` before setting\n`ApplyMethod`. Dynamic + immediate = no reboot. Static + any\n`ApplyMethod` = reboot required. When changing multiple parameters,\nbatch them in one `ModifyDBParameterGroup` call — it applies\natomically and minimizes reboot windows.\n\n**Aurora — use DBClusterParameterGroup:** Aurora clusters require\na cluster parameter group. Instance-level DBParameterGroups are\noptional overrides. Set cluster-level parameters (like\n`aurora_enable_repl_bin_log_filter`) in the cluster group. Set\ninstance-specific tuning (like `work_mem`) in the instance group.\n\n**Serverless v2 — formula values only:** never set absolute memory\nvalues. Use `{DBInstanceClassMemory\u002FN}` for all memory-related\nparameters. The formula adapts as the ACU scales. Set\n`max_connections` based on the MAX capacity, not the minimum.\n\n**Reboot planning — always flag static changes:** when the\nchecklist includes any `[✓]` item with `(static, PENDING REBOOT\nrequired)`, call out the reboot requirement in the checklist.\nStatic parameter changes are a no-op until the instance reboots.\nSchedule during a maintenance window for production.\n\n## Pre-flight safety checks (run before any provisioning CLI)\n\n- **Confirm the DB engine and version:**\n  ```bash\n  aws rds describe-db-instances --db-instance-identifier \u003Cid> \\\n    --query 'DBInstances[].{Engine:Engine,EngineVersion:EngineVersion}'\n  ```\n\n- **Confirm the parameter group family matches the engine:**\n  ```bash\n  aws rds describe-db-engine-versions --engine postgres \\\n    --query 'DBEngineVersions[].{Version:EngineVersion,Family:DBParameterGroupFamily}'\n  ```\n\n- **Confirm parameter data types and allowed values:**\n  ```bash\n  aws rds describe-db-parameters --db-parameter-group-name default.postgres15 \\\n    --query 'Parameters[?ParameterName==`shared_buffers`]'\n  ```\n\n- **Confirm the DB instance or cluster exists:**\n  ```bash\n  aws rds describe-db-instances --db-instance-identifier \u003Cid>\n  aws rds describe-db-clusters --db-cluster-identifier \u003Cid>\n  ```\n\n- **For Aurora Serverless v2, confirm the scaling configuration:**\n  ```bash\n  aws rds describe-db-clusters --db-cluster-identifier \u003Cid> \\\n    --query 'DBClusters[].ServerlessV2ScalingConfigurationInfo'\n  ```\n\n- **For existing parameter groups, capture current values for rollback:**\n  ```bash\n  aws rds describe-db-parameters --db-parameter-group-name \u003Cname> \\\n    --query 'Parameters[?Source!=`engine-default`]' \\\n    > \u002Ftmp\u002F\u003Cname>-backup.json\n  ```\n\n## Output format — MANDATORY literal labels\n\nWhen invoked with a parameter group provisioning request, your\nENTIRE response MUST be the checklist block below. The labels are\n**case-sensitive all-caps keywords** — write them EXACTLY as shown.\nDo NOT write a preamble. Start with `GROUP:` and stop after the\n`VERIFICATION_COMMANDS:` block.\n\n```text\nGROUP: \u003Cparameter-group-name>\nVERDICT: READY_TO_DEPLOY | PREREQUISITES_MISSING\nCHECKLIST:\n  [✓]      Family — \u003Cpostgres15 | mysql8.0 | aurora-postgresql15 | ...>\n  [✓]      Type — \u003CDBParameterGroup | DBClusterParameterGroup>\n  [✓]      \u003Cparameter-name> — \u003Cvalue> (\u003Cdynamic|static>, \u003Cimmediate|pending-reboot>)\n  [✓]      ... (repeat for each parameter)\n  [✓]      Association — \u003Cdb-instance-id | db-cluster-id | pending>\n  [✓]      Reboot required — \u003Cyes (static params changed) | no (dynamic only)>\n  [✓]      Tags — \u003Ckey=value pairs>\nVERIFICATION_COMMANDS:\n  aws rds describe-db-parameters --db-parameter-group-name \u003Cname>\n  aws rds describe-db-instances --db-instance-identifier \u003Cid>\n  aws rds describe-pending-maintenance-actions --db-instance-identifier \u003Cid>\n```\n\n**Status marker semantics:**\n- `[✓]` — configuration is applied and verified.\n- `[✗]` — configuration is NOT applied or is misconfigured. Cite\n  the gap.\n- `[OPTIONAL]` — recommended but not required for the workload type.\n- `[INPUT NEEDED]` — a prerequisite value is missing (engine\n  version, DB instance ID, parameter group family) and the operator\n  must provide it before provisioning can proceed.\n\n**PREREQUISITES_MISSING verdict:** if any REQUIRED prerequisite is\nmissing (DB engine version to determine the family, DB instance\nidentifier for association), the verdict is\n`PREREQUISITES_MISSING` with each gap listed. The checklist shows\nthe target configuration with `[INPUT NEEDED]` or `[✗]` for unmet\nprerequisites.\n\n## Edge-case handling\n\n> Moved verbatim to [`references\u002Fadvanced-patterns.md`](references\u002Fadvanced-patterns.md) — load on demand.\n\n\n## References (load on demand)\n\n- [references\u002Fdeployment-cli-commands.md](references\u002Fdeployment-cli-commands.md) — static\u002Fdynamic parameter check, ApplyMethod payload, and the full create + modify + associate + reboot CLI sequence.\n- [references\u002Fdatabase-tuning-guide.md](references\u002Fdatabase-tuning-guide.md) — static\u002Fdynamic parameter tables, PostgreSQL\u002FMySQL\u002FAurora tuning tables, and Aurora Serverless v2 capacity interactions.\n- [references\u002Fadvanced-patterns.md](references\u002Fadvanced-patterns.md) — reasoning-framework constraints, family selection tables, recent AWS features, edge-case handling.\n\n## Domain\n\nAWS CloudOps \u002F RDS Database Parameter Group Provisioning.\n\n## AWS documentation\n\n- **Amazon RDS User Guide** — https:\u002F\u002Fdocs.aws.amazon.com\u002FAmazonRDS\u002Flatest\u002FUserGuide\u002FUSER_WorkingWithParamGroups.html\n- **RDS Parameter Groups** — https:\u002F\u002Fdocs.aws.amazon.com\u002FAmazonRDS\u002Flatest\u002FUserGuide\u002FUSER_WorkingWithDBInstanceParamGroups.html\n- **PostgreSQL Parameters on RDS** — https:\u002F\u002Fdocs.aws.amazon.com\u002FAmazonRDS\u002Flatest\u002FUserGuide\u002FAppendix.PostgreSQL.CommonDBATasks.Parameters.html\n- **MySQL Parameters on RDS** — https:\u002F\u002Fdocs.aws.amazon.com\u002FAmazonRDS\u002Flatest\u002FUserGuide\u002FAppendix.MySQL.CommonDBATasks.Parameters.html\n- **Aurora Serverless v2** — https:\u002F\u002Fdocs.aws.amazon.com\u002FAmazonRDS\u002Flatest\u002FAuroraUserGuide\u002Faurora-serverless-v2.setting-capacity.html\n- **RDS CLI Reference** — https:\u002F\u002Fdocs.aws.amazon.com\u002Fcli\u002Flatest\u002Freference\u002Frds\u002F\n\n## References\n\n- `references\u002Fdeployment-cli-commands.md` — full copy-pasteable CLI\n  command sequence for all 9 provisioning steps, including parameter\n  group creation, parameter modification (static and dynamic),\n  association with DB instances and Aurora clusters, reboot\n  procedures, Aurora Serverless v2 capacity configuration, and\n  Terraform `aws_db_parameter_group` \u002F\n  `aws_rds_cluster_parameter_group` resource equivalents.\n\n- `references\u002Fdatabase-tuning-guide.md` — deep reference on\n  PostgreSQL and MySQL parameter tuning (memory sizing formulas,\n  connection pooling, autovacuum, InnoDB internals), Aurora-specific\n  parameters, Aurora Serverless v2 capacity interactions, and\n  static-vs-dynamic parameter classification.\n","# RDS Parameter Group Deployer\n\nAn AWS CloudOps agent skill that provisions RDS DB parameter groups\nand DB cluster parameter groups with correct production defaults.\nThe skill walks the operator through a 9-step provisioning\nprocedure, explains why each default matters, and emits a\nREADY_TO_DEPLOY checklist verifying every configuration item.\n\n## Quick navigation\n\n| Need | Section |\n|---|---|\n| What MUST be in the response | \"STRICT output contract\" |\n| Why the provisioning order matters | \"Reasoning framework\" |\n| What to verify before provisioning | \"Prerequisites\" |\n| The ordered provisioning steps | \"Deployment procedure\" |\n| Common silent-failure pitfalls | \"NEVER\" |\n| Choosing family, parameters, ApplyMethod | \"Expert heuristic\" |\n| Workload-specific defaults | \"Workload matrix\" |\n| 2024-2026 feature changes | \"Recent AWS features\" |\n| Deep CLI sequences | `references\u002Fdeployment-cli-commands.md` |\n| PostgreSQL\u002FMySQL\u002FAurora tuning reference | `references\u002Fdatabase-tuning-guide.md` |\n\n## Activation keywords\n\ncreate RDS parameter group, DB parameter group, DB parameter group\nfamily, DB cluster parameter group, postgres parameter group,\nmysql parameter group, aurora parameter group, static vs dynamic\nparameters, ApplyMethod immediate, pending-reboot, shared_buffers,\nwork_mem, wal_buffers, checkpoint_completion_target,\nmax_connections, innodb_buffer_pool_size, slow_query_log,\nlong_query_time, aurora_enable_repl_bin_log_filter,\naurora serverless v2, RDS parameter tuning, ModifyDBParameterGroup,\nModifyDBClusterParameterGroup.\n\n## STRICT output contract\n\nWhen this skill is invoked with an RDS parameter group provisioning\nrequest (group name, family, engine, parameter list, or a partial\nexisting configuration), the agent MUST respond with the\nREADY_TO_DEPLOY checklist defined in \"Output format\" using the\nliteral all-caps labels `GROUP:`, `VERDICT:`, `CHECKLIST:`, and\n`VERIFICATION_COMMANDS:`. Do NOT preface the checklist with prose,\nheadings, or disclaimers — emit the block as the first lines of\nthe response.\n\n### Required output structure\n\n1. `GROUP: \u003Cparameter-group-name>` — the parameter group being\n   provisioned.\n2. `VERDICT: READY_TO_DEPLOY` OR `VERDICT: PREREQUISITES_MISSING` —\n   nothing else.\n3. `CHECKLIST:` followed by indented lines, each prefixed with a\n   status marker (`[✓]`, `[✗]`, `[OPTIONAL]`, `[INPUT NEEDED]`).\n4. `VERIFICATION_COMMANDS:` followed by indented `aws rds ...`\n   commands the operator can run.\n\n### 6 FORBIDDEN output patterns (each silently breaks automation)\n\n1. **FORBIDDEN — prose preamble before `GROUP:`.** The first\n   non-empty line MUST be `GROUP:`. No \"Here is your parameter\n   group checklist…\".\n2. **FORBIDDEN — markdown variants of the labels.** Write\n   `VERDICT:`, not `**VERDICT:**`, `### Verdict`, `Verdict =`, or\n   `\\`VERDICT\\``. The labels are case-sensitive all-caps keywords.\n3. **FORBIDDEN — swapping verdict tokens.** The verdict is exactly\n   `READY_TO_DEPLOY` or `PREREQUISITES_MISSING` — not \"ready\",\n   \"missing\", \"BLOCKED\", \"OK\", or \"needs review\".\n4. **FORBIDDEN — omitting `VERIFICATION_COMMANDS:`.** Even when\n   the verdict is `PREREQUISITES_MISSING`, include the commands\n   the operator needs to verify the gaps.\n5. **FORBIDDEN — extra sections after `VERIFICATION_COMMANDS:`.**\n   The checklist block is the entire response. Put deeper\n   explanation in `references\u002F` files, not after the block.\n6. **FORBIDDEN — status marker drift.** Use only `[✓]`, `[✗]`,\n   `[OPTIONAL]`, `[INPUT NEEDED]`. Do not invent `[?]`, `[!]`,\n   `[WARN]`, or emoji markers.\n\n### Perfect example (copy the shape exactly)\n\n```text\nGROUP: payments-pg15-params\nVERDICT: READY_TO_DEPLOY\nCHECKLIST:\n  [✓]      Family — postgres15\n  [✓]      Type — DBParameterGroup\n  [✓]      max_connections — 200 (dynamic, immediate)\n  [✓]      shared_buffers — {6GB} (static, PENDING REBOOT required)\n  [✓]      work_mem — 8MB (dynamic, immediate)\n  [✓]      wal_buffers — 16MB (dynamic, immediate)\n  [✓]      checkpoint_completion_target — 0.9 (dynamic, immediate)\n  [✓]      Association — DB instance payments-db-pg15 (pending reboot for static params)\n  [✓]      Tags — Environment=production, Application=payments\nVERIFICATION_COMMANDS:\n  aws rds describe-db-parameters --db-parameter-group-name payments-pg15-params\n  aws rds describe-db-instances --db-instance-identifier payments-db-pg15\n  aws rds describe-pending-maintenance-actions --db-instance-identifier payments-db-pg15\n```\n\n## Reasoning framework (why the provisioning order matters)\n\nRDS parameter group provisioning has **family, static-vs-dynamic,\nand association constraints** that make the procedure non-trivial.\nApplying configurations in the wrong order causes parameters that\nsilently don't take effect, unnecessary reboots, or Aurora cluster\ndisconnects:\n\n1. **Family FIRST — the DB parameter group family is immutable.**\n   The family (`postgres15`, `mysql8.0`, `aurora-postgresql15`,\n   `sqlserver-se-15.00`, `oracle-ee-19`) determines which\n   parameters are available and their defaults. The family MUST\n   match the DB engine version. A `postgres14` parameter group\n   cannot be associated with a `postgres15` instance. The family\n   CANNOT be changed after creation — you must create a new group.\n\n2. **DBParameterGroup vs DBClusterParameterGroup — two types.**\n   A `DBParameterGroup` applies to individual DB instances. A\n   `DBClusterParameterGroup` applies to all instances in an Aurora\n   cluster (and is the ONLY type accepted by Aurora clusters).\n   Regular RDS (non-Aurora) uses DBParameterGroup only. Aurora\n   uses BOTH — the cluster parameter group sets cluster-level\n   defaults, and each instance can override via its own\n   DBParameterGroup.\n\n> Moved verbatim to [`references\u002Fadvanced-patterns.md`](references\u002Fadvanced-patterns.md) — load on demand.\n\n\n## Prerequisites (verify before deployment)\n\n| Prerequisite | Why it matters | How to verify |\n|---|---|---|\n| **DB engine and version** | The parameter group family MUST match the engine version. `postgres15` ≠ `postgres14`. | `aws rds describe-db-instances --db-instance-identifier \u003Cid>` |\n| **Parameter group family** | Derived from the engine version. Immutable after creation. | `aws rds describe-db-engine-versions --engine postgres --query 'DBEngineVersions[].DBParameterGroupFamily'` |\n| **DB instance or cluster identifier** (for association) | The parameter group must be associated with an existing instance or cluster. | `aws rds describe-db-instances` \u002F `aws rds describe-db-clusters` |\n| **Parameter data types** | Each parameter has a `DataType` (string, integer, boolean) and `AllowedValues`. Setting the wrong type fails at ModifyDBParameterGroup time. | `aws rds describe-db-parameters --db-parameter-group-name \u003Cfamily-default>` |\n| **Static vs dynamic awareness** | Static parameters require a reboot. Plan reboot windows accordingly. | `DescribeDBParameters` — check `ApplyType: static` |\n| **Aurora cluster type** (if Aurora) | Aurora Serverless v2 uses `ServerlessV2ScalingConfiguration`, not parameter values, for capacity. Parameter group tuning complements the ACU range. | `aws rds describe-db-clusters --db-cluster-identifier \u003Cid>` |\n| **IAM permissions** | Caller needs `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`, `rds:ModifyDBInstance` or `rds:ModifyDBCluster`. | `aws sts get-caller-identity` |\n\n## Deployment procedure (apply in order)\n\n### Step 1: Family selection\n\nThe parameter group family is determined by the DB engine and\nversion. It is immutable after creation.\n\n> Moved verbatim to [`references\u002Fadvanced-patterns.md`](references\u002Fadvanced-patterns.md) — load on demand.\n\n\n### Step 2: DBParameterGroup vs DBClusterParameterGroup\n\n| Type | Used by | Scope |\n|---|---|---|\n| `DBParameterGroup` | RDS instances, Aurora instance-level overrides | Single DB instance |\n| `DBClusterParameterGroup` | Aurora clusters ONLY | All instances in an Aurora cluster |\n\n**Rule:** if the target is an Aurora cluster, create a\n`DBClusterParameterGroup`. If the target is a regular RDS instance,\ncreate a `DBParameterGroup`. Aurora clusters can use BOTH — cluster\ngroup for cluster-level defaults, instance group for overrides.\n\n### Step 3: Static vs dynamic parameters\n\nEvery RDS parameter has an `ApplyType` of either `static` or\n`dynamic`:\n\n- **Dynamic** — the parameter takes effect immediately (for\n  `ApplyMethod: immediate`) or at the next connection. No reboot\n  required.\n- **Static** — the parameter requires a DB instance reboot to take\n  effect. `ApplyMethod` is always `pending-reboot` regardless of\n  what you specify.\n\n> Moved verbatim to [`references\u002Fdeployment-cli-commands.md`](references\u002Fdeployment-cli-commands.md) — load on demand.\n\n\n> Moved verbatim to [`references\u002Fdatabase-tuning-guide.md`](references\u002Fdatabase-tuning-guide.md) — load on demand.\n\n\n### Step 4: ApplyMethod (immediate vs pending-reboot)\n\nThe `ApplyMethod` controls when a parameter change takes effect:\n\n> Moved verbatim to [`references\u002Fdeployment-cli-commands.md`](references\u002Fdeployment-cli-commands.md) — load on demand.\n\n\n| ApplyMethod | Effect | Works for |\n|---|---|---|\n| `immediate` | Applies as soon as possible (typically within seconds for dynamic params) | Dynamic parameters only |\n| `pending-reboot` | Applies after the next DB instance reboot | Static AND dynamic parameters |\n\n**Rule:** always use `immediate` for dynamic parameters (unless you\nwant to batch changes at the next maintenance window). Always use\n`pending-reboot` for static parameters (it is the only option, but\nexplicitly stating it documents the reboot requirement).\n\nSetting `ApplyMethod: immediate` on a static parameter does NOT\nforce immediate application. RDS silently treats it as\n`pending-reboot`. This is a common source of confusion.\n\n### Step 5: Common PostgreSQL tuning parameters\n\n> Moved verbatim to [`references\u002Fdatabase-tuning-guide.md`](references\u002Fdatabase-tuning-guide.md) — load on demand.\n\n\n### Step 6: Common MySQL tuning parameters\n\n> Moved verbatim to [`references\u002Fdatabase-tuning-guide.md`](references\u002Fdatabase-tuning-guide.md) — load on demand.\n\n\n### Step 7: Aurora-specific parameters\n\n> Moved verbatim to [`references\u002Fdatabase-tuning-guide.md`](references\u002Fdatabase-tuning-guide.md) — load on demand.\n\n\n### Step 8: Aurora Serverless v2 capacity\n\n> Moved verbatim to [`references\u002Fdatabase-tuning-guide.md`](references\u002Fdatabase-tuning-guide.md) — load on demand.\n\n\n### Step 9: Create + associate + apply\n\n> Moved verbatim to [`references\u002Fdeployment-cli-commands.md`](references\u002Fdeployment-cli-commands.md) — load on demand.\n\n\nFor Aurora clusters, use `create-db-cluster-parameter-group` \u002F\n`modify-db-cluster-parameter-group` \u002F `modify-db-cluster`.\n\n## Workload matrix\n\n| Workload | Engine | Key parameters | Notes |\n|---|---|---|---|\n| OLTP (high-throughput) | PostgreSQL | `shared_buffers=25%`, `work_mem=8MB`, `max_connections=200`, `checkpoint_completion_target=0.9` | Use RDS Proxy for connection pooling |\n| Read-heavy analytics | PostgreSQL | `work_mem=64MB`, `maintenance_work_mem=1GB`, `effective_cache_size=75%`, `random_page_cost=1.1` | Higher work_mem for large sorts\u002Fhashes |\n| MySQL web app | MySQL | `innodb_buffer_pool_size=75%`, `max_connections=300`, `slow_query_log=1`, `long_query_time=1` | Enable slow query logging in production |\n| Aurora Serverless v2 | Aurora PG\u002FMySQL | Use formula values (`{DBInstanceClassMemory\u002FN}`), conservative `work_mem` | Never set absolute memory values |\n| Migration staging | PostgreSQL | Source DB's exact parameter values | Match source to validate query plans |\n| High-availability replica | Aurora MySQL | `aurora_enable_repl_bin_log_filter=1`, `binlog_format=ROW` | ROW format for reliable replication |\n\n## Recent AWS features (2024-2026)\n\n> Moved verbatim to [`references\u002Fadvanced-patterns.md`](references\u002Fadvanced-patterns.md) — load on demand.\n\n\n## NEVER (anti-patterns)\n\n- NEVER create a parameter group with the wrong family. The family\n  is immutable. A `postgres15` parameter group cannot attach to a\n  `postgres14` instance. Always verify the engine version before\n  creating.\n\n- NEVER set `ApplyMethod: immediate` on a static parameter and\n  assume it will apply without a reboot. RDS silently treats it as\n  `pending-reboot`. Static parameters ALWAYS require a reboot.\n  Check `ApplyType` via `DescribeDBParameters` before setting.\n\n- NEVER set absolute memory values (`shared_buffers = 6GB`) on\n  Aurora Serverless v2. The instance class changes dynamically\n  with ACU scaling — an absolute value tuned for 16 ACU causes OOM\n  at 2 ACU. Always use `{DBInstanceClassMemory\u002FN}` formula syntax.\n\n- NEVER modify a production DB parameter group without planning a\n  reboot window for static parameters. Static parameters (like\n  `shared_buffers`, `max_connections` on some engines) require a\n  reboot. Schedule during a maintenance window.\n\n- NEVER disable `autovacuum` on PostgreSQL in production. Without\n  autovacuum, dead tuples accumulate, bloat increases, and\n  performance degrades. Tune autovacuum settings\n  (`autovacuum_naptime`, `autovacuum_vacuum_threshold`) instead.\n\n- NEVER exceed `max_connections` beyond what the instance class can\n  handle. Each connection consumes memory (thread stack + work_mem +\n  sort buffers). Formula: `(RAM - shared_buffers) \u002F (work_mem × 2)`\n  gives a safe ceiling. Use RDS Proxy or PgBouncer for pooling.\n\n- NEVER set `innodb_flush_log_at_trx_commit=0` or `sync_binlog=0`\n  in production if data durability matters. These settings trade\n  crash safety for throughput — you can lose committed transactions\n  on a crash. Use `1` for both unless you explicitly accept the risk.\n\n- NEVER change a parameter group on an Aurora cluster without\n  understanding that the DBClusterParameterGroup applies to ALL\n  instances. Instance-level overrides via DBParameterGroup can\n  conflict — test the interaction in staging.\n\n- NEVER forget to associate the parameter group with the DB\n  instance after creating it. Creating the group alone has no\n  effect. Call `ModifyDBInstance` or `ModifyDBCluster`.\n\n- NEVER deviate from the checklist output format. Substituting\n  `Verdict` \u002F `**VERDICT**` \u002F `### Verdict:` for the literal\n  `VERDICT:` label silently breaks downstream deployment pipelines\n  and assertion-based evals.\n\n## Expert heuristic — choosing family, parameters, and ApplyMethod\n\n**Family — match the engine version exactly:** the family is\n`\u003Cengine>\u003Cmajor-version>` (e.g., `postgres15`, `mysql8.0`). For\nAurora, prefix with `aurora-` (e.g., `aurora-postgresql15`). Use\n`DescribeDBEngineVersions` to find the family for a specific engine\nversion. When in doubt, check the existing default group name\n(`default.postgres15`).\n\n**Parameters — start with memory and connections, then planner:**\nthe highest-impact parameters are `shared_buffers` \u002F \n`innodb_buffer_pool_size` (25-75% of RAM), `max_connections`\n(scale with instance class), `work_mem` (4-16MB per query), and\nplanner hints (`effective_cache_size`, `random_page_cost`). These\nhave more impact than micro-tuning dozens of minor parameters.\n\n**ApplyMethod — immediate for dynamic, pending-reboot for static:**\nalways check the parameter's `ApplyType` before setting\n`ApplyMethod`. Dynamic + immediate = no reboot. Static + any\n`ApplyMethod` = reboot required. When changing multiple parameters,\nbatch them in one `ModifyDBParameterGroup` call — it applies\natomically and minimizes reboot windows.\n\n**Aurora — use DBClusterParameterGroup:** Aurora clusters require\na cluster parameter group. Instance-level DBParameterGroups are\noptional overrides. Set cluster-level parameters (like\n`aurora_enable_repl_bin_log_filter`) in the cluster group. Set\ninstance-specific tuning (like `work_mem`) in the instance group.\n\n**Serverless v2 — formula values only:** never set absolute memory\nvalues. Use `{DBInstanceClassMemory\u002FN}` for all memory-related\nparameters. The formula adapts as the ACU scales. Set\n`max_connections` based on the MAX capacity, not the minimum.\n\n**Reboot planning — always flag static changes:** when the\nchecklist includes any `[✓]` item with `(static, PENDING REBOOT\nrequired)`, call out the reboot requirement in the checklist.\nStatic parameter changes are a no-op until the instance reboots.\nSchedule during a maintenance window for production.\n\n## Pre-flight safety checks (run before any provisioning CLI)\n\n- **Confirm the DB engine and version:**\n  ```bash\n  aws rds describe-db-instances --db-instance-identifier \u003Cid> \\\n    --query 'DBInstances[].{Engine:Engine,EngineVersion:EngineVersion}'\n  ```\n\n- **Confirm the parameter group family matches the engine:**\n  ```bash\n  aws rds describe-db-engine-versions --engine postgres \\\n    --query 'DBEngineVersions[].{Version:EngineVersion,Family:DBParameterGroupFamily}'\n  ```\n\n- **Confirm parameter data types and allowed values:**\n  ```bash\n  aws rds describe-db-parameters --db-parameter-group-name default.postgres15 \\\n    --query 'Parameters[?ParameterName==`shared_buffers`]'\n  ```\n\n- **Confirm the DB instance or cluster exists:**\n  ```bash\n  aws rds describe-db-instances --db-instance-identifier \u003Cid>\n  aws rds describe-db-clusters --db-cluster-identifier \u003Cid>\n  ```\n\n- **For Aurora Serverless v2, confirm the scaling configuration:**\n  ```bash\n  aws rds describe-db-clusters --db-cluster-identifier \u003Cid> \\\n    --query 'DBClusters[].ServerlessV2ScalingConfigurationInfo'\n  ```\n\n- **For existing parameter groups, capture current values for rollback:**\n  ```bash\n  aws rds describe-db-parameters --db-parameter-group-name \u003Cname> \\\n    --query 'Parameters[?Source!=`engine-default`]' \\\n    > \u002Ftmp\u002F\u003Cname>-backup.json\n  ```\n\n## Output format — MANDATORY literal labels\n\nWhen invoked with a parameter group provisioning request, your\nENTIRE response MUST be the checklist block below. The labels are\n**case-sensitive all-caps keywords** — write them EXACTLY as shown.\nDo NOT write a preamble. Start with `GROUP:` and stop after the\n`VERIFICATION_COMMANDS:` block.\n\n```text\nGROUP: \u003Cparameter-group-name>\nVERDICT: READY_TO_DEPLOY | PREREQUISITES_MISSING\nCHECKLIST:\n  [✓]      Family — \u003Cpostgres15 | mysql8.0 | aurora-postgresql15 | ...>\n  [✓]      Type — \u003CDBParameterGroup | DBClusterParameterGroup>\n  [✓]      \u003Cparameter-name> — \u003Cvalue> (\u003Cdynamic|static>, \u003Cimmediate|pending-reboot>)\n  [✓]      ... (repeat for each parameter)\n  [✓]      Association — \u003Cdb-instance-id | db-cluster-id | pending>\n  [✓]      Reboot required — \u003Cyes (static params changed) | no (dynamic only)>\n  [✓]      Tags — \u003Ckey=value pairs>\nVERIFICATION_COMMANDS:\n  aws rds describe-db-parameters --db-parameter-group-name \u003Cname>\n  aws rds describe-db-instances --db-instance-identifier \u003Cid>\n  aws rds describe-pending-maintenance-actions --db-instance-identifier \u003Cid>\n```\n\n**Status marker semantics:**\n- `[✓]` — configuration is applied and verified.\n- `[✗]` — configuration is NOT applied or is misconfigured. Cite\n  the gap.\n- `[OPTIONAL]` — recommended but not required for the workload type.\n- `[INPUT NEEDED]` — a prerequisite value is missing (engine\n  version, DB instance ID, parameter group family) and the operator\n  must provide it before provisioning can proceed.\n\n**PREREQUISITES_MISSING verdict:** if any REQUIRED prerequisite is\nmissing (DB engine version to determine the family, DB instance\nidentifier for association), the verdict is\n`PREREQUISITES_MISSING` with each gap listed. The checklist shows\nthe target configuration with `[INPUT NEEDED]` or `[✗]` for unmet\nprerequisites.\n\n## Edge-case handling\n\n> Moved verbatim to [`references\u002Fadvanced-patterns.md`](references\u002Fadvanced-patterns.md) — load on demand.\n\n\n## References (load on demand)\n\n- [references\u002Fdeployment-cli-commands.md](references\u002Fdeployment-cli-commands.md) — static\u002Fdynamic parameter check, ApplyMethod payload, and the full create + modify + associate + reboot CLI sequence.\n- [references\u002Fdatabase-tuning-guide.md](references\u002Fdatabase-tuning-guide.md) — static\u002Fdynamic parameter tables, PostgreSQL\u002FMySQL\u002FAurora tuning tables, and Aurora Serverless v2 capacity interactions.\n- [references\u002Fadvanced-patterns.md](references\u002Fadvanced-patterns.md) — reasoning-framework constraints, family selection tables, recent AWS features, edge-case handling.\n\n## Domain\n\nAWS CloudOps \u002F RDS Database Parameter Group Provisioning.\n\n## AWS documentation\n\n- **Amazon RDS User Guide** — https:\u002F\u002Fdocs.aws.amazon.com\u002FAmazonRDS\u002Flatest\u002FUserGuide\u002FUSER_WorkingWithParamGroups.html\n- **RDS Parameter Groups** — https:\u002F\u002Fdocs.aws.amazon.com\u002FAmazonRDS\u002Flatest\u002FUserGuide\u002FUSER_WorkingWithDBInstanceParamGroups.html\n- **PostgreSQL Parameters on RDS** — https:\u002F\u002Fdocs.aws.amazon.com\u002FAmazonRDS\u002Flatest\u002FUserGuide\u002FAppendix.PostgreSQL.CommonDBATasks.Parameters.html\n- **MySQL Parameters on RDS** — https:\u002F\u002Fdocs.aws.amazon.com\u002FAmazonRDS\u002Flatest\u002FUserGuide\u002FAppendix.MySQL.CommonDBATasks.Parameters.html\n- **Aurora Serverless v2** — https:\u002F\u002Fdocs.aws.amazon.com\u002FAmazonRDS\u002Flatest\u002FAuroraUserGuide\u002Faurora-serverless-v2.setting-capacity.html\n- **RDS CLI Reference** — https:\u002F\u002Fdocs.aws.amazon.com\u002Fcli\u002Flatest\u002Freference\u002Frds\u002F\n\n## References\n\n- `references\u002Fdeployment-cli-commands.md` — full copy-pasteable CLI\n  command sequence for all 9 provisioning steps, including parameter\n  group creation, parameter modification (static and dynamic),\n  association with DB instances and Aurora clusters, reboot\n  procedures, Aurora Serverless v2 capacity configuration, and\n  Terraform `aws_db_parameter_group` \u002F\n  `aws_rds_cluster_parameter_group` resource equivalents.\n\n- `references\u002Fdatabase-tuning-guide.md` — deep reference on\n  PostgreSQL and MySQL parameter tuning (memory sizing formulas,\n  connection pooling, autovacuum, InnoDB internals), Aurora-specific\n  parameters, Aurora Serverless v2 capacity interactions, and\n  static-vs-dynamic parameter classification.\n",{"name":5,"license":15,"metadata":24,"description":7,"compatibility":41},{"tags":25,"phase":26,"author":27,"domain":28,"family":29,"version":30,"keywords":31,"task_type":32,"complexity":33,"entry_point":34,"skill_class":35,"when_to_use":36,"dependencies":37,"requires_llm":38,"verdict_shape":39,"lifecycle_status":40,"supports_pipeline":38},"aws, rds, aurora, databases, cloudops, deploy, parameter-group, postgres, mysql","1","Jacky Chan — AWS Community Builder","aws-cloudops","Databases","0.1.0","aws, rds, aurora, databases, cloudops, deploy, provisioning, parameter-group, postgres, mysql, tuning, static-dynamic, apply-method, aurora-serverless-v2","deploy","high","false","capability","Invoke when the user wants to create a new RDS DB parameter group or DB cluster parameter group, tune PostgreSQL or MySQL parameters, configure Aurora-specific parameters, set up Aurora Serverless v2 capacity settings, or associate a parameter group with a DB instance or Aurora cluster. Do NOT invoke for option groups (use the option-group skill), for DB instance class changes (use the instance-deployer skill), or for RDS Proxy configuration.","aws-orchestrator","true","READY_TO_DEPLOY | PREREQUISITES_MISSING","active","Requires an LLM agent runtime (Claude Code, Cursor, Windsurf, Codex, Gemini). For live deployment: AWS CLI v2 with rds access. Works with Terraform aws_db_parameter_group \u002F aws_rds_cluster_parameter_group resources, CloudFormation AWS::RDS::DBParameterGroup \u002F AWS::RDS::DBClusterParameterGroup, and SAM templates.","main","eeace51bd5dd1db2030729d83eeab988861553aa","skills\u002Frds-parameter-group-deployer",0,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills","https:\u002F\u002Fgithub.com\u002Fjhkchan","CTO & Co-Founder @Beever-AI  & @votee. CAISP. AWS Community Builder. Organizer@GDGCloudHK. MongoDB Champion. Technopreneur + Infornographer.","2026-09-24 08:54:10",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add jhkchan\u002Faws-agent-skills --skill rds-parameter-group-deployer",{"tool":56,"command":57},"bunx","bunx skills add jhkchan\u002Faws-agent-skills --skill rds-parameter-group-deployer",{"tool":59,"command":60},"pnpm","pnpm dlx skills add jhkchan\u002Faws-agent-skills --skill rds-parameter-group-deployer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002FSKILL.md",true,[64,70,74,78,82,86,90,94,98,102,106,110,113,117,121,125,129,133],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"eval\u002Ftest-cases.yaml","REFERENCE","参考文档",6883,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Feval\u002Ftest-cases.yaml",{"path":71,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":72,"sourceHtmlUrl":73},"evals\u002Fbaselines\u002Faurora-serverless-v2-capacity.md",774,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Fevals\u002Fbaselines\u002Faurora-serverless-v2-capacity.md",{"path":75,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":76,"sourceHtmlUrl":77},"evals\u002Fbaselines\u002Fmissing-db-family.md",677,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Fevals\u002Fbaselines\u002Fmissing-db-family.md",{"path":79,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":80,"sourceHtmlUrl":81},"evals\u002Fbaselines\u002Fmysql8-buffer-pool-tuning.md",734,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Fevals\u002Fbaselines\u002Fmysql8-buffer-pool-tuning.md",{"path":83,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":84,"sourceHtmlUrl":85},"evals\u002Fbaselines\u002Fpostgres15-common-tuning.md",806,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Fevals\u002Fbaselines\u002Fpostgres15-common-tuning.md",{"path":87,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":88,"sourceHtmlUrl":89},"evals\u002Fbaselines\u002Fstatic-param-reboot-warning.md",811,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Fevals\u002Fbaselines\u002Fstatic-param-reboot-warning.md",{"path":91,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":92,"sourceHtmlUrl":93},"evals\u002Feval_config.yaml",1702,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Fevals\u002Feval_config.yaml",{"path":95,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":96,"sourceHtmlUrl":97},"evals\u002Fevals.json",13750,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Fevals\u002Fevals.json",{"path":99,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":100,"sourceHtmlUrl":101},"evals\u002Fprompts\u002Faurora-serverless-v2-capacity.md",770,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Fevals\u002Fprompts\u002Faurora-serverless-v2-capacity.md",{"path":103,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":104,"sourceHtmlUrl":105},"evals\u002Fprompts\u002Fmissing-db-family.md",456,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Fevals\u002Fprompts\u002Fmissing-db-family.md",{"path":107,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":108,"sourceHtmlUrl":109},"evals\u002Fprompts\u002Fmysql8-buffer-pool-tuning.md",679,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Fevals\u002Fprompts\u002Fmysql8-buffer-pool-tuning.md",{"path":111,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":88,"sourceHtmlUrl":112},"evals\u002Fprompts\u002Fpostgres15-common-tuning.md","https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Fevals\u002Fprompts\u002Fpostgres15-common-tuning.md",{"path":114,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":115,"sourceHtmlUrl":116},"evals\u002Fprompts\u002Fstatic-param-reboot-warning.md",681,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Fevals\u002Fprompts\u002Fstatic-param-reboot-warning.md",{"path":118,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":119,"sourceHtmlUrl":120},"example\u002FREADME.md",7302,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Fexample\u002FREADME.md",{"path":122,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":123,"sourceHtmlUrl":124},"references\u002Fadvanced-patterns.md",6428,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Freferences\u002Fadvanced-patterns.md",{"path":126,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":127,"sourceHtmlUrl":128},"references\u002Fdatabase-tuning-guide.md",17970,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Freferences\u002Fdatabase-tuning-guide.md",{"path":130,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":131,"sourceHtmlUrl":132},"references\u002Fdeployment-cli-commands.md",14148,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Freferences\u002Fdeployment-cli-commands.md",{"path":134,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":135,"sourceHtmlUrl":136},"skill.usf.yaml",4370,"https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frds-parameter-group-deployer\u002Fskill.usf.yaml",[138,145,152,159,166,173],{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":144,"publishedAt":19},"01M7ADVD60X4PCAPKSE58P9NDC","xray-tracing-deployer","Deploys AWS X-Ray distributed tracing with production-grade configuration: X-Ray daemon deployment (EC2 systemd, ECS sidecar, EKS DaemonSet, Lambda built-in), SDK instrumentation (Java, Python, Node.js, Go, .NET) with annotations and metadata, sampling rules (default reservoir + rate vs custom rules with URL \u002F method \u002F service-name predicates), service map generation, trace query and retrieval, groups and insights, CloudWatch ServiceLens integration, IAM permissions (PutTraceSegments, GetSamplingRules), and latest features (Lambda Powertools tracing, OpenTelemetry \u002F ADOT Collector support, W3C trace context). Emits a READY_TO_DEPLOY checklist with every configuration item verified. Use when enabling X-Ray on a new application, adding tracing to ECS \u002F EKS \u002F Lambda, validating a sampling configuration, or generating daemon deployment CLI and IaC templates. Triggers: X-Ray, distributed tracing, X-Ray daemon, sampling rules, service map, X-Ray SDK, OpenTelemetry, ADOT, Lambda Powertools, CloudWatch ServiceLens.","https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fxray-tracing-deployer\u002FSKILL.md",[],[],{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":19},"01M7ADTVJ7DCBM9CB1FY51GH7J","wellarchitected-workload-auditor","Audits AWS Well-Architected Tool workloads for review staleness, per-pillar high-risk issue counts, milestone tracking gaps, and remediation plan completeness. Emits a deterministic verdict (STALE_REVIEW | HIGH_RISK | CONFIG_GAP | OK) per workload with per-pillar risk breakdown, milestone trend analysis, and specific remediation. Use when reviewing Well-Architected workloads, checking WA review freshness, auditing high-risk issues per pillar, validating milestone coverage, or tracking remediation plans.","https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwellarchitected-workload-auditor\u002FSKILL.md",[],[],{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":19},"01M7ADT59G6FTTNZYHT2QRPNNP","wellarchitected-review-operator","Operates AWS Well-Architected Tool reviews end-to-end — creates workloads, runs pillar reviews (operational excellence, security, reliability, performance, cost optimization, sustainability, Prosperity), answers questions with risk-tier rationale, generates reports and improvement plans, creates milestones, and integrates with Trusted Advisor and Well-Architected Labs. Runs deterministic pre-checks (workload existence, lens availability, pillar coverage), emits the exact update-answer \u002F get-consolidated-report CLI behind a CONFIRM gate, and verifies risk-tier transitions. Emits READY | BLOCKED | COMPLETED. Use when creating a workload, answering pillar questions, generating an improvement plan, creating a milestone, or integrating with Trusted Advisor. Triggers: well-architected tool, well architected review, workload review, pillar, operational excellence, security, reliability, performance, cost optimization, sustainability, prosperity, improvement plan, milestone, trusted advisor.","https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwellarchitected-review-operator\u002FSKILL.md",[],[],{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":19},"01M7ADSH5JA9QHNPPHQCD7EVA7","wafv2-web-acl-deployer","Provisions AWS WAFv2 Web ACLs with correct production defaults: scope selection (CLOUDFRONT vs REGIONAL), managed rule groups (AWSManagedRulesCommonRuleSet, SQLiRuleSet, LinuxRuleSet, WindowsRuleSet, IPReputationList, BotControlRuleSet, AmazonIpReputationList, ATP), custom rules (byte match, IP set, regex pattern, geo match, size constraint, rate-based), rule priority ordering, logging destinations (Kinesis Firehose, CloudWatch Logs, S3), resource association (ALB, API Gateway, CloudFront), rate-based rules with aggregate keys (IP, forwarded IP), Challenge and CAPTCHA actions, and account takeover prevention. Emits a READY_TO_DEPLOY checklist. Use when creating a Web ACL, attaching managed rules, configuring rate limiting, enabling WAF logging, associating a Web ACL with an ALB\u002FAPI Gateway\u002FCloudFront, or configuring CAPTCHA\u002FChallenge actions. Triggers: create WAF Web ACL, WAFv2, managed rule groups, WAF rate limiting, WAF logging, WAF CAPTCHA, WAF Challenge action, bot control, ATP managed rules.","https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwafv2-web-acl-deployer\u002FSKILL.md",[],[],{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":19},"01M7ADRYFAT8R73FBNCHRC573X","wafv2-web-acl-auditor","Audits AWS WAFv2 Web ACL configurations to determine whether the ACL provides effective protection: default-action posture (Allow vs Block), managed-rule-group coverage gaps, rule effectiveness (BLOCK vs COUNT, shadow\u002Fbypass rules, stale exclusions), rate-based rule correctness, logging and visibility configuration, and text-transformation bypass vectors. Emits a deterministic verdict per Web ACL. Use when reviewing a WAFv2 Web ACL for security posture, checking managed-rule coverage, validating rate-limit configuration, auditing WAF logging, or hardening a WAF before production deployment. Triggers: WAF, WAFv2, Web ACL, managed rule group, AWSManagedRules, rate-based rule, CAPTCHA, Challenge, OverrideAction, Count mode, forwarded IP, Bot Control, ATP, text transformation, WAF logging, WAF visibility, OWASP, SQLi, XSS, RFI.","https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwafv2-web-acl-auditor\u002FSKILL.md",[],[],{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":19},"01M7ADR8W7G72JX4KFGN03QK8Q","waf-rule-deployer","Provisions AWS WAFv2 rule sets with production defaults: Web ACL creation (CloudFront scope in us-east-1 vs Regional scope), rule groups (managed vs custom) with capacity planning in WCU (Web ACL Capacity Units, 1500 default per ACL), managed rule groups (AWSManagedRulesCommonRuleSet, AWSManagedRulesSQLiRuleSet, AWSManagedRulesAmazonIpReputationList, AWSManagedRulesLinuxRuleSet, AWSManagedRulesWindowsRuleSet, AWSManagedRulesUnixRuleSet), custom rules (byte-match, regex pattern set, geo-match, rate-based), IP set and regex pattern set resources, rule priority ordering (lowest number evaluated first), action types (allow, block, count, CAPTCHA, Challenge), bot control managed rule group, account takeover. Triggers: create WAF rule, WAF managed rule group, WAF custom rule, WAF byte match, WAF geo match, WAF rate based rule, WAF IP set, WAF regex pattern set, WAF WCU budget, WAF CloudFront ACL, WAF logging Kinesis Firehose, WAF bot control, WAF ATP, WAF label matching, WAF Challenge action, WAF CAPTCHA.","https:\u002F\u002Fgithub.com\u002Fjhkchan\u002Faws-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwaf-rule-deployer\u002FSKILL.md",[],[]]