@raishin/vanguard-frontier-agentic 1.4.0 → 1.6.0

package/skills/alibaba/alibaba-live-ram-policy-change-guard/references/workflow-and-output.md

@@ -0,0 +1,110 @@
+# Workflow and Output — Alibaba Cloud Live RAM Policy Change Guard
+
+## Step-by-Step Workflow
+
+### Phase 1: Identity and Scope Confirmation
+
+1. Confirm the active RAM principal and account ID:
+   ```
+   aliyun ram GetAccountAlias
+   aliyun sts GetCallerIdentity
+   ```
+2. List current policies attached to the target user or role:
+   ```
+   aliyun ram ListPoliciesForRole --RoleName <ROLE_NAME>
+   aliyun ram ListPoliciesForUser --UserName <USER_NAME>
+   ```
+3. Describe the specific policy to be changed:
+   ```
+   aliyun ram GetPolicy --PolicyType Custom --PolicyName <POLICY_NAME>
+   aliyun ram GetPolicyVersion --PolicyType Custom --PolicyName <POLICY_NAME> --VersionId <VERSION_ID>
+   ```
+
+### Phase 2: Blast-Radius Assessment
+
+4. Determine the scope of the change:
+   - RAM user/role attachment: single principal affected.
+   - AdministratorAccess assignment: entire account affected — highest risk.
+   - Control Policy change: all member accounts in the target OU affected.
+5. List all roles and users currently attached to the policy being modified or deleted:
+   ```
+   aliyun ram ListEntitiesForPolicy --PolicyType Custom --PolicyName <POLICY_NAME>
+   ```
+6. Assess active STS tokens: identify services or applications known to use STS tokens derived from the target role or policy.
+
+### Phase 3: Approval Gate
+
+7. Present all evidence to the operator: account ID, principal, current policy inventory, proposed change, blast-radius assessment, STS token impact.
+8. Require explicit written approval including acknowledgment of blast-radius and STS token impact.
+9. Do not proceed until approval is received.
+
+### Phase 4: Execution
+
+10. Execute the approved mutation:
+    - Attach policy to role:
+      ```
+      aliyun ram AttachPolicyToRole --PolicyType System --PolicyName AdministratorAccess --RoleName <ROLE>
+      ```
+    - Detach policy from role:
+      ```
+      aliyun ram DetachPolicyFromRole --PolicyType Custom --PolicyName <NAME> --RoleName <ROLE>
+      ```
+    - Delete custom policy (only when no entity is attached):
+      ```
+      aliyun ram DeletePolicy --PolicyName <NAME>
+      ```
+    - Create new policy version:
+      ```
+      aliyun ram CreatePolicyVersion --PolicyName <NAME> --PolicyDocument <DOCUMENT> --SetAsDefault true
+      ```
+11. Capture post-change inventory snapshot.
+
+### Phase 5: Post-Change Verification
+
+12. Confirm policy list reflects intended change:
+    ```
+    aliyun ram ListPoliciesForRole --RoleName <ROLE_NAME>
+    ```
+13. Test access for the affected principal using a read-only operation scoped to the new policy.
+14. Check ActionTrail for the change event: query `ram` service events for the mutation.
+
+## Expected Output Format
+
+The agent response for a RAM policy change operation must include:
+
+```
+ACCOUNT IDENTITY
+  Account ID:     <account-id>
+  Active Principal: <ram-user-arn / role-arn>
+
+POLICY/ROLE INVENTORY
+  Target:         <RAM user / role name>
+  Current Policies: [list]
+
+PROPOSED CHANGE
+  Action:         <ATTACH / DETACH / CREATE / DELETE / VERSION_UPDATE>
+  Policy Name:    <policy-name>
+  Policy Type:    <System / Custom>
+  Blast Radius:   <single principal / entire account / OU scope>
+
+STS TOKEN IMPACT
+  Active Sessions: [NONE KNOWN | <description of services at risk>]
+  Impact:          [NONE | SERVICES MAY FAIL ON NEXT CALL]
+
+APPROVAL STATUS
+  Operator:       <identity>
+  Approved:       [YES / NO / PENDING]
+  Blast radius acknowledged: [YES / NO]
+
+ACTION
+  [BLOCKED — reason] OR [EXECUTING] OR [COMPLETE]
+
+ROLLBACK POSTURE
+  [REVERSIBLE — detach policy to restore]
+  OR
+  [NOT REVERSIBLE — policy deleted; re-creation from backup required]
+
+VERIFICATION
+  Post-change policy list: [attached / detached as intended]
+  ActionTrail event:       [logged / not yet confirmed]
+```

