@raishin/vanguard-frontier-agentic 1.6.0 → 1.7.0

package/skills/ionos/ionos-security-compliance-reviewer/references/official-sources.md

@@ -0,0 +1,16 @@
+# Official sources
+
+Use this reference only when grounding IONOS Cloud security controls, compliance posture, or IAM behavior.
+
+## IONOS Cloud security and compliance documentation
+
+Use these as starting points, not as proof of the user's live IONOS security state:
+
+- https://docs.ionos.com/cloud/security — security controls, compliance certifications, and GDPR documentation
+- https://docs.ionos.com/cloud/identity-and-access-management — IAM role design, bearer token scope, and access control reference
+- https://api.ionos.com/docs/ — API authentication patterns and authorization scope reference
+- https://docs.ionos.com/cloud/ — platform-level compliance certifications and regional availability
+
+## Grounding rule
+
+Official IONOS documentation describes platform security capabilities and compliance certifications. It does not prove the user's current token scope, encryption configuration, firewall rules, audit log retention, or GDPR processing location alignment. Prefer live or user-provided sanitized evidence for current-state claims. When live tooling is unavailable, state this explicitly and label findings as `documentation-based` or `inference`.

package/skills/ionos/ionos-security-compliance-reviewer/references/safety-checklist.md

@@ -0,0 +1,26 @@
+# Safety checklist
+
+Use this reference before recommending any configuration change, remediation, or posture hardening that touches a production IONOS Cloud environment.
+
+## Non-negotiables
+
+- Never request, echo, or transmit bearer tokens, API keys, database credentials, or customer account identifiers.
+- Never recommend disabling encryption at rest or in transit for any production workload.
+- GDPR data residency is a hard blocker — if the declared processing region and the active datacenter region do not match, flag this as CRITICAL before any other finding.
+- Do not invent datacenter IDs, resource names, token scopes, or live configuration state.
+- Require explicit evidence of API token scope before approving any IAM posture as compliant.
+- Stay advisory — do not call IONOS Cloud API endpoints or apply configuration changes.
+- Label all claims: `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.
+
+## Stress checks
+
+- What can expose data outside the declared GDPR region? (Cross-border endpoint mismatch, replication settings)
+- What can allow unauthorized access to production resources? (Overly broad API token, missing LAN firewall rule)
+- What can break audit trail continuity? (Logging disabled, short retention period)
+- What can expose credentials or API tokens? (Plaintext config, unrestricted token scope)
+- What compliance evidence is missing or assumed rather than verified?
+- Is the regional endpoint correct for each IONOS service in scope? (`de-txl`, `de-fra`, `fr-par`, `es-vit`, `gb-lhr`, `gb-bhx`, `us-las`, `us-mci`, `us-ewr`)
+
+## Evidence labels
+
+Use `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live IONOS Cloud compliance posture — it describes expected service behavior only.

package/skills/ionos/ionos-security-compliance-reviewer/references/workflow-and-output.md

