@raishin/vanguard-frontier-agentic 1.4.0 → 1.6.0

package/skills/alibaba/alibaba-kms-secret-lifecycle-steward/references/workflow-and-output.md

@@ -0,0 +1,62 @@
+# Workflow and output contract
+
+Use this reference only when performing the full review, implementation guidance, incident triage, or production-readiness pass.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- CMK purpose, data classification, owning service, key policy, RAM policy, key version history, rotation schedule, aliases, tags, deletion window, and break-glass path
+- SSM secret type, rotation pattern (FC trigger), retry/client caching, resource policy, and monitoring
+- Certificate Manager SSL/TLS certificates: expiry dates, auto-renewal status, domain coverage, and CloudMonitor alarm configuration
+- HSM key custody: dedicated HSM instances, key wrapping, operator access, and FIPS compliance evidence
+- Envelope encryption coverage: which services use CMK-wrapped data keys vs. plain storage
+- Recovery risk: backups, cross-region restore, disabled/deleted CMKs, stale credentials, and operator ownership
+
+## Safe workflow
+
+1. **Frame scope**
+   - Workload/account/Region/environment:
+   - Business criticality and owner:
+   - Data classification and compliance driver:
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer live read-only evidence if available.
+   - Otherwise inspect repository IaC/config, 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 risk**
+   - What can expose data?
+   - What can escalate privilege?
+   - What can break production or block rollback?
+   - What can create unbounded cost?
+   - What evidence is missing?
+4. **Recommend the smallest safe action**
+   - Prefer narrow scope, staged rollout, validation, and rollback.
+   - If the safest action is to stop and gather evidence, say that plainly.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Alibaba Cloud KMS Secret Lifecycle Steward: <scope>
+## Executive verdict
+- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Findings
+| Severity | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Commands or checks:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/alibaba/alibaba-landing-zone-architect/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: alibaba-landing-zone-architect
+description: Design Alibaba Cloud landing zone — Resource Management org tree, Cloud SSO, Control Policy (SCP equivalent), multi-account governance baseline, billing account structure, and ActionTrail centralization.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-08"
+  category: platform
+---
+
+# Alibaba Cloud Landing Zone Architect
+
+## Purpose
+
+Act as the Alibaba Cloud landing zone architect who designs multi-account governance structures with traceable audit trails, least-privilege RAM baselines, and enforceable Control Policies.
+
+## When to use
+
+Use this skill for:
+
+- Resource Management org tree design with master and member accounts
+- Control Policy (SCP equivalent) authoring and OU-level application
+- Cloud SSO configuration for centralized identity federation
+- ActionTrail centralization to a cross-account SLS project
+- RAM permission boundary design for automation-created roles
+- Billing account structure and cost allocation strategy
+- Implementation roadmap for landing zone bootstrapping
+
+## Lean operating rules
+
+- Prefer official Alibaba Cloud documentation and live evidence over memory or inference.
+- Separate confirmed facts from inference. If a governance control was not verified, say so.
+- Challenge broad Control Policies, missing ActionTrail coverage, and unbounded RAM permission boundaries.
+- Keep answers scoped, traceable, and explicit about trade-offs and open questions.
+- Load references only when needed; do not pull all deep guidance into short answers.
+
+## Key landing zone guidance
+
+- **Resource Management** creates an org tree with a master (payer) account and member accounts grouped into OUs (resource folders).
+- **Control Policy** applies deny-based restrictions at the OU or account level — equivalent to AWS SCPs. Must explicitly allow actions that Control Policy would otherwise deny.
+- **Cloud SSO** provides centralized SSO with SAML/OIDC federation to external IdPs for cross-account access.
+- **ActionTrail** must be configured to deliver trail events to a central SLS (Log Service) project in the master account for cross-account audit coverage.
+- **RAM permission boundaries** cap the maximum permissions a RAM entity can exercise — apply to all roles created by automation pipelines.
+- STS tokens have a maximum TTL of 12 hours; design short-lived token workflows for automation.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full landing zone design or formatting the final governance output.
+- [Official sources](references/official-sources.md) — use when grounding Alibaba Cloud governance service behavior or feature claims.
+
+## Response minimum
+
+Return, at minimum:
+
+- the org tree structure and account assignments,
+- the Control Policy baseline with rationale,
+- the Cloud SSO and ActionTrail configuration approach,
+- the RAM permission boundary baseline,
+- the open questions that must be resolved before implementation.

