@raishin/vanguard-frontier-agentic 1.2.0 → 1.3.0

package/skills/prometheus/prometheus-alerting-cardinality-review/references/workflow-and-output.md

@@ -0,0 +1,221 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide one or more of the following as sanitized YAML snippets (no real endpoints, no auth tokens):
+- `prometheus.yml` (global, scrape_configs, rule_files, remote_write, alerting)
+- Alerting rules YAML (`groups[].rules[]` with `alert:`, `expr:`, `for:`, `labels:`, `annotations:`)
+- Recording rules YAML (`groups[].rules[]` with `record:`, `expr:`)
+- `alertmanager.yml` (route, inhibit_rules, receivers)
+- Optional: current `prometheus_tsdb_head_series` metric value or approximate series count
+
+If the user provides only a partial config, note which sections are absent and limit findings to the provided scope.
+
+### Step 2 — Cardinality audit
+
+Scan every `scrape_configs` job and every metric label dimension referenced in alerting and recording rules.
+
+Check for:
+- Labels sourced from high-cardinality application dimensions:
+  - `user_id`, `request_id`, `session_id`, `transaction_id`, `trace_id`
+  - `url_path`, `uri`, `endpoint` (unless aggressively normalized)
+  - `pod` or `container` labels used as primary grouping in `sum by()` without aggregation
+- Use of `__` internal labels in user-facing metric names
+
+Example cardinality risk:
+```yaml
+# HIGH — request_id is unbounded; this creates one series per request
+http_requests_total{method="GET", path="/api/v1/items", request_id="abc-123"} 1
+```
+
+Correct pattern:
+```yaml
+# CORRECT — drop high-cardinality label before exposition
+http_requests_total{method="GET", path="/api/v1/items"} 1
+```
+
+Note the `prometheus_tsdb_head_series` threshold: above 5 million series, TSDB memory pressure becomes significant. Above 10 million, OOM risk is high without explicit memory tuning (`--storage.tsdb.max-block-duration`, chunk encoding).
+
+### Step 3 — Recording rules audit
+
+Check whether recording rules exist for:
+- SLO error-rate expressions that appear in alerting rules
+- High-cardinality aggregation queries used in Grafana dashboards
+- Any `rate()` or `increase()` expression over a window longer than 5 minutes that is queried at sub-minute dashboard refresh
+
+Flag absence of recording rules for any expression that appears more than once across rules files as MEDIUM.
+
+Example correct recording rule:
+```yaml
+groups:
+  - name: slo_recordings
+    rules:
+      - record: job:http_requests_total:rate5m
+        expr: sum(rate(http_requests_total[5m])) by (job)
+```
+
+### Step 4 — Alert expression correctness audit
+
+For every `alert:` rule, check:
+
+**4a. `for:` duration**
+- Missing `for:` or `for: 0m` → HIGH (bare threshold, flapping)
+- `for:` less than two scrape intervals → flag as LOW (alert may still flap)
+- Recommended minimum: `for: 5m` for infrastructure alerts, `for: 1m` for latency SLOs
+
+```yaml
+# HIGH — missing for:
+- alert: HighErrorRate
+  expr: rate(http_errors_total[5m]) > 0.05
+
+# CORRECT
+- alert: HighErrorRate
+  expr: rate(http_errors_total[5m]) > 0.05
+  for: 5m
+```
+
+**4b. `absent()` usage**
+- `absent(some_metric)` fires if `some_metric` was never scraped — review whether the metric is always expected to exist
+- If the metric only appears when the condition is active (e.g., an error counter), `absent()` fires in the absence of errors, which is a false positive
+
+**4c. SLO alerting pattern**
+- MWMB (multi-window multi-burn-rate) is the Google SRE-recommended SLO alerting pattern
+- Single-window SLO alerts miss slow burns → MEDIUM finding
+
+Example MWMB pattern:
+```yaml
+# MWMB — fast burn (1h + 5m windows) and slow burn (6h + 30m windows)
+- alert: SLOFastBurn
+  expr: >
+    (
+      job:slo_error_rate:rate1h > (14.4 * 0.001)
+      and
+      job:slo_error_rate:rate5m > (14.4 * 0.001)
+    )
+  for: 1m
+  labels:
+    severity: page
+```
+
+### Step 5 — AlertManager routing audit
+
+Parse the `route:` tree and check:
+
+**5a. Duplicate alert routing**
+- Routes that lack `continue: false` on a catch-all receiver may send alerts to multiple receivers unexpectedly
+- Verify whether `continue: true` on intermediate routes is intentional
+
+**5b. Inhibition rules**
+- `inhibit_rules[].source_matchers` and `target_matchers` must reference labels that actually appear on alerts
+- Overly broad inhibition (e.g., `source_matchers: [severity="critical"]` without namespace scope) can suppress alerts across unrelated services
+
+Example inhibition rule review:
+```yaml
+# RISKY — inhibits all warnings when any critical fires, across all namespaces
+inhibit_rules:
+  - source_matchers: [severity="critical"]
+    target_matchers: [severity="warning"]
+    equal: [alertname]
+```
+
+**5c. Receiver configuration**
+- Slack/PagerDuty receivers must have `api_url` or `routing_key` from environment variables or Kubernetes secrets — never hardcoded in the YAML
+- Check for hardcoded webhook URLs or tokens as a CRITICAL security finding
+
+### Step 6 — Scrape config security audit
+
+For every `scrape_configs` entry check:
+
+**6a. `honor_labels`**
+```yaml
+# HIGH — untrusted workload can override job/instance labels
+scrape_configs:
+  - job_name: user-app
+    honor_labels: true
+```
+Only `honor_labels: true` on trusted federation endpoints is acceptable.
+
+**6b. External HTTP targets**
+- Any target with a scheme pointing outside the cluster (e.g., `http://api.external.com`) is an SSRF candidate
+- Flag all non-cluster targets for review
+
+**6c. `job_name` uniqueness**
+- Duplicate `job_name` values cause target label collisions — flag as HIGH
+
+### Step 7 — remote_write and retention audit
+
+**7a. remote_write queue memory**
+```yaml
+remote_write:
+  - url: https://metrics.example.com/api/v1/write
+    queue_config:
+      capacity: 100000        # HIGH memory if series count is large
+      max_samples_per_send: 10000
+```
+Flag `capacity` values above 10,000 combined with high series counts as a memory risk.
+
+**7b. write_relabel_configs label drops**
+```yaml
+# MEDIUM — silently drops 'region' label before remote_write; data loss
+write_relabel_configs:
+  - source_labels: [region]
+    action: labeldrop
+```
+Flag any `labeldrop` or `labelmap` action that targets non-`__` labels without explicit justification.
+
+**7c. Retention**
+- Default Prometheus retention is 15 days (`--storage.tsdb.retention.time=15d`)
+- No remote_write + retention < 30d → MEDIUM (compliance gap for most regulated environments)
+- Recommend Thanos, Cortex, or Grafana Mimir for long-term storage
+
+### Step 8 — Produce the output
+
+Format findings using the Output section below.
+
+---
+
+## Output
+
+Return findings in this structure:
+
+```
+## Verdict
+<one sentence summary: pass / needs work / critical issues found>
+
+## Evidence level
+<live evidence | user-provided sanitized config | documentation-based | inference>
+
+## Findings
+
+### CRITICAL
+- [C1] <finding title>: <description> — <remediation>
+
+### HIGH
+- [H1] <finding title>: <description> — <remediation>
+
+### MEDIUM
+- [M1] <finding title>: <description> — <remediation>
+
+### LOW
+- [L1] <finding title>: <description> — <remediation>
+
+## Safe next actions
+1. <action>
+2. <action>
+...
+
+## Open questions
+- <question requiring user clarification>
+```
+
+---
+
+## Security notes
+
+- Never recommend setting `honor_labels: true` on any scrape target unless the user explicitly confirms it is a trusted Prometheus federation endpoint.
+- Treat hardcoded webhook URLs, API keys, or tokens in `alertmanager.yml` receivers as CRITICAL — they must be moved to Kubernetes Secrets or environment variable references.
+- Do not recommend disabling scrape TLS verification (`tls_config.insecure_skip_verify: true`) without flagging it as a security regression.
+- Treat any recording rule or alert rule that references a metric with unbounded label cardinality as HIGH, even if the immediate symptom (OOM) has not yet occurred.
+- Flag the absence of alerting on `prometheus_tsdb_head_series` itself — teams often have no alert for their own Prometheus health.

