alibaba-live-rds-polardb-mutation-guard

Name: alibaba-live-rds-polardb-mutation-guard
Author: Raishin

17stars3forks

How to install alibaba-live-rds-polardb-mutation-guard?

raishin/vanguard-frontier-agentic/alibaba-live-rds-polardb-mutation-guard

$npx -y skills add Raishin/vanguard-frontier-agentic --skill alibaba-live-rds-polardb-mutation-guard

Installs into the current project.

Summary

Gate RDS/PolarDB instance deletion, spec downgrade, and backup policy removal — database deletion without verified backup is permanently destructive.

Files · 1

View on GitHub

SKILL.md

1	# Alibaba Cloud Live RDS/PolarDB Mutation Guard
2
3	## Purpose
4
5	Act as the guarded live Alibaba Cloud operator for alibaba-live-rds-polardb-mutation-guard work. Gate every RDS or PolarDB instance deletion, spec downgrade, and backup policy removal with a complete backup verification and explicit operator approval. Treat database deletion without verified backup as an irreversible data-loss event.
6
7	## When to Use
8
9	Use this skill when:
10
11	- An RDS or PolarDB instance deletion is being requested
12	- A spec downgrade (instance type reduction) is being planned for an RDS or PolarDB instance
13	- A backup policy is being removed or modified to reduce retention period or disable automated backups
14	- An operator needs to verify backup status and restore readiness before any destructive database operation
15	- A database endpoint or high-availability configuration change is being made during business hours
16
17	## When NOT to Use
18
19	Do not use this skill when:
20
21	- The task is a read-only RDS/PolarDB audit with no mutation intent
22	- The task involves only SQL query execution or data-level operations
23	- The task involves creating a new RDS/PolarDB instance (no existing data at risk)
24	- The task involves minor parameter group changes that do not affect availability or data retention
25
26	## Key Risk Facts
27
28	- RDS/PolarDB instance deletion removes all instance data, parameter groups, and backups associated with the instance immediately upon deletion (backups may have a brief retention window depending on configuration — verify explicitly). This action cannot be reversed.
29	- Spec downgrade during peak hours causes connection resets and query timeouts during the instance resize window. Downgrading to an instance type that cannot handle current load causes cascading failures in dependent applications.
30	- Backup policy removal leaves the database unprotected for the period between the last backup and the next backup cycle. If the instance fails during this window, data from that period is lost.
31	- All three actions require the 6-step live-guard gate: (1) identity confirm, (2) backup verification, (3) blast radius assessment, (4) explicit approval, (5) execution, (6) post-change verification.
32
33	## Pre-Flight Checklist
34
35	Before executing any RDS or PolarDB mutation, verify all of the following:
36
37	1. Instance identity confirmed — confirm the exact instance ID, region, engine type (MySQL/PG/SQL Server/MariaDB for RDS; MySQL/PG/Oracle for PolarDB), and account. Run `aliyun rds DescribeDBInstances` or check PolarDB console to confirm.
38	2. Backup existence verified — confirm a recent automated or manual backup exists. Check: backup creation time, backup status (Completed), backup size, and retention period. A backup that cannot be listed is not a verified backup.
39	3. Restore tested or documented — for critical instances, verify the backup is restorable by checking the last restore test date. If never tested, flag as high risk.
40	4. Current spec and load assessed — for downgrade: compare current CPU/memory/IOPS utilization to the target spec limits. If current utilization is within 20% of target spec limits, the downgrade is high risk.
41	5. Blast radius assessed — which applications depend on this instance? what is the connection string? what downstream services will fail during the maintenance window?
42	6. Change window confirmed — spec downgrades and deletions should be executed during a planned maintenance window with application owners notified.
43
44	## Required Confirmation
45
46	The operator must explicitly state all of the following before any mutation is executed:
47
48	- "I confirm the instance is `<INSTANCE_ID>` of type `<ENGINE>` in region `<REGION>` in account `<ACCOUNT_ID>`."
49	- "I have verified a backup exists: backup ID `<BACKUP_ID>`, created at `<TIMESTAMP>`, status `<Completed>`."
50	- "I have assessed the blast radius: `<DESCRIPTION OF DEPENDENT APPLICATIONS>`."
51	- "I understand that instance deletion is permanent and all data will be irrecoverable without a verified backup."
52	- "I approve this `<deletion / spec downgrade / backup policy change>`."
53	- For deletion: "I confirm the backup is restorable and all dependent applications have been notified."
54	- For spec downgrade: "I confirm the current peak utilization is `<RATE>%` of the target spec and the change window is `<WINDOW>`."
55
56	## Execution Steps
57
58	1. Capture pre-change instance state: instance metadata, current spec, backup list.
59	2. Verify backup status and restore readiness.
60	3. Present the planned action, backup verification results, and blast radius to the operator for explicit approval.
61	4. Execute the mutation:
62	- Delete instance: `ali

People who liked this also viewed

6 picks

Type

alibaba-live-rds-polardb-mutation-guard

17stars3forks

View on GitHub

How to install alibaba-live-rds-polardb-mutation-guard?

raishin/vanguard-frontier-agentic/alibaba-live-rds-polardb-mutation-guard

$npx -y skills add Raishin/vanguard-frontier-agentic --skill alibaba-live-rds-polardb-mutation-guard

Installs into the current project.

Summary

Gate RDS/PolarDB instance deletion, spec downgrade, and backup policy removal — database deletion without verified backup is permanently destructive.

Files · 1

View on GitHub

SKILL.md

1	# Alibaba Cloud Live RDS/PolarDB Mutation Guard
2
3	## Purpose
4
5	Act as the guarded live Alibaba Cloud operator for alibaba-live-rds-polardb-mutation-guard work. Gate every RDS or PolarDB instance deletion, spec downgrade, and backup policy removal with a complete backup verification and explicit operator approval. Treat database deletion without verified backup as an irreversible data-loss event.
6
7	## When to Use
8
9	Use this skill when:
10
11	- An RDS or PolarDB instance deletion is being requested
12	- A spec downgrade (instance type reduction) is being planned for an RDS or PolarDB instance
13	- A backup policy is being removed or modified to reduce retention period or disable automated backups
14	- An operator needs to verify backup status and restore readiness before any destructive database operation
15	- A database endpoint or high-availability configuration change is being made during business hours
16
17	## When NOT to Use
18
19	Do not use this skill when:
20
21	- The task is a read-only RDS/PolarDB audit with no mutation intent
22	- The task involves only SQL query execution or data-level operations
23	- The task involves creating a new RDS/PolarDB instance (no existing data at risk)
24	- The task involves minor parameter group changes that do not affect availability or data retention
25
26	## Key Risk Facts
27
28	- RDS/PolarDB instance deletion removes all instance data, parameter groups, and backups associated with the instance immediately upon deletion (backups may have a brief retention window depending on configuration — verify explicitly). This action cannot be reversed.
29	- Spec downgrade during peak hours causes connection resets and query timeouts during the instance resize window. Downgrading to an instance type that cannot handle current load causes cascading failures in dependent applications.
30	- Backup policy removal leaves the database unprotected for the period between the last backup and the next backup cycle. If the instance fails during this window, data from that period is lost.
31	- All three actions require the 6-step live-guard gate: (1) identity confirm, (2) backup verification, (3) blast radius assessment, (4) explicit approval, (5) execution, (6) post-change verification.
32
33	## Pre-Flight Checklist
34
35	Before executing any RDS or PolarDB mutation, verify all of the following:
36
37	1. Instance identity confirmed — confirm the exact instance ID, region, engine type (MySQL/PG/SQL Server/MariaDB for RDS; MySQL/PG/Oracle for PolarDB), and account. Run `aliyun rds DescribeDBInstances` or check PolarDB console to confirm.
38	2. Backup existence verified — confirm a recent automated or manual backup exists. Check: backup creation time, backup status (Completed), backup size, and retention period. A backup that cannot be listed is not a verified backup.
39	3. Restore tested or documented — for critical instances, verify the backup is restorable by checking the last restore test date. If never tested, flag as high risk.
40	4. Current spec and load assessed — for downgrade: compare current CPU/memory/IOPS utilization to the target spec limits. If current utilization is within 20% of target spec limits, the downgrade is high risk.
41	5. Blast radius assessed — which applications depend on this instance? what is the connection string? what downstream services will fail during the maintenance window?
42	6. Change window confirmed — spec downgrades and deletions should be executed during a planned maintenance window with application owners notified.
43
44	## Required Confirmation
45
46	The operator must explicitly state all of the following before any mutation is executed:
47
48	- "I confirm the instance is `<INSTANCE_ID>` of type `<ENGINE>` in region `<REGION>` in account `<ACCOUNT_ID>`."
49	- "I have verified a backup exists: backup ID `<BACKUP_ID>`, created at `<TIMESTAMP>`, status `<Completed>`."
50	- "I have assessed the blast radius: `<DESCRIPTION OF DEPENDENT APPLICATIONS>`."
51	- "I understand that instance deletion is permanent and all data will be irrecoverable without a verified backup."
52	- "I approve this `<deletion / spec downgrade / backup policy change>`."
53	- For deletion: "I confirm the backup is restorable and all dependent applications have been notified."
54	- For spec downgrade: "I confirm the current peak utilization is `<RATE>%` of the target spec and the change window is `<WINDOW>`."
55
56	## Execution Steps
57
58	1. Capture pre-change instance state: instance metadata, current spec, backup list.
59	2. Verify backup status and restore readiness.
60	3. Present the planned action, backup verification results, and blast radius to the operator for explicit approval.
61	4. Execute the mutation:
62	- Delete instance: `ali

People who liked this also viewed

6 picks

Type