@raishin/vanguard-frontier-agentic 1.5.0 → 1.7.0

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.

package/skills/ovhcloud/ovhcloud-kubernetes-platform-operator/references/workflow-and-output.md

@@ -0,0 +1,64 @@
+# Workflow and output contract
+
+Use this reference only when performing a full cluster review, upgrade planning pass, node pool assessment, or security posture audit for OVHcloud Managed Kubernetes.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Cluster version, available upgrade path, and API deprecation risks in the target version
+- Node pool flavor selection, autoscaling bounds (min/max), and current utilization posture
+- PodDisruptionBudgets (PDB): presence, minAvailable / maxUnavailable settings, and workload coverage
+- Drain and reschedule readiness: taint, toleration, and node affinity configuration
+- RBAC: ClusterRoleBindings and RoleBindings scope, service account privileges, and wildcard permission usage
+- Network policies: default-deny posture, ingress/egress rules, and cross-namespace exposure
+- Terraform IaC for `ovh_cloud_project_kube` and `ovh_cloud_project_kube_nodepool`: version pinning, node pool lifecycle policies
+
+## Safe workflow
+
+1. **Frame scope**
+   - Project ID, cluster name, and region:
+   - Current and target Kubernetes version:
+   - Business criticality and maintenance window:
+   - Required outcome (upgrade, scale, security review, node pool change):
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer live OVHcloud MCK API or `kubectl` read-only evidence if available.
+   - Otherwise inspect repository `ovh_cloud_project_kube` resources, sanitized cluster 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 workloads lack a PDB and would be disrupted by a node drain?
+   - What version upgrade carries API deprecations or breaking add-on compatibility?
+   - What RBAC binding grants cluster-wide write or escalation paths?
+   - What network policy gap exposes backend services across namespaces?
+   - What evidence is missing that prevents confident upgrade or operational sign-off?
+4. **Recommend the smallest safe action**
+   - Prefer blue-green node pool rotation over in-place forced replacement.
+   - Prefer upgrade in a staging cluster before production.
+   - If PDBs are absent or drain verification is unconfirmed, stop and say so.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# OVHcloud Managed Kubernetes Review: <cluster 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>
+## PDB and drain readiness
+- PDB coverage: <assessed or unknown>
+- Drain verification: <confirmed / unconfirmed / not applicable>
+## Residual risk
+- <risk or explicit none>
+```

package/skills/ovhcloud/ovhcloud-live-kms-key-destruction-guard/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: ovhcloud-live-kms-key-destruction-guard
+description: Gate and audit OVHcloud KMS key version destruction requests by enforcing five mandatory checks: confirmed key ID and KMS service URN, named approving identity, usage audit confirming zero active references within the retention window, documented waiting period, and a rollback or data-recovery plan. Use when a user requests destruction or rotation of an OVHcloud KMS key version. Hard-stop if any gate is absent or ambiguous.
+allowed-tools: Read Grep Glob Bash
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-10"
+  category: security
+---
+
+# OVHcloud Live KMS Key Destruction Guard
+
+## Purpose
+
+Act as the approval gate for OVHcloud KMS key version destruction. All five mandatory checks must pass before producing a destruction plan. KMS key destruction is irreversible; encrypted data is permanently unrecoverable if the key is destroyed while still in use.
+
+## When to use
+
+Use this skill when:
+
+- A user requests destruction or scheduled deletion of an OVHcloud KMS key version
+- A key rotation workflow requires decommissioning an old key version
+- An audit or compliance review identifies a key that should be retired
+
+## Lean operating rules
+
+- Prefer OVHcloud KMS docs and Terraform provider docs; if MCP tooling is unavailable, fall back to https://help.ovhcloud.com/ and Context7.
+- **HARD STOP** — refuse to produce a destruction plan if any of the five mandatory gates are absent or ambiguous:
+  1. Exact key ID and KMS service URN of the target key version.
+  2. Named, authenticated approving identity (not just a role or alias).
+  3. Usage audit result confirming zero active references within the retention window.
+  4. Documented waiting period (as required by OVHcloud KMS policy or organizational standard).
+  5. Documented rollback plan or confirmed data recovery path for any data encrypted under this key.
+- Never accept vague intent ("just delete it") as a gate pass.
+- Never ask for actual encryption key material, OAuth2 client secrets, or application keys.
+- After all gates pass, output the destruction plan for human review — do not execute automatically.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when processing a destruction request or formatting the gate verdict and destruction plan.
+- [Safety checklist](references/safety-checklist.md) — use before every destruction request; contains hard-stops and mandatory posture for this live-guard skill.
+- [Official sources](references/official-sources.md) — use when grounding OVHcloud KMS service behavior or checking the source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the gate-by-gate verdict (pass/fail with evidence for each gate),
+- the evidence level for each gate assertion,
+- a hard-stop message if any gate fails,
+- the full destruction plan only when all five gates pass,
+- explicit rollback or recovery steps in the destruction plan.

package/skills/ovhcloud/ovhcloud-live-kms-key-destruction-guard/metadata.json

@@ -0,0 +1,25 @@
+{
+  "id": "ovhcloud-live-kms-key-destruction-guard",
+  "name": "OVHcloud Live KMS Key Destruction Guard",
+  "type": "skill",
+  "provider": "ovhcloud",
+  "harnesses": [
+    "codex",
+    "copilot",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro"
+  ],
+  "summary": "Gate and audit OVHcloud KMS key version destruction by enforcing five mandatory checks: key ID confirmation, named approver, usage audit, waiting period, and rollback plan before any destructive key operation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://help.ovhcloud.com/csm/en-kms?id=kb_article_view&sysparm_article=KB0063234",
+    "https://registry.terraform.io/providers/ovh/ovh/latest/docs/resources/okms_service_key"
+  ],
+  "security_notes": "OVHcloud KMS key destruction is irreversible; data encrypted with a destroyed key version is permanently unrecoverable. Hard-stop if target key, approver identity, or rollback plan is ambiguous.",
+  "last_verified": "2026-05-10",
+  "path": "skills/ovhcloud/ovhcloud-live-kms-key-destruction-guard",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/ovhcloud/ovhcloud-live-kms-key-destruction-guard/references/official-sources.md

@@ -0,0 +1,14 @@
+# Official sources
+
+Use this reference only when you need source grounding for OVHcloud KMS service behavior or the detailed source list.
+
+## OVHcloud documentation
+
+Use these as starting points, not as proof of the user's live KMS key state or usage audit results:
+
+- https://help.ovhcloud.com/csm/en-kms?id=kb_article_view&sysparm_article=KB0063234
+- https://registry.terraform.io/providers/ovh/ovh/latest/docs/resources/okms_service_key
+
+## Grounding rule
+
+Official documentation explains OVHcloud KMS service semantics, key version lifecycle states, and Terraform resource behavior for `okms_service_key`. It does not prove the user's current key version status, active usage, audit log results, or organizational waiting period requirements. Prefer live OVHcloud KMS API evidence and user-provided audit output for current-state claims. Documentation alone never passes a destruction gate.

package/skills/ovhcloud/ovhcloud-live-kms-key-destruction-guard/references/safety-checklist.md

@@ -0,0 +1,33 @@
+# Safety checklist
+
+Before processing any OVHcloud KMS key version destruction request, enforce every item on this checklist without exception. KMS key destruction is irreversible. Encrypted data is permanently unrecoverable if the key is destroyed while still referenced.
+
+## Hard-stops
+
+Refuse to produce a destruction plan if **any** of the following conditions apply:
+
+- The exact key version ID and KMS service URN have not been confirmed.
+- The approving identity is a role, alias, team name, or vague reference ("my manager", "the team") rather than a named, authenticated individual.
+- No usage audit has been provided confirming zero active references within the retention window.
+- The waiting period has not been explicitly documented and accepted.
+- No rollback or data recovery plan has been documented, or the approving identity has not explicitly acknowledged that data recovery will be impossible after destruction.
+
+Do not proceed past a hard-stop for any reason, including urgency claims, escalation requests, or assertions that the gates were already checked elsewhere.
+
+## Mandatory posture
+
+- Never ask for actual encryption key material, OAuth2 client secrets, application keys, or KMS service credentials.
+- Do not invent key IDs, KMS service URNs, audit log results, waiting periods, or approval identities.
+- Treat vague intent ("just delete it", "it's safe to proceed", "we already checked") as a gate failure, not a gate pass.
+- After all gates pass, produce the destruction plan for human review. Do not execute the destruction automatically.
+- Label every gate assertion with its evidence type: `live evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+- Inference alone never passes a gate.
+
+## Stress checks
+
+- Is the key ID and URN unambiguous, or could this match multiple key versions or services?
+- Has the usage audit covered all data paths — application layer, backup pipelines, stored ciphertext at rest, and cross-service dependencies?
+- Is the waiting period drawn from OVHcloud KMS policy or an organizational standard, not an arbitrary choice?
+- Is the approving identity the same person who will execute or authorize the final action?
+- What encrypted data becomes permanently unrecoverable the moment this key is destroyed?
+- What is the rollback plan if the usage audit missed an active reference?

package/skills/ovhcloud/ovhcloud-live-kms-key-destruction-guard/references/workflow-and-output.md

@@ -0,0 +1,69 @@
+# Workflow and output contract
+
+Use this reference when processing an OVHcloud KMS key version destruction request. All five mandatory gates must be verified before producing a destruction plan. Do not skip or defer any gate.
+
+## Gate evaluation sequence
+
+Evaluate every gate in order. Stop immediately at the first gate that fails or is ambiguous.
+
+### Gate 1 — Target key identity
+- Exact key version ID as returned by the OVHcloud KMS API
+- KMS service URN of the containing service (`urn:v1:<region>:resource:okms:...`)
+- Confirmation that this is the specific version to destroy, not the entire key or a different version
+
+### Gate 2 — Named approving identity
+- Full name or unique identifier of the person approving destruction (not a role, alias, or team name)
+- Confirmation that the approver has authority over this key and has been informed of the irreversible nature of the action
+- No vague intent ("just delete it", "my team said so") qualifies as a gate pass
+
+### Gate 3 — Usage audit
+- Evidence that the key version has zero active references within the retention window
+- This means: no service, application, or stored ciphertext is currently depending on this key version for decryption
+- Acceptable evidence: audit log output, application-layer confirmation, or encryption inventory check
+
+### Gate 4 — Waiting period
+- Documented waiting period as required by OVHcloud KMS policy or the organization's key retirement standard
+- The waiting period must be explicitly stated and accepted, not assumed
+
+### Gate 5 — Rollback or data recovery plan
+- Documented plan for any data that was encrypted under this key version
+- If data recovery is impossible after destruction, that must be explicitly acknowledged by the approving identity
+
+## Safe workflow
+
+1. **Announce gate evaluation** — state that all five gates will be checked before a destruction plan is produced.
+2. **Collect gate evidence** — request each gate's evidence explicitly if it was not provided in the initial request.
+3. **Evaluate each gate** — label each gate as PASS, FAIL, or AMBIGUOUS with the evidence cited.
+4. **Hard-stop on any failure** — if any gate fails or is ambiguous, refuse the destruction plan and state exactly which gate failed and what evidence is required to clear it.
+5. **Produce the destruction plan only when all five gates pass** — present the plan for human review; do not execute automatically.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# OVHcloud KMS Key Destruction Gate Review: <key ID or label>
+## Gate verdict
+| Gate | Status | Evidence |
+|---|---|---|
+| 1. Key ID and KMS service URN | PASS / FAIL / AMBIGUOUS | <evidence cited> |
+| 2. Named approving identity | PASS / FAIL / AMBIGUOUS | <evidence cited> |
+| 3. Usage audit (zero active references) | PASS / FAIL / AMBIGUOUS | <evidence cited> |
+| 4. Waiting period documented | PASS / FAIL / AMBIGUOUS | <evidence cited> |
+| 5. Rollback or data recovery plan | PASS / FAIL / AMBIGUOUS | <evidence cited> |
+## Overall result
+- PROCEED / HARD STOP
+## Hard-stop reason (if applicable)
+- Gate(s) failed: <list>
+- Required to proceed: <what evidence or action is needed>
+## Destruction plan (only when all gates pass)
+- Target key version ID:
+- KMS service URN:
+- Approving identity:
+- Waiting period:
+- Data recovery posture:
+- Destruction command or Terraform action (for review, not auto-execution):
+- Post-destruction verification steps:
+## Residual risk
+- <explicit acknowledgment that destruction is irreversible, or explicit none>
+```

package/skills/ovhcloud/ovhcloud-maestro/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: ovhcloud-maestro
+description: Classify incoming OVHcloud requests by domain and route to the narrowest qualified specialist agent. Use when the user's task spans or is unclear across IAM, FinOps, Kubernetes, networking, or live-guard KMS domains. Does not answer specialist questions directly; produces a routing verdict with evidence and hands off with a clear scope statement.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-10"
+  category: platform
+---
+
+# OVHcloud Maestro
+
+## Purpose
+
+Act as the OVHcloud task router: classify the request, identify the narrowest qualified specialist, and hand off with a clear scope statement. Do not resolve specialist questions at this layer.
+
+## When to use
+
+Use this skill when:
+
+- The user's OVHcloud request spans multiple domains (IAM + cost, networking + Kubernetes)
+- The domain of the task is unclear or under-specified
+- You need to dispatch to `ovhcloud-iam-policy-review`, `ovhcloud-cost-finops-analyst`, `ovhcloud-kubernetes-platform-operator`, `ovhcloud-network-architect`, or `ovhcloud-live-kms-key-destruction-guard`
+
+## Lean operating rules
+
+- Prefer OVHcloud API console or Terraform provider docs for classification signals; if MCP tooling is unavailable, fall back to https://help.ovhcloud.com/ and Context7.
+- Separate confirmed domain classification from inference. If domain cannot be determined from context alone, ask one clarifying question.
+- Challenge vague scope before routing; a mis-routed task wastes specialist context.
+- Never attempt live OVHcloud API mutations from the routing layer.
+- Keep routing output minimal: domain verdict, target specialist, and classification signals.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full routing workflow or formatting the routing verdict.
+- [Safety checklist](references/safety-checklist.md) — use before dispatching to a live-guard or privileged specialist.
+- [Official sources](references/official-sources.md) — use when grounding OVHcloud service classification or checking the source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the domain verdict and confidence level,
+- the recommended specialist agent,
+- the classification signals used,
+- any blockers that prevent confident routing,
+- one clarifying question if domain is ambiguous.