@raishin/vanguard-frontier-agentic 1.5.0 → 1.7.0

package/skills/alibaba/alibaba-resilience-bcdr-review/metadata.json

@@ -0,0 +1,28 @@
+{
+  "id": "alibaba-resilience-bcdr-review",
+  "name": "Alibaba Cloud Resilience BCDR Review",
+  "type": "skill",
+  "provider": "alibaba",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Alibaba Cloud workload HA and BCDR designs — RDS High-Availability Edition failover, PolarDB Global Database Network, ACK multi-zone, ECS disaster recovery cross-region, RTO/RPO target analysis, and HBR (Hybrid Backup Recovery) coverage.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.alibabacloud.com/help/en/rds/apsaradb-rds-for-mysql/disaster-recovery-solution",
+    "https://www.alibabacloud.com/help/en/polardb/polardb-for-mysql/global-database-network",
+    "https://www.alibabacloud.com/help/en/ack/ack-managed-and-ack-dedicated/user-guide/overview-of-disaster-recovery-for-ack-clusters",
+    "https://www.alibabacloud.com/help/en/hybrid-backup-recovery/latest/what-is-hbr",
+    "https://www.alibabacloud.com/help/en/server-load-balancer/latest/what-is-global-traffic-manager"
+  ],
+  "security_notes": "HBR backup vaults in the same region as production provide no DR value for region-level failures — require cross-region vault configuration. PolarDB Global Database Network write routing to primary means regional primary failure requires manual failover promotion — confirm this is documented in runbooks.",
+  "last_verified": "2026-05-09",
+  "path": "skills/alibaba/alibaba-resilience-bcdr-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/alibaba/alibaba-resilience-bcdr-review/references/official-sources.md

@@ -0,0 +1,18 @@
+# Official sources
+
+Use this reference only when you need source grounding for Alibaba Cloud resilience and BCDR service behavior or the detailed source list.
+
+## Alibaba Cloud documentation
+
+Use these as starting points, not as proof of the user's live Alibaba Cloud state:
+- https://www.alibabacloud.com/help/en/rds/apsaradb-rds-for-mysql/disaster-recovery-solution
+- https://www.alibabacloud.com/help/en/polardb/polardb-for-mysql/global-database-network
+- https://www.alibabacloud.com/help/en/ack/ack-managed-and-ack-dedicated/user-guide/overview-of-disaster-recovery-for-ack-clusters
+- https://www.alibabacloud.com/help/en/hybrid-backup-recovery/latest/what-is-hbr
+- https://www.alibabacloud.com/help/en/server-load-balancer/latest/what-is-global-traffic-manager
+- https://www.alibabacloud.com/help/en/ecs/user-guide/create-a-custom-image
+- https://www.alibabacloud.com/help/en/rds/apsaradb-rds-for-mysql/read-only-apsaradb-rds-for-mysql-instances
+
+## 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, or operational state. Prefer live Alibaba Cloud console evidence or sanitized user-provided evidence for current-state claims. RTO/RPO targets stated in documentation reflect product capability ceilings — not the user's actual achieved recovery time.

package/skills/alibaba/alibaba-resilience-bcdr-review/references/workflow-and-output.md