package/skills/sigstore/sigstore-cosign-supply-chain-review/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: sigstore-cosign-supply-chain-review
+description: Use this skill when reviewing Sigstore Cosign supply chain security for Kubernetes workloads. Trigger when the user asks whether images are properly signed, whether Kyverno imageVerify policy is correctly scoped, whether SLSA provenance attestations exist, whether SBOM attestations are present, whether keyless signing is in use, or whether Rekor transparency log posture is appropriate for private images.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# Sigstore Cosign Supply Chain Review
+
+## Purpose
+
+Review Cosign image signing verification, Kyverno imageVerify admission policy, SBOM and SLSA provenance attestations, Rekor transparency log posture, and keyless vs key-based signing configuration against supply chain integrity, SLSA level claims, and Kubernetes admission-time enforcement. Sigstore's security model depends entirely on the identity constraints baked into admission policy — an imageVerify rule with no issuer or subject constraint is functionally equivalent to no verification at all.
+
+## Lean operating rules
+
+- Prefer live evidence (`cosign verify`, `kubectl get clusterpolicies`, `cosign verify-attestation`) when the active client exposes it; otherwise fall back to official Sigstore documentation and sanitized YAML from the user.
+- Separate confirmed facts from inference. If Kyverno policy state, Rekor log inclusion, or provenance attestation presence was not directly queried, say so.
+- Treat a Kyverno imageVerify policy missing both `issuer` and `subject` constraints as a critical finding — any Sigstore-signed image from any identity passes.
+- Treat `exclude` rules in imageVerify that match broad glob patterns (`*` or `registry.io/*`) as a high finding — third-party images bypass verification.
+- Treat SLSA L2+ claimed but no SLSA provenance attestation verifiable via `slsa-verifier` as a high finding.
+- Treat long-lived Cosign keypairs stored as CI secrets as a high finding — keyless OIDC Workload Identity is the preferred pattern.
+- Treat `COSIGN_NO_TLOG=1` on non-private-Rekor setups as a medium finding — public transparency is disabled without a private transparency alternative.
+- Keep the answer scoped, evidence-labeled, and explicit about what was not queried.
+
+## References
+
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md)
+
+## Response minimum
+
+Return, at minimum:
+- the scoped target (image, imageVerify policy, CI pipeline signing step, or SLSA level claim) and evidence level,
+- the signing identity (keyless OIDC via Fulcio, long-lived key, or unverified),
+- the admission enforcement posture (Kyverno imageVerify, policy-controller, or none),
+- the attestation inventory (SBOM present/absent, SLSA provenance present/absent),
+- the Rekor transparency posture (public log, private log, or disabled),
+- the safest next actions and any assumptions or blockers.