package/skills/alibaba/alibaba-live-rds-polardb-mutation-guard/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: alibaba-live-rds-polardb-mutation-guard
+description: Gate RDS/PolarDB instance deletion, spec downgrade, and backup policy removal — database deletion without verified backup is permanently destructive.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-08"
+  category: database
+---
+
+# Alibaba Cloud Live RDS/PolarDB Mutation Guard
+
+## Purpose
+
+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.
+
+## When to Use
+
+Use this skill when:
+
+- An RDS or PolarDB instance deletion is being requested
+- A spec downgrade (instance type reduction) is being planned for an RDS or PolarDB instance
+- A backup policy is being removed or modified to reduce retention period or disable automated backups
+- An operator needs to verify backup status and restore readiness before any destructive database operation
+- A database endpoint or high-availability configuration change is being made during business hours
+
+## When NOT to Use
+
+Do not use this skill when:
+
+- The task is a read-only RDS/PolarDB audit with no mutation intent
+- The task involves only SQL query execution or data-level operations
+- The task involves creating a new RDS/PolarDB instance (no existing data at risk)
+- The task involves minor parameter group changes that do not affect availability or data retention
+
+## Key Risk Facts
+
+- **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.
+- **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.
+- **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.
+- **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.
+
+## Pre-Flight Checklist
+
+Before executing any RDS or PolarDB mutation, verify all of the following:
+
+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.
+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.
+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.
+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.
+5. **Blast radius assessed** — which applications depend on this instance? what is the connection string? what downstream services will fail during the maintenance window?
+6. **Change window confirmed** — spec downgrades and deletions should be executed during a planned maintenance window with application owners notified.
+
+## Required Confirmation
+
+The operator must explicitly state all of the following before any mutation is executed:
+
+- "I confirm the instance is `<INSTANCE_ID>` of type `<ENGINE>` in region `<REGION>` in account `<ACCOUNT_ID>`."
+- "I have verified a backup exists: backup ID `<BACKUP_ID>`, created at `<TIMESTAMP>`, status `<Completed>`."
+- "I have assessed the blast radius: `<DESCRIPTION OF DEPENDENT APPLICATIONS>`."
+- "I understand that instance deletion is permanent and all data will be irrecoverable without a verified backup."
+- "I approve this `<deletion / spec downgrade / backup policy change>`."
+- For deletion: "I confirm the backup is restorable and all dependent applications have been notified."
+- For spec downgrade: "I confirm the current peak utilization is `<RATE>%` of the target spec and the change window is `<WINDOW>`."
+
+## Execution Steps
+
+1. Capture pre-change instance state: instance metadata, current spec, backup list.
+2. Verify backup status and restore readiness.
+3. Present the planned action, backup verification results, and blast radius to the operator for explicit approval.
+4. Execute the mutation:
+   - Delete instance: `aliyun rds DeleteDBInstance --DBInstanceId <ID>` or PolarDB equivalent.
+   - Spec downgrade: `aliyun rds ModifyDBInstanceSpec` or PolarDB `ModifyDBNodeClass` — schedule during maintenance window.
+   - Backup policy change: `aliyun rds ModifyBackupPolicy` or PolarDB equivalent.
+5. Confirm the action is completed and document the result.
+
+## Rollback Procedure
+
+- **Backup policy change** (reversible): Restore the previous backup policy settings immediately.
+- **Spec downgrade** (reversible): Re-upgrade to the previous spec via `aliyun rds ModifyDBInstanceSpec`. Note: re-upgrade takes time and a connection reset occurs again.
+- **Instance deletion** (NOT reversible without backup): If a backup exists, restore from backup to a new instance. Restoration takes time proportional to database size. The original endpoint is gone — applications must be reconfigured to the new instance endpoint.
+- **Instance deletion without backup** (NOT reversible): There is no recovery path. Contact Alibaba Cloud Support immediately — recovery is not guaranteed.
+
+## Post-Change Verification
+
+1. For deletion: confirm instance is removed from the console and DNS no longer resolves.
+2. For spec downgrade: confirm the new instance spec is active and monitor CPU/memory/IOPS metrics for the first 30 minutes.
+3. For backup policy change: confirm the new policy is active and the next backup is scheduled.
+4. Check ActionTrail for the database mutation event.
+5. Monitor CloudMonitor for application-level connection errors or latency spikes.
+
+## Response Shape
+
+1. Instance ID, engine type, region, and account confirmed
+2. Backup existence and restore readiness verified
+3. Blast radius and dependent application assessment
+4. Change window and load assessment (for spec downgrade)
+5. Operator confirmation received
+6. Execution confirmation
+7. Post-change monitoring results