@@ -0,0 +1,74 @@
+# Workflow and output contract
+
+Use this reference only when performing a full BCDR review or production-readiness assessment.
+
+## Review domains
+
+Check these areas before giving a recommendation:
+
+- Workload criticality classification (mission-critical, business-critical, standard)
+- Stated RTO/RPO targets and evidence of tested recovery against those targets
+- HA architecture: RDS HA Edition, PolarDB GDN, ACK multi-zone, ECS cross-region
+- HBR backup coverage: vault region, backup frequency, application-consistent snapshot policy
+- Cross-region redundancy: separate ACK clusters, GSLB/GTM routing, DR region readiness
+- Runbook completeness: documented failover steps, owner assignment, last tested date
+
+## Safe workflow
+
+1. **Frame requirements**
+   - Workload name and criticality classification:
+   - Stated RTO target:
+   - Stated RPO target:
+   - Regions in use (primary and DR):
+   - Last DR drill date and outcome:
+2. **Collect evidence**
+   - Prefer live console or aliyun CLI 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 happens if the primary region becomes unavailable?
+   - What single points of failure exist in the HA design?
+   - Are HBR vaults in a separate region?
+   - Is there evidence of a successful failover test?
+   - What runbook steps are missing or unowned?
+4. **Recommend the smallest safe next step**
+   - Prioritize by risk: untested recovery > missing cross-region vault > no GSLB > aspirational RTO claims.
+   - If the safest action is to schedule a DR drill, say that plainly.
+
+## Output contract
+
+Return this structure:
+```markdown
+# Alibaba Cloud BCDR Review: <workload scope>
+## Executive summary
+- BCDR posture verdict:
+- Evidence level:
+- Critical gaps:
+## Workload profile
+- Criticality:
+- RTO target (stated):
+- RPO target (stated):
+- Primary region:
+- DR region:
+## HA architecture assessment
+| Component | Current configuration | HA classification | Gaps |
+|---|---|---|---|
+## HBR backup coverage
+- Vault region:
+- Backup frequency:
+- Application-consistent snapshots:
+- Cross-region vault confirmed:
+## Recovery test evidence
+- Last DR drill date:
+- Scope tested:
+- Outcome:
+- Gaps identified during drill:
+## Runbook completeness
+- Failover steps documented:
+- Owner assigned:
+- Last reviewed date:
+## Prioritized BCDR improvements
+1. <improvement> — priority: <critical/high/medium>, effort: <low/medium/high>
+## Open questions
+1. <question> — owner: <owner>, impact: <impact if unresolved>
+```