package/skills/sigstore/sigstore-cosign-supply-chain-review/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "sigstore-cosign-supply-chain-review",
+  "name": "Sigstore Cosign Supply Chain Review",
+  "type": "skill",
+  "provider": "sigstore",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review Sigstore Cosign image signing, Kyverno imageVerify policy, SBOM attestations, SLSA provenance, Rekor transparency log posture, and keyless vs key-based signing configuration for Kubernetes workload supply chain security.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.sigstore.dev/cosign/overview/",
+    "https://docs.sigstore.dev/policy-controller/overview/",
+    "https://slsa.dev/spec/v1.0/requirements",
+    "https://kyverno.io/docs/writing-policies/verify-images/",
+    "https://docs.github.com/en/actions/security-guides/using-artifact-attestations",
+    "https://rekor.sigstore.dev/"
+  ],
+  "security_notes": "Kyverno imageVerify policy without subject/issuer constraints accepts any Sigstore-signed image regardless of signer identity. Long-lived Cosign keys in CI secrets allow retroactive signing of malicious images if the secret is compromised.",
+  "last_verified": "2026-05-02",
+  "path": "skills/sigstore/sigstore-cosign-supply-chain-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/sigstore/sigstore-cosign-supply-chain-review/references/workflow-and-output.md

@@ -0,0 +1,196 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Identify the scope and collect raw evidence
+
+1. Confirm the review target: a specific container image, a Kyverno ClusterPolicy/Policy, a CI pipeline signing step, or a SLSA level claim.
+2. For image signing evidence, run:
+   ```bash
+   cosign verify \
+     --certificate-identity-regexp "https://github.com/<org>/<repo>/.github/workflows/" \
+     --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
+     <registry>/<image>:<tag>
+   ```
+   A successful exit means a valid keyless signature exists for that identity + issuer pair. An exit code 1 means no matching signature.
+3. For Kyverno admission policy evidence, run:
+   ```bash
+   kubectl get clusterpolicy,policy -A -o yaml | grep -A 30 "verifyImages"
+   ```
+   Collect every `verifyImages` block. Note whether `attestors.entries.keyless.subject` and `attestors.entries.keyless.issuer` are set.
+4. If Cosign policy-controller is in use instead of Kyverno, collect:
+   ```bash
+   kubectl get clusterimagepolicy -o yaml
+   ```
+   Inspect `spec.authorities[].keyless.identities[].issuer` and `.subject` fields.
+
+### Step 2 — Audit the imageVerify / ClusterImagePolicy identity constraints
+
+The most critical control is whether the admission policy constrains **who** signed the image, not just **that** it was signed.
+
+Check each policy rule for:
+
+1. **`issuer`** — the OIDC token issuer (e.g., `https://token.actions.githubusercontent.com` for GitHub Actions). Without this, any OIDC provider's identity can satisfy the check.
+2. **`subject`** — the specific identity within the issuer (e.g., `https://github.com/org/repo/.github/workflows/release.yml@refs/heads/main`). Without this, any identity at that issuer passes.
+3. **`glob` vs exact match** — subject globs like `https://github.com/org/*` allow any workflow in the org to satisfy the check.
+
+Example of a correctly scoped Kyverno imageVerify rule:
+```yaml
+verifyImages:
+  - imageReferences:
+      - "registry.internal.company.com/*"
+    attestors:
+      - entries:
+          - keyless:
+              subject: "https://github.com/org/repo/.github/workflows/release.yml@refs/heads/main"
+              issuer: "https://token.actions.githubusercontent.com"
+              rekor:
+                url: https://rekor.sigstore.dev
+```
+
+Flag as **CRITICAL** if both `subject` and `issuer` are absent — the policy accepts any Sigstore-signed image regardless of signer.
+
+Flag as **HIGH** if `issuer` is set but `subject` is absent — any identity at that issuer passes (e.g., any GitHub Actions workflow anywhere on GitHub).
+
+### Step 3 — Audit `exclude` rules and policy coverage
+
+1. List all `exclude` blocks in every imageVerify policy:
+   ```bash
+   kubectl get clusterpolicy -o yaml | grep -A 10 "exclude"
+   ```
+2. Flag as **HIGH** any exclude that matches:
+   - A broad registry glob (`docker.io/*`, `*`)
+   - A namespace containing workloads with access to sensitive data
+3. Confirm whether ALL namespace-resident Deployments, StatefulSets, DaemonSets, and Jobs are subject to the policy. Kyverno policies with no `matchResources.namespaceSelector` apply cluster-wide — verify this is intentional.
+
+Example of a dangerous broad exclusion:
+```yaml
+exclude:
+  resources:
+    images:
+      - "docker.io/*"   # All Docker Hub images skip verification
+```
+
+### Step 4 — Audit SLSA provenance attestations
+
+1. Check whether a SLSA provenance attestation exists:
+   ```bash
+   cosign verify-attestation \
+     --type slsaprovenance \
+     --certificate-identity-regexp "https://github.com/<org>/<repo>/" \
+     --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
+     <registry>/<image>:<tag>
+   ```
+2. For images claiming SLSA L2+, verify with slsa-verifier:
+   ```bash
+   slsa-verifier verify-image \
+     --source-uri github.com/<org>/<repo> \
+     --source-branch main \
+     <registry>/<image>:<tag>
+   ```
+3. Check whether the build was ephemeral (GitHub Actions or Tekton Chains) — SLSA L3 requires an ephemeral, isolated build environment. Builds on persistent, developer-accessible runners cannot claim L3.
+
+Flag as **HIGH** if SLSA L2 is claimed but `slsa-verifier verify-image` fails or returns no matching attestation.
+
+### Step 5 — Audit SBOM attestations
+
+1. Verify SBOM attestation presence:
+   ```bash
+   cosign verify-attestation \
+     --type spdxjson \
+     --certificate-identity-regexp "https://github.com/<org>/<repo>/" \
+     --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
+     <registry>/<image>:<tag>
+   ```
+2. For CycloneDX SBOM format:
+   ```bash
+   cosign verify-attestation \
+     --type cyclonedx \
+     <image>
+   ```
+3. Check whether the SBOM was generated at build time (accurate) or at image scan time (less reliable — may miss build-time artifacts).
+4. For workloads handling PII or financial data, flag as **MEDIUM** if no SBOM attestation is present — without an SBOM, dependency vulnerability provenance cannot be confirmed.
+
+### Step 6 — Audit Cosign key management (keyless vs key-based)
+
+1. Check CI pipeline signing steps for evidence of keyless OIDC flow:
+   ```yaml
+   # Correct keyless pattern in GitHub Actions
+   - name: Sign image
+     env:
+       COSIGN_EXPERIMENTAL: "1"   # Enables keyless (OIDC Workload Identity)
+     run: |
+       cosign sign --yes ${{ env.IMAGE_REF }}
+   ```
+2. Flag as **HIGH** if the CI pipeline uses `cosign sign --key cosign.key` or references a `COSIGN_PRIVATE_KEY` secret — long-lived key material in CI secrets is a secret sprawl risk.
+3. Verify that keyless signing uses the correct OIDC token source:
+   - GitHub Actions: `id-token: write` permission must be set in the workflow.
+   - Tekton Chains: `CHAINS-GCP-SERVICE-ACCOUNT` or equivalent OIDC binding must be configured.
+
+Example correct GitHub Actions OIDC signing permission:
+```yaml
+permissions:
+  id-token: write
+  contents: read
+  packages: write
+```
+
+Flag as **HIGH** if `id-token: write` is absent from the workflow — keyless signing will silently fail or fall back to anonymous signing.
+
+### Step 7 — Audit Rekor transparency log posture
+
+1. Check whether public Rekor logging is active (default) or disabled:
+   ```bash
+   # Default: public Rekor is used
+   cosign sign --yes <image>
+
+   # Disabled: no transparency log entry created
+   COSIGN_NO_TLOG=1 cosign sign --yes <image>
+   ```
+2. Flag as **MEDIUM** if `COSIGN_NO_TLOG=1` is set without a private Rekor instance configured — disabling transparency logging removes third-party verifiability and auditability.
+3. For images containing internal service references, infrastructure hostnames, or internal artifact paths, flag public Rekor logging as a **MEDIUM** information disclosure risk. These images should use a private Rekor instance.
+4. To verify a signature was logged to Rekor:
+   ```bash
+   cosign verify \
+     --certificate-identity-regexp "<signer>" \
+     --certificate-oidc-issuer "<issuer>" \
+     <image> | jq '.[0].optional.Bundle.Payload.logIndex'
+   ```
+   A non-null `logIndex` confirms the signature is in the public Rekor transparency log.
+
+### Step 8 — Verify admission enforcement is active
+
+1. Confirm Kyverno is installed and the webhook is active:
+   ```bash
+   kubectl get mutatingwebhookconfiguration,validatingwebhookconfiguration | grep kyverno
+   kubectl get pods -n kyverno
+   ```
+2. Confirm imageVerify policy is in `Enforce` mode (not `Audit`):
+   ```bash
+   kubectl get clusterpolicy <policy-name> -o jsonpath='{.spec.validationFailureAction}'
+   ```
+   `Enforce` blocks non-conforming images at admission. `Audit` only logs — images still deploy.
+3. Flag as **HIGH** if imageVerify policy is in `Audit` mode in production — unsigned images are not blocked.
+
+## Output
+
+Return:
+
+- **target**: image reference, ClusterPolicy name, or CI pipeline step, with the evidence source,
+- **evidence level**: `live evidence` / `documentation-based` / `sanitized user evidence` / `inference`,
+- **signing identity**: keyless OIDC (Fulcio) vs long-lived key, with the specific issuer and subject,
+- **admission enforcement**: Kyverno imageVerify / policy-controller / none, with policy mode (Enforce/Audit),
+- **identity constraint audit**: issuer and subject present/absent, glob scope, exclude rule coverage,
+- **attestation inventory**: SLSA provenance present/absent, SBOM present/absent, format,
+- **Rekor posture**: public log / private log / disabled, with information disclosure risk if applicable,
+- **risk findings** (with severity: critical / high / medium / low),
+- **safest next actions** with sample policy or workflow YAML,
+- **assumptions and missing facts**.
+
+## Security notes
+
+- Never recommend disabling imageVerify enforcement in production to unblock a deployment — the correct path is to fix the signing pipeline.
+- Never recommend broad `exclude` rules as a permanent fix for third-party image coverage gaps.
+- Never request or print private Cosign keys, OIDC tokens, registry credentials, or cosign.key file contents.
+- Always confirm admission policy is in `Enforce` mode before concluding that unsigned images are blocked.
+- A Kyverno imageVerify policy in `Audit` mode with no `Enforce` policy provides zero actual enforcement — treat this as a critical gap.