@@ -0,0 +1,65 @@
+# Workflow and output contract
+
+Use this reference only when performing a full IONOS Cloud security and GDPR compliance review.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- GDPR data residency: datacenter region matches declared data processing location; endpoint region is correct for all service calls
+- Encryption posture: volumes encrypted at rest, TLS enforced in transit for all service endpoints
+- Network isolation: private LAN segmentation, NIC firewall rules, no unintended public interfaces on sensitive workloads
+- IAM hygiene: bearer token scope is least-privilege, token rotation cadence, no overly broad API token assignments
+- Audit trail: logging enabled for control-plane and data-plane operations, retention meets compliance requirements
+- Vulnerability posture: server OS update cadence, exposed port surface, known CVE exposure on managed services
+
+## Safe workflow
+
+1. **Frame scope**
+   - Datacenter region(s) and declared GDPR processing location:
+   - Workload type and data classification:
+   - Compliance driver (GDPR, ISO 27001, internal policy):
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer live IONOS Cloud API or DCD export evidence if available.
+   - Otherwise inspect IaC (Terraform), user-provided sanitized configuration, or official IONOS docs.
+   - Label each finding as `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - What can expose data outside the declared GDPR region?
+   - What can allow unauthorized access to production resources?
+   - What can break audit trail continuity?
+   - What can expose credentials or API tokens?
+   - What compliance evidence is missing?
+4. **Recommend the smallest safe action**
+   - Prefer additive hardening (add encryption, tighten scope) over disruptive remediation.
+   - If the safest action is to gather more evidence before recommending, say that plainly.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# IONOS Security and Compliance Review: <scope>
+## Executive verdict
+- Status: COMPLIANT / COMPLIANT WITH RISKS / NON-COMPLIANT / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## GDPR data residency
+- Datacenter region:
+- Endpoint region validated:
+- Status: CONFIRMED / MISMATCH / UNKNOWN
+## Findings
+| Severity | Domain | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Evidence gaps
+- <gap or explicit none>
+## Residual risk
+- <risk or explicit none>
+```

package/skills/ovhcloud/ovhcloud-cost-finops-analyst/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: ovhcloud-cost-finops-analyst
+description: Analyze OVHcloud Public Cloud cost posture across projects and regions: identify idle instances and unattached volumes, review Savings Plans and commitment coverage, recommend rightsizing and tagging improvements, and surface forecast risks. Use when the user asks to reduce, explain, or govern OVHcloud spend without compromising observability, backups, or redundancy.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-10"
+  category: finops
+---
+
+# OVHcloud Cost FinOps Analyst
+
+## Purpose
+
+Act as the OVHcloud FinOps analyst: surface waste, validate commitment coverage, and recommend cost reductions that preserve reliability, observability, and security posture.
+
+## When to use
+
+Use this skill for:
+
+- OVHcloud Public Cloud bill review, cost spike diagnosis, or spend forecast
+- Idle instance, unattached volume, or unused snapshot identification
+- Savings Plans coverage review and commitment gap analysis
+- Rightsizing recommendations based on instance usage baselines
+- Tagging governance and showback/chargeback design
+- Cost optimization roadmap across projects and regions
+
+## Lean operating rules
+
+- Prefer OVHcloud billing and Public Cloud documentation; if MCP tooling is unavailable, fall back to https://help.ovhcloud.com/ and Context7.
+- Separate confirmed spend from estimated savings. Never present projected savings as guaranteed.
+- Challenge idle-resource deletion, commitment cancellation, or rightsizing without confirmed backup state, usage baseline, and rollback path.
+- Do not recommend cuts that remove backups, monitoring agents, log retention, or redundant components without explicit risk acceptance.
+- Keep recommendations reversible; prefer snapshot-before-delete patterns.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full cost review or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before recommending resource deletion, commitment changes, or any cost action affecting reliability or compliance.
+- [Official sources](references/official-sources.md) — use when grounding OVHcloud billing behavior or checking the source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- confirmed waste or over-spend signals,
+- safe cost-reduction recommendations with rollback notes,
+- savings estimates labeled as projected (not guaranteed),
+- blockers or assumptions that prevent stronger conclusions.

package/skills/ovhcloud/ovhcloud-cost-finops-analyst/metadata.json