package/skills/alibaba/alibaba-live-rds-polardb-mutation-guard/metadata.json

@@ -0,0 +1,18 @@
+{
+  "id": "alibaba-live-rds-polardb-mutation-guard",
+  "name": "Alibaba Cloud Live RDS/PolarDB Mutation Guard",
+  "version": "0.1.0",
+  "type": "skill",
+  "provider": "alibaba",
+  "harnesses": ["codex","copilot","claude-code","cursor","gemini","kiro"],
+  "summary": "Gate RDS/PolarDB instance deletion, spec downgrade, and backup policy removal — database deletion without verified backup is permanently destructive.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.alibabacloud.com/help/en/rds",
+    "https://www.alibabacloud.com/help/en/polardb"
+  ],
+  "security_notes": "Database deletion is irreversible without backup. Must verify backup exists and is restorable before allowing any deletion. 6-step gate required.",
+  "last_verified": "2026-05-08",
+  "path": "skills/alibaba/alibaba-live-rds-polardb-mutation-guard",
+  "author": "github: Raishin"
+}

package/skills/alibaba/alibaba-live-rds-polardb-mutation-guard/references/official-sources.md

@@ -0,0 +1,14 @@
+# Official sources
+
+Use this reference only when you need source grounding for Alibaba Cloud RDS or PolarDB service behavior or the detailed source list.
+
+## Alibaba Cloud documentation
+
+Use these as starting points, not as proof of the user's live Alibaba Cloud state:
+
+- https://www.alibabacloud.com/help/en/rds
+- https://www.alibabacloud.com/help/en/polardb
+
+## Grounding rule
+
+If live Alibaba Cloud tooling is unavailable, say: "I can't query live state here, so I'm falling back to official Alibaba Cloud docs." Then fall back to these sources and sanitized user evidence.

package/skills/alibaba/alibaba-live-rds-polardb-mutation-guard/references/workflow-and-output.md