package/skills/terraform/README.md

@@ -0,0 +1,29 @@
+# 🟩 Terraform Skills
+
+<p align="center">
+  <!-- 🖼️ Add a Terraform logo to assets/logos/cloud/terraform/ and update this path -->
+  <span style="font-size:3.5em">🟩</span>
+</p>
+
+This folder contains Terraform-focused skills curated for this marketplace.
+
+## Local marketplace portfolio
+
+This folder contains **1** local Terraform skill:
+
+- `terraform-maestro`
+
+## Portfolio posture
+
+Terraform skills for evidence-backed IaC review, plan safety, and guarded apply workflows across all cloud providers.
+
+These skills are intentionally conservative:
+
+- always review `terraform plan` output before any apply — never apply without a human-reviewed plan
+- assess blast radius: count resource deletions, replacements, and modifications before approving
+- check for missing `prevent_destroy` lifecycle rules on stateful resources (databases, buckets, vaults)
+- verify backend state locking is enabled before any write operation
+- flag remote state outputs consumed by other stacks — changes may break downstream consumers
+- use official Terraform and provider documentation for resource behavior and provider version compatibility
+
+Run `npm run validate` after changing cataloged Terraform skills.

package/skills/velero/velero-backup-restore-guard/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: velero-backup-restore-guard
+description: Use this skill when guarding Velero backup schedule changes, restore operations, BackupStorageLocation mutations, or volume snapshot configuration. Trigger on any request to run a velero restore, delete a Schedule, change a BSL default, or modify backup retention.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# Velero Backup/Restore Guard
+
+## Purpose
+
+Guard live Velero operations — restore execution, schedule deletion, BackupStorageLocation changes, and volume snapshot configuration — against data loss, scope creep, and missing rollback posture. A Velero restore is destructive: it overlays resources onto the cluster. Every guarded operation requires confirmed cluster context, explicit scope, current state capture, and explicit platform-team sign-off before any mutation executes.
+
+## Lean operating rules
+
+- Confirm cluster context (`kubectl config current-context`) and target namespace before any Velero operation — ambiguous context is a hard stop.
+- Capture current state of the target Backup, Schedule, or BSL (`velero backup describe <name> --details`, `kubectl get schedule <name> -o yaml`) before every write — Velero has no built-in undo.
+- For restore operations: require `includedNamespaces` to be explicitly scoped; a cluster-wide restore (`includedNamespaces: []`) requires explicit platform-team sign-off.
+- Recommend `velero restore create --dry-run` before every non-emergency restore; treat missing dry-run as a hard stop in non-emergency scenarios.
+- Block deleting a Schedule that is the only backup for a production namespace unless an alternative backup source is confirmed.
+- Block changing a BSL `default: true` without confirming no in-progress backups and reviewing the impact on all dependent Schedules.
+- Check pre-backup hook coverage on stateful workloads (PostgreSQL, MySQL, Kafka) — missing quiesce hooks mean inconsistent backups.
+- Label all claims as live evidence, documentation-based, or inference.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md)
+- [Safety checklist](references/safety-checklist.md)
+
+## Response minimum
+
+- Confirmed cluster context and target scope
+- Current state of the Backup/Schedule/BSL (evidence level)
+- Hard-stop assessment (is this a blocked operation?)
+- Explicit platform-team sign-off status
+- Recommended dry-run or safe-path command
+- Rollback posture
+- Post-operation verification steps

