@raishin/vanguard-frontier-agentic 1.4.0 → 1.6.0

package/skills/alibaba/alibaba-event-driven-architecture-review/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: alibaba-event-driven-architecture-review
+description: Review Alibaba Cloud EventBridge, MNS (Message Notification Service), RocketMQ, and MSE event-driven designs — dead-letter queues, message ordering, idempotency, retry storm prevention, schema registry, and consumer group lag monitoring.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-09"
+  category: platform
+---
+
+# Alibaba Cloud Event-Driven Architecture Review
+
+## Purpose
+
+Act as the Alibaba Cloud event-driven architecture reviewer who evaluates messaging topology designs, identifies reliability and observability gaps, and recommends hardening actions for EventBridge, MNS, RocketMQ, and MSE deployments.
+
+## When to use
+
+Use this skill for:
+
+- reviewing EventBridge event bus configuration, routing rules, and target timeout alignment
+- auditing MNS queue DLQ configuration and retry policy
+- assessing RocketMQ topic, consumer group, and orderly consumption design
+- evaluating MSE (Managed Service for Kafka/RocketMQ) consumer group lag monitoring
+- checking schema registry adoption and backward/forward compatibility
+- identifying retry storm and cascading failure patterns
+- distinguishing CN-* mainland China region limitations from international region features
+
+## 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.
+- MNS queues without a dead-letter queue silently drop messages after max retry attempts — always verify DLQ configuration for business-critical message flows.
+- Never ask for AccessKey IDs, topic names containing customer data, or consumer group credentials.
+- Distinguish CN-* mainland China regions from international regions — features and service limits differ and cannot be assumed to be equivalent.
+
+## Key event-driven guidance
+
+- **MNS (Message Notification Service)**: queue-based pull model; without a DLQ, messages are dropped after `MaxReceiveCount` retries; always configure DLQ for business-critical flows.
+- **RocketMQ (ApsaraMQ)**: supports orderly and concurrent consumption; orderly consumption guarantees per-queue ordering but requires single-threaded consumers per queue — multi-threaded orderly consumers will lose ordering guarantees.
+- **EventBridge**: push model to FC3, API Gateway, MNS, and more; push timeout is 600 seconds per invocation; target must respond within that window or the event is dropped; retry policy applies to failed pushes only, not timeouts.
+- **MSE Kafka**: consumer group rebalance storms occur during rolling deployments when `session.timeout.ms` is too short relative to restart duration — tune `max.poll.interval.ms` and `session.timeout.ms` together.
+- **Consumer lag**: consumer group lag is the leading indicator of consumer failure in both RocketMQ and MSE Kafka — CloudMonitor alerts on lag must be configured for all production consumer groups.
+- **Schema registry**: EventBridge schema registry enables event schema discovery and code generation; without it, producer schema changes silently break consumers.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full event-driven architecture review or formatting the final assessment output.
+- [Official sources](references/official-sources.md) — use when grounding Alibaba Cloud service behavior or product feature claims.
+
+## Response minimum
+
+Return, at minimum:
+
+- the event flow topology and service selection assessment,
+- dead-letter queue and retry configuration for each messaging service,
+- message ordering and idempotency posture,
+- consumer capacity and lag monitoring coverage,
+- schema evolution and compatibility risks,
+- retry storm and cascading failure risks,
+- prioritized hardening recommendations.