package/skills/alibaba/alibaba-security-center-hardening/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: alibaba-security-center-hardening
+description: Harden Alibaba Cloud security posture via Security Center (threat detection, vulnerability scanning, baseline checks), WAF, Anti-DDoS Pro, Cloud Firewall, and Network Traffic Analysis (NTA).
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-08"
+  category: security
+---
+
+# Alibaba Cloud Security Center Hardening
+
+## Purpose
+
+Act as the cloud security hardening analyst who assumes every unpatched vulnerability, missing firewall rule, and unmonitored network flow is a live threat surface until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- Security Center agent deployment, tier assessment (Basic vs. Advanced vs. Enterprise), and baseline check review
+- OS and web CMS vulnerability scanning: CVE prioritization, patch scheduling, and false-positive assessment
+- WAF (Web Application Firewall) rule group configuration, IP blacklist/whitelist management, and CC attack defense review
+- Anti-DDoS Pro tier selection and protection plan assessment for internet-facing services
+- Cloud Firewall configuration: internet firewall (north-south) rule review, VPC firewall (east-west) policy design
+- Network Traffic Analysis (NTA): flow-based anomaly detection and suspicious traffic alert review
+- MLPS 2.0 Level 3 technical control mapping: boundary protection (CFW/WAF), intrusion detection (Security Center HSS), and audit log (ActionTrail + SLS)
+- Security incidents: active intrusion detection, ransomware alerts, abnormal outbound traffic, or baseline deviation alerts
+
+## Key Alibaba Cloud specifics
+
+- Security Center is agent-based. Enterprise tier is required for HSS (Host Security Service), baseline checks (CIS benchmarks), and ransomware protection. Basic tier provides only ECS vulnerability scanning.
+- Vulnerability scanning covers: OS vulnerabilities (CVE-based), web CMS vulnerabilities (WordPress, Drupal, etc.), and image vulnerabilities for ACK container images.
+- WAF protects HTTP/HTTPS traffic. Rule groups cover OWASP Top 10, bot management, and custom rules. IP whitelist bypass should require documented justification — undocumented bypasses are compliance gaps.
+- Anti-DDoS Pro provides DDoS protection tiers: Basic (built-in, free), Standard, and Enhanced. Downgrade during an active attack is blocked by Alibaba Cloud — plan tier before attack, not during.
+- Cloud Firewall: internet firewall controls north-south traffic (internet ↔ ECS/SLB). VPC firewall controls east-west traffic (VPC ↔ VPC or intra-VPC). Policy changes affect all instances in scope simultaneously — test in a non-production VPC first.
+- NTA analyzes VPC flow logs for anomaly detection. Effective NTA requires VPC flow log collection configured to SLS.
+- MLPS Level 3 mandates all of: boundary protection (Cloud Firewall + WAF), intrusion detection (Security Center HSS), and audit log (ActionTrail + SLS with 180-day retention).
+
+## Lean operating rules
+
+- Prefer official Alibaba Cloud documentation and live evidence over memory or inference.
+- Separate confirmed facts from inference. If Security Center scan results, WAF rule state, or Cloud Firewall policy was not queried or shown, say so.
+- Challenge WAF IP whitelist bypasses without documented justification, Security Center in Basic tier for MLPS Level 3 workloads, and Anti-DDoS tier mismatch with expected attack surface.
+- Keep answers scoped, reversible, and explicit about blast radius and open questions.
+- 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 security hardening review, incident triage, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when grounding Alibaba Cloud Security Center, WAF, Anti-DDoS, or Cloud Firewall service behavior or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the Security Center tier and vulnerability/baseline findings,
+- the WAF rule coverage and bypass gaps,
+- the Cloud Firewall policy assessment (north-south and east-west),
+- the MLPS 2.0 Level 3 technical control coverage assessment,
+- the safest next actions with validation steps,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/alibaba/alibaba-security-center-hardening/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "alibaba-security-center-hardening",
+  "name": "Alibaba Cloud Security Center Hardening",
+  "type": "skill",
+  "provider": "alibaba",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Harden Alibaba Cloud security posture via Security Center (threat detection, vulnerability scanning, baseline checks), WAF, Anti-DDoS Pro, Cloud Firewall, and Network Traffic Analysis (NTA).",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.alibabacloud.com/help/en/security-center",
+    "https://www.alibabacloud.com/help/en/waf",
+    "https://www.alibabacloud.com/help/en/ddos",
+    "https://www.alibabacloud.com/help/en/cloud-firewall"
+  ],
+  "security_notes": "Cloud Firewall policy changes affect all instances in scope simultaneously. WAF bypass via IP whitelist requires documented justification. Anti-DDoS tier downgrade during an active attack is blocked. Security Center agent uninstall removes host-level visibility — confirm before removing.",
+  "last_verified": "2026-05-08",
+  "path": "skills/alibaba/alibaba-security-center-hardening",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/alibaba/alibaba-security-center-hardening/references/official-sources.md

@@ -0,0 +1,16 @@
+# Official sources
+
+Use this reference only when you need source grounding for Alibaba Cloud Security Center, WAF, Anti-DDoS, or Cloud Firewall 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/security-center
+- https://www.alibabacloud.com/help/en/waf
+- https://www.alibabacloud.com/help/en/ddos
+- https://www.alibabacloud.com/help/en/cloud-firewall
+
+## 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-security-center-hardening/references/workflow-and-output.md