package/skills/alibaba/alibaba-landing-zone-architect/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "alibaba-landing-zone-architect",
+  "name": "Alibaba Cloud Landing Zone Architect",
+  "type": "skill",
+  "provider": "alibaba",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Design Alibaba Cloud landing zone — Resource Management org tree, Cloud SSO, Control Policy (SCP equivalent), multi-account governance baseline, billing account structure, and ActionTrail centralization.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.alibabacloud.com/help/en/resource-management",
+    "https://www.alibabacloud.com/help/en/cloud-sso",
+    "https://www.alibabacloud.com/help/en/actiontrail",
+    "https://www.alibabacloud.com/help/en/ram"
+  ],
+  "security_notes": "Enforce least-privilege RAM permission boundaries on all automation-created roles. Require ActionTrail coverage before declaring a landing zone production-ready. Do not approve broad Control Policies that bypass compliance guardrails.",
+  "last_verified": "2026-05-08",
+  "path": "skills/alibaba/alibaba-landing-zone-architect",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/alibaba/alibaba-landing-zone-architect/references/official-sources.md

@@ -0,0 +1,17 @@
+# Official sources
+
+Use this reference only when you need source grounding for Alibaba Cloud governance 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/resource-management
+- https://www.alibabacloud.com/help/en/cloud-sso
+- https://www.alibabacloud.com/help/en/actiontrail
+- https://www.alibabacloud.com/help/en/ram
+- https://www.alibabacloud.com/help/en/log-service
+- https://www.alibabacloud.com/help/en/sts
+
+## Grounding rule
+
+Official documentation explains Alibaba Cloud service behavior and feature availability. It does not prove the user's current account, region, quota, resource configuration, pricing, or operational state. Prefer live Alibaba Cloud console evidence or sanitized user-provided evidence for current-state claims.

package/skills/alibaba/alibaba-landing-zone-architect/references/workflow-and-output.md

@@ -0,0 +1,70 @@
+# Workflow and output contract
+
+Use this reference only when performing a full landing zone design, governance review, or implementation roadmap.
+
+## Design domains
+
+Check these areas before giving a recommendation:
+
+- Resource Management org tree structure and OU hierarchy
+- Control Policy baseline and deny-list coverage
+- Cloud SSO configuration and IdP federation
+- ActionTrail cross-account centralization to SLS
+- RAM baseline and permission boundary application
+- Billing account structure and tag-based cost allocation
+
+## Safe workflow
+
+1. **Frame requirements**
+   - Number of accounts and intended OU groupings:
+   - Identity provider and SSO requirements:
+   - Compliance and audit trail requirements:
+   - Billing and cost allocation structure:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer live Resource Management console or API evidence if available.
+   - 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 design**
+   - What Control Policy gaps allow unrestricted actions in member accounts?
+   - What ActionTrail gaps leave audit blind spots?
+   - What automation roles lack permission boundaries?
+   - What evidence is missing?
+4. **Recommend the smallest safe next step**
+   - Prefer bootstrapping master account controls before enrolling member accounts.
+   - If the safest action is to gather more evidence, say that plainly.
+
+## Output contract
+
+Return this structure:
+```markdown
+# Alibaba Cloud Landing Zone Design: <scope>
+## Executive summary
+- Recommendation:
+- Evidence level:
+- Key risks:
+## Org tree design
+- Master account:
+- OU structure:
+- Member account assignments:
+## Control Policy baseline
+| Policy | Applied at | Effect | Rationale |
+|---|---|---|---|
+## Cloud SSO configuration
+- IdP federation method:
+- Permission set baseline:
+## ActionTrail centralization
+- Trail scope:
+- SLS project target:
+- Retention policy:
+## RAM baseline
+- Permission boundary template:
+- Applied to:
+## Billing structure
+- Cost allocation tags:
+- Billing account assignments:
+## Implementation roadmap
+1. <step> — owner: <owner>, prerequisite: <prerequisite>
+## Open questions
+1. <question> — owner: <owner>, impact: <impact if unresolved>
+```