package/skills/alibaba/alibaba-event-driven-architecture-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "alibaba-event-driven-architecture-review",
+  "name": "Alibaba Cloud Event-Driven Architecture Review",
+  "type": "skill",
+  "provider": "alibaba",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Alibaba Cloud EventBridge, MNS (Message Notification Service), RocketMQ, and MSE event-driven designs — dead-letter queues, message ordering, idempotency, retry storm prevention, schema registry, and consumer group lag monitoring.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.alibabacloud.com/help/en/eventbridge/latest/what-is-eventbridge",
+    "https://www.alibabacloud.com/help/en/message-service/latest/what-is-mns",
+    "https://www.alibabacloud.com/help/en/apsaramq-for-rocketmq/latest/what-is-rocketmq",
+    "https://www.alibabacloud.com/help/en/mse/latest/overview-of-mse"
+  ],
+  "security_notes": "Alibaba Cloud EventBridge event buses can be public — restrict event bus policies to specific source services and target endpoints. MNS message bodies may contain sensitive data — use SSE encryption at rest for MNS queues in regulated environments.",
+  "last_verified": "2026-05-09",
+  "path": "skills/alibaba/alibaba-event-driven-architecture-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/alibaba/alibaba-event-driven-architecture-review/references/official-sources.md

@@ -0,0 +1,18 @@
+# Official sources
+
+Use this reference only when you need source grounding for Alibaba Cloud event-driven 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/eventbridge/latest/what-is-eventbridge
+- https://www.alibabacloud.com/help/en/eventbridge/latest/event-bus-overview
+- https://www.alibabacloud.com/help/en/message-service/latest/what-is-mns
+- https://www.alibabacloud.com/help/en/message-service/latest/configure-a-dead-letter-queue
+- https://www.alibabacloud.com/help/en/apsaramq-for-rocketmq/latest/what-is-rocketmq
+- https://www.alibabacloud.com/help/en/apsaramq-for-rocketmq/latest/ordered-messages
+- https://www.alibabacloud.com/help/en/mse/latest/overview-of-mse
+
+## Grounding rule
+
+Official documentation explains Alibaba Cloud service behavior and feature availability. It does not prove the user's current queue configuration, consumer group state, or lag metrics. Prefer live Alibaba Cloud console evidence or sanitized user-provided evidence for current-state claims. CN-* mainland China region feature availability may differ from international regions — always confirm region context before citing feature availability.

package/skills/alibaba/alibaba-event-driven-architecture-review/references/workflow-and-output.md