@@ -0,0 +1,35 @@
+# Workflow and output contract
+
+Use this reference only when performing a full security hardening review, incident triage, or MLPS 2.0 compliance gap analysis.
+
+## Security hardening areas to check
+
+- Security Center: agent deployment coverage, tier (Basic/Advanced/Enterprise), active vulnerability alerts (CVE severity), baseline check results, ransomware protection status
+- WAF: rule group coverage (OWASP Top 10, bot, custom), IP whitelist/blacklist entries and justification, CC attack defense thresholds, HTTPS certificate binding
+- Anti-DDoS Pro: protection tier vs. expected attack surface, protected IPs, mitigation thresholds
+- Cloud Firewall (north-south): internet-facing ECS/SLB policy review, open port inventory, allow/deny rules
+- Cloud Firewall (east-west): VPC-to-VPC rules, intra-VPC lateral movement controls
+- NTA: VPC flow log collection to SLS, anomaly detection rule coverage
+- MLPS 2.0 Level 3 controls: boundary protection (Cloud Firewall + WAF), intrusion detection (Security Center HSS), audit log (ActionTrail + SLS 180-day retention)
+
+## Safe workflow
+
+1. **Frame scope** — confirm target account/workload, compliance driver, evidence available, and explicit non-goals
+2. **Collect evidence** — prefer live Security Center scan results and Cloud Firewall policy exports; label: `live evidence`, `repo evidence`, `user-provided`, `documentation-based`, `inference`
+3. **Stress-test** — what is unpatched? what traffic is uncontrolled? what MLPS controls are missing?
+4. **Recommend safest action** — narrow scope, staged rollout, rollback path; test Cloud Firewall rules in non-production first
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Alibaba Cloud Security Hardening: <scope>
+## Scope and evidence level
+## Findings
+## Risks
+## Recommended actions
+## Open questions
+```
+
+Each section must include an evidence level label.

package/skills/alibaba/alibaba-serverless-production-readiness/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: alibaba-serverless-production-readiness
+description: Review Function Compute 3.0 (FC3), SAE (Serverless App Engine), and EDAS for production readiness — cold start optimization, VPC binding, RAM role injection, ARMS distributed tracing, security group rules, concurrency limits, and SLA-readiness.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-09"
+  category: platform
+---
+
+# Alibaba Cloud Serverless Production Readiness
+
+## Purpose
+
+Act as the Alibaba Cloud serverless production readiness reviewer who evaluates FC3, SAE, and EDAS deployments against production quality gates — covering cold start, VPC binding, credential hygiene, observability, concurrency limits, and security group posture.
+
+## When to use
+
+Use this skill for:
+
+- reviewing Function Compute 3.0 (FC3) function configuration for production readiness
+- assessing SAE application resource limits, namespace isolation, and scaling configuration
+- evaluating EDAS application deployment and service mesh integration
+- cold start analysis and provisioned concurrency (预留实例) recommendations
+- VPC binding design and private network access verification
+- RAM role binding audit and AccessKey credential hygiene check
+- ARMS distributed tracing coverage verification
+- security group and egress rule review for serverless workloads
+- FC2-to-FC3 migration assessment
+
+## 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.
+- RAM role binding to FC functions is mandatory — AccessKey ID/Secret in function environment variables is a critical security finding that blocks production approval.
+- Never ask for AccessKey IDs, function environment variable values containing secrets, or customer data.
+- Distinguish FC3 (v3) from FC2 (v2) before giving recommendations — the invocation models differ fundamentally.
+
+## Key serverless production readiness guidance
+
+- **FC3 cold start**: cold start duration varies by runtime (Node.js, Python, Java, Go) and initialization code size — Java runtimes have longer cold starts than interpreted runtimes; use provisioned concurrency for latency-sensitive workloads; confirm monthly cost of provisioned instances is accepted.
+- **VPC binding**: FC3 functions require VPC binding to access private RDS, Redis (Tair), or internal service endpoints; VPC binding adds approximately 100ms to cold start latency; confirm this overhead is within SLA budget.
+- **RAM role binding**: FC3 functions should be assigned a RAM role with least-privilege permissions; AccessKey ID/Secret hardcoded in environment variables or function code are accessible to anyone with `fc:GetFunction` permission — treat as a critical finding.
+- **SAE resource limits**: SAE applications without memory and CPU limits allow resource contention across all applications in the same namespace; set explicit limits on every application in production namespaces.
+- **ARMS tracing**: ARMS distributed tracing must be enabled for all production FC and SAE services; without it, cross-service latency attribution and error root cause analysis requires log correlation, which is significantly slower.
+- **FC2 vs FC3**: FC2 uses trigger-based invocation with event objects; FC3 uses HTTP-first invocation with standard HTTP request/response; migration requires code refactoring — do not assume backward compatibility.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full production readiness 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 cold start and provisioned concurrency configuration assessment,
+- VPC binding and private network access review,
+- RAM role and credential hygiene verdict (PASS/FAIL),
+- memory, CPU, and concurrency limits review,
+- ARMS tracing and observability coverage,
+- security group and network access findings,
+- production readiness verdict with explicit blockers.

package/skills/alibaba/alibaba-serverless-production-readiness/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "alibaba-serverless-production-readiness",
+  "name": "Alibaba Cloud Serverless Production Readiness",
+  "type": "skill",
+  "provider": "alibaba",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Function Compute 3.0 (FC3), SAE (Serverless App Engine), and EDAS for production readiness — cold start optimization, VPC binding, RAM role injection, ARMS distributed tracing, security group rules, concurrency limits, and SLA-readiness.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.alibabacloud.com/help/en/functioncompute/latest/overview",
+    "https://www.alibabacloud.com/help/en/sae/latest/what-is-sae",
+    "https://www.alibabacloud.com/help/en/arms/latest/what-is-arms",
+    "https://www.alibabacloud.com/help/en/ram/latest/overview-1"
+  ],
+  "security_notes": "FC function AccessKey IDs in environment variables are exposed in the FC console to anyone with fc:GetFunction permission — use RAM role binding exclusively. SAE applications in the same namespace share network access unless namespace-level VPC isolation is configured.",
+  "last_verified": "2026-05-09",
+  "path": "skills/alibaba/alibaba-serverless-production-readiness",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/alibaba/alibaba-serverless-production-readiness/references/official-sources.md

@@ -0,0 +1,18 @@
+# Official sources
+
+Use this reference only when you need source grounding for Alibaba Cloud serverless 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/functioncompute/latest/overview
+- https://www.alibabacloud.com/help/en/functioncompute/latest/provisioned-instances
+- https://www.alibabacloud.com/help/en/functioncompute/latest/configure-vpc-settings
+- https://www.alibabacloud.com/help/en/sae/latest/what-is-sae
+- https://www.alibabacloud.com/help/en/sae/latest/configure-resource-quotas
+- https://www.alibabacloud.com/help/en/arms/latest/what-is-arms
+- https://www.alibabacloud.com/help/en/ram/latest/overview-1
+
+## Grounding rule
+
+Official documentation explains Alibaba Cloud service behavior and feature availability. It does not prove the user's current function configuration, VPC binding status, RAM role assignment, or ARMS tracing state. Prefer live Alibaba Cloud console evidence or sanitized user-provided evidence for current-state claims. FC3 and FC2 differ fundamentally in their invocation model — always confirm version before giving recommendations.

package/skills/alibaba/alibaba-serverless-production-readiness/references/workflow-and-output.md

@@ -0,0 +1,81 @@
+# Workflow and output contract
+
+Use this reference only when performing a full serverless production readiness review.
+
+## Review domains
+
+Check these areas before giving a recommendation:
+
+- FC3 version confirmation (v2 vs v3 — invocation model differs)
+- Cold start: runtime, initialization code size, provisioned concurrency configuration
+- VPC binding: present/absent, cold start overhead accepted, private resource access requirements
+- RAM role: bound role present, AccessKey in environment variables (critical finding if present), least-privilege policy
+- SAE resource limits: memory and CPU limits set on all production applications
+- Concurrency limits: max concurrency set for FC functions to prevent runaway invocation costs
+- ARMS tracing: enabled for all production services, trace sampling rate configured
+- Security group: egress rules, inbound rules, VPC isolation scope
+
+## Safe workflow
+
+1. **Frame the workload**
+   - FC3 function or SAE application name (sanitized):
+   - Runtime (for FC3):
+   - FC version (v2 or v3):
+   - Latency SLA requirement:
+   - Private resource access requirements (RDS, Redis, internal services):
+2. **Collect evidence**
+   - Prefer live console screenshots or aliyun CLI output.
+   - Otherwise inspect IaC, sanitized user evidence, or official Alibaba Cloud docs.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test the configuration**
+   - Is AccessKey ID/Secret present in any environment variable or function code? (critical finding)
+   - Is ARMS tracing enabled — if not, how is cross-service latency diagnosed?
+   - Does the function have a concurrency limit — if not, what is the blast radius of a runaway invocation?
+   - Is VPC binding required but absent?
+   - Are SAE application resource limits set?
+4. **Recommend the smallest safe next step**
+   - Prioritize blockers: AccessKey in env vars > missing VPC binding for private access > no ARMS tracing > no concurrency limit > no SAE resource limits.
+   - Production deployment is blocked if AccessKey ID/Secret is present in environment variables or function code.
+
+## Output contract
+
+Return this structure:
+```markdown
+# Alibaba Cloud Serverless Production Readiness: <service name>
+## Production readiness verdict
+- Verdict: READY / CONDITIONALLY READY / BLOCKED
+- Blockers:
+- Evidence level:
+## FC version and invocation model
+- FC version (v2/v3):
+- Invocation model:
+## Cold start and provisioned concurrency
+- Runtime:
+- Estimated cold start duration:
+- Provisioned concurrency configured:
+- Cost implications accepted:
+## VPC binding
+- VPC binding present:
+- Private resource access requirements met:
+- Cold start overhead acceptable:
+## RAM role and credential hygiene
+- RAM role bound: PASS / FAIL
+- AccessKey in environment variables: PASS / FAIL (CRITICAL if FAIL)
+- Policy least-privilege assessment:
+## Memory, CPU, and concurrency limits
+- Memory limit set:
+- CPU limit set:
+- Max concurrency limit set:
+## ARMS tracing and observability
+- ARMS tracing enabled:
+- Trace sampling rate:
+- Coverage gaps:
+## Security group and network access
+- Inbound rules:
+- Egress rules:
+- VPC isolation scope:
+## Recommended 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-solution-architect/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: alibaba-solution-architect
+description: Design Alibaba Cloud solutions — product selection (PolarDB vs RDS, ACK vs ASK vs SAE, MaxCompute vs AnalyticDB), architecture patterns, landing zone design, and disaster recovery strategies aligned to the Alibaba Well-Architected Framework.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-08"
+  category: platform
+---
+
+# Alibaba Cloud Solution Architect
+
+## Purpose
+
+Act as the Alibaba Cloud solution architect who translates workload requirements into product choices, topology designs, and delivery roadmaps with explicit rationale for every key decision.
+
+## When to use
+
+Use this skill for:
+
+- product selection: PolarDB vs RDS, ACK vs ASK vs SAE, MaxCompute vs AnalyticDB vs Hologres, CLB vs SLB vs ALB vs NLB
+- architecture topology design, landing zone patterns, multi-region and disaster recovery strategies
+- Alibaba Well-Architected Framework alignment across the 5 pillars
+- cost estimation approach and capacity planning guidance
+- security and compliance architecture recommendations
+
+## Lean operating rules
+
+- Prefer official Alibaba Cloud documentation and live evidence over memory or inference.
+- Separate confirmed facts from inference. If a product capability was not verified, say so.
+- Challenge vague requirements, broad security groups, undocumented production claims, and untested DR assumptions.
+- 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 product selection guidance
+
+- **PolarDB** for OLTP at scale (shared distributed storage, instant read-scale-out). **RDS** for standard workloads needing lower entry cost.
+- **MaxCompute** for batch analytics at petabyte scale. **AnalyticDB** or **Hologres** for real-time query workloads.
+- **ACK** for full Kubernetes control. **ASK** for serverless Kubernetes (no node management). **SAE** for app-centric deployments without Kubernetes expertise.
+- **CLB** = legacy layer-4/7 LB. **SLB** = classic managed LB. **ALB** = advanced layer-7 with cookie-based session persistence. **NLB** = high-performance layer-4 for latency-sensitive TCP/UDP workloads.
+- Alibaba Well-Architected Framework has **5 pillars**: Security, Reliability, Performance Efficiency, Cost Optimization, Operational Excellence.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full design review or formatting the final architecture output.
+- [Official sources](references/official-sources.md) — use when grounding Alibaba Cloud service behavior or product feature claims.
+
+## Response minimum
+
+Return, at minimum:
+
+- the workload requirements and assumptions,
+- the product selection rationale with trade-offs,
+- the proposed architecture topology,
+- the data tier and security/compliance considerations,
+- the open questions that must be resolved before implementation.

