@raishin/vanguard-frontier-agentic 1.5.0 → 1.6.0

package/skills/alibaba/alibaba-live-cost-budget-action-guard/references/workflow-and-output.md

@@ -0,0 +1,35 @@
+# Workflow and output contract
+
+Use this reference only when executing the full live financial authority gate — budget threshold changes, Savings Plan purchases, or Reserved Instance commitments.
+
+## Financial guard areas to check
+
+- Budget inventory: all active budgets, current thresholds, notification targets, spend vs. threshold ratio
+- Savings Plan commitments: active plans, hourly commitment amount, remaining term, utilization rate
+- Reserved Instance commitments: instance type, zone/regional scope, payment option, remaining term
+- Blast radius: services at risk from budget threshold reduction; suspension timeline; rollback path
+- Financial authority: approver identity, written confirmation, documented approval chain
+
+## Safe workflow
+
+1. **Frame scope** — confirm BSS account, operator identity, and the specific financial action requested
+2. **Collect evidence** — capture current budget and commitment inventory before any change; label: `live evidence`, `user-provided`, `documentation-based`, `inference`
+3. **Stress-test** — what is the blast radius of this action? what is non-refundable? what services suspend?
+4. **Gate** — require explicit written confirmation from the operator covering all required confirmation statements
+5. **Execute and verify** — execute the minimum scoped action; confirm in BSS; document confirmation ID
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Alibaba Cloud Live Cost Budget Action Guard: <scope>
+## Identity and authority confirmed
+## Current inventory
+## Blast radius assessment
+## Confirmation received
+## Execution result
+## Post-action verification
+```
+
+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-live-kms-key-mutation-guard/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: alibaba-live-kms-key-mutation-guard
+description: Gate KMS key deletion and disable operations. All data encrypted with a deleted CMK (OSS SSE-KMS, ECS encrypted disks, RDS/PolarDB TDE) becomes permanently and irrecoverably inaccessible. This guard enforces complete CMK dependency audits, deletion window confirmation, and explicit operator approval before any key state mutation.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-08"
+  category: security
+---
+
+# Alibaba Cloud Live KMS Key Mutation Guard
+
+## Purpose
+
+Act as the guarded live Alibaba Cloud operator for alibaba-live-kms-key-mutation-guard work. Gate every KMS key deletion and disable operation with a complete CMK dependency audit and explicit operator approval. Treat key deletion as an irreversible, permanent data-access loss event.
+
+## When to Use
+
+Use this skill when:
+
+- A KMS CMK (Customer Master Key) deletion is requested or scheduled
+- A KMS CMK is being disabled
+- A pending key deletion needs to be cancelled
+- A key rotation is being configured or triggered
+- An operator needs to audit CMK-dependent resources before a key operation
+- A key is being re-enabled after a disable operation
+
+## When NOT to Use
+
+Do not use this skill when:
+
+- The task is a read-only KMS audit with no mutation intent
+- The task involves only alias operations (alias creation/deletion does not affect key availability)
+- The task is creating a new CMK (no existing data at risk)
+- The task involves envelope encryption key management at the application layer with no KMS API calls
+
+## Key State Model
+
+Alibaba Cloud KMS keys have the following states:
+
+- **Enabled**: Key is active and can be used for encryption/decryption.
+- **Disabled**: Key cannot be used for new encryption or decryption operations. **This is reversible** — re-enable restores full functionality. Existing encrypted data remains accessible once re-enabled.
+- **PendingDeletion**: Key is scheduled for deletion. The deletion window is 7–30 days (default: 30 days). **This can be cancelled** during the pending window.
+- **Deleted**: Key has been permanently destroyed. **All encrypted data is irrecoverable.**
+
+Always recommend disable over deletion when the operator is uncertain about CMK dependencies.
+
+## CMK Dependency Categories
+
+Before any key deletion or disable, audit ALL of the following:
+
+- **OSS SSE-KMS**: Buckets using this CMK for server-side encryption. Objects become inaccessible if the key is deleted.
+- **ECS Encrypted Disks**: System and data disks encrypted with this CMK. Instances cannot decrypt disk data.
+- **ECS Snapshot Encryption**: Snapshots created from encrypted disks using this CMK.
+- **RDS Transparent Data Encryption (TDE)**: RDS instances with TDE enabled using this CMK.
+- **PolarDB TDE**: PolarDB clusters with TDE using this CMK.
+- **SLB/ALB HTTPS Certificates**: Certificates stored in KMS used by load balancers.
+- **Secrets Manager (SSM)**: Secrets encrypted with this CMK.
+
+## Pre-Flight Checklist
+
+Before executing any KMS key mutation, verify all of the following:
+
+1. **Key identity confirmed** — confirm the exact key ID (not alias). Run `aliyun kms DescribeKey --KeyId <KEY_ID>` to confirm key metadata, current state, and region.
+2. **Active RAM principal confirmed** — confirm the identity has `AliyunKMSFullAccess` assumed via STS for this specific operation.
+3. **CMK dependency audit complete** — enumerate all OSS buckets, ECS disks, RDS instances, PolarDB clusters, and SSM secrets using this key. This audit must be complete before any mutation.
+4. **Key state assessed** — confirm whether the key is Enabled, Disabled, or already in PendingDeletion state.
+5. **Disable vs. delete decision** — if the operator is uncertain about dependencies, recommend disable first. Only proceed to deletion after all dependencies are migrated or confirmed non-critical.
+6. **Deletion window confirmed** — if proceeding with deletion, confirm the scheduled deletion window (7–30 days). Default is 30 days.
+7. **Rollback plan** — for disable: re-enable is the rollback. For deletion: no rollback after the window expires.
+
+## Required Confirmation
+
+The operator must explicitly state all of the following before any mutation is executed:
+
+- "I confirm the key is `<KEY_ID>` in region `<REGION>` in account `<ACCOUNT_ID>`."
+- "I have completed the CMK dependency audit and the following dependencies are confirmed: `<list or NONE>`."
+- "I understand that key deletion is permanent after the `<N>`-day deletion window and all dependent encrypted data will be irrecoverable."
+- "I approve this key `<disable / deletion>` action."
+- For deletion: "I confirm all CMK-dependent data has been migrated or is non-critical."
+
+## Execution Steps
+
+1. Capture pre-change key state: `aliyun kms DescribeKey --KeyId <KEY_ID>`.
+2. Enumerate CMK dependencies (see CMK Dependency Categories above).
+3. Present the planned change, dependency audit results, and deletion window to the operator for explicit approval.
+4. Execute the mutation:
+   - Disable key: `aliyun kms DisableKey --KeyId <KEY_ID>`
+   - Schedule deletion: `aliyun kms ScheduleKeyDeletion --KeyId <KEY_ID> --PendingWindowInDays <7-30>`
+   - Cancel deletion: `aliyun kms CancelKeyDeletion --KeyId <KEY_ID>`
+   - Re-enable key: `aliyun kms EnableKey --KeyId <KEY_ID>`
+5. Confirm new key state: `aliyun kms DescribeKey --KeyId <KEY_ID>`.
+
+## Rollback Procedure
+
+- **Key disable** (reversible): `aliyun kms EnableKey --KeyId <KEY_ID>` — restores full encryption/decryption capability immediately.
+- **Key scheduled for deletion** (reversible during pending window): `aliyun kms CancelKeyDeletion --KeyId <KEY_ID>` — cancels the scheduled deletion. Act before the deletion window expires.
+- **Key deleted** (NOT reversible): A deleted key cannot be recovered. All data encrypted with this key is permanently inaccessible. Contact Alibaba Cloud Support immediately — there is no recovery path.
+
+## Post-Change Verification
+
+1. Confirm key state matches expected state: `aliyun kms DescribeKey --KeyId <KEY_ID>`.
+2. For disable: verify that applications dependent on this key are gracefully handling the disable state.
+3. For scheduled deletion: confirm deletion date and set a reminder to cancel if needed.
+4. Check ActionTrail for the key mutation event.
+5. Monitor CloudMonitor for any application-level errors indicating unexpected CMK access failures.
+
+## Response Shape
+
+1. Key ID and region confirmed
+2. Key status (enabled/disabled/pending-deletion)
+3. CMK dependency audit (OSS, ECS, RDS, PolarDB using this key)
+4. Disable vs. delete assessment
+5. Scheduled deletion window
+6. Approval status
+7. Post-action dependency verification

package/skills/alibaba/alibaba-live-kms-key-mutation-guard/metadata.json

@@ -0,0 +1,25 @@
+{
+  "id": "alibaba-live-kms-key-mutation-guard",
+  "name": "Alibaba Cloud Live KMS Key Mutation Guard",
+  "version": "0.1.0",
+  "type": "skill",
+  "provider": "alibaba",
+  "harnesses": [
+    "codex",
+    "copilot",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro"
+  ],
+  "summary": "Gate KMS key deletion and disable operations \u2014 all data encrypted with a deleted CMK becomes permanently and irrecoverably inaccessible.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.alibabacloud.com/help/en/kms",
+    "https://www.alibabacloud.com/help/en/kms/user-guide/schedule-key-deletion"
+  ],
+  "last_verified": "2026-05-08",
+  "path": "skills/alibaba/alibaba-live-kms-key-mutation-guard",
+  "author": "github: Raishin",
+  "security_notes": "KMS key deletion is irreversible after pending-deletion window. Key disable immediately prevents all decryption operations. CMK-encrypted data becomes permanently inaccessible when the key is deleted."
+}

package/skills/alibaba/alibaba-live-kms-key-mutation-guard/references/official-sources.md

@@ -0,0 +1,32 @@
+# Official Sources — Alibaba Cloud Live KMS Key Mutation Guard
+
+Authoritative Alibaba Cloud documentation for KMS key lifecycle and CMK dependency operations.
+
+## Core References
+
+- **KMS Overview** — https://www.alibabacloud.com/help/en/kms
+  KMS architecture, CMK types (software vs. hardware), key states, and key lifecycle.
+
+- **Schedule Key Deletion** — https://www.alibabacloud.com/help/en/kms/user-guide/schedule-key-deletion
+  How to schedule CMK deletion, configure the pending deletion window (7–30 days), and cancel a scheduled deletion.
+
+- **Disable and Enable a CMK** — https://www.alibabacloud.com/help/en/kms/user-guide/disable-or-enable-a-cmk
+  Disabling a key without deleting it — reversible operation that prevents new encryption/decryption.
+
+- **Key Rotation** — https://www.alibabacloud.com/help/en/kms/user-guide/automatic-key-rotation
+  Automatic and manual key rotation, key version management, and how rotation affects existing encrypted data.
+
+- **OSS Server-Side Encryption** — https://www.alibabacloud.com/help/en/oss/user-guide/server-side-encryption
+  How OSS uses KMS CMKs for SSE-KMS, and the dependency between OSS objects and KMS key availability.
+
+- **ECS Disk Encryption** — https://www.alibabacloud.com/help/en/ecs/user-guide/encryption-overview
+  ECS disk encryption using KMS CMKs, and the impact of key deletion on encrypted disk access.
+
+- **RDS TDE** — https://www.alibabacloud.com/help/en/rds/user-guide/configure-tde-for-an-arn-instance
+  Transparent Data Encryption for RDS using KMS CMKs.
+
+- **PolarDB TDE** — https://www.alibabacloud.com/help/en/polardb/user-guide/tde
+  Transparent Data Encryption for PolarDB clusters using KMS CMKs.
+
+- **KMS ActionTrail Events** — https://www.alibabacloud.com/help/en/actiontrail
+  Audit logging for KMS key mutations; querying ScheduleKeyDeletion, DisableKey, and EnableKey events.

package/skills/alibaba/alibaba-live-kms-key-mutation-guard/references/workflow-and-output.md

@@ -0,0 +1,115 @@
+# Workflow and Output — Alibaba Cloud Live KMS Key Mutation Guard
+
+## Step-by-Step Workflow
+
+### Phase 1: Key Identity and State Confirmation
+
+1. Describe the target key to confirm identity and current state:
+   ```
+   aliyun kms DescribeKey --KeyId <KEY_ID>
+   ```
+2. Confirm region and account ID match the intended target.
+3. Note the key state: `Enabled`, `Disabled`, or `PendingDeletion`.
+
+### Phase 2: CMK Dependency Audit
+
+4. Identify OSS buckets using SSE-KMS with this key ID (check bucket encryption config in OSS console or via API).
+5. Identify ECS disks encrypted with this key:
+   - Query ECS disk list filtered by KMS key ID in the console or via:
+     ```
+     aliyun ecs DescribeDisks --Encrypted true --KMSKeyId <KEY_ID>
+     ```
+6. Identify RDS instances with TDE using this key (check RDS console TDE settings).
+7. Identify PolarDB clusters with TDE using this key (check PolarDB console TDE settings).
+8. Identify SSM secrets encrypted with this key:
+   ```
+   aliyun kms ListSecrets
+   ```
+   Filter results for secrets using the target key ID.
+
+### Phase 3: Disable vs. Delete Assessment
+
+9. If any CMK dependencies are found: recommend **disable** first, not deletion.
+10. If the operator proceeds to deletion: confirm all dependent data has been migrated or is confirmed non-critical.
+11. Confirm the deletion window (7–30 days, default 30 days).
+
+### Phase 4: Approval Gate
+
+12. Present all evidence to the operator: key ID, current state, dependency audit results, disable vs. delete recommendation, deletion window.
+13. Require explicit written approval including acknowledgment that deletion is permanent.
+14. Do not proceed until approval is received.
+
+### Phase 5: Execution
+
+15. Execute the approved operation:
+    - Disable key:
+      ```
+      aliyun kms DisableKey --KeyId <KEY_ID>
+      ```
+    - Schedule deletion:
+      ```
+      aliyun kms ScheduleKeyDeletion --KeyId <KEY_ID> --PendingWindowInDays 30
+      ```
+    - Cancel deletion (if reversing):
+      ```
+      aliyun kms CancelKeyDeletion --KeyId <KEY_ID>
+      ```
+    - Re-enable key:
+      ```
+      aliyun kms EnableKey --KeyId <KEY_ID>
+      ```
+
+### Phase 6: Post-Action Verification
+
+16. Confirm new key state:
+    ```
+    aliyun kms DescribeKey --KeyId <KEY_ID>
+    ```
+17. Check ActionTrail for the mutation event.
+18. Monitor CloudMonitor for application-level errors indicating CMK access failures.
+
+## Expected Output Format
+
+The agent response for a KMS key mutation operation must include:
+
+```
+KEY IDENTITY
+  Key ID:         <key-id>
+  Key Alias:      <alias or NONE>
+  Region:         <region>
+  Account ID:     <account-id>
+  Current State:  <Enabled / Disabled / PendingDeletion>
+
+CMK DEPENDENCY AUDIT
+  OSS SSE-KMS Buckets:    [NONE | <bucket names>]
+  ECS Encrypted Disks:    [NONE | <disk IDs>]
+  RDS TDE Instances:      [NONE | <instance IDs>]
+  PolarDB TDE Clusters:   [NONE | <cluster IDs>]
+  SSM Secrets:            [NONE | <secret names>]
+
+DISABLE vs. DELETE
+  Recommendation:   [DISABLE FIRST | PROCEED TO DELETION]
+  Reason:           <dependency status or operator decision>
+
+DELETION WINDOW
+  Window:           <N days (if deletion selected)>
+  Deletion Date:    <date or N/A>
+
+APPROVAL STATUS
+  Operator:         <identity>
+  Approved:         [YES / NO / PENDING]
+  Permanent loss acknowledged: [YES / NO]
+
+ACTION
+  [BLOCKED — reason] OR [EXECUTING] OR [COMPLETE]
+
+ROLLBACK POSTURE
+  [REVERSIBLE — re-enable key or cancel deletion before <date>]
+  OR
+  [NOT REVERSIBLE — deletion window expired; data permanently inaccessible]
+
+VERIFICATION
+  Key State Post-Action:  <Enabled / Disabled / PendingDeletion>
+  ActionTrail Event:      [logged / not yet confirmed]
+  Application Errors:     <none detected / <description>>
+```

package/skills/alibaba/alibaba-live-oss-bucket-policy-guard/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: alibaba-live-oss-bucket-policy-guard
+description: Gate OSS bucket ACL and policy mutations — public-read/write ACL exposes data to internet crawlers within seconds; CN-* cross-border replication requires DSL Article 31 assessment.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-08"
+  category: storage
+---
+
+# Alibaba Cloud Live OSS Bucket Policy Guard
+
+## Purpose
+
+Act as the guarded live Alibaba Cloud operator for alibaba-live-oss-bucket-policy-guard work. Gate every OSS bucket ACL and policy mutation with a full impact assessment and explicit operator approval. Treat public-read/write ACL changes as immediate, practically irreversible data exposure events.
+
+## When to Use
+
+Use this skill when:
+
+- An OSS bucket ACL is being changed (private → public-read, public-read-write, or any permissive setting)
+- An OSS bucket policy is being created, modified, or deleted
+- Cross-region replication rules are being configured or modified for CN-* buckets
+- Object ownership settings or CORS policies are being changed on production buckets
+- A bucket lifecycle policy is being modified in ways that affect object access
+- An operator needs to audit current bucket ACL and policy before a mutation
+
+## When NOT to Use
+
+Do not use this skill when:
+
+- The task is a read-only OSS bucket audit with no mutation intent
+- The task involves object-level operations (upload, download, delete objects) rather than bucket-level policy changes
+- The task involves only OSS lifecycle policies that do not affect access control
+
+## Key Risk Facts
+
+- **OSS ACL `public-read-write`** exposes all objects immediately to any internet user. Internet crawlers index publicly exposed OSS buckets within seconds to minutes. Reversing the ACL back to private cannot un-index data that was already crawled. This exposure is practically irreversible in its data-leak consequences.
+- **OSS ACL `public-read`** makes all objects readable by the internet. Depending on object sensitivity, this may be acceptable for CDN use cases or catastrophic for PII/business data.
+- **Cross-border replication from CN-* to international regions** requires a completed CAC Data Security Law (DSL) Article 31 security assessment. Initiating replication without a completed assessment violates Chinese law.
+- **Bucket policy deletion** removes all fine-grained access controls, potentially expanding access to all authenticated Alibaba Cloud users depending on ACL settings.
+- **All mutations** require the 6-step live-guard gate.
+
+## Pre-Flight Checklist
+
+Before executing any OSS bucket ACL or policy mutation, verify all of the following:
+
+1. **Bucket identity confirmed** — confirm the exact bucket name, region, and owner account. Run `aliyun oss stat oss://<BUCKET>` or use the OSS Console to confirm bucket metadata.
+2. **Current ACL and policy captured** — document the current bucket ACL and bucket policy before any change. This is the rollback baseline.
+3. **Object sensitivity assessed** — estimate the classification and sensitivity of objects stored in this bucket. Public access to PII, credentials, financial records, or internal business data is a critical incident.
+4. **Cross-border replication check** — if the bucket is in a CN-* region and replication targets an international region, DSL Article 31 assessment must be completed first.
+5. **Blast radius assessed** — how many objects are in scope? what services or users depend on the current access model? what applications will break if access changes?
+6. **Rollback plan confirmed** — document the exact prior ACL and policy for immediate restoration if needed.
+
+## Required Confirmation
+
+The operator must explicitly state all of the following before any mutation is executed:
+
+- "I confirm the bucket is `<BUCKET_NAME>` in region `<REGION>` in account `<ACCOUNT_ID>`."
+- "I have reviewed the current ACL (`<CURRENT_ACL>`) and policy and the proposed change is `<SPECIFIC_CHANGE>`."
+- "I have assessed the data sensitivity of objects in this bucket: `<ASSESSMENT>`."
+- "I understand the blast radius of this change: `<DESCRIPTION>`."
+- For public-read or public-read-write ACL: "I understand that internet crawlers may index exposed data within seconds and that this exposure cannot be reversed for already-crawled data. I accept this risk."
+- For CN-* cross-border replication: "I confirm a completed DSL Article 31 assessment is on file for this data transfer."
+- "I approve this OSS bucket ACL/policy change."
+
+## Execution Steps
+
+1. Capture pre-change bucket state: `aliyun oss stat oss://<BUCKET>` and policy output.
+2. Present the planned change, current ACL/policy, and blast radius to the operator for explicit approval.
+3. Execute the mutation:
+   - Set ACL: `aliyun oss set-acl oss://<BUCKET> <ACL>` or via OSS Console.
+   - Set bucket policy: via OSS Console > Bucket > Permissions > Bucket Policy, or Alibaba Cloud OSS API.
+   - Configure replication: via OSS Console > Bucket > Data Replication, with DSL assessment confirmed.
+4. Confirm the new ACL and policy are in effect.
+
+## Rollback Procedure
+
+- **ACL change** (reversible): Restore the previous ACL immediately — `aliyun oss set-acl oss://<BUCKET> private`. Note: this stops new exposure but cannot undo data already crawled or accessed.
+- **Bucket policy change** (reversible): Restore the prior policy document via OSS Console or API.
+- **Cross-border replication** (reversible): Disable the replication rule via OSS Console; note that objects already replicated to the destination remain there.
+
+## Post-Change Verification
+
+1. Confirm new ACL is in effect: `aliyun oss stat oss://<BUCKET>`.
+2. Confirm bucket policy reflects the intended rules.
+3. Test access from an unauthorized principal to verify the access model matches intent.
+4. Check ActionTrail for the bucket mutation event.
+5. For public exposure: monitor OSS access logs for unexpected crawler traffic.
+
+## Response Shape
+
+1. Bucket name, region, and account confirmed
+2. Current ACL and policy captured
+3. Data sensitivity and blast radius assessment
+4. Cross-border replication DSL assessment status (if applicable)
+5. Operator confirmation received
+6. Execution confirmation
+7. Post-change verification results