package/skills/alibaba/alibaba-live-ack-rollout-guard/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: alibaba-live-ack-rollout-guard
+description: Gate ACK deployment mutations, node pool scaling, and cluster version upgrades against rollback posture and workload disruption budget. Prevents irreversible cluster version upgrades from proceeding without PodDisruptionBudget verification, node drain confirmation, and explicit operator approval.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-08"
+  category: delivery
+---
+
+# Alibaba Cloud Live ACK Rollout Guard
+
+## Purpose
+
+Act as the guarded live Alibaba Cloud operator for alibaba-live-ack-rollout-guard work. Gate ACK deployment mutations, node pool scaling, and cluster version upgrades. Insist on PDB audit and rollback posture evidence before execution, and treat any ambiguous approval or target as a stop condition.
+
+## When to Use
+
+Use this skill when:
+
+- An ACK cluster version upgrade is requested (Kubernetes minor or patch version bump)
+- A node pool is being scaled up or down (especially when removing nodes)
+- A Deployment or DaemonSet rollout is being executed against a production workload
+- Node pool configuration changes are planned (instance type, image version, count)
+- An operator needs to audit PodDisruptionBudgets before a disruptive node pool operation
+- An emergency rollback of a broken rollout is required
+
+## When NOT to Use
+
+Do not use this skill when:
+
+- The target is a non-production cluster with no PDB requirements and no live traffic
+- The task is creating a brand-new cluster (no existing workloads at risk)
+- The task is purely read-only cluster inspection with no mutation intent
+- The task involves Function Compute, SAE, or other non-ACK compute
+
+## Cluster Type Awareness
+
+ACK supports three cluster types — mutation procedures differ per type:
+
+- **Managed cluster**: Control plane managed by Alibaba Cloud. Node pool upgrades and scaling are the primary mutation surface.
+- **Dedicated cluster**: Full control plane access. Both control plane and data plane versions must be managed.
+- **Serverless cluster (ASK)**: No node pool concept. Pod-level scaling only — ECI instances are provisioned on demand. Version upgrades are less common but follow the same approval gate.
+
+Always confirm cluster type before recommending a mutation path.
+
+## Pre-Flight Checklist
+
+Before executing any ACK mutation, verify all of the following:
+
+1. **Cluster identity confirmed** — query the ACK API or Alibaba Cloud console to confirm the cluster ID, name, type, and region match the intended target.
+2. **Active RAM principal confirmed** — confirm the active identity has the required RAM policy (`AliyunCSFullAccess` scoped to target cluster) for the operation.
+3. **Current cluster version and node pool version captured** — document both before proceeding; confirm the target version is available for the cluster type.
+4. **PDB audit complete** — run `kubectl get pdb --all-namespaces` and confirm no PDB has `DISRUPTIONS ALLOWED: 0` for workloads running on the affected node pool.
+5. **Node drain posture verified** — for scale-in operations, confirm all nodes to be removed can be safely drained (no pods with no toleration for eviction, no local storage).
+6. **Rollback posture acknowledged** — cluster version upgrades cannot be downgraded; operator must explicitly acknowledge this is one-way.
+7. **Maintenance window confirmed** — confirm the upgrade is within the approved change window.
+8. **Rollout history captured** — run `kubectl rollout history deployment/<NAME> -n <NAMESPACE>` to document the pre-change state for Deployment rollouts.
+
+## Required Confirmation
+
+The operator must explicitly state all of the following before any mutation is executed:
+
+- "I confirm the cluster is `<CLUSTER_ID>` (`<CLUSTER_NAME>`) of type `<managed/dedicated/serverless>` in region `<REGION>`."
+- "I confirm the target version is `<TARGET_VERSION>` and I understand cluster version upgrades cannot be downgraded."
+- "I have reviewed PDB status for all workloads on this node pool and no disruption-blocking PDB is present."
+- "I approve this rollout action."
+
+## Execution Steps
+
+1. Capture pre-change state: cluster version, node pool version, all PDB states, Deployment rollout history.
+2. Confirm active RAM principal and policy scope.
+3. Present the planned change and its blast radius to the operator for explicit approval.
+4. Execute the mutation via the ACK console, Alibaba Cloud CLI (`aliyun cs`), or kubectl as appropriate.
+5. Monitor rollout progress: `kubectl rollout status deployment/<NAME> -n <NAMESPACE>` or poll the ACK task status via API.
+6. Verify all nodes reach `Ready` status and all workloads are running post-upgrade.
+
+## Rollback Procedure
+
+- **Deployment rollback** (reversible): `kubectl rollout undo deployment/<NAME> -n <NAMESPACE>`
+- **Node pool scaling scale-in** (partially reversible): New nodes can be added back, but drained workloads need to be rescheduled.
+- **Cluster version upgrade** (NOT reversible): A completed cluster version upgrade cannot be downgraded. If the upgrade causes issues, address them on the upgraded version or contact Alibaba Cloud support.
+- Document the incident and open an Alibaba Cloud support ticket if cluster corruption is suspected.
+
+## Post-Change Verification
+
+1. Confirm cluster version matches target via ACK console or API.
+2. Run `kubectl get nodes` — confirm all nodes show `Ready` with the new version.
+3. Run `kubectl get pods --all-namespaces` — confirm no pods in `CrashLoopBackOff` or `Pending` state.
+4. Run `kubectl get pdb --all-namespaces` — confirm all PDBs still show healthy disruption budgets.
+5. Verify application health via CloudMonitor metrics: error rate and latency for affected workloads.
+
+## Response Shape
+
+1. Cluster type and version confirmed
+2. Node pool inventory and version status
+3. PDB audit for affected workloads
+4. Rollout strategy
+5. Approval status
+6. Executed action
+7. Post-rollout verification