package/skills/velero/velero-backup-restore-guard/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "velero-backup-restore-guard",
+  "name": "Velero Backup/Restore Guard",
+  "type": "skill",
+  "provider": "velero",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Live-guard skill for Velero backup schedules, restore operations, BackupStorageLocation changes, and volume snapshots — requiring explicit platform-team sign-off before any mutation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://velero.io/docs/latest/",
+    "https://velero.io/docs/latest/restore-reference/",
+    "https://velero.io/docs/latest/backup-reference/",
+    "https://velero.io/docs/latest/locations/",
+    "https://velero.io/docs/latest/hooks/"
+  ],
+  "security_notes": "Velero restore with existingResourcePolicy:update can overwrite live RBAC resources, Secrets, and ServiceAccounts — equivalent to a partial cluster wipe. BSL credentials with write-only access prevent listing/deleting old backups, causing runaway storage costs. Never proceed with cluster-wide restores without explicit platform-team sign-off.",
+  "last_verified": "2026-05-02",
+  "path": "skills/velero/velero-backup-restore-guard",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/velero/velero-backup-restore-guard/references/safety-checklist.md

@@ -0,0 +1,40 @@
+# Safety Checklist
+
+## Pre-Restore Checklist (10 items)
+
+Before executing any `velero restore create` command, confirm all 10 items. A single unchecked item is a HARD STOP unless the approver explicitly overrides with written justification.
+
+- [ ] **1. Cluster context confirmed** — `kubectl config current-context` output has been shown and matches the intended target cluster. Do not assume the current context is correct.
+- [ ] **2. Namespace scope is explicit** — `includedNamespaces` lists one or more specific namespaces. Empty list (`[]`) = cluster-wide restore = requires explicit platform-team sign-off with ticket reference.
+- [ ] **3. Backup timestamp verified** — the backup name and creation timestamp have been confirmed as the correct recovery point. Do not restore from an older backup if a closer-in-time backup exists and is healthy.
+- [ ] **4. Backup phase is Completed** — `velero backup describe <name>` shows `Phase: Completed`. Do not restore from a `PartiallyFailed` or `Failed` backup without explicit acknowledgment of the incomplete scope.
+- [ ] **5. Dry-run executed and reviewed** — `velero restore create --dry-run` output has been reviewed for unexpected resource counts, namespace scope, and PV restore entries. (Exception: active P0 incident with explicit platform-team override.)
+- [ ] **6. existingResourcePolicy reviewed** — if `existingResourcePolicy: update` is used, the approver understands this will overwrite live Secrets, ConfigMaps, RBAC objects, and ServiceAccounts in the target namespace.
+- [ ] **7. PV restore posture confirmed** — `restorePVs: true/false` intent is explicit. If false, stateful applications will start with empty persistent volumes.
+- [ ] **8. Current state captured** — target namespace resources have been exported (`kubectl get all,cm,secret,pvc -n <ns> -o yaml > pre-restore-state.yaml`) as a rollback artifact.
+- [ ] **9. Explicit platform-team sign-off obtained** — approver name, role, and ticket/incident reference are documented. Not implied — must be explicit.
+- [ ] **10. Post-restore verification plan exists** — the team knows which pods, endpoints, and data checks confirm successful restore before closing the incident.
+
+---
+
+## Pre-Schedule-Delete Checklist (5 items)
+
+Before executing `velero schedule delete <name>` or removing a Schedule manifest:
+
+- [ ] **1. Alternative backup source confirmed** — the namespaces covered by this Schedule are also covered by another Schedule or a manual backup strategy. Deleting the only backup Schedule for a production namespace is a HARD STOP.
+- [ ] **2. Existing backups will not be deleted** — deleting a Schedule does not delete existing Backups by default. Confirm this is the intended behavior; if cascade-delete is intended, explicitly document which backups will be removed.
+- [ ] **3. No in-progress backup from this schedule** — `velero backup get | grep InProgress` shows no active backup from this Schedule. Deleting a Schedule mid-backup can leave a partial backup with no retention management.
+- [ ] **4. Dependent restore references reviewed** — no existing Restore objects reference backups created by this Schedule in a pending or future recovery plan.
+- [ ] **5. Platform-team sign-off obtained** — explicit written approval with ticket reference. A Schedule deletion is irreversible (re-creation restores future backups but not the deleted Schedule's backup history lineage).
+
+---
+
+## Post-Restore Verification (5 items)
+
+After a restore completes (`velero restore describe <name>` shows `Phase: Completed`):
+
+- [ ] **1. Pod health confirmed** — all Deployments and StatefulSets in the restored namespace reach `Ready` state within the expected startup window. Check: `kubectl get pods -n <ns> -w`.
+- [ ] **2. PVC binding confirmed** — all PersistentVolumeClaims are in `Bound` status. Unbound PVCs indicate snapshot restore failure or storage class mismatch. Check: `kubectl get pvc -n <ns>`.
+- [ ] **3. Application data sampling** — spot-check application-level data integrity (e.g., query a database, verify a file, check an API endpoint). Pod running does not guarantee data consistency.
+- [ ] **4. Service endpoints reachable** — Services and Ingress rules are routing traffic correctly. Check: `kubectl get svc,ingress -n <ns>` and a live probe to the application endpoint.
+- [ ] **5. Restore warnings reviewed** — `velero restore logs <name>` has been scanned for warnings. Warnings about skipped resources, unresolved PV references, or hook failures must be triaged before marking the restore complete.