package/skills/alibaba/alibaba-live-oss-bucket-policy-guard/metadata.json

@@ -0,0 +1,17 @@
+{
+  "id": "alibaba-live-oss-bucket-policy-guard",
+  "name": "Alibaba Cloud Live OSS Bucket Policy Guard",
+  "version": "0.1.0",
+  "type": "skill",
+  "provider": "alibaba",
+  "harnesses": ["codex","copilot","claude-code","cursor","gemini","kiro"],
+  "summary": "Gate OSS bucket ACL and policy mutations — public-read/write ACL exposes data to internet crawlers within seconds; CN-* cross-border replication requires DSL Article 31 assessment.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.alibabacloud.com/help/en/oss"
+  ],
+  "security_notes": "Public ACL exposure is practically irreversible (data indexed by crawlers). CN-* cross-border replication may violate DSL. 6-step gate required.",
+  "last_verified": "2026-05-08",
+  "path": "skills/alibaba/alibaba-live-oss-bucket-policy-guard",
+  "author": "github: Raishin"
+}

package/skills/alibaba/alibaba-live-oss-bucket-policy-guard/references/official-sources.md

@@ -0,0 +1,13 @@
+# Official sources
+
+Use this reference only when you need source grounding for Alibaba Cloud OSS 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/oss
+
+## 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-oss-bucket-policy-guard/references/workflow-and-output.md

@@ -0,0 +1,35 @@
+# Workflow and output contract
+
+Use this reference only when executing the full live OSS bucket ACL and policy mutation gate.
+
+## OSS bucket guard areas to check
+
+- Bucket ACL: current setting (private/public-read/public-read-write); intended change; data sensitivity assessment
+- Bucket policy: current policy document; intended change; affected principals and resources
+- Cross-border replication: source region (CN-* or international); destination region; DSL Article 31 assessment status
+- Blast radius: object count and sensitivity; dependent services and users; rollback baseline (prior ACL and policy captured)
+- Operator authorization: identity confirmed; explicit written confirmation covering all required statements
+
+## Safe workflow
+
+1. **Frame scope** — confirm bucket identity, current ACL/policy, and the specific mutation requested
+2. **Collect evidence** — capture current state before any change; label: `live evidence`, `user-provided`, `documentation-based`, `inference`
+3. **Stress-test** — what data is exposed? what is the CN-* replication status? what is the rollback path?
+4. **Gate** — require explicit written confirmation from the operator covering all required confirmation statements
+5. **Execute and verify** — execute the minimum scoped change; confirm new state; monitor access logs
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Alibaba Cloud Live OSS Bucket Policy Guard: <scope>
+## Bucket identity and current state
+## Data sensitivity and blast radius assessment
+## Cross-border replication check (if applicable)
+## Confirmation received
+## Execution result
+## Post-change verification
+```
+
+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-live-ram-policy-change-guard/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: alibaba-live-ram-policy-change-guard
+description: Gate RAM policy/role mutations against the Alibaba Cloud account hierarchy. RAM AdministratorAccess assignment, policy deletion with active STS tokens, and Resource Directory Control Policy changes carry account-wide or org-wide blast radius. This guard enforces blast-radius assessment, STS token impact analysis, and explicit authority approval before any policy mutation is executed.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-08"
+  category: security
+---
+
+# Alibaba Cloud Live RAM Policy Change Guard
+
+## Purpose
+
+Act as the guarded live Alibaba Cloud operator for alibaba-live-ram-policy-change-guard work. Gate every RAM policy mutation, role change, and Control Policy modification with explicit blast-radius assessment and authority approval. Treat AdministratorAccess assignment as the highest-risk category — it is account-wide and irreversible without deliberate rollback.
+
+## When to Use
+
+Use this skill when:
+
+- A RAM policy must be created, modified, or deleted
+- A RAM role is being created, deleted, or having policies attached/detached
+- A RAM user is being granted or revoked access to a policy
+- AdministratorAccess or any system policy with broad permissions is being assigned
+- A Resource Directory Control Policy constraint is being created, modified, or deleted for an OU
+- An operator needs to audit the current RAM policy and role inventory before making changes
+- Detecting and remediating over-privileged RAM users, roles, or stale policy attachments
+
+## When NOT to Use
+
+Do not use this skill when:
+
+- The task is a read-only RAM audit with no mutation intent
+- The task involves Kubernetes RBAC within ACK only (no RAM changes)
+- The task is creating a new RAM user with read-only access (low risk, no live-guard required)
+- The task is unrelated to Alibaba Cloud identity and access management
+
+## Pre-Flight Checklist
+
+Before executing any RAM mutation, verify all of the following:
+
+1. **Account identity confirmed** — explicitly state the target Alibaba Cloud account ID. Confirm via `aliyun ram GetAccountAlias` or the console.
+2. **Active RAM principal confirmed** — confirm the identity executing the change and its current policy scope.
+3. **Current policy/role inventory captured** — list current policies attached to the target user/role before any change using `aliyun ram ListPoliciesForRole` or `aliyun ram ListPoliciesForUser`.
+4. **Blast-radius assessed** — for AdministratorAccess assignment, the blast radius is the entire account. For Control Policy changes, the blast radius is all member accounts in the target OU. Document this explicitly.
+5. **Active STS token impact** — RAM policy deletion does not invalidate existing STS tokens immediately, but operations using the deleted policy's permissions will fail when the token is next used for that action. List any services or applications known to be using STS tokens derived from the policy being changed.
+6. **Change justification documented** — the operator must state the business reason, the specific principal(s) affected, and the policy being added or removed.
+7. **Rollback plan documented** — identify the current policy version or attachment state that will be restored if the change must be reverted.
+
+## Required Confirmation
+
+The operator must explicitly state all of the following before any mutation is executed:
+
+- "I confirm the target account is `<ACCOUNT_ID>`."
+- "I confirm the principal is `<RAM_USER_NAME / ROLE_NAME>` and the policy change is `<ATTACH/DETACH/CREATE/DELETE> <POLICY_NAME>`."
+- "I understand the blast radius of this change: `<scope statement>`."
+- "I have assessed the active STS token impact and it is `<acceptable / none known>`."
+- "I approve this RAM change."
+- For AdministratorAccess assignment: "I confirm I have the authority to grant account-wide admin access and this is explicitly required."
+
+## Execution Steps
+
+1. Capture pre-change RAM policy and role inventory snapshot.
+2. Confirm active RAM principal has `AliyunRAMFullAccess` (assumed via STS for specific change only).
+3. Present the planned change, blast-radius assessment, and STS token impact to the operator for explicit approval.
+4. Execute the mutation via the RAM console or Alibaba Cloud CLI:
+   - Attach policy to role: `aliyun ram AttachPolicyToRole --PolicyType <System/Custom> --PolicyName <NAME> --RoleName <ROLE>`
+   - Detach policy from role: `aliyun ram DetachPolicyFromRole --PolicyType <System/Custom> --PolicyName <NAME> --RoleName <ROLE>`
+   - Attach policy to user: `aliyun ram AttachPolicyToUser --PolicyType <System/Custom> --PolicyName <NAME> --UserName <USER>`
+   - Delete custom policy: `aliyun ram DeletePolicy --PolicyName <NAME>`
+   - Create custom policy: `aliyun ram CreatePolicy --PolicyName <NAME> --PolicyDocument <DOCUMENT>`
+5. Capture post-change inventory snapshot and diff against pre-change snapshot.
+
+## Rollback Procedure
+
+- **Policy attachment** (reversible): Detach the policy with `DetachPolicyFromRole` or `DetachPolicyFromUser`. Effect is immediate.
+- **Policy detachment** (reversible but risky): Re-attach the policy. If the detachment caused a service lockout, restore it immediately.
+- **Policy deletion** (NOT reversible): A deleted custom policy cannot be recovered. Re-create the policy from the documented pre-change version. System policies (AliyunXxxAccess) are not deletable.
+- **AdministratorAccess assignment** (reversible — detach the policy): Detach `AdministratorAccess` from the principal immediately if granted in error.
+
+## Post-Change Verification
+
+1. Run `aliyun ram ListPoliciesForRole --RoleName <ROLE>` or `aliyun ram ListPoliciesForUser --UserName <USER>` — confirm the policy list reflects the intended change.
+2. Test access for the affected principal to verify the change has the expected effect.
+3. Check ActionTrail for the change event: query for `EventName` containing the mutation operation.
+4. For Control Policy changes, confirm constraint enforcement in Resource Directory console.
+
+## Response Shape
+
+1. Account and RAM principal confirmed
+2. Current policy/role inventory
+3. Proposed change and blast-radius assessment
+4. Active STS token impact
+5. Approval status
+6. Applied change
+7. Post-change access verification

package/skills/alibaba/alibaba-live-ram-policy-change-guard/metadata.json

@@ -0,0 +1,25 @@
+{
+  "id": "alibaba-live-ram-policy-change-guard",
+  "name": "Alibaba Cloud Live RAM Policy Change Guard",
+  "version": "0.1.0",
+  "type": "skill",
+  "provider": "alibaba",
+  "harnesses": [
+    "codex",
+    "copilot",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro"
+  ],
+  "summary": "Gate RAM policy/role mutations \u2014 account-wide blast radius, privilege escalation risk, service breakage from accidental denial.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.alibabacloud.com/help/en/ram",
+    "https://www.alibabacloud.com/help/en/ram/user-guide/create-a-custom-policy"
+  ],
+  "last_verified": "2026-05-08",
+  "path": "skills/alibaba/alibaba-live-ram-policy-change-guard",
+  "author": "github: Raishin",
+  "security_notes": "RAM policy with AdministratorAccess grants full account-wide control. Removing a RAM role trust policy immediately breaks all cross-account access. STS token revocation affects all active sessions for that role."
+}

package/skills/alibaba/alibaba-live-ram-policy-change-guard/references/official-sources.md

@@ -0,0 +1,32 @@
+# Official Sources — Alibaba Cloud Live RAM Policy Change Guard
+
+Authoritative Alibaba Cloud documentation for RAM policy, role, and access management operations.
+
+## Core References
+
+- **RAM Overview** — https://www.alibabacloud.com/help/en/ram
+  RAM architecture, principals (users, groups, roles), policy types, and trust relationships.
+
+- **Create a Custom Policy** — https://www.alibabacloud.com/help/en/ram/user-guide/create-a-custom-policy
+  Policy syntax, version management, and best practices for least-privilege custom policies.
+
+- **Attach a Policy to a RAM Role** — https://www.alibabacloud.com/help/en/ram/user-guide/grant-permissions-to-a-ram-role
+  How to attach and detach system and custom policies from RAM roles.
+
+- **STS Overview** — https://www.alibabacloud.com/help/en/ram/user-guide/what-is-sts
+  STS token issuance, TTL configuration, and how policy changes affect active STS sessions.
+
+- **RAM Policy Language** — https://www.alibabacloud.com/help/en/ram/user-guide/policy-language
+  RAM policy syntax reference, condition operators, and wildcard usage.
+
+- **Resource Directory Overview** — https://www.alibabacloud.com/help/en/resource-management
+  Multi-account governance, OU structure, and Control Policy hierarchy.
+
+- **Control Policies** — https://www.alibabacloud.com/help/en/resource-management/user-guide/control-policy-overview
+  Creating and managing Control Policies (service control policies) for Resource Directory OUs.
+
+- **ActionTrail Overview** — https://www.alibabacloud.com/help/en/actiontrail
+  Audit logging for RAM mutations, event structure, and querying RAM change events.
+
+- **RAM Best Practices** — https://www.alibabacloud.com/help/en/ram/user-guide/ram-best-practices
+  Least-privilege guidance, STS over access keys, and role-based access patterns.