package/skills/alibaba/alibaba-live-ack-rollout-guard/metadata.json

@@ -0,0 +1,25 @@
+{
+  "id": "alibaba-live-ack-rollout-guard",
+  "name": "Alibaba Cloud Live ACK Rollout Guard",
+  "version": "0.1.0",
+  "type": "skill",
+  "provider": "alibaba",
+  "harnesses": [
+    "codex",
+    "copilot",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro"
+  ],
+  "summary": "Gate ACK deployment mutations, node pool scaling, and cluster version upgrades against rollback posture and workload disruption budget before any production change.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.alibabacloud.com/help/en/ack",
+    "https://www.alibabacloud.com/help/en/ack/ack-managed-and-dedicated/user-guide/upgrade-a-cluster"
+  ],
+  "last_verified": "2026-05-08",
+  "path": "skills/alibaba/alibaba-live-ack-rollout-guard",
+  "author": "github: Raishin",
+  "security_notes": "ACK cluster version downgrade is not supported. Node pool scale-in evicts workloads without PDB compliance check. Addon upgrades can break workloads if version incompatible. Never approve a cluster mutation without explicit rollback posture and disruption budget audit."
+}

package/skills/alibaba/alibaba-live-ack-rollout-guard/references/official-sources.md

@@ -0,0 +1,29 @@
+# Official Sources — Alibaba Cloud Live ACK Rollout Guard
+
+Authoritative Alibaba Cloud documentation for ACK rollout, node pool, and upgrade operations.
+
+## Core References
+
+- **ACK Overview** — https://www.alibabacloud.com/help/en/ack
+  Overview of Alibaba Cloud Container Service for Kubernetes (ACK), cluster types, and feature comparison.
+
+- **Upgrade a Cluster** — https://www.alibabacloud.com/help/en/ack/ack-managed-and-dedicated/user-guide/upgrade-a-cluster
+  Step-by-step guide for upgrading ACK managed and dedicated cluster versions, including pre-upgrade checks.
+
+- **Managed Node Pools** — https://www.alibabacloud.com/help/en/ack/ack-managed-and-dedicated/user-guide/node-pool-overview
+  Node pool architecture, managed upgrade settings, and scaling configuration.
+
+- **Scale a Node Pool** — https://www.alibabacloud.com/help/en/ack/ack-managed-and-dedicated/user-guide/scale-a-node-pool
+  How to scale node pools up and down, including drain behavior and auto-scaling policies.
+
+- **Serverless Kubernetes (ASK)** — https://www.alibabacloud.com/help/en/ack/serverless-kubernetes
+  Serverless cluster architecture, ECI-based workload scheduling, and version management.
+
+- **PodDisruptionBudget** — https://kubernetes.io/docs/tasks/run-application/configure-pdb/
+  Kubernetes upstream documentation for configuring and auditing PDBs before disruptive operations.
+
+- **ACK Audit Logging** — https://www.alibabacloud.com/help/en/ack/ack-managed-and-dedicated/user-guide/audit-log-overview
+  Enabling and querying ACK audit logs for cluster and node pool operations.
+
+- **ACK Release Notes** — https://www.alibabacloud.com/help/en/ack/ack-managed-and-dedicated/product-overview/release-notes
+  Available Kubernetes versions for ACK clusters, deprecation timelines, and upgrade paths.

package/skills/alibaba/alibaba-live-ack-rollout-guard/references/workflow-and-output.md

@@ -0,0 +1,110 @@
+# Workflow and Output — Alibaba Cloud Live ACK Rollout Guard
+
+## Step-by-Step Workflow
+
+### Phase 1: Identity and Scope Confirmation
+
+1. Confirm the active RAM principal and its policy scope.
+2. Describe the target cluster to confirm cluster ID, type, region, and current version via the ACK console or API.
+3. List all node pools and their current versions:
+   ```
+   aliyun cs GET /clusters/<CLUSTER_ID>/nodepools
+   ```
+
+### Phase 2: PDB Audit
+
+4. List all PodDisruptionBudgets across all namespaces:
+   ```
+   kubectl get pdb --all-namespaces -o wide
+   ```
+5. Identify any PDB with `DISRUPTIONS ALLOWED: 0` — these are blocking conditions.
+6. For each blocking PDB, identify the affected workload and its node pool placement.
+
+### Phase 3: Rollout Strategy Review
+
+7. For node pool scale-in: confirm drain posture — identify any pods with local storage or no eviction toleration.
+8. For Deployment rollouts, review rollout history:
+   ```
+   kubectl rollout history deployment/<NAME> -n <NAMESPACE>
+   ```
+9. For cluster version upgrades: confirm the target version is available and document that the operation is irreversible.
+
+### Phase 4: Approval Gate
+
+10. Present all evidence to the operator: cluster identity, type, current vs. target version, PDB findings, drain posture.
+11. Require explicit written approval including acknowledgment that cluster version upgrades are irreversible.
+12. Do not proceed until approval is received.
+
+### Phase 5: Execution
+
+13. Execute the approved operation:
+    - Node pool scale via console or:
+      ```
+      aliyun cs POST /clusters/<CLUSTER_ID>/nodepools/<NODEPOOL_ID>/scale
+      ```
+    - Cluster version upgrade via console or ACK API.
+    - Deployment rollout:
+      ```
+      kubectl set image deployment/<NAME> <CONTAINER>=<IMAGE> -n <NAMESPACE>
+      ```
+14. Monitor the operation:
+    ```
+    kubectl rollout status deployment/<NAME> -n <NAMESPACE>
+    aliyun cs GET /clusters/<CLUSTER_ID>/tasks/<TASK_ID>
+    ```
+
+### Phase 6: Post-Change Verification
+
+15. Confirm all nodes are Ready at the new version:
+    ```
+    kubectl get nodes -o wide
+    ```
+16. Confirm no pods are in error states:
+    ```
+    kubectl get pods --all-namespaces | grep -v Running | grep -v Completed
+    ```
+17. Re-audit PDBs to confirm disruption budgets are healthy.
+18. Check CloudMonitor for elevated error rates or latency anomalies in the 15 minutes following the change.
+
+## Expected Output Format
+
+The agent response for an ACK rollout operation must include:
+
+```
+CLUSTER IDENTITY
+  Cluster ID:     <cluster-id>
+  Cluster Name:   <cluster-name>
+  Cluster Type:   <managed / dedicated / serverless>
+  Region:         <region>
+  Current Version: <x.y.z>
+  Target Version:  <x.y.z>
+
+NODE POOL
+  Pool ID:        <nodepool-id>
+  Pool Name:      <nodepool-name>
+  Current Version: <x.y.z>
+  Node Count:     <N>
+
+PDB AUDIT
+  Blocking PDBs:  [NONE | <list of PDB names with ALLOWED=0>]
+  Non-blocking:   <count>
+
+APPROVAL STATUS
+  Operator:       <RAM principal>
+  Approved:       [YES / NO / PENDING]
+  Irreversibility acknowledged: [YES / NO]
+
+ACTION
+  [BLOCKED — reason] OR [EXECUTING — task ID] OR [COMPLETE]
+
+ROLLBACK POSTURE
+  [NOT POSSIBLE — cluster version upgrade is one-way]
+  OR
+  [AVAILABLE — kubectl rollout undo deployment/<NAME>]
+
+VERIFICATION
+  Nodes Ready:    <count>/<total>
+  Pods Healthy:   <count>/<total>
+  PDB Status:     OK
+  Error Rate:     <value or "not yet checked">
+```

package/skills/alibaba/alibaba-live-cost-budget-action-guard/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: alibaba-live-cost-budget-action-guard
+description: Gate live financial authority actions — budget threshold changes, Savings Plan purchases, and Reserved Instance commitments. These are committed spend or can trigger immediate service suspension.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-08"
+  category: finops
+---
+
+# Alibaba Cloud Live Cost Budget Action Guard
+
+## Purpose
+
+Act as the guarded live Alibaba Cloud operator for alibaba-live-cost-budget-action-guard work. Gate every budget threshold change, Savings Plan purchase, and Reserved Instance commitment with a full financial-impact assessment and explicit financial-authority approval. Treat Savings Plan and RI purchases as the highest-risk financial actions — they are non-refundable committed spend contracts.
+
+## When to Use
+
+Use this skill when:
+
+- A Cost Manager budget alert threshold needs to be increased or decreased
+- A Savings Plan purchase (compute-based or ECS-instance) is being requested
+- A Reserved Instance commitment (zone or regional, 1-year or 3-year) is being submitted
+- An operator needs to audit current budgets, alert thresholds, and active commitments
+- A budget anomaly or unexpected billing spike needs investigation and remediation
+
+## When NOT to Use
+
+Do not use this skill when:
+
+- The task is a read-only cost report review with no billing mutation intent
+- The task involves resource rightsizing or scheduling that does not touch billing account settings
+- The task is unrelated to Alibaba Cloud billing, Savings Plans, or Reserved Instances
+
+## Key Risk Facts
+
+- **Savings Plans** are non-refundable committed spend contracts (hourly commitment × term). A compute-based Savings Plan requires an hourly CNY/USD commitment for 1 or 3 years — there is no cancellation.
+- **Reserved Instances** lock capacity for 1 or 3 years. Partial/all-upfront payment options exist. RI purchases cannot be refunded.
+- **Budget threshold reduction below current spend** triggers immediate service suspension in Alibaba Cloud BSS. Services are suspended within minutes of the billing threshold being breached. Restoration requires manual re-enabling of suspended services and can cause data loss in stateful workloads.
+- **All three actions** require the 6-step live-guard gate: (1) identity confirm, (2) current inventory capture, (3) blast radius assessment, (4) financial authority confirm, (5) explicit written approval, (6) post-action verification.
+
+## Pre-Flight Checklist
+
+Before executing any billing mutation, verify all of the following:
+
+1. **Account identity confirmed** — confirm the BSS account ID, billing account name, and the operator's RAM identity.
+2. **Current budget inventory captured** — list all active budgets, current thresholds, alert notification targets, and actual spend vs. threshold ratio before any change.
+3. **Commitment inventory captured** — list all active Savings Plans (commitment amount, remaining term) and Reserved Instances (instance type, scope, expiry) before any new purchase.
+4. **Utilization verified** — for Savings Plans and RIs: confirm current utilization rate of existing commitments before purchasing additional. Purchasing new commitments when existing ones are underutilized compounds waste.
+5. **Blast radius assessed** — for budget threshold reduction: calculate the gap between the proposed threshold and current spend. Confirm the new threshold is above the minimum operational spend. Document which services are at risk of suspension.
+6. **Financial authority confirmed** — the approver must have explicit financial authority (BSS account administrator, VP Engineering, CFO delegate, or equivalent). Document their identity and written approval.
+
+## Required Confirmation
+
+The operator must explicitly state all of the following before any mutation is executed:
+
+- "I confirm the BSS account is `<ACCOUNT_ID>` and the operator identity is `<RAM_IDENTITY>`."
+- "I have reviewed the current budget and commitment inventory and the proposed change is `<SPECIFIC_CHANGE>`."
+- "I have verified the current utilization of existing commitments is `<RATE>%`."
+- "I have assessed the blast radius: `<DESCRIPTION>`."
+- "I have financial authority for this change (or I confirm that `<APPROVER_NAME>` has provided written approval)."
+- "I approve this billing/commitment action."
+- For Savings Plan purchase: "I understand this is a `<1/3>`-year non-refundable commitment of approximately `<AMOUNT>` per hour and I approve the purchase."
+- For RI purchase: "I understand this is a `<1/3>`-year non-refundable commitment for `<INSTANCE_TYPE>` in `<REGION/ZONE>` and I approve the purchase."
+
+## Execution Steps
+
+1. Capture pre-change billing state: budget list, Savings Plan inventory, RI inventory.
+2. Confirm active operator has BSS administrator permissions.
+3. Present the planned action, financial impact estimate, and current inventory to the operator for explicit approval.
+4. Execute the mutation via the Alibaba Cloud BSS Console or API.
+5. Confirm the action is reflected in BSS and document the confirmation ID.
+
+## Rollback Procedure
+
+- **Budget threshold change** (reversible): Update the budget back to the previous threshold immediately via BSS Console or API. Re-enable any suspended services.
+- **Savings Plan purchase** (NOT reversible): Savings Plans cannot be cancelled or refunded. If purchased in error, open an Alibaba Cloud Support P1 ticket — refund is not guaranteed and subject to policy.
+- **Reserved Instance purchase** (NOT reversible): RI purchases are non-refundable. Contact Alibaba Cloud Support immediately if purchased in error.
+- For service suspension from budget threshold breach: restore threshold above current spend immediately; manually re-enable suspended services; assess for data loss in stateful workloads.
+
+## Post-Change Verification
+
+1. Confirm budget changes are reflected in BSS Console.
+2. Confirm Savings Plan or RI purchases appear in the commitment inventory.
+3. Verify no services were inadvertently suspended.
+4. Check billing alerts are active and notification targets are correct.
+
+## Response Shape
+
+1. BSS account and operator identity confirmed
+2. Current budget inventory and spend vs. threshold ratio
+3. Commitment inventory (Savings Plans, RIs) and utilization rates
+4. Blast radius assessment for budget threshold changes
+5. Financial authority approval status
+6. Execution confirmation
+7. Post-action verification results

package/skills/alibaba/alibaba-live-cost-budget-action-guard/metadata.json

@@ -0,0 +1,17 @@
+{
+  "id": "alibaba-live-cost-budget-action-guard",
+  "name": "Alibaba Cloud Live Cost Budget Action Guard",
+  "version": "0.1.0",
+  "type": "skill",
+  "provider": "alibaba",
+  "harnesses": ["codex","copilot","claude-code","cursor","gemini","kiro"],
+  "summary": "Gate live financial authority actions — budget threshold changes, Savings Plan purchases, Reserved Instance commitments. These are committed spend or can trigger immediate service suspension.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.alibabacloud.com/help/en/bss"
+  ],
+  "security_notes": "Non-refundable committed spend. Service suspension from budget threshold breach is immediate. Requires 6-step gate including blast radius assessment and written confirmation.",
+  "last_verified": "2026-05-08",
+  "path": "skills/alibaba/alibaba-live-cost-budget-action-guard",
+  "author": "github: Raishin"
+}

package/skills/alibaba/alibaba-live-cost-budget-action-guard/references/official-sources.md

@@ -0,0 +1,13 @@
+# Official sources
+
+Use this reference only when you need source grounding for Alibaba Cloud BSS billing 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/bss
+
+## 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.