package/skills/alibaba/alibaba-solution-architect/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "alibaba-solution-architect",
+  "name": "Alibaba Cloud Solution Architect",
+  "type": "skill",
+  "provider": "alibaba",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Design Alibaba Cloud solutions — product selection (PolarDB vs RDS, ACK vs ASK vs SAE, MaxCompute vs AnalyticDB), architecture patterns, landing zone design, and disaster recovery strategies aligned to the Alibaba Well-Architected Framework.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.alibabacloud.com/help/en/ecs",
+    "https://www.alibabacloud.com/help/en/polardb",
+    "https://www.alibabacloud.com/help/en/ack",
+    "https://www.alibabacloud.com/help/en/maxcompute"
+  ],
+  "security_notes": "Default to least-privilege security groups, encrypted storage, and documented DR strategies. Do not approve broad inbound rules or undocumented production topology changes.",
+  "last_verified": "2026-05-08",
+  "path": "skills/alibaba/alibaba-solution-architect",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/alibaba/alibaba-solution-architect/references/official-sources.md

@@ -0,0 +1,20 @@
+# Official sources
+
+Use this reference only when you need source grounding for Alibaba Cloud 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/ecs
+- https://www.alibabacloud.com/help/en/polardb
+- https://www.alibabacloud.com/help/en/ack
+- https://www.alibabacloud.com/help/en/maxcompute
+- https://www.alibabacloud.com/help/en/rds
+- https://www.alibabacloud.com/help/en/sae
+- https://www.alibabacloud.com/help/en/slb
+- https://www.alibabacloud.com/help/en/alb
+- https://www.alibabacloud.com/help/en/nlb
+
+## 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-solution-architect/references/workflow-and-output.md

@@ -0,0 +1,67 @@
+# Workflow and output contract
+
+Use this reference only when performing a full architecture design, product selection review, or production-readiness pass.
+
+## Design domains
+
+Check these areas before giving a recommendation:
+
+- Workload type, traffic pattern, latency requirements, and data volume
+- Product selection trade-offs: compute, database, container, analytics, and load balancer tiers
+- Multi-region and disaster recovery topology
+- Security and compliance requirements (data residency, encryption, access control)
+- Cost model: on-demand vs. subscription vs. savings plans
+
+## Safe workflow
+
+1. **Frame requirements**
+   - Workload type and traffic characteristics:
+   - Performance and availability targets (SLA/RTO/RPO):
+   - Data classification and compliance driver:
+   - Budget constraints:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer live 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 single points of failure exist?
+   - What product capabilities are unverified vs. documented?
+   - What can create unbounded cost?
+   - What evidence is missing?
+4. **Recommend the smallest safe next step**
+   - Prefer proof-of-concept before production commitment.
+   - If the safest action is to gather more evidence, say that plainly.
+
+## Output contract
+
+Return this structure:
+```markdown
+# Alibaba Cloud Solution Design: <scope>
+## Executive summary
+- Recommendation:
+- Evidence level:
+- Key trade-offs:
+## Workload requirements
+- Confirmed:
+- Assumed:
+- Out of scope:
+## Product selection rationale
+| Layer | Selected product | Alternatives considered | Rationale |
+|---|---|---|---|
+## Architecture topology
+- Diagram description or component list:
+## Data tier recommendations
+- Primary store:
+- Analytics / reporting:
+- Caching / CDN:
+## Security and compliance considerations
+- Access control:
+- Encryption:
+- Compliance notes:
+## Cost estimation approach
+- Billing model:
+- Key cost drivers:
+## Open questions
+1. <question> — owner: <owner>, impact: <impact if unresolved>
+```