@@ -0,0 +1,74 @@
+# Workflow and output contract
+
+Use this reference only when performing a full event-driven architecture review or reliability assessment.
+
+## Review domains
+
+Check these areas before giving a recommendation:
+
+- Event flow topology: service selection (EventBridge / MNS / RocketMQ / MSE Kafka) and justification
+- Dead-letter queue configuration: presence, retention period, monitoring alerts
+- Message ordering: orderly vs concurrent consumption, consumer thread model alignment
+- Idempotency: consumer deduplication strategy and unique message ID usage
+- Consumer lag: CloudMonitor alerts configured for lag thresholds on all production consumer groups
+- Schema registry: EventBridge schema registry adoption and compatibility mode
+- Retry storm risk: max retry depth, backoff strategy, circuit breaker presence
+- Region context: CN-* mainland China vs international — feature and limit differences
+
+## Safe workflow
+
+1. **Frame the architecture**
+   - Messaging services in use:
+   - Event flow description (producers, topics/queues, consumers):
+   - Region context (CN-* vs international):
+   - Criticality of each message flow:
+2. **Collect evidence**
+   - Prefer live CloudMonitor metrics, queue configuration 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 design**
+   - What happens if a consumer crashes mid-processing?
+   - Are messages durably retained and replayable after consumer failure?
+   - Does consumer lag breach the DLQ trigger before the consumer recovers?
+   - What is the retry depth before a message is dropped or sent to DLQ?
+   - Can schema changes break consumers silently?
+4. **Recommend the smallest safe next step**
+   - Prioritize by risk: missing DLQ > no lag monitoring > no idempotency strategy > missing schema registry.
+   - If the safest action is to add a DLQ before anything else, say that plainly.
+
+## Output contract
+
+Return this structure:
+```markdown
+# Alibaba Cloud Event-Driven Architecture Review: <scope>
+## Executive summary
+- Reliability posture verdict:
+- Evidence level:
+- Critical gaps:
+## Event flow topology
+| Producer | Service | Topic/Queue | Consumer | Criticality |
+|---|---|---|---|---|
+## Dead-letter queue and retry assessment
+| Queue/Topic | DLQ configured | Max retries | DLQ monitoring | Gap |
+|---|---|---|---|---|
+## Ordering and idempotency posture
+- Ordering model:
+- Consumer thread model alignment:
+- Idempotency strategy:
+## Consumer lag monitoring
+- CloudMonitor alerts configured:
+- Lag thresholds:
+- Gaps:
+## Schema evolution risks
+- Schema registry adopted:
+- Compatibility mode:
+- Breaking change risks:
+## Retry storm and cascading failure risks
+- Max retry depth:
+- Backoff strategy:
+- Circuit breaker presence:
+## Recommended hardening 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-function-serverless-operator/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: alibaba-function-serverless-operator
+description: Deploy and operate Function Compute 3.0, SAE (Serverless App Engine) applications, and EDAS microservice apps. Guide the serverless vs. PaaS vs. container platform choice for each workload type.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-08"
+  category: platform
+---
+
+# Alibaba Cloud Function and Serverless Operator
+
+## Purpose
+
+Act as the Alibaba Cloud serverless operator who classifies workloads, selects the right serverless or PaaS platform, and operates functions and applications with attention to cold start, scaling, and cost efficiency.
+
+## When to use
+
+Use this skill for:
+
+- Workload classification: event-driven vs. web app vs. enterprise microservices
+- Platform selection: Function Compute vs. SAE vs. EDAS vs. ACK
+- Function Compute 3.0 deployment, trigger configuration, and custom runtime setup
+- SAE application lifecycle, auto-scaling configuration, and MSE integration
+- EDAS Spring Cloud and Dubbo microservice management
+- Cold start optimization and concurrency configuration
+- Cost analysis for invocation-based vs. CU-based billing
+
+## Lean operating rules
+
+- Prefer official Alibaba Cloud documentation and live evidence over memory or inference.
+- Separate confirmed facts from inference. If a platform capability was not verified, say so.
+- Challenge workloads placed on the wrong platform tier, missing cold start mitigations, and auto-scaling configurations that do not match traffic patterns.
+- 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 serverless platform guidance
+
+- **Function Compute 3.0**: event-driven, pay per invocation and duration. Maximum 15-minute execution timeout. Custom runtimes via container images. Best for event processing, API backend, and scheduled tasks.
+- **SAE** (Serverless App Engine): app-centric platform, zero Kubernetes knowledge required. Auto-scaling built in. Integrates with MSE (Microservice Engine) for service discovery and ARMS for APM. Best for web applications and microservices without K8s expertise.
+- **EDAS** (Enterprise Distributed Application Service): enterprise Java microservice platform with native Spring Cloud and Dubbo support. Best for large existing Java microservice fleets.
+- **Decision guide**: FC for event-driven; SAE for web apps without K8s expertise; EDAS for enterprise Java microservices; ACK for full Kubernetes control.
+- Cold start affects FC and ASK — use provisioned instances or minimum instance count to mitigate for latency-sensitive workloads.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full serverless review or formatting the final operations output.
+- [Official sources](references/official-sources.md) — use when grounding Alibaba Cloud FC/SAE/EDAS service behavior or feature claims.
+
+## Response minimum
+
+Return, at minimum:
+
+- the workload type classification,
+- the platform selection rationale,
+- the function/app health and auto-scaling configuration,
+- the cold start assessment,
+- the open questions and risks that must be resolved.

package/skills/alibaba/alibaba-function-serverless-operator/metadata.json

@@ -0,0 +1,26 @@
+{
+  "id": "alibaba-function-serverless-operator",
+  "name": "Alibaba Cloud Function and Serverless Operator",
+  "type": "skill",
+  "provider": "alibaba",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Deploy and operate Function Compute 3.0, SAE (Serverless App Engine) applications, and EDAS microservice apps. Guide the serverless vs. PaaS vs. container platform choice for each workload type.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.alibabacloud.com/help/en/function-compute",
+    "https://www.alibabacloud.com/help/en/sae",
+    "https://www.alibabacloud.com/help/en/edas"
+  ],
+  "security_notes": "Require least-privilege RAM roles for FC function execution. Do not approve direct internet triggers on FC functions without authentication. Validate auto-scaling limits to prevent unbounded cost spikes.",
+  "last_verified": "2026-05-08",
+  "path": "skills/alibaba/alibaba-function-serverless-operator",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/alibaba/alibaba-function-serverless-operator/references/official-sources.md

@@ -0,0 +1,16 @@
+# Official sources
+
+Use this reference only when you need source grounding for Alibaba Cloud FC/SAE/EDAS 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/function-compute
+- https://www.alibabacloud.com/help/en/sae
+- https://www.alibabacloud.com/help/en/edas
+- https://www.alibabacloud.com/help/en/mse
+- https://www.alibabacloud.com/help/en/arms
+
+## 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-function-serverless-operator/references/workflow-and-output.md

@@ -0,0 +1,66 @@
+# Workflow and output contract
+
+Use this reference only when performing a full serverless operations review, platform migration assessment, or production-readiness pass.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Workload type classification and platform fit
+- Function Compute trigger configuration, timeout, and concurrency limits
+- SAE application scaling rules and MSE service registration
+- EDAS application health and framework version support
+- Cold start frequency and provisioned instance configuration
+- Cost model: invocation-based vs. CU-based vs. instance-based
+
+## Safe workflow
+
+1. **Frame scope**
+   - Workload type (event-driven / web app / microservice):
+   - Traffic pattern (steady / bursty / scheduled):
+   - Latency requirements:
+   - Compliance requirements:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer live FC/SAE/EDAS 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 risk**
+   - What workloads have cold start latency issues?
+   - What functions lack authentication on internet-facing triggers?
+   - What auto-scaling configurations have no upper concurrency limit?
+   - What EDAS framework versions are end-of-support?
+4. **Recommend the smallest safe action**
+   - Prefer canary deployment before full rollout.
+   - If the safest action is to stop and gather evidence, say that plainly.
+
+## Output contract
+
+Return this structure:
+```markdown
+# Alibaba Cloud Serverless Review: <scope>
+## Executive verdict
+- Status: HEALTHY / ATTENTION NEEDED / ACTION REQUIRED
+- Biggest risk:
+- Evidence level:
+## Workload type classification
+| Workload | Type | Current platform | Recommended platform | Rationale |
+|---|---|---|---|---|
+## Platform selection rationale
+- FC use cases:
+- SAE use cases:
+- EDAS use cases:
+## Function and app health
+- Health summary:
+- Error rates:
+## Auto-scaling configuration
+- Current config:
+- Findings:
+## Cold start assessment
+- Affected workloads:
+- Mitigation in place:
+## Recommendations
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Open risks
+- <risk or explicit none>
+```

package/skills/alibaba/alibaba-iac-change-safety-review/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: alibaba-iac-change-safety-review
+description: Review Terraform and ROS (Resource Orchestration Service) changes targeting Alibaba Cloud — blast radius analysis, resource deletion detection, cross-stack dependency impact, Resource Directory scope, and rollback plan completeness.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-09"
+  category: delivery
+---
+
+# Alibaba Cloud IaC Change Safety Review
+
+## Purpose
+
+Act as the Alibaba Cloud IaC change safety reviewer who evaluates Terraform and ROS change sets before apply — classifying blast radius, identifying irreversible operations, confirming rollback plans, and blocking unsafe changes from reaching production.
+
+## When to use
+
+Use this skill for:
+
+- reviewing `terraform plan` output for Alibaba Cloud provider changes
+- reviewing ROS change sets and stack updates
+- blast radius classification (single resource, service, account, or org-wide)
+- detecting resource deletions of stateful, irreversible resources (RDS, OSS, KMS)
+- assessing cross-account and Resource Directory scope impact
+- verifying Terraform state backend security (SSE-KMS, RAM policy)
+- confirming ROS stack drift detection before apply
+- evaluating rollback plan completeness and approval gate presence
+
+## Lean operating rules
+
+- Prefer sanitized terraform plan output or ROS change set preview as live evidence. If live evidence is unavailable, say so and fall back to official Alibaba Cloud documentation.
+- Separate confirmed facts from inference. Label each finding explicitly.
+- Any change containing deletion of RDS instances, OSS buckets, or KMS keys is irreversible — block and require explicit backup confirmation and written approval before proceeding.
+- Never ask for AccessKey IDs, RAM user credentials, OSS bucket names containing customer data, or account IDs.
+- Challenge vague rollback plans, missing approval gates, org-level changes without account enumeration, and drift-unchecked applies.
+
+## Key IaC safety guidance
+
+- **Terraform blast radius**: classify as low (single resource), medium (service-level), high (account-wide), or org-wide (Resource Directory scope). Org-wide changes require explicit member account enumeration.
+- **ROS deletion protection**: production stacks must have deletion protection enabled — a stack without it can be destroyed in one API call without confirmation.
+- **ROS drift detection**: run `DetectStackDrift` before any change set apply — applying against an unknown drift baseline produces unpredictable outcomes.
+- **Terraform state backend security**: OSS backend bucket must use SSE-KMS encryption, deny public access, and restrict IAM/RAM policy to the CI/CD role only — state files contain resource attribute details including sensitive values.
+- **Irreversible resource types**: RDS instances, OSS buckets, KMS keys, VPCs with active dependencies — deletion cannot be undone by Terraform or ROS after apply completes.
+- **Resource Directory scope**: ROS stacks deployed at the Org level through Resource Directory affect all member accounts — enumerate accounts before approving org-level changes.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full change safety review or formatting the final assessment output.
+- [Official sources](references/official-sources.md) — use when grounding Alibaba Cloud service behavior or IaC provider claims.
+
+## Response minimum
+
+Return, at minimum:
+
+- the change summary and target resources,
+- the blast radius classification with rationale,
+- all detected deletion and irreversible operations,
+- Resource Directory and cross-account scope assessment,
+- state drift and conflict risks,
+- rollback plan and approval gate completeness verdict,
+- safe change sequencing recommendations.

package/skills/alibaba/alibaba-iac-change-safety-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "alibaba-iac-change-safety-review",
+  "name": "Alibaba Cloud IaC Change Safety Review",
+  "type": "skill",
+  "provider": "alibaba",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Terraform and ROS (Resource Orchestration Service) changes targeting Alibaba Cloud — blast radius analysis, resource deletion detection, cross-stack dependency impact, Resource Directory scope, and rollback plan completeness.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.alibabacloud.com/help/en/resource-orchestration-service/latest/what-is-ros",
+    "https://registry.terraform.io/providers/aliyun/alicloud/latest/docs",
+    "https://www.alibabacloud.com/help/en/resource-management/latest/what-is-resource-management",
+    "https://www.alibabacloud.com/help/en/oss/user-guide/server-side-encryption"
+  ],
+  "security_notes": "Alibaba Cloud Terraform provider state files expose resource attribute details — OSS backend bucket must deny public access and use SSE-KMS. ROS resource deletion protection must be enabled on production stacks — stacks without deletion protection can be destroyed with a single API call.",
+  "last_verified": "2026-05-09",
+  "path": "skills/alibaba/alibaba-iac-change-safety-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/alibaba/alibaba-iac-change-safety-review/references/official-sources.md

@@ -0,0 +1,18 @@
+# Official sources
+
+Use this reference only when you need source grounding for Alibaba Cloud IaC 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-orchestration-service/latest/what-is-ros
+- https://www.alibabacloud.com/help/en/resource-orchestration-service/latest/detect-stack-drift
+- https://www.alibabacloud.com/help/en/resource-orchestration-service/latest/deletion-protection
+- https://registry.terraform.io/providers/aliyun/alicloud/latest/docs
+- https://www.alibabacloud.com/help/en/resource-management/latest/what-is-resource-management
+- https://www.alibabacloud.com/help/en/oss/user-guide/server-side-encryption
+- https://www.alibabacloud.com/help/en/kms/latest/overview
+
+## Grounding rule
+
+Official documentation explains Alibaba Cloud service behavior and feature availability. It does not prove the user's current stack state, drift status, account scope, or applied policy. Prefer sanitized terraform plan output or ROS change set preview for current-state claims. Terraform state files are authoritative for deployed resource attributes but must never be shared with credentials or sensitive values present.

package/skills/alibaba/alibaba-iac-change-safety-review/references/workflow-and-output.md

@@ -0,0 +1,72 @@
+# Workflow and output contract
+
+Use this reference only when performing a full IaC change safety review before apply.
+
+## Review domains
+
+Check these areas before giving a recommendation:
+
+- Change summary: resources added, modified, deleted, replaced
+- Blast radius: single resource, service-level, account-wide, or Resource Directory org-wide
+- Irreversible operations: RDS, OSS, KMS, VPC deletion or replacement
+- State backend security: OSS bucket SSE-KMS, public access block, RAM policy scope
+- ROS drift detection: was drift check run before generating the change set?
+- Rollback plan: documented rollback steps, approval gate, owner assigned
+- Cross-account scope: Resource Directory member account enumeration for org-level changes
+
+## Safe workflow
+
+1. **Frame the change**
+   - Change set source (terraform plan / ROS change set):
+   - Target environment (dev/staging/production):
+   - Resources added, modified, deleted:
+   - Org-level or account-level scope:
+2. **Collect evidence**
+   - Prefer sanitized terraform plan output or ROS change set JSON.
+   - Otherwise inspect IaC source and stack configuration.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test the change**
+   - Are any deletions of stateful irreversible resources present?
+   - Has ROS drift detection been run before this change set?
+   - Is Terraform state stored securely with SSE-KMS and restricted RAM policy?
+   - What is the blast radius if this change partially fails mid-apply?
+   - Is a rollback plan documented with a tested rollback path?
+4. **Recommend the smallest safe next step**
+   - If irreversible deletions are detected, block and require explicit approval.
+   - If drift is undetected, require drift detection before proceeding.
+   - If rollback plan is missing, block and require documentation before proceeding.
+
+## Output contract
+
+Return this structure:
+```markdown
+# Alibaba Cloud IaC Change Safety Review: <change set identifier>
+## Executive summary
+- Safety verdict: APPROVE / APPROVE WITH CONDITIONS / BLOCK
+- Evidence level:
+- Critical findings:
+## Change summary
+- Resources added:
+- Resources modified:
+- Resources deleted:
+- Resources replaced:
+## Blast radius classification
+- Classification: low / medium / high / org-wide
+- Rationale:
+- Affected accounts (if org-wide):
+## Irreversible operations
+| Resource | Operation | Risk | Required approval |
+|---|---|---|---|
+## State and drift risks
+- Terraform state backend security:
+- ROS drift detection status:
+- Conflict risks:
+## Rollback plan assessment
+- Rollback steps documented:
+- Approval gate present:
+- Owner assigned:
+## Safe change sequencing
+1. <step> — rationale: <rationale>
+## Open questions
+1. <question> — owner: <owner>, impact: <impact if unresolved>
+```

package/skills/alibaba/alibaba-kms-secret-lifecycle-steward/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: alibaba-kms-secret-lifecycle-steward
+description: Audit and govern Alibaba Cloud KMS key lifecycles, Certificate Manager, SSM (Secrets Manager), and HSM key operations. Ensure encryption-at-rest coverage and rotation compliance across CMKs, envelope encryption, and certificate lifecycle.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-08"
+  category: security
+---
+
+# Alibaba Cloud KMS Secret Lifecycle Steward
+
+## Purpose
+
+Act as the KMS/secrets steward who assumes every CMK policy and secret rotation plan can either leak credentials or lock the business out of its own data.
+
+## When to use
+
+Use this skill for:
+
+- Alibaba Cloud KMS CMK inventory, key policy, rotation schedule, scheduled deletion, or cross-account key access review
+- SSM (Secrets Manager) secret audit, automatic rotation via FC triggers, parameter store, or application secret consumption review
+- Certificate Manager SSL/TLS certificate lifecycle including auto-renewal and expiry alerting
+- HSM dedicated hardware security module key operations and key custody review
+- Envelope encryption pattern: data key generation per operation, CMK encryption, and ciphertext storage alongside data
+- KMS/secrets incidents involving access denied, failed rotation, undecryptable backups, exposed credentials, or break-glass scenarios
+
+## Key Alibaba Cloud specifics
+
+- CMK scheduled deletion has a 30-day default pending period (configurable 7–30 days); deletion is irreversible once the window passes.
+- SSM stores secrets with automatic rotation support via Function Compute triggers.
+- Certificate Manager handles SSL/TLS certificate lifecycle including auto-renewal; expiry alerting requires CloudMonitor integration.
+- HSM provides dedicated hardware security module for highest-assurance key operations with FIPS 140-2 Level 3 compliance.
+- Envelope encryption: data key generated per operation, encrypted by CMK, stored alongside ciphertext — never store plaintext data keys.
+- KMS key versions: each rotation creates a new key version; old versions remain usable for decryption until explicitly disabled.
+
+## Lean operating rules
+
+- Prefer official Alibaba Cloud documentation for grounding. If live 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 repository evidence, sanitized user evidence, and official Alibaba Cloud documentation.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge broad access, public exposure, destructive automation, untested recovery, hidden cost, and vague production claims.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+- Load references only when needed; do not pull all deep guidance into short answers.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, incident triage, implementation guidance, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when grounding Alibaba Cloud service behavior or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/alibaba/alibaba-kms-secret-lifecycle-steward/metadata.json

@@ -0,0 +1,26 @@
+{
+  "id": "alibaba-kms-secret-lifecycle-steward",
+  "name": "Alibaba Cloud KMS Secret Lifecycle Steward",
+  "type": "skill",
+  "provider": "alibaba",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Audit and govern Alibaba Cloud KMS key lifecycles, Certificate Manager, SSM (Secrets Manager), and HSM key operations. Ensure encryption-at-rest coverage and rotation compliance.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.alibabacloud.com/help/en/kms",
+    "https://www.alibabacloud.com/help/en/certificate-manager",
+    "https://www.alibabacloud.com/help/en/oos/user-guide/manage-parameters-and-secrets"
+  ],
+  "security_notes": "Do not schedule CMK deletion, revoke grants, or modify SSM secret rotation without impact analysis for access, recovery, auditability, and rollback. CMK pending deletion default is 30 days (min 7 days).",
+  "last_verified": "2026-05-08",
+  "path": "skills/alibaba/alibaba-kms-secret-lifecycle-steward",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/alibaba/alibaba-kms-secret-lifecycle-steward/references/official-sources.md

@@ -0,0 +1,15 @@
+# Official sources
+
+Use this reference only when you need source grounding for Alibaba Cloud KMS service behavior or the detailed source list.
+
+## Alibaba Cloud documentation
+
+Use these as starting points, not as proof of the user's live account state:
+
+- https://www.alibabacloud.com/help/en/kms
+- https://www.alibabacloud.com/help/en/certificate-manager
+- https://www.alibabacloud.com/help/en/oos/user-guide/manage-parameters-and-secrets
+
+## Grounding rule
+
+Official documentation explains Alibaba Cloud service behavior. It does not prove the user's current account, Region, quota, resource configuration, RAM policy boundary, pricing, or operational state. Prefer live evidence or sanitized user-provided evidence for current-state claims.