@@ -0,0 +1,26 @@
+{
+  "id": "ovhcloud-cost-finops-analyst",
+  "name": "OVHcloud Cost FinOps Analyst",
+  "type": "skill",
+  "provider": "ovhcloud",
+  "harnesses": [
+    "codex",
+    "copilot",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro"
+  ],
+  "summary": "Analyze OVHcloud Public Cloud cost posture, identify idle resources and commitment gaps, and recommend rightsizing and tagging improvements without compromising reliability or observability.",
+  "source_type": "original",
+  "official_docs": [
+    "https://help.ovhcloud.com/csm/en-public-cloud-billing?id=kb_article_view&sysparm_article=KB0050830",
+    "https://help.ovhcloud.com/csm/en-public-cloud-compute-savings-plan?id=kb_article_view&sysparm_article=KB0062980",
+    "https://registry.terraform.io/providers/ovh/ovh/latest/docs/resources/cloud_project"
+  ],
+  "security_notes": "Cost optimizations must not remove backups, monitoring agents, log retention, or redundant components without explicit risk acceptance; idle resource deletion is irreversible without a prior snapshot.",
+  "last_verified": "2026-05-10",
+  "path": "skills/ovhcloud/ovhcloud-cost-finops-analyst",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/ovhcloud/ovhcloud-cost-finops-analyst/references/official-sources.md

@@ -0,0 +1,15 @@
+# Official sources
+
+Use this reference only when you need source grounding for OVHcloud billing and Public Cloud cost behavior or the detailed source list.
+
+## OVHcloud documentation
+
+Use these as starting points, not as proof of the user's live OVHcloud spend or resource state:
+
+- https://help.ovhcloud.com/csm/en-public-cloud-billing?id=kb_article_view&sysparm_article=KB0050830
+- https://help.ovhcloud.com/csm/en-public-cloud-compute-savings-plan?id=kb_article_view&sysparm_article=KB0062980
+- https://registry.terraform.io/providers/ovh/ovh/latest/docs/resources/cloud_project
+
+## Grounding rule
+
+Official documentation explains OVHcloud billing mechanics, Savings Plan commitment rules, and Public Cloud resource pricing models. It does not prove the user's current spend, resource utilization, commitment coverage, or tagging state. Prefer live billing export or sanitized user-provided evidence for current-state claims. Never present pricing or savings figures derived only from documentation as exact quotes for the user's environment.

package/skills/ovhcloud/ovhcloud-cost-finops-analyst/references/safety-checklist.md

@@ -0,0 +1,26 @@
+# Safety checklist
+
+Use this reference before recommending resource deletion, commitment changes, rightsizing, or any cost action that could affect reliability, observability, or compliance posture.
+
+## Non-negotiables
+
+- Never ask users to paste API tokens, application keys, billing credentials, or account passwords into chat.
+- Prefer OVHcloud billing and Public Cloud documentation for service behavior. If no live tooling is available, use repository evidence or official documentation and label the evidence level.
+- Do not invent project IDs, resource names, pricing rates, utilization baselines, or Savings Plan commitment details.
+- Require explicit user approval before recommending instance deletion, volume deletion, snapshot cleanup, or commitment cancellation.
+- Never recommend removing backups, monitoring agents, log retention pipelines, or redundant components without explicit risk acceptance from the user.
+- Separate confirmed waste from estimated savings. Never present projected savings as guaranteed.
+- Use Context7 or official OVHcloud documentation for current billing and pricing behavior when the answer depends on OVHcloud-specific service details.
+
+## Stress checks
+
+- What resource deletion could break backups, log retention, monitoring, or redundancy?
+- What rightsizing could cause performance degradation, outage, or SLA breach?
+- What commitment cancellation could incur penalty charges or coverage gaps?
+- What tagging or chargeback change could misattribute spend and cause organizational confusion?
+- What compliance or audit evidence is missing?
+- What rollback or recovery path is unproven if the cost action has negative effects?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live OVHcloud project spend, resource state, or Savings Plan coverage.

package/skills/ovhcloud/ovhcloud-cost-finops-analyst/references/workflow-and-output.md

@@ -0,0 +1,61 @@
+# Workflow and output contract
+
+Use this reference only when performing the full cost review, spend forecast, optimization roadmap, or Savings Plan coverage analysis.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Public Cloud project scope, region breakdown, and active service inventory
+- Idle or unattached resources: stopped instances still billed, unattached volumes, unused floating IPs, orphaned snapshots
+- Savings Plans coverage: commitment level, term, matching instance types, coverage gaps vs. on-demand spend
+- Instance rightsizing signals: CPU and memory utilization baselines, instance flavor choices vs. workload requirements
+- Tagging hygiene: untagged resources blocking showback, chargeback attribution, or cost allocation
+- Backup, monitoring, and redundancy components that must not be cut without explicit risk acceptance
+
+## Safe workflow
+
+1. **Frame scope**
+   - Project ID(s) and region(s) in scope:
+   - Current monthly spend baseline or billing period:
+   - Business criticality and reliability requirements:
+   - Required outcome (reduce spend / explain spike / forecast / tagging governance):
+   - Explicit non-goals (e.g., do not touch production databases):
+2. **Collect evidence**
+   - Prefer OVHcloud billing export, Public Cloud usage APIs, or Terraform state evidence if available.
+   - Otherwise inspect repository `ovh_cloud_project` or related resources, sanitized billing screenshots, or official OVHcloud docs.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - What resource deletion could break backups, log retention, monitoring, or redundancy?
+   - What rightsizing recommendation could cause performance degradation or SLA breach?
+   - What commitment cancellation could incur penalty charges?
+   - What evidence is missing that prevents confident savings estimates?
+4. **Recommend the smallest safe action**
+   - Prefer snapshot-before-delete, staged rightsizing, and validated commitment coverage before recommending cuts.
+   - Separate confirmed waste from estimated potential savings; never present projected savings as guaranteed.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# OVHcloud Cost FinOps Review: <project or scope>
+## Executive verdict
+- Status: OPTIMIZED / IMPROVEMENT AVAILABLE / RISKS PRESENT / NEEDS EVIDENCE
+- Biggest waste signal:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Findings
+| Severity | Finding | Evidence | Estimated monthly saving | Minimum safe action |
+|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, prerequisite: <check>, rollback: <rollback>
+## Savings summary
+- Confirmed waste: <amount or unknown>
+- Projected savings (not guaranteed): <range>
+## Residual risk
+- <risk or explicit none>
+```

package/skills/ovhcloud/ovhcloud-iam-policy-review/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: ovhcloud-iam-policy-review
+description: Review OVHcloud IAM policies for overly permissive allow rules, missing deny blocks, unscoped URNs, absent condition blocks (IP CIDR, resource tag, expiration), and identity-group hygiene. Use when the user needs to audit access control, review `ovh_iam_policy` Terraform resources, assess OAuth2 service account scopes, or validate conditional access configuration against the principle of least privilege.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-10"
+  category: security
+---
+
+# OVHcloud IAM Policy Review
+
+## Purpose
+
+Audit OVHcloud IAM policies for over-permissive access, missing conditional controls, and identity-group hygiene gaps. Produce an evidence-backed verdict with least-privilege recommendations.
+
+## When to use
+
+Use this skill for:
+
+- Auditing `ovh_iam_policy` Terraform resources for scope and condition gaps
+- Reviewing OAuth2 service account permissions against the principle of least privilege
+- Assessing identity groups for membership sprawl or excessive aggregated permissions
+- Evaluating conditional access blocks: IP CIDR restrictions, resource tag conditions, expiration dates
+- Pre-deployment review of new IAM policies or policy changes
+
+## Lean operating rules
+
+- Prefer OVHcloud IAM docs and Terraform provider docs; if MCP tooling is unavailable, fall back to https://help.ovhcloud.com/ and Context7.
+- Separate confirmed policy state from inference. If the policy was not shown, say so.
+- Challenge policies with wildcarded URNs (`urn:v1:eu:resource:*`), missing condition blocks, or allow rules that supersede deny rules unexpectedly.
+- Recommend least-privilege: scope to narrowest URN prefix, add IP condition, set expiration where supported.
+- Keep recommendations reversible and explicit about blast radius.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full IAM audit or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before privileged, access-granting, or production-impacting recommendations.
+- [Official sources](references/official-sources.md) — use when grounding OVHcloud IAM service behavior or checking the source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the policy verdict and evidence level,
+- specific URN scope and condition gaps found,
+- the blast radius of the current policy,
+- safe remediation recommendations with rollback notes,
+- blockers or unknowns that prevent stronger conclusions.

package/skills/ovhcloud/ovhcloud-iam-policy-review/metadata.json

@@ -0,0 +1,26 @@
+{
+  "id": "ovhcloud-iam-policy-review",
+  "name": "OVHcloud IAM Policy Review",
+  "type": "skill",
+  "provider": "ovhcloud",
+  "harnesses": [
+    "codex",
+    "copilot",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro"
+  ],
+  "summary": "Review OVHcloud IAM policies for overly permissive allow rules, missing deny blocks, unscoped URNs, absent condition blocks (IP CIDR, resource tag, expiration), and identity-group hygiene.",
+  "source_type": "original",
+  "official_docs": [
+    "https://help.ovhcloud.com/csm/en-account-iam-policies?id=kb_article_view&sysparm_article=KB0055594",
+    "https://registry.terraform.io/providers/ovh/ovh/latest/docs/resources/iam_policy",
+    "https://api.ovh.com/console/#/me/api/credential"
+  ],
+  "security_notes": "OVHcloud IAM conditions (IP CIDR, resource tags, expiration) can silently allow broad access if omitted; always audit allow/deny rule order and URN scope before approving policy changes.",
+  "last_verified": "2026-05-10",
+  "path": "skills/ovhcloud/ovhcloud-iam-policy-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/ovhcloud/ovhcloud-iam-policy-review/references/official-sources.md

@@ -0,0 +1,15 @@
+# Official sources
+
+Use this reference only when you need source grounding for OVHcloud IAM service behavior or the detailed source list.
+
+## OVHcloud documentation
+
+Use these as starting points, not as proof of the user's live OVHcloud IAM state:
+
+- https://help.ovhcloud.com/csm/en-account-iam-policies?id=kb_article_view&sysparm_article=KB0055594
+- https://registry.terraform.io/providers/ovh/ovh/latest/docs/resources/iam_policy
+- https://api.ovh.com/console/#/me/api/credential
+
+## Grounding rule
+
+Official documentation explains OVHcloud IAM service behavior and URN schema. It does not prove the user's current account policies, identity group membership, OAuth2 credential scopes, or live access state. Prefer live OVHcloud API evidence or sanitized user-provided policy JSON for current-state claims.

package/skills/ovhcloud/ovhcloud-iam-policy-review/references/safety-checklist.md

@@ -0,0 +1,25 @@
+# Safety checklist
+
+Use this reference before privileged, destructive, access-granting, compliance-impacting, or production-impacting recommendations.
+
+## Non-negotiables
+
+- Never ask users to paste API tokens, application keys, OAuth2 client secrets, session tokens, or account passwords into chat.
+- Prefer OVHcloud IAM docs and Terraform provider docs as the source of truth for policy behavior. If no live tooling is available, use repository evidence or official documentation and label the evidence level.
+- Do not invent account IDs, NIC handles, URN paths, identity group names, or live policy state.
+- Require explicit user approval before recommending policy changes, group membership changes, or OAuth2 scope reductions that affect production workloads.
+- Use Context7 or official OVHcloud documentation for current IAM service behavior when the answer depends on OVHcloud-specific semantics.
+- Keep remediation least-privilege, reversible, and scoped to the requested account boundary.
+
+## Stress checks
+
+- What URN scope can expose unintended resources or actions?
+- What action list can escalate privilege or perform irreversible operations?
+- What missing condition block allows access from untrusted origins?
+- What identity group aggregation creates unexpected cross-service blast radius?
+- What compliance or audit evidence is missing?
+- What rollback or validation path is unproven?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live OVHcloud IAM state.

package/skills/ovhcloud/ovhcloud-iam-policy-review/references/workflow-and-output.md

@@ -0,0 +1,62 @@
+# Workflow and output contract
+
+Use this reference only when performing the full IAM policy audit, pre-deployment review, or least-privilege remediation pass.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Policy type, principal identity or group, resource URN scope, action set, and intended operations
+- Wildcarded URNs (`urn:v1:eu:resource:*`), over-broad action lists, allow rules that may supersede deny rules unexpectedly
+- Missing condition blocks: IP CIDR restrictions, resource tag conditions, expiration dates
+- OAuth2 service account scope vs. minimum required permissions
+- Identity group membership sprawl and aggregated permission blast radius
+- Reversibility of policy changes and rollback path
+
+## Safe workflow
+
+1. **Frame scope**
+   - Account / NIC handle and environment:
+   - Policy name(s) and principal type (user, group, service account):
+   - Business purpose and data classification:
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer live OVHcloud API or Terraform state evidence if available.
+   - Otherwise inspect repository `ovh_iam_policy` resources, sanitized user-provided config, or official OVHcloud docs.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - What URN scope can expose unintended resources?
+   - What action set can escalate privilege or perform destructive operations?
+   - What missing condition allows access from untrusted networks or identities?
+   - What identity group membership creates over-aggregated permissions?
+   - What evidence is missing that prevents a confident verdict?
+4. **Recommend the smallest safe action**
+   - Prefer narrowest URN prefix, explicit condition blocks, and staged rollout.
+   - If the safest action is to stop and gather the actual policy JSON, say that plainly.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# OVHcloud IAM Policy Review: <policy name or scope>
+## Executive verdict
+- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Findings
+| Severity | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Checks or API calls:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/ovhcloud/ovhcloud-kubernetes-platform-operator/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: ovhcloud-kubernetes-platform-operator
+description: Review and advise on OVHcloud Managed Kubernetes (MCK) cluster lifecycle, node pool sizing, autoscaling configuration, version upgrade planning, workload placement via taints and tolerations, network policies, RBAC hardening, and cluster security posture. Use when the user needs MCK operational guidance, Terraform IaC review for `ovh_cloud_project_kube` resources, or upgrade risk assessment.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-10"
+  category: platform
+---
+
+# OVHcloud Kubernetes Platform Operator
+
+## Purpose
+
+Provide advisory guidance on OVHcloud Managed Kubernetes lifecycle, node pool operations, workload placement, and cluster security — without performing live mutations.
+
+## When to use
+
+Use this skill for:
+
+- MCK cluster version upgrade planning and compatibility review
+- Node pool sizing, autoscaling bounds, and flavor selection guidance
+- Workload placement via taints, tolerations, and node affinity rules
+- Network policy and RBAC hardening review
+- Terraform IaC review for `ovh_cloud_project_kube` and `ovh_cloud_project_kube_nodepool` resources
+- Pre-deletion drain and PodDisruptionBudget validation review
+
+## Lean operating rules
+
+- Prefer OVHcloud Kubernetes docs and Terraform provider docs; if MCP tooling is unavailable, fall back to https://help.ovhcloud.com/ and Context7.
+- Separate confirmed cluster state from inference. If the cluster configuration was not shown, say so.
+- Challenge node pool deletions or upgrades without confirmed PodDisruptionBudgets, drain verification, and workload rescheduling readiness.
+- Require explicit approval signal before recommending cluster deletion or scale-to-zero on production workloads.
+- Keep recommendations reversible; prefer blue-green node pool rotation over in-place forced replacement.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full cluster review or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before cluster upgrades, node pool deletions, scale-to-zero operations, or RBAC changes.
+- [Official sources](references/official-sources.md) — use when grounding OVHcloud Managed Kubernetes service behavior or checking the source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the cluster posture verdict and evidence level,
+- confirmed upgrade or operational risks,
+- safe next actions with rollback notes,
+- PDB and drain readiness assessment where relevant,
+- blockers or unknowns that prevent stronger conclusions.

package/skills/ovhcloud/ovhcloud-kubernetes-platform-operator/metadata.json

@@ -0,0 +1,26 @@
+{
+  "id": "ovhcloud-kubernetes-platform-operator",
+  "name": "OVHcloud Kubernetes Platform Operator",
+  "type": "skill",
+  "provider": "ovhcloud",
+  "harnesses": [
+    "codex",
+    "copilot",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro"
+  ],
+  "summary": "Review and advise on OVHcloud Managed Kubernetes lifecycle, node pool operations, upgrade planning, workload placement, RBAC, and cluster security posture.",
+  "source_type": "original",
+  "official_docs": [
+    "https://help.ovhcloud.com/csm/en-public-cloud-kubernetes?id=kb_article_view&sysparm_article=KB0049613",
+    "https://registry.terraform.io/providers/ovh/ovh/latest/docs/resources/cloud_project_kube",
+    "https://registry.terraform.io/providers/ovh/ovh/latest/docs/resources/cloud_project_kube_nodepool"
+  ],
+  "security_notes": "MCK node pool upgrades are disruptive if PodDisruptionBudgets are absent; never recommend force-deleting nodes without draining and confirming workload rescheduling.",
+  "last_verified": "2026-05-10",
+  "path": "skills/ovhcloud/ovhcloud-kubernetes-platform-operator",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/ovhcloud/ovhcloud-kubernetes-platform-operator/references/official-sources.md

@@ -0,0 +1,15 @@
+# Official sources
+
+Use this reference only when you need source grounding for OVHcloud Managed Kubernetes service behavior or the detailed source list.
+
+## OVHcloud documentation
+
+Use these as starting points, not as proof of the user's live cluster state:
+
+- https://help.ovhcloud.com/csm/en-public-cloud-kubernetes?id=kb_article_view&sysparm_article=KB0049613
+- https://registry.terraform.io/providers/ovh/ovh/latest/docs/resources/cloud_project_kube
+- https://registry.terraform.io/providers/ovh/ovh/latest/docs/resources/cloud_project_kube_nodepool
+
+## Grounding rule
+
+Official documentation explains OVHcloud Managed Kubernetes version support windows, node pool lifecycle policies, and MCK-specific behavior. It does not prove the user's current cluster version, node pool configuration, PodDisruptionBudget coverage, RBAC state, or network policy posture. Prefer live MCK API evidence or sanitized user-provided cluster config for current-state claims.

package/skills/ovhcloud/ovhcloud-kubernetes-platform-operator/references/safety-checklist.md

@@ -0,0 +1,26 @@
+# Safety checklist
+
+Use this reference before recommending cluster upgrades, node pool deletions, scale-to-zero operations, RBAC changes, or any action that could disrupt running workloads.
+
+## Non-negotiables
+
+- Never ask users to paste kubeconfig files, service account tokens, API tokens, or cluster certificates into chat.
+- Prefer OVHcloud Managed Kubernetes docs and Terraform provider docs for service behavior. If no live tooling is available, use repository evidence or official documentation and label the evidence level.
+- Do not invent cluster names, node pool IDs, Kubernetes versions, autoscaling limits, or live workload state.
+- Require explicit user approval before recommending cluster deletion, node pool deletion, forced drain, or scale-to-zero on production workloads.
+- Do not recommend a node pool upgrade or replacement without confirmed PodDisruptionBudgets and drain readiness for all affected workloads.
+- Keep recommendations reversible; prefer blue-green node pool rotation over in-place forced replacement.
+- Use Context7 or official OVHcloud documentation for current Kubernetes version support windows and MCK-specific behavior.
+
+## Stress checks
+
+- What workloads lack a PDB and would be disrupted by a node drain or pool replacement?
+- What Kubernetes version upgrade introduces API deprecations or breaking add-on changes?
+- What RBAC binding creates cluster-wide write access or privilege escalation paths?
+- What network policy gap leaves backend services exposed across namespaces?
+- What autoscaling configuration could trigger uncontrolled cost growth?
+- What rollback path is available if the upgrade fails mid-process?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live cluster state, workload PDB coverage, or RBAC configuration.