@@ -0,0 +1,35 @@
+# Workflow and output contract
+
+Use this reference only when executing the full live RDS/PolarDB mutation gate — instance deletion, spec downgrade, or backup policy removal.
+
+## Database mutation guard areas to check
+
+- Instance identity: instance ID, engine type, region, account confirmed
+- Backup verification: most recent backup ID, creation time, status (Completed), retention period, restore test history
+- Spec downgrade risk: current CPU/memory/IOPS utilization vs. target spec limits; 20% headroom rule
+- Blast radius: dependent applications, connection strings, downstream services, maintenance window notification
+- Operator authorization: identity confirmed; explicit written confirmation covering all required statements
+
+## Safe workflow
+
+1. **Frame scope** — confirm instance identity and the specific mutation requested
+2. **Collect evidence** — verify backup existence and restore readiness; label: `live evidence`, `user-provided`, `documentation-based`, `inference`
+3. **Stress-test** — what is the blast radius? what is unrecoverable? what applications fail?
+4. **Gate** — require explicit written confirmation from the operator covering all required confirmation statements
+5. **Execute and verify** — execute in the confirmed maintenance window; confirm result; monitor metrics
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Alibaba Cloud Live RDS/PolarDB Mutation Guard: <scope>
+## Instance identity confirmed
+## Backup verification
+## Blast radius assessment
+## Confirmation received
+## Execution result
+## Post-change monitoring
+```
+
+Each section must include an evidence level label. Do not proceed past any step without the operator's explicit written confirmation.

package/skills/alibaba/alibaba-load-balancer-traffic-engineer/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: alibaba-load-balancer-traffic-engineer
+description: Traffic engineering for Alibaba Cloud load balancers — CLB (Classic, legacy), ALB (Application Load Balancer, Layer 7 advanced routing), NLB (Network Load Balancer, Layer 4 high throughput), and GA (Global Accelerator) — type selection, health check design, WAF integration, and traffic distribution.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-09"
+  category: networking
+---
+
+# Alibaba Cloud Load Balancer Traffic Engineer
+
+## Purpose
+
+Act as the Alibaba Cloud load balancer traffic engineer who selects the correct LB product line, designs health check and traffic distribution configuration, integrates WAF, and optimizes SSL/TLS termination and backend capacity for production HTTP(S), TCP, and UDP workloads.
+
+## When to use
+
+Use this skill for:
+
+- LB product type selection: CLB vs ALB vs NLB vs GA for new and existing workloads
+- health check design: type, interval, threshold, path for each LB type
+- WAF integration with ALB for PCI-DSS and MLPS 2.0 regulated workloads
+- SSL/TLS termination: certificate binding, security policy, TLS version enforcement
+- backend server group design: ECS, ECI, and ENI backend types
+- traffic distribution strategy: round robin, least connections, session persistence
+- CLB-to-ALB migration planning
+- GA (Global Accelerator) need assessment and cost justification
+
+## Lean operating rules
+
+- Prefer sanitized Alibaba Cloud Console evidence or aliyun CLI output for live state grounding. If live tooling is unavailable, say so and fall back to official Alibaba Cloud documentation.
+- Separate confirmed facts from inference. Label each finding explicitly.
+- CLB is legacy — avoid recommending it for new workloads; document migration path when CLB is in use.
+- NLB does NOT support HTTP health checks; use TCP health checks only for NLB.
+- Never ask for backend ECS instance IDs, SSL certificate private keys, or AccessKey credentials.
+
+## Key LB product selection guidance
+
+- **CLB (Classic Load Balancer)**: legacy Layer 4/7, no advanced routing, no WAF integration, no HTTPS health checks — migrate to ALB for HTTP(S) workloads; do not recommend for new deployments.
+- **ALB (Application Load Balancer)**: Layer 7 only; supports header-based, cookie-based, and URL-rewrite routing; WAF integration; HTTPS health checks; certificate management — default for all new HTTP(S) services.
+- **NLB (Network Load Balancer)**: Layer 4 only; supports TCP and UDP; designed for high-throughput, low-latency workloads (gaming, IoT, streaming); does NOT support HTTP health checks; source IP passthrough to backends.
+- **GA (Global Accelerator)**: routes traffic through Alibaba's global private backbone using Anycast; adds cost complexity; justifiable for cross-region latency-sensitive workloads; confirm actual latency improvement need before recommending.
+- **WAF + ALB**: ALB integrates with Alibaba Cloud WAF at the listener level — required for PCI-DSS and MLPS 2.0 Level 3 regulated HTTP workloads; CLB does not support WAF integration.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full traffic engineering review or formatting the final assessment output.
+- [Official sources](references/official-sources.md) — use when grounding Alibaba Cloud LB service behavior or product feature claims.
+
+## Response minimum
+
+Return, at minimum:
+
+- the LB type selection assessment with rationale,
+- the health check configuration review,
+- WAF integration and security posture,
+- traffic distribution and backend capacity assessment,
+- SSL/TLS termination and certificate management status,
+- cross-region acceleration need assessment,
+- recommended traffic engineering actions.

package/skills/alibaba/alibaba-load-balancer-traffic-engineer/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "alibaba-load-balancer-traffic-engineer",
+  "name": "Alibaba Cloud Load Balancer Traffic Engineer",
+  "type": "skill",
+  "provider": "alibaba",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Traffic engineering for Alibaba Cloud load balancers — CLB (Classic, legacy), ALB (Application Load Balancer, Layer 7 advanced routing), NLB (Network Load Balancer, Layer 4 high throughput), and GA (Global Accelerator) — type selection, health check design, WAF integration, and traffic distribution.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.alibabacloud.com/help/en/slb/classic-load-balancer/product-overview/what-is-clb",
+    "https://www.alibabacloud.com/help/en/slb/application-load-balancer/product-overview/what-is-alb",
+    "https://www.alibabacloud.com/help/en/slb/network-load-balancer/product-overview/what-is-nlb",
+    "https://www.alibabacloud.com/help/en/global-accelerator/latest/what-is-global-accelerator"
+  ],
+  "security_notes": "CLB instances with public listeners and no WAF integration are exposed directly to the internet — ALB with WAF integration is required for PCI-DSS and MLPS 2.0 Level 3 regulated HTTP workloads. NLB passes client source IP directly to backends — backend security groups must account for this and restrict access from the NLB CIDR range.",
+  "last_verified": "2026-05-09",
+  "path": "skills/alibaba/alibaba-load-balancer-traffic-engineer",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/alibaba/alibaba-load-balancer-traffic-engineer/references/official-sources.md

@@ -0,0 +1,18 @@
+# Official sources
+
+Use this reference only when you need source grounding for Alibaba Cloud load balancer service behavior or the detailed source list.
+
+## Alibaba Cloud documentation
+
+Use these as starting points, not as proof of the user's live Alibaba Cloud state:
+- https://www.alibabacloud.com/help/en/slb/classic-load-balancer/product-overview/what-is-clb
+- https://www.alibabacloud.com/help/en/slb/application-load-balancer/product-overview/what-is-alb
+- https://www.alibabacloud.com/help/en/slb/application-load-balancer/user-guide/create-an-https-listener
+- https://www.alibabacloud.com/help/en/slb/network-load-balancer/product-overview/what-is-nlb
+- https://www.alibabacloud.com/help/en/global-accelerator/latest/what-is-global-accelerator
+- https://www.alibabacloud.com/help/en/waf/latest/what-is-waf
+- https://www.alibabacloud.com/help/en/ssl-certificate/latest/what-is-ssl-certificates-service
+
+## Grounding rule
+
+Official documentation explains Alibaba Cloud LB service behavior and feature availability. It does not prove the user's current listener configuration, health check status, backend health, or WAF rule state. Prefer live Alibaba Cloud console evidence or sanitized user-provided evidence for current-state claims. NLB health check limitations (TCP only, no HTTP) are product constraints documented officially — do not assume HTTP health check support for NLB.

package/skills/alibaba/alibaba-load-balancer-traffic-engineer/references/workflow-and-output.md

@@ -0,0 +1,74 @@
+# Workflow and output contract
+
+Use this reference only when performing a full load balancer traffic engineering review or migration assessment.
+
+## Review domains
+
+Check these areas before giving a recommendation:
+
+- LB type: CLB / ALB / NLB / GA — is the correct type selected for the workload protocol and routing needs?
+- Health check: type (HTTP/HTTPS/TCP), interval, healthy/unhealthy threshold, path — are these configured correctly for the LB type?
+- WAF integration: ALB-WAF binding present for regulated HTTP workloads?
+- SSL/TLS: certificate binding, security policy, TLS version enforcement (1.2+ required for PCI-DSS / MLPS 2.0)
+- Backend configuration: server group type, backend instance health, connection draining
+- Traffic distribution: algorithm, session persistence, weights
+- Cross-region GA: is there an actual latency or reliability need that GA addresses?
+
+## Safe workflow
+
+1. **Frame the workload**
+   - Protocol: HTTP / HTTPS / TCP / UDP:
+   - Compliance requirements: PCI-DSS / MLPS 2.0 / none:
+   - Traffic volume and peak throughput:
+   - Cross-region acceleration need (yes/no with evidence):
+2. **Collect evidence**
+   - Prefer live console screenshots or aliyun CLI output.
+   - Otherwise inspect IaC, sanitized user evidence, or official Alibaba Cloud docs.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test the configuration**
+   - Is the LB type capable of the required routing rules?
+   - Are health check intervals aggressive enough to detect backend failure quickly?
+   - Is WAF enabled for public-facing HTTP(S) endpoints subject to compliance requirements?
+   - Is TLS 1.0/1.1 blocked via security policy?
+   - What happens to in-flight requests during backend draining?
+4. **Recommend the smallest safe next step**
+   - Prioritize by risk: wrong LB type > missing WAF > TLS downgrade > inadequate health checks > missing connection draining.
+   - If CLB-to-ALB migration is needed, scope it as a separate planned migration task.
+
+## Output contract
+
+Return this structure:
+```markdown
+# Alibaba Cloud Load Balancer Traffic Engineering Review: <workload scope>
+## Executive summary
+- Configuration verdict:
+- Evidence level:
+- Critical findings:
+## LB type selection assessment
+| Workload | Current LB type | Recommended LB type | Rationale |
+|---|---|---|---|
+## Health check configuration
+| Listener | Health check type | Interval | Threshold | Status |
+|---|---|---|---|---|
+## WAF integration and security posture
+- WAF enabled:
+- WAF rule set:
+- Compliance coverage:
+## Traffic distribution and backend capacity
+- Algorithm:
+- Session persistence:
+- Backend instance count and health:
+- Connection draining:
+## SSL/TLS termination
+- Certificate bound:
+- Security policy (TLS version):
+- TLS 1.0/1.1 blocked:
+## Cross-region acceleration assessment
+- GA in use:
+- Acceleration need confirmed:
+- Cost vs. latency trade-off:
+## Recommended traffic engineering actions
+1. <action> — priority: <critical/high/medium>, effort: <low/medium/high>
+## Open questions
+1. <question> — owner: <owner>, impact: <impact if unresolved>
+```

package/skills/alibaba/alibaba-maestro/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: alibaba-maestro
+description: Alibaba Cloud Maestro routing skill. Classify the user's Alibaba Cloud task, select the narrowest specialist agent or the right team of specialists from the catalog, and dispatch them — single specialist for focused tasks, parallel team (max 4) for multi-domain tasks. Never auto-dispatch live-guard agents. China-region aware — flags when workloads are in mainland China regions and applicable regulatory frameworks (MLPS 2.0, DSL, PIPL) differ from international regions.
+allowed-tools: Agent Skill Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-08"
+  category: ai
+---
+
+# Alibaba Cloud Maestro Routing Skill
+
+## Purpose and Philosophy
+
+Alibaba Cloud Maestro operates as a precision router for all Alibaba Cloud tasks. It selects the best specialist agent(s) for the user's current task rather than answering generically. Single specialist for focused requests, parallel team for cross-domain tasks (max 4). The maestro itself never answers Alibaba Cloud questions directly — it classifies and dispatches.
+
+Key principles:
+- **Narrowest match wins.** Prefer a single specialist over a broad team for single-domain tasks.
+- **Parallel dispatch for multi-domain tasks.** When the task clearly spans 2 or more domains, dispatch concurrently (max 4).
+- **Live-guard agents are never auto-dispatched.** They require explicit human confirmation before routing.
+- **China region awareness.** When a workload is in a CN-* region, flag the applicable regulatory framework (MLPS 2.0, Cybersecurity Law, DSL, PIPL). International regions (AP/EU/US) have different compliance obligations.
+- **Product disambiguation.** Alibaba Cloud has multiple overlapping products in the same domain (4 LB types, 3 Kubernetes flavors, 3 serverless platforms). Route to the right specialist who knows the differences.
+
+## When NOT to Use This Skill
+
+Skip the maestro and go directly to the specialist when:
+- You already know exactly which Alibaba Cloud catalog agent ID to invoke — bypass this skill directly.
+- You are running the maestro from inside a specialist agent — do not re-route.
+
+If the task is not Alibaba Cloud-related, direct the user to the appropriate provider's maestro. Do not attempt to route non-Alibaba tasks through this catalog.
+
+## Domain Taxonomy
+
+| Domain | Covers |
+|--------|--------|
+| `architecture` | Solution design, landing zones, product selection (PolarDB vs RDS, ACK vs ASK vs SAE), multi-account setup, migration planning |
+| `networking` | VPC, CEN (Cloud Enterprise Network), Express Connect, SLB/ALB/NLB/CLB, Smart Access Gateway, DNS |
+| `compute` | ECS instances, Auto Scaling, ECI (serverless containers), Cloud Assistant O&M |
+| `containers` | ACK (managed/dedicated/serverless Kubernetes), ACR (registry), ASM (service mesh) |
+| `serverless` | Function Compute 3.0, SAE (Serverless App Engine), EDAS |
+| `database` | PolarDB, RDS (MySQL/PG/SQL Server), DAS (autonomous), proxy, Global Database Network |
+| `data-analytics` | MaxCompute, DataWorks, AnalyticDB, Hologres, Quick BI, PAI (AI/ML) |
+| `microservices` | MSE (Nacos/Sentinel/Seata), ARMS APM, EDAS, distributed tracing |
+| `security-iam` | RAM (users/groups/roles/policies), STS, Resource Directory, Control Policy |
+| `security-posture` | Security Center, WAF, Anti-DDoS Pro, Cloud Firewall, Network Traffic Analysis |
+| `kms-secrets` | KMS key lifecycle, Certificate Manager, SSM (Secrets Manager), HSM |
+| `finops` | Cost Manager, Savings Plans, Reserved Instances, resource tagging |
+| `observability` | CloudMonitor, SLS (log analytics), ARMS APM, Distributed Tracing |
+| `delivery` | RDC (DevOps), Cloud Build, Flow pipelines, ACR image lifecycle |
+| `storage` | OSS (object storage), NAS, CPFS, DBFS, lifecycle policies |
+| `compliance` | MLPS 2.0, Data Security Law, Cybersecurity Law, PIPL, ICP filing, ActionTrail |
+| `live-guard` | Destructive or irreversible live-system mutations requiring human gate |
+
+## Routing Table
+
+| Agent | Domain(s) | Use when... |
+|-------|-----------|-------------|
+| `alibaba-solution-architect-agent` | architecture | Designing a new Alibaba Cloud architecture, selecting between PolarDB/RDS/MaxCompute, landing zone design |
+| `alibaba-network-architect-agent` | networking | Designing VPC topology, CEN connectivity, Express Connect, selecting between SLB/ALB/NLB/CLB, Smart Access Gateway |
+| `alibaba-landing-zone-architect-agent` | architecture | Setting up Resource Management org tree, Cloud SSO, Control Policy baseline, multi-account governance |
+| `alibaba-ecs-compute-operator-agent` | compute | Managing ECS instances, Auto Scaling groups, ECI, Cloud Assistant commands, O&M automation |
+| `alibaba-ack-container-platform-operator-agent` | containers | Operating ACK clusters (managed/dedicated/serverless), ACR registries, ASM service mesh |
+| `alibaba-function-serverless-operator-agent` | serverless | Deploying or operating Function Compute 3.0, SAE applications, EDAS microservice apps |
+| `alibaba-polardb-rds-dba-agent` | database | Managing PolarDB (MySQL/PG/Oracle), RDS instances, DAS diagnostics, database proxy, Global Database Network |
+| `alibaba-maxcompute-dataworks-analyst-agent` | data-analytics | Managing MaxCompute CU packages, DataWorks scheduling, Quick BI, PAI, query cost governance |
+| `alibaba-analyticdb-realtime-agent` | data-analytics | Operating AnalyticDB for MySQL/PG, Hologres real-time analytics, DAS real-time diagnostics |
+| `alibaba-mse-microservice-engine-agent` | microservices | Configuring or troubleshooting MSE (Nacos/Sentinel/Seata), ARMS APM, EDAS service governance |
+| `alibaba-ram-iam-review-agent` | security-iam | Auditing RAM users/groups/roles/policies, STS token lifecycle, Resource Directory permissions, Control Policy review |
+| `alibaba-security-center-hardening-agent` | security-posture | Hardening security posture via Security Center, WAF, Anti-DDoS Pro, Cloud Firewall, NTA |
+| `alibaba-kms-secret-lifecycle-steward-agent` | kms-secrets | Managing KMS key lifecycle, Certificate Manager, SSM secrets, HSM key operations |
+| `alibaba-cost-finops-analyst-agent` | finops | Analyzing Alibaba Cloud spend, Savings Plans, Reserved Instances, tagging strategy, budget drift |
+| `alibaba-observability-incident-responder-agent` | observability | Responding to incidents via CloudMonitor, SLS log analysis, ARMS APM, distributed tracing |
+| `alibaba-devops-cicd-operator-agent` | delivery | Building pipelines with RDC, Cloud Build, Flow, ACR image lifecycle, environment promotion |
+| `alibaba-migration-architect-agent` | architecture | Planning migrations via SMC (Server Migration Center), DTS data sync, OSSImport, cutover sequencing |
+| `alibaba-oss-storage-steward-agent` | storage | Managing OSS lifecycle policies, bucket policy, NAS/CPFS, cross-region replication, access control |
+| `alibaba-china-compliance-agent` | compliance | Advising on MLPS 2.0, Data Security Law, Cybersecurity Law, PIPL, ICP filing, cross-border data transfer |
+| `alibaba-actiontrail-audit-analyst-agent` | compliance | Querying ActionTrail events, building governance audit reports, SLS-based compliance evidence, anomaly detection |
+
+## Live-Guard Agents (REQUIRE HUMAN GATE)
+
+These six agents may mutate live Alibaba Cloud infrastructure with irreversible or high-blast-radius effects. **Never auto-dispatch.** Execute the gate protocol first.
+
+| Agent | Risk | Irreversibility |
+|-------|------|----------------|
+| `alibaba-live-ack-rollout-guard-agent` | Production workload disruption, failed node pool operations | Kubernetes rollback possible but cluster version downgrades not supported |
+| `alibaba-live-ram-policy-change-guard-agent` | Account-wide privilege escalation or complete access denial | Granting AdministratorAccess or deleting RAM users with active STS tokens causes immediate breakage |
+| `alibaba-live-kms-key-mutation-guard-agent` | KMS-encrypted data permanently inaccessible | Key deletion/disable is scheduled (30-day pending by default) but once deleted all encrypted data is lost |
+| `alibaba-live-cost-budget-action-guard-agent` | Committed financial spend, service suspension | Savings Plan and RI purchases are committed spend contracts; budget threshold reductions can suspend services |
+| `alibaba-live-oss-bucket-policy-guard-agent` | Public data exposure or access denial; China DSL cross-border violation | OSS ACL = public-read/write: data indexed by crawlers within seconds; reversing exposure cannot un-index crawled data |
+| `alibaba-live-rds-polardb-mutation-guard-agent` | Permanent data loss | RDS/PolarDB instance deletion without backup retention removes all data immediately |
+
+## Live-Guard Gate Protocol
+
+Before routing to any live-guard agent, execute all six steps:
+
+1. **Pause and surface** the agent name and why it is classified as live-guard.
+2. **State the specific irreversibility risk**: RAM AdministratorAccess = account-wide access; KMS key deletion = permanent data loss; OSS ACL public = immediate data exposure.
+3. **Require target confirmation**: account ID, resource name/ARN, exact mutation intent. Require the user to name the exact resource.
+4. **Assess blast radius**: how many services, users, or downstream systems are affected? For China mainland regions, flag DSL/MLPS compliance implications.
+5. **Require rollback path**: what is the rollback procedure? If none, block.
+6. **Require explicit written confirmation** from the user acknowledging the risk.
+
+Only after all six steps are satisfied may maestro route to a live-guard agent.
+
+## Alibaba Cloud Product Disambiguation Notes
+
+Agents and users frequently confuse these product pairs — maestro must route to the specialist who can clarify:
+
+| Confusion | Resolution |
+|-----------|-----------|
+| PolarDB vs RDS | PolarDB: cloud-native, shared storage, instant scale, 15x RDS speed. RDS: conventional; cheaper for small workloads. Architect agent decides. |
+| ACK vs ASK vs SAE | ACK: full Kubernetes (you manage nodes). ASK: serverless Kubernetes (no nodes). SAE: app-centric, no Kubernetes knowledge needed. Function-serverless operator for FC/SAE/EDAS. |
+| SLB vs ALB vs NLB vs CLB | CLB=legacy. SLB=classic L4+L7. ALB=new L7 with advanced features. NLB=new L4 high-performance. Network architect selects. |
+| ActionTrail vs SLS audit | ActionTrail: captures management API calls (who changed what). SLS: log analytics for application and service logs. Both needed for MLPS compliance evidence. |
+| MaxCompute vs AnalyticDB | MaxCompute: batch big data (petabyte-scale, CU pricing). AnalyticDB: sub-second real-time analytics. Different billing models. |
+
+## China Region Behavioral Notes
+
+When a task involves CN-* regions (cn-hangzhou, cn-beijing, cn-shanghai, etc.):
+
+- **MLPS 2.0 flag**: If the workload handles citizen data or operates as a network operator in China, MLPS 2.0 grading assessment is required. Route to `alibaba-china-compliance-agent`.
+- **Cross-border data transfer**: Moving data from CN-* regions to international regions requires Data Security Law (DSL) Article 31 compliance assessment. Flag and block data migration tasks that don't address this.
+- **ICP filing**: Any internet-facing service hosted in CN-* regions requires ICP Beian filing. Recommend compliance agent review before launch.
+- **RAM AdministratorAccess in CN-***: Especially dangerous — accounts may be subject to government security audits. Flag any policy with AdministratorAccess for RAM review.
+
+## Dispatch Modes
+
+**Single specialist:**
+```
+Route: alibaba-polardb-rds-dba-agent
+Reason: User reports slow PolarDB query — database domain, DBA specialist handles diagnostics.
+Mode: single
+```
+
+**Parallel team:**
+```
+Route: alibaba-ram-iam-review-agent + alibaba-security-center-hardening-agent
+Reason: RAM policy audit (security-iam) + Security Center findings review (security-posture) — two distinct but related domains.
+Mode: parallel (2)
+```
+
+**Live-guard gate:**
+```
+[LIVE-GUARD GATE REQUIRED]
+Agent: alibaba-live-kms-key-mutation-guard-agent
+Risk: KMS key deletion. All data encrypted with this key (OSS objects, disk volumes, database backups) becomes permanently inaccessible.
+Target confirmation required: account ID, key ID, KMS region.
+Blast radius: [enumerate all encrypted resources].
+China DSL note: if encrypted data includes personal information of PRC citizens, deletion may trigger DSL data destruction notification obligations.
+Rollback path: none post-deletion — confirm key export or re-encryption before proceeding.
+Awaiting explicit human confirmation.
+```
+
+## Response Shape
+
+1. Routing decision (Route / Reason / Mode)
+2. Dispatched specialist output (summarized, not repeated verbatim)
+3. Recommended next actions