@raishin/vanguard-frontier-agentic 1.6.0 → 1.7.0

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.

package/skills/ovhcloud/ovhcloud-maestro/metadata.json

@@ -0,0 +1,26 @@
+{
+  "id": "ovhcloud-maestro",
+  "name": "OVHcloud Maestro",
+  "type": "skill",
+  "provider": "ovhcloud",
+  "harnesses": [
+    "codex",
+    "copilot",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro"
+  ],
+  "summary": "Classify incoming OVHcloud tasks by domain and route to the narrowest qualified specialist agent for IAM, FinOps, Kubernetes, networking, or KMS operations.",
+  "source_type": "original",
+  "official_docs": [
+    "https://help.ovhcloud.com/csm/en-documentation?id=kb_home",
+    "https://api.ovh.com/console/",
+    "https://registry.terraform.io/providers/ovh/ovh/latest/docs"
+  ],
+  "security_notes": "Routing layer must stay read-only; never attempt live OVHcloud API mutations from the classification layer — hand off to approval-gated specialists.",
+  "last_verified": "2026-05-10",
+  "path": "skills/ovhcloud/ovhcloud-maestro",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/ovhcloud/ovhcloud-maestro/references/official-sources.md

@@ -0,0 +1,15 @@
+# Official sources
+
+Use this reference only when you need source grounding for OVHcloud service classification or the detailed source list.
+
+## OVHcloud documentation
+
+Use these as classification anchors, not as proof of the user's live OVHcloud 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
+- https://api.ovh.com/console/
+
+## Grounding rule
+
+Official documentation describes OVHcloud service behavior and resource types. It does not prove the user's current account structure, project configuration, deployed resources, or operational state. Prefer user-provided evidence or repository IaC for current-state claims. Use documentation only to confirm service semantics, resource naming, and domain classification signals.

package/skills/ovhcloud/ovhcloud-maestro/references/safety-checklist.md

@@ -0,0 +1,23 @@
+# Safety checklist
+
+Use this reference before any routing decision that may dispatch to a live-guard or privileged specialist.
+
+## Non-negotiables
+
+- Never attempt live OVHcloud API calls, Terraform mutations, or credential operations from the routing layer.
+- Never ask users to paste API tokens, application keys, OAuth2 client secrets, or account passwords into chat.
+- Do not invent account IDs, project IDs, region codes, resource URNs, or service names.
+- Treat an ambiguous domain as a blocker — ask one clarifying question rather than routing to the wrong specialist.
+- If the request contains signals for the live-guard KMS skill, confirm explicitly before routing. Key destruction is irreversible.
+- Keep routing output minimal; do not speculate about specialist-layer findings before routing.
+
+## Stress checks
+
+- Is the domain actually clear, or is the classification an inference?
+- Does the request contain any live-guard signals (key destruction, irreversible deletion, production mutation)?
+- Is there enough scope information to give the specialist a useful handoff, or does the user need to provide more context first?
+- Could routing to the wrong specialist expose privileged evidence or trigger an inappropriate action?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference` when describing classification signals. Inference alone never justifies routing to a live-guard specialist.

package/skills/ovhcloud/ovhcloud-maestro/references/workflow-and-output.md

@@ -0,0 +1,50 @@
+# Workflow and output contract
+
+Use this reference only when performing domain classification, routing arbitration, or scope disambiguation for OVHcloud requests.
+
+## Classification domains
+
+Check these signals before assigning a domain verdict:
+
+- **IAM** — policy URNs, `ovh_iam_policy` resources, OAuth2 credentials, identity groups, conditional access blocks
+- **FinOps** — billing spikes, idle instances, unattached volumes, Savings Plans coverage gaps, tagging hygiene
+- **Kubernetes** — MCK cluster lifecycle, node pool operations, version upgrades, RBAC, network policies
+- **Networking** — vRack membership, VLAN segmentation, private network attachment, security groups, DNS zones
+- **Live KMS guard** — key version destruction, key rotation decommission, scheduled deletion of `okms_service_key`
+
+## Safe routing workflow
+
+1. **Frame the request**
+   - Requested operation and surface area:
+   - Account / project ID (if stated):
+   - Environment (production / staging / unknown):
+   - Explicit non-goals:
+2. **Collect classification signals**
+   - Prefer OVHcloud API console or Terraform provider resource names as domain anchors.
+   - Otherwise inspect repository IaC, user-provided config, or official OVHcloud docs.
+   - Label each signal as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Resolve domain overlap**
+   - If the request spans two domains, name both and route to the primary domain specialist with a note for the secondary.
+   - If domain cannot be determined from context alone, ask exactly one clarifying question. Do not ask compound questions.
+4. **Emit routing verdict**
+   - Keep the verdict minimal: domain, specialist, signals, blockers, and one follow-up question if ambiguous.
+   - Never attempt live OVHcloud API mutations from the routing layer.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# OVHcloud Routing Verdict: <brief task label>
+## Domain verdict
+- Primary domain: <IAM | FinOps | Kubernetes | Networking | Live KMS guard>
+- Confidence: HIGH / MEDIUM / LOW
+- Classification signals:
+## Recommended specialist
+- Skill: <ovhcloud-iam-policy-review | ovhcloud-cost-finops-analyst | ovhcloud-kubernetes-platform-operator | ovhcloud-network-architect | ovhcloud-live-kms-key-destruction-guard>
+- Scope handed off: <concise scope statement>
+## Blockers
+- <list or explicit none>
+## Clarifying question (if confidence is LOW)
+- <single question or omit this section>
+```

package/skills/ovhcloud/ovhcloud-network-architect/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: ovhcloud-network-architect
+description: Design and review OVHcloud network topology including vRack private network segmentation, VLAN configuration, Public Cloud private network attachment, dedicated server connectivity, load balancer placement, DNS zone design, security group rules, and blast-radius scoping for topology changes. Use when the user needs vRack design guidance, network isolation review, or Terraform IaC review for `ovh_vrack` and related resources.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-10"
+  category: networking
+---
+
+# OVHcloud Network Architect
+
+## Purpose
+
+Design and review OVHcloud network topology with a security-first, least-exposure posture: vRack segmentation, VLAN isolation, private connectivity, and blast-radius scoping before any topology change.
+
+## When to use
+
+Use this skill for:
+
+- vRack design: member inventory, VLAN assignment, and isolation between Public Cloud and dedicated infrastructure
+- Private network attachment for Public Cloud projects and Kubernetes clusters
+- Load balancer placement and upstream routing design
+- DNS zone design and record management via `ovh_domain_zone` resources
+- Security group rule review for Public Cloud instances
+- Pre-change blast-radius assessment for vRack topology modifications
+- Terraform IaC review for `ovh_vrack`, `ovh_cloud_project_network_private`, and related resources
+
+## Lean operating rules
+
+- Prefer OVHcloud networking docs and Terraform provider docs; if MCP tooling is unavailable, fall back to https://help.ovhcloud.com/ and Context7.
+- Separate confirmed topology from inference. If the current vRack member list was not shown, say so.
+- Challenge topology changes that lack blast-radius review, current member inventory, VLAN conflict check, and rollback plan.
+- Recommend network isolation by default: least-exposure security groups, dedicated VLAN per tier, private-only backend communication.
+- Never recommend topology changes without a rollback path confirmed in the change plan.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full topology review or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before vRack topology changes, VLAN modifications, private network deletions, or security group updates.
+- [Official sources](references/official-sources.md) — use when grounding OVHcloud networking service behavior or checking the source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the topology verdict and evidence level,
+- confirmed isolation gaps or blast-radius risks,
+- safe topology recommendations with rollback notes,
+- VLAN conflict or member inventory gaps,
+- blockers or unknowns that prevent stronger conclusions.

package/skills/ovhcloud/ovhcloud-network-architect/metadata.json

@@ -0,0 +1,26 @@
+{
+  "id": "ovhcloud-network-architect",
+  "name": "OVHcloud Network Architect",
+  "type": "skill",
+  "provider": "ovhcloud",
+  "harnesses": [
+    "codex",
+    "copilot",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro"
+  ],
+  "summary": "Design and review OVHcloud vRack topology, network isolation, private connectivity, load balancer placement, DNS, and security groups with blast-radius scoping for topology changes.",
+  "source_type": "original",
+  "official_docs": [
+    "https://help.ovhcloud.com/csm/en-vrack?id=kb_article_view&sysparm_article=KB0044799",
+    "https://registry.terraform.io/providers/ovh/ovh/latest/docs/resources/vrack",
+    "https://registry.terraform.io/providers/ovh/ovh/latest/docs/resources/cloud_project_network_private"
+  ],
+  "security_notes": "vRack topology changes can expose bare-metal and Public Cloud resources to unintended lateral movement; always audit current vRack members and routing rules before recommending topology modifications.",
+  "last_verified": "2026-05-10",
+  "path": "skills/ovhcloud/ovhcloud-network-architect",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/ovhcloud/ovhcloud-network-architect/references/official-sources.md

@@ -0,0 +1,15 @@
+# Official sources
+
+Use this reference only when you need source grounding for OVHcloud networking service behavior or the detailed source list.
+
+## OVHcloud documentation
+
+Use these as starting points, not as proof of the user's live vRack topology or network state:
+
+- https://help.ovhcloud.com/csm/en-vrack?id=kb_article_view&sysparm_article=KB0044799
+- https://registry.terraform.io/providers/ovh/ovh/latest/docs/resources/vrack
+- https://registry.terraform.io/providers/ovh/ovh/latest/docs/resources/cloud_project_network_private
+
+## Grounding rule
+
+Official documentation explains OVHcloud vRack service semantics, VLAN configuration, private network attachment behavior, and Terraform resource capabilities. It does not prove the user's current vRack member inventory, VLAN assignments, security group rules, subnet configuration, or routing state. Prefer live OVHcloud API evidence or sanitized user-provided topology diagrams and Terraform state for current-state claims.

package/skills/ovhcloud/ovhcloud-network-architect/references/safety-checklist.md

@@ -0,0 +1,26 @@
+# Safety checklist
+
+Use this reference before recommending vRack topology changes, VLAN additions or removals, private network modifications, security group updates, or any action that could affect network isolation or connectivity.
+
+## Non-negotiables
+
+- Never ask users to paste API tokens, application keys, SSH private keys, or account passwords into chat.
+- Prefer OVHcloud networking 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 vRack IDs, VLAN IDs, subnet CIDRs, security group rule IDs, or live topology state.
+- Require explicit user approval before recommending vRack member detachment, VLAN removal, private subnet deletion, or security group rule changes that affect production traffic paths.
+- Never recommend a topology change without a confirmed rollback plan and blast-radius assessment.
+- If the current vRack member inventory has not been confirmed, stop and require it before proceeding with topology change recommendations.
+- Use Context7 or official OVHcloud documentation for current vRack service behavior, VLAN limits, and MCK private network attachment semantics.
+
+## Stress checks
+
+- What topology change could isolate a production member and cause a service outage?
+- What VLAN ID conflict could cause cross-tenant or cross-tier traffic leakage?
+- What security group rule change leaves backend services reachable from the public internet or wrong tier?
+- What private network modification could break Kubernetes cluster networking or inter-node communication?
+- What DNS change could cause resolution failures, delegation breaks, or split-horizon inconsistencies?
+- What rollback or recovery path is available if the topology change has unintended effects?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live vRack membership, VLAN assignments, security group rules, or routing state.

package/skills/ovhcloud/ovhcloud-network-architect/references/workflow-and-output.md

@@ -0,0 +1,65 @@
+# Workflow and output contract
+
+Use this reference only when performing a full vRack topology review, network isolation audit, private network design, or blast-radius assessment for OVHcloud networking.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- vRack member inventory: Public Cloud projects, dedicated servers, and other services attached to the vRack
+- VLAN assignment and segmentation: VLAN IDs per tier, conflict risk with other members, and isolation between Public Cloud and dedicated infrastructure
+- Private network attachment: `ovh_cloud_project_network_private` subnets, DHCP configuration, and routing between VLANs
+- Security group rules: ingress and egress rules for Public Cloud instances, default-allow vs. least-exposure posture
+- Load balancer placement and upstream routing path to backends
+- DNS zone design: `ovh_domain_zone` record management, delegation, and split-horizon considerations
+- Blast radius of proposed topology changes: what services lose connectivity if a vRack member or VLAN is removed
+- Terraform IaC for `ovh_vrack`, `ovh_cloud_project_network_private`, and related resources
+
+## Safe workflow
+
+1. **Frame scope**
+   - vRack ID, attached member list (if known), and environment:
+   - Business criticality and traffic paths in scope:
+   - Change type (design, review, topology modification, VLAN add/remove):
+   - Required outcome:
+   - Explicit non-goals (e.g., do not modify dedicated server connectivity):
+2. **Collect evidence**
+   - Prefer live OVHcloud API or Terraform state evidence if available.
+   - Otherwise inspect repository `ovh_vrack` and `ovh_cloud_project_network_private` resources, sanitized user-provided topology diagrams, or official OVHcloud docs.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - What topology change could isolate a production member or break a critical traffic path?
+   - What VLAN conflict could cause cross-tenant or cross-tier leakage?
+   - What security group gap leaves backend services reachable from the wrong tier or the public internet?
+   - What DNS change could cause resolution failures or split-horizon inconsistencies?
+   - What evidence is missing that prevents a confident blast-radius assessment?
+4. **Recommend the smallest safe action**
+   - Prefer additive changes (add VLAN, add private subnet) before removals.
+   - Require a rollback plan before recommending any vRack member detachment or VLAN removal.
+   - If the current vRack member inventory was not confirmed, stop and say so.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# OVHcloud Network Architecture Review: <vRack 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>
+## Blast-radius assessment
+- Members at risk: <list or none>
+- VLAN conflict check: <confirmed / unconfirmed / not applicable>
+## Residual risk
+- <risk or explicit none>
+```