@raishin/vanguard-frontier-agentic 1.4.0 → 1.6.0

package/skills/kubernetes/kubernetes-network-architecture-review/references/service-gateway-routing.md

@@ -0,0 +1,108 @@
+# Service and Gateway API Routing
+
+## Step 1 — Identify the routing surface
+
+Capture:
+
+- `kubectl get services -A -o wide` — types, ClusterIPs, externalIPs, ports.
+- `kubectl get endpointslices -A` — confirm endpoints actually exist for every ClusterIP. A Service with zero EndpointSlices selects no pods.
+- `kubectl get ingress -A` and `kubectl get gateway,gatewayclass,httproute,grpcroute,tlsroute,referencegrant -A` — Ingress and Gateway API surface.
+- IngressClass and GatewayClass ownership — `kubectl get ingressclass`, `kubectl get gatewayclass` — which controllers actually exist on this cluster.
+
+## Step 2 — Stress-test Service type selection
+
+| Type | When right | When wrong |
+|---|---|---|
+| `ClusterIP` (default) | In-cluster only. | Used as a "fix" for east-west reachability when the real issue is NetworkPolicy or DNS. |
+| `NodePort` | Bare-metal or dev clusters where no cloud LB exists. | Used in cloud — exposes every node as an entry point, scraping the NodePort range from outside. Rarely the right cloud answer. |
+| `LoadBalancer` | Public/private endpoint via the cloud LB controller (or MetalLB / Cilium L2/BGP). | One LB per Service in classic mode is expensive at scale. Consolidate via Ingress/Gateway when feasible. |
+| `ExternalName` | DNS CNAME into an external host. | Used as policy-bypass — the pod still does its own DNS resolution; NetworkPolicy still applies to the resolved IP. |
+| Headless (`clusterIP: None`) | StatefulSet stable DNS, gRPC client-side LB, custom service discovery. | Used because someone wanted "no kube-proxy" — but then there is no load balancing, only DNS round-robin against EndpointSlices. |
+
+## Step 3 — Stress-test EndpointSlices
+
+EndpointSlices replace the legacy single-Endpoints object and are the data the Service VIP rules / eBPF maps actually consume.
+
+- A Service with `selector` populated but zero matching pods has an empty EndpointSlice — the VIP exists but every connection RSTs or hangs depending on kube-proxy mode. Common cause: Pod label drift after a Helm upgrade.
+- A Service without a `selector` (used for static external endpoints) requires a hand-maintained EndpointSlice; without it nothing is routed.
+- EndpointSlices report `Ready`, `Serving`, `Terminating` conditions. `externalTrafficPolicy: Local` plus rolling pod restart can transiently hit a node where the only local endpoint is `Terminating`. Verify ProxyTerminatingEndpoints behavior in the cluster's kube-proxy version.
+- Topology hints live in EndpointSlices (`hints.forZones`). They are populated by the EndpointSlice controller only when topology-aware routing prerequisites are met (multiple zones, sufficient endpoints per zone).
+
+## Step 4 — `internalTrafficPolicy` and `externalTrafficPolicy`
+
+These two fields are the single most-misunderstood part of Kubernetes networking.
+
+- **`externalTrafficPolicy: Cluster`** (default) — kube-proxy routes external traffic to any pod cluster-wide. Source IP is rewritten to the receiving node. Even load distribution.
+- **`externalTrafficPolicy: Local`** — kube-proxy only routes external traffic to pods on the same node as the receiving NodePort/LoadBalancer ingress point. Preserves source IP. **Black-holes traffic if no local endpoint exists** — health-check ports rely on this for cloud LB to drop the node from rotation. If health-check is misconfigured, the LB sends to a node with no pod, and the connection hangs.
+- **`internalTrafficPolicy: Cluster`** (default) — same as Cluster externally.
+- **`internalTrafficPolicy: Local`** — in-cluster traffic from a pod is routed only to a pod on the same node. **Silent black-hole** if no local endpoint exists; there is no LB rotation to fall back to. Used for node-local agent → app patterns where co-location is guaranteed by DaemonSet.
+
+Stress-tests the review must apply:
+
+- A Service with `externalTrafficPolicy: Local` and a Deployment of `replicas: 2` on a 10-node cluster — 8 nodes black-hole the NodePort. The cloud LB health-check must mark them unhealthy or every 8/10 connections fails.
+- `externalTrafficPolicy: Local` with `Local` health-check disabled on the LB — random failures.
+- `internalTrafficPolicy: Local` on a Service backing a Deployment with no anti-affinity — silent black-holes when no replica lands on the caller's node.
+
+## Step 5 — Topology-aware routing
+
+Three generations of API for keeping in-cluster traffic local:
+
+1. **`topologyKeys`** — first-generation Service field. **Removed** (not just deprecated) in Kubernetes 1.27. Clusters on 1.26 or earlier still using `topologyKeys` MUST plan migration before the 1.27 upgrade.
+2. **`service.kubernetes.io/topology-mode: Auto`** — annotation; replaced `topologyKeys`. Tells the EndpointSlice controller to populate `hints.forZones` so kube-proxy prefers same-zone endpoints, reducing cross-zone traffic cost. Per upstream kubernetes.io documentation, this annotation may itself be deprecated in favor of the next-generation `trafficDistribution` field.
+3. **`spec.trafficDistribution`** field on Service (KEP-4444) — newest API. If both `trafficDistribution` and `topology-mode: Auto` are set, the annotation overrides the field.
+
+Pick the API that matches your cluster's Kubernetes version; do not use `topologyKeys` even on 1.26 — the upgrade trap is too easy.
+
+Traps:
+
+- Auto mode requires sufficient endpoints per zone — too few endpoints, hints are not populated, no zone preference. Behavior silently changes when the deployment scales up.
+- A Service with topology hints behaves like `internalTrafficPolicy: Local` from a cost perspective but without the black-hole risk — same-zone preferred, fall back to cross-zone if local endpoints unhealthy.
+- Topology hints do not respect `externalTrafficPolicy: Local` — they are independent fields.
+
+## Step 6 — Ingress vs Gateway API
+
+Gateway API is the successor to Ingress. The migration is per-route, not per-cluster.
+
+What's GA today (per the [Gateway API site](https://gateway-api.sigs.k8s.io/) and the [versioning page](https://gateway-api.sigs.k8s.io/concepts/versioning/)):
+
+- `Gateway`, `GatewayClass`, `HTTPRoute` — Standard channel, graduated to `v1` in the v1.0.0 release.
+- `GRPCRoute` — **Standard channel since v1.1.0** (`v1`). Earlier sources that label it experimental refer to the v1.0 line.
+- `ReferenceGrant` — Standard channel (`v1beta1`).
+- GAMMA service-mesh integration (routes attach directly to a Service rather than a Gateway) — Standard channel since v1.1.0.
+
+Experimental channel as of the v1.x line — verify against the controller's conformance for the version in use:
+
+- `TLSRoute`, `TCPRoute`, `UDPRoute`, `BackendTLSPolicy`, `BackendTrafficPolicy`.
+
+Always confirm by listing the CRDs the controller actually installed: `kubectl get crd -l gateway.networking.k8s.io/bundle-version`.
+
+The role-oriented model:
+
+- **Infrastructure provider** owns `GatewayClass`.
+- **Cluster operator** owns `Gateway` instances (and the policies that bound them).
+- **Application developer** owns `HTTPRoute` / `GRPCRoute` / `TLSRoute` and attaches them to a Gateway via `parentRefs`.
+
+Migration stress-tests:
+
+- Ingress Controller annotations (`nginx.ingress.kubernetes.io/...`, `cert-manager.io/cluster-issuer`, `external-dns.alpha.kubernetes.io/...`) are non-portable. Migrating an Ingress to an HTTPRoute requires translating each annotation into either a built-in HTTPRoute field, a `BackendTLSPolicy`, or a controller-specific extension.
+- Cross-namespace references in HTTPRoute (`backendRefs` to a Service in a different namespace) require an explicit `ReferenceGrant` in the target namespace — without it, the reference is denied. This is a deliberate security posture; do not work around it with cluster-scoped routes.
+- Two GatewayClasses on the same cluster (e.g. `cilium` and `nginx`) — routes must select via `parentRefs.name`/`namespace`. Avoid having multiple Gateways listen on the same hostname.
+- TLS termination at the Gateway with `backendRefs` over plain HTTP — re-encryption to the backend requires `BackendTLSPolicy` (Experimental) or a service mesh; without it, in-cluster traffic is plaintext.
+- GAMMA mesh — HTTPRoute attached to a Service (not a Gateway) reshapes east-west traffic. Available implementations differ on which fields they honor; verify against the controller's GAMMA conformance report.
+
+## Step 7 — Session affinity, sourceIPHash, and gRPC
+
+- `Service.spec.sessionAffinity: ClientIP` plus `sessionAffinityConfig.clientIP.timeoutSeconds` keeps a client IP pinned to one endpoint via conntrack/IPVS hash. Useful for stateful protocols, hostile to deployment rollover (sessions stick to the old pod until timeout).
+- gRPC over a single HTTP/2 connection multiplexes RPCs over one TCP connection; a single Service VIP without client-side LB sticks every RPC to one backend. Headless Service plus client-side resolver (gRPC-Go / xDS) is the canonical answer; an L7 Gateway (gRPC-aware) is the other.
+- Long-lived WebSocket connections plus rolling deployment plus session affinity — every old-pod connection survives until the client disconnects. Plan termination grace and client-reconnect strategy.
+
+## Output for this section
+
+- Service surface inventory and types,
+- EndpointSlice health (selectors actually match pods),
+- `internalTrafficPolicy` and `externalTrafficPolicy` correctness against pod placement and replica count,
+- topology-aware routing readiness,
+- Ingress vs Gateway API posture, GA-channel resources in use vs experimental,
+- migration path with annotation-to-route mapping for the controller in scope,
+- session affinity and gRPC routing posture,
+- findings, severity, and the next-step delegate (e.g. NetworkPolicy review if a route depends on cross-namespace traffic).

package/skills/kubernetes/kubernetes-network-architecture-review/references/troubleshooting-playbook.md

@@ -0,0 +1,100 @@
+# Connectivity Troubleshooting Playbook (read-only)
+
+This playbook is for diagnosis. It does not mutate cluster state. Every command listed here either reads from the API server, reads from a node's kernel, or emits a controlled probe (a single ping, a single curl).
+
+## Symptom 1 — Pod-to-pod connectivity fails
+
+Hypothesis ladder, in order of cost:
+
+1. **DNS** — does the source pod resolve the destination's Service or pod-IP DNS name? `kubectl exec <src> -- nslookup <name>`. If this fails, jump to the DNS playbook below.
+2. **Service VIP exists and has endpoints** — `kubectl get svc <svc>` plus `kubectl get endpointslice -l kubernetes.io/service-name=<svc>`. Empty EndpointSlice → label selector mismatch.
+3. **NetworkPolicy** — `kubectl get networkpolicies,ciliumnetworkpolicies,ciliumclusterwidenetworkpolicies -A -o yaml`. If any policy selects either pod, default-deny may be active. **At this point, hand off to `cilium-network-policy-review`** — that skill owns policy correctness.
+4. **Underlying L3 reachability** — from the source node, `ip route get <dst-pod-ip>`; on Cilium, `cilium-dbg bpf endpoint list` and `cilium-dbg policy trace --src-pod ns/pod --dst-pod ns/pod`.
+5. **MTU** — `kubectl exec <src> -- ping -M do -s 1450 <dst-pod-ip>` then increment payload until packets are dropped. The largest size that succeeds is the path MTU.
+6. **Conntrack table full** — on the source node, `conntrack -L | wc -l` vs `sysctl net.netfilter.nf_conntrack_max`. Near 90% means new connections will be dropped.
+
+## Symptom 2 — Pod can reach Service VIP but only some endpoints
+
+Likely causes:
+
+- **`externalTrafficPolicy: Local` or `internalTrafficPolicy: Local`** — `kubectl get svc <svc> -o yaml | grep -i trafficpolicy`. With `Local`, pods on nodes without a local endpoint silently fail.
+- **EndpointSlice marked `Ready: false` or `Terminating: true`** — `kubectl get endpointslice -l kubernetes.io/service-name=<svc> -o yaml`. ProxyTerminatingEndpoints behavior depends on the kube-proxy / Cilium version.
+- **kube-proxy stale rules** — `kubectl -n kube-system logs <kube-proxy-pod>` for sync errors. On iptables mode, full resync runs every `syncPeriod`; a stuck sync leaves stale rules pointing at deleted pods.
+- **Topology hints with insufficient endpoints** — Auto mode does not populate hints when one zone has too few; behavior changes silently with deployment scale.
+
+## Symptom 3 — Pod-to-external service intermittent failure
+
+Hypothesis ladder:
+
+1. **DNS** — 5-second timeouts indicate UDP packet drops; check NodeLocal DNSCache health and conntrack pressure on the node. CoreDNS request latency: `coredns_dns_request_duration_seconds`.
+2. **Cloud metadata service** — `169.254.169.254` (AWS / Azure IMDS) or `metadata.google.internal` (GCP). **Flag as HIGH severity if any pod can reach it without an explicit NetworkPolicy deny.** Unblocked access lets any pod obtain the node's instance IAM credentials — credential-theft CVE class. Recommend IRSA (AWS), Workload Identity (GCP/Azure), or Pod Identity as the *first* remediation; the policy deny rule is delegated to `cilium-network-policy-review`, but the architectural posture finding must surface here, not be silently delegated.
+3. **NAT Gateway port exhaustion** — AWS NAT GW supports ~55k simultaneous connections per destination IP/port. Pods making many short connections to the same external endpoint can exhaust ports; symptom is intermittent SYN drops. Solution: Network Load Balancer instead of NAT GW for that destination, or VPC endpoint.
+4. **Egress firewall / WAF** — if a per-namespace egress proxy exists, check its logs.
+5. **Path MTU** — see Symptom 1, step 5; path-MTU issues to external endpoints often blame TLS but the failure is L3.
+
+## Symptom 4 — DNS-specific high latency
+
+Hypothesis ladder:
+
+1. **CoreDNS replicas saturated** — CPU throttling: `kube_pod_container_status_throttled_seconds_total{pod=~"coredns.*"}`. Insufficient replicas → autoscaler or manual bump.
+2. **`ndots:5` amplification** — `kubectl exec <pod> -- cat /etc/resolv.conf` to confirm `ndots`. External hostnames generate 4× lookups before the absolute name. Mitigations are in the DNS-and-discovery reference.
+3. **NodeLocal DNSCache OOM or absent** — `kubectl -n kube-system get pods -l k8s-app=node-local-dns -o wide` (or whatever the label is). If absent, every UDP packet adds conntrack pressure.
+4. **Upstream DNS slow** — the cluster's `forward .` target. CoreDNS `coredns_forward_request_duration_seconds` segments by upstream.
+5. **conntrack table full** — UDP DNS queries fill it.
+
+## Symptom 5 — Intermittent stalls on large payloads only
+
+Almost always MTU. The TCP handshake (small packets) succeeds, then the first response above the path MTU is dropped because Path MTU Discovery ICMP is filtered.
+
+Diagnose:
+
+- `kubectl exec <pod> -- ping -M do -s <bytes> <peer>` — find the MTU ceiling.
+- Check overlay MTU vs node MTU vs underlay. Encapsulation overhead must be subtracted from node MTU when configuring the overlay device (`cilium_vxlan`, `flannel.1`, `cni0`).
+- Cross-AZ on AWS — jumbo frames silently capped at 1500.
+
+Fix: configure the CNI overlay MTU correctly and restart the agent DaemonSet (rolling). On Cilium, `cilium config view | grep -i mtu` and Helm value `MTU` (the Cilium agent reads MTU from the host but explicit config is safer).
+
+## Symptom 6 — NodePort or LoadBalancer connection refused intermittently
+
+- `externalTrafficPolicy: Local` — health-check on the LB must be on the right port, otherwise the LB sends to nodes with no local endpoint.
+- IPVS mode and `sessionAffinity: ClientIP` — sessions persist past pod deletion until timeout.
+- Cilium kube-proxy replacement transition — verify `cilium status` reports KPR `Strict` (or expected mode) on every node.
+
+## Diagnostic commands (read-only, by component)
+
+```shell
+# API view
+kubectl get nodes -o wide
+kubectl -n kube-system get pods -o wide
+kubectl get svc,endpointslices,ingress,gateway,gatewayclass,httproute -A
+
+# CoreDNS
+kubectl -n kube-system get cm coredns -o yaml
+kubectl -n kube-system logs -l k8s-app=kube-dns --tail=200
+kubectl exec <pod> -- cat /etc/resolv.conf
+
+# kube-proxy
+kubectl -n kube-system get cm kube-proxy -o yaml
+kubectl -n kube-system logs -l k8s-app=kube-proxy --tail=200
+
+# Cilium
+kubectl -n kube-system exec ds/cilium -- cilium status --verbose
+kubectl -n kube-system exec ds/cilium -- cilium-dbg bpf endpoint list
+kubectl -n kube-system exec ds/cilium -- cilium-dbg policy trace --src-pod <ns>/<pod> --dst-pod <ns>/<pod>
+hubble observe --from-pod <ns>/<pod> --to-pod <ns>/<pod> --last 200
+
+# Node-level (use kubectl debug ephemeral container with --profile=netadmin — do NOT use --privileged)
+# Example: kubectl debug node/<node-name> -it --image=registry.k8s.io/e2e-test-images/agnhost:2.45 --profile=netadmin
+ip route
+ip link show
+conntrack -L | wc -l
+sysctl net.netfilter.nf_conntrack_max
+```
+
+## When the playbook hits the scope boundary
+
+- Policy correctness — hand off to `cilium-network-policy-review`.
+- Mesh L7 problems — hand off to `istio-ambient-mesh-review`.
+- Live mutation of policy — hand off to `kubernetes-live-network-policy-guard` or `kubernetes-live-mesh-policy-guard`.
+- Pod-spec hostNetwork / capabilities issues — hand off to `kubernetes-pod-spec-review`.
+- Cloud-side network problems (NAT GW, VPC peering, hosted DNS) — hand off to the cloud-provider network architect agent.

package/skills/oci/oci-waf-cost-optimization-review/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: oci-waf-cost-optimization-review
+description: "Assess OCI workload cost posture covering compute rightsizing, Ampere A1 adoption, Universal Credits coverage, tagging compliance, idle resource elimination, and OCI Cost Management tooling."
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-09"
+  category: finops
+---
+
+# OCI WAF Cost Optimization Review
+
+## Role Charter
+
+Act as a rigorous OCI FinOps reviewer. Your job is to produce safe, scoped, evidence-driven cost optimization assessments — not vague advice. Challenge undocumented shape choices, missing tagging, idle resources left unchecked, and commitment discount gaps backed by estimation rather than actual Cost Management data.
+
+## Background
+
+OCI cost optimization covers rightsizing compute, selecting cost-efficient shapes, leveraging Universal Credits and Annual Flex commitments, tagging for cost attribution, and using OCI Cost Management tools to continuously reduce waste.
+
+## OCI Cost Optimization Design Principles
+
+1. **Right-size and select efficient shapes** — OCI Ampere A1 Compute (Arm-based) is the most cost-efficient shape at $0.01/OCPU-hour and $0.0015/GB-hour; use Flex shapes to precisely size OCPU and memory ratios; avoid Standard shapes with fixed OCPU/memory ratios when you need only one dimension
+2. **Leverage commitment discounts** — OCI Universal Credits (1yr/3yr) provide up to 33-45% discount vs PAYG; Annual Flex contracts allow credit spending across any OCI service; commit to steady-state baseline, use PAYG for burst
+3. **Use preemptible instances for fault-tolerant workloads** — OCI Preemptible Instances offer 50% off On-Demand pricing; they can be reclaimed with 30-second notice; ideal for CI/CD, batch, ML training, dev/test
+4. **Tag everything for cost attribution** — OCI tagging (Defined Tags via Tag Namespaces + Free-form Tags); cost attribution requires Defined Tags with tag keys approved in the root compartment; enforce via Tag Defaults on compartments
+5. **Monitor continuously and act on recommendations** — OCI Cost Management (budget alerts, cost analysis), Cloud Advisor recommendations (idle VMs, underutilized block volumes, unattached volumes), OCI Monitoring for utilization
+
+## OCI Cost Tools and Services
+
+- **OCI Cost Management**: cost analysis by compartment/service/tag, budget alerts (absolute + forecast-based), cost report CSV export for Athena/BQ analysis
+- **Cloud Advisor**: AI-powered cost and performance recommendations — idle compute, oversized shapes, unattached volumes, reserved capacity suggestions
+- **OCI Usage Explorer**: granular hourly usage and cost breakdown
+- **OCI Pricing**: list prices at cloud.oracle.com/pricing; Universal Credits pricing requires contract — use Cost Management for actuals
+- **OCI Always Free Tier**: 4 OCPUs + 24GB RAM Ampere A1 instances, 200GB Block Volume, 10GB Object Storage, 1 Autonomous Database 20GB — permanent free tier for development/testing
+
+## Key OCI Pricing Insights
+
+- **Ampere A1 (Arm)**: $0.01/OCPU-hr, $0.0015/GB-hr — 2-3x cheaper than x86 Standard shapes for equivalent workloads
+- **Egress**: data transfer within OCI (same region, cross-AD) is FREE; Internet egress is $0.0085/GB (first 10TB/month free); OCI egress is 10-25x cheaper than AWS/Azure
+- **Object Storage**: $0.0255/GB-month (Standard); data retrieval is free (unlike S3 Glacier)
+- **Autonomous Database Serverless**: compute auto-scales to 0 OCPUs when idle; pay only for storage during idle — significant for dev/test
+
+## Assessment Questions
+
+- How do you select compute shapes and sizes for new workloads?
+- How do you leverage commitment discounts (Universal Credits, Annual Flex) for steady-state workloads?
+- How do you tag resources for cost attribution across compartments and teams?
+- How do you monitor and act on Cloud Advisor cost recommendations?
+- How do you retire unused or underutilized resources?
+- How do you use preemptible instances for cost-reduction on fault-tolerant workloads?
+- How do you manage OCI budgets and cost alerts?
+
+## Validation Checklist
+
+- [ ] Ampere A1 Compute shapes evaluated for all Linux-compatible workloads — x86-only justified by binary dependency
+- [ ] OCI Flex shapes used instead of fixed Standard shapes where OCPU/memory ratio flexibility is needed
+- [ ] Cloud Advisor cost recommendations reviewed monthly; idle/oversized resources actioned
+- [ ] Preemptible Instances used for CI/CD, ML training, batch, and dev/test workloads
+- [ ] Tag Defaults configured at compartment level for required Defined Tags (env, team, app, cost-center)
+- [ ] OCI Budget alerts configured per compartment or project with notification at 80% and 100%
+- [ ] Unattached Block Volumes (no attached instance) identified and deleted or archived monthly
+- [ ] Autonomous Database Serverless used for dev/test databases — auto-scale to 0 OCPUs when idle
+- [ ] OCI egress costs compared to current architecture — verify cross-region vs internet egress paths
+- [ ] Universal Credits or Annual Flex contract coverage reviewed quarterly
+
+## Safe Workflow
+
+1. **Classify the request.** Cost analysis, rightsizing review, tagging audit, commitment planning, or idle resource cleanup.
+2. **Confirm scope.** Compartments in scope, time window, cost categories, tagging namespaces used.
+3. **Prefer read-only evidence.** Work from Cost Management exports, Cloud Advisor reports, or sanitized usage data.
+4. **Challenge the dangerous path.** Do not delete resources, cancel commitments, or modify compartment structures without explicit approval and resource inventory confirmation.
+5. **Report facts separately from assumptions.** Label every conclusion as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`.
+
+## Response Shape
+
+1. Shape selection and rightsizing assessment
+2. Commitment discount coverage
+3. Tagging compliance
+4. Cost visibility and alerting
+5. Preemptible instance adoption
+6. Idle resource inventory
+7. Ampere A1 migration opportunities
+8. Prioritized savings actions
+
+## Red Flags
+
+- Standard (fixed ratio) shapes used where Flex shapes would reduce cost
+- No Ampere A1 evaluation documented for new Linux workloads
+- Defined Tag Defaults missing at compartment level — cost attribution is broken
+- No OCI Budget alerts configured — runaway spending goes undetected
+- Unattached Block Volumes left provisioned for more than 30 days
+- Dev/test databases using Always-On Autonomous configurations instead of Serverless auto-scale
+- Preemptible Instances not used for any batch/CI/CD workloads

package/skills/oci/oci-waf-cost-optimization-review/metadata.json

@@ -0,0 +1,19 @@
+{
+  "id": "oci-waf-cost-optimization-review",
+  "name": "OCI WAF Cost Optimization Review",
+  "type": "skill",
+  "provider": "oci",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review OCI workload cost posture across compute rightsizing, Ampere A1 adoption, Universal Credits coverage, tagging compliance, idle resource elimination, and OCI Cost Management tooling aligned to OCI Architecture Best Practices.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.oracle.com/en-us/iaas/Content/Billing/home.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/CloudAdvisor/home.htm",
+    "https://www.oracle.com/cloud/pricing/"
+  ],
+  "security_notes": "Read-only advisory. Do not delete resources, cancel commitments, or modify compartment structures without explicit approval and resource inventory confirmation.",
+  "last_verified": "2026-05-09",
+  "path": "skills/oci/oci-waf-cost-optimization-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/oci/oci-waf-reliability-review/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: oci-waf-reliability-review
+description: "Review OCI workload reliability posture across Availability Domain and Fault Domain redundancy, load balancing, database HA, backup and replication, DR orchestration, and recovery testing. Use when assessing OCI WAF reliability pillar alignment, evaluating Full Stack DR plans, or auditing RTO/RPO readiness for production workloads."
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-09"
+  category: resilience
+---
+
+# OCI WAF Reliability Review
+
+## Role Charter
+
+Act as an OCI reliability pillar reviewer aligned to OCI Architecture Best Practices. Your job is to identify single points of failure, unvalidated recovery assumptions, missing redundancy, and gaps in DR orchestration — and translate them into prioritized, evidence-backed remediation.
+
+Primary outcomes:
+- Evaluate AD/FD topology and instance distribution for fault-tolerance alignment.
+- Identify missing load balancing, autoscaling, and stateful session risks.
+- Validate database HA, backup policies, and cross-region replication.
+- Assess DR plan completeness, drill history, and RTO/RPO documentation.
+- Separate verified facts from inference. State "I don't know" when evidence is missing.
+- Refuse to recommend destructive changes without explicit scope and rollback path.
+
+## OCI Reliability Design Principles
+
+1. **Design for AD and Fault Domain redundancy** — OCI regions have 1-3 Availability Domains (ADs), each with 3 Fault Domains (FDs); for single-AD regions, spread instances across all 3 FDs; for multi-AD regions, spread across ADs for highest availability.
+2. **Use managed services for built-in HA** — OCI Autonomous Database (Autonomous Guard), OCI MySQL HeatWave with HA, OCI Streaming (Apache Kafka-compatible), OCI Object Storage (11 nines durability) reduce operational reliability burden.
+3. **Implement automated health checks and failover** — OCI Load Balancer health checks with backend set failover; DNS Traffic Management (failover, load balancing, geolocation steering); OCI Full Stack DR orchestration.
+4. **Design stateless tiers** — store session state in OCI Cache (Redis-compatible) or Autonomous Database; design compute tiers for horizontal scaling via Instance Pools and Autoscaling.
+5. **Protect data with backup and replication** — Block Volume Backup Policies (automated daily/weekly/monthly), Object Storage Cross-Region Replication, Autonomous Database Autonomous Data Guard (local + remote standby).
+6. **Test recovery regularly** — OCI Full Stack Disaster Recovery drill mode; backup restore validation; Instance Pool scaling tests.
+
+## OCI Reliability Service Areas
+
+- **Compute HA:** Instance Pools + Autoscaling Configurations (scale-out on CPU/memory/custom metrics); OCI Container Engine for Kubernetes (OKE) with multi-AD node pools; OCI Functions (serverless, inherently HA).
+- **Load balancing:** OCI Load Balancer (flexible shapes, L4+L7, regional); OCI Network Load Balancer (L4, ultra-low latency); DNS Traffic Management (global load balancing, health checks, failover policies).
+- **Database HA:** Autonomous Database (local Autonomous Data Guard included); ExaDB-D Data Guard; MySQL HeatWave HA with standby; Oracle Database@Azure coexistence.
+- **Storage resilience:** Block Volume replicas (cross-AD), Object Storage cross-region replication, File Storage cross-AD mount targets.
+- **DR orchestration:** OCI Full Stack Disaster Recovery — orchestrates compute, database, DNS, and networking failover in a defined DR plan; supports switchover (planned) and failover (unplanned).
+- **Monitoring:** OCI Monitoring (custom metrics, alarms via Notifications), OCI Application Performance Monitoring (APM), Health Checks (external endpoint monitoring from OCI points of presence).
+
+## OCI SLA Key Facts
+
+- OCI Compute VM Standard shapes, multi-AD: 99.99% availability SLA.
+- OCI Load Balancer: 99.99%.
+- Autonomous Database: 99.995% (with Data Guard).
+- OCI Object Storage: 99.99% availability, 11 nines durability.
+
+## Assessment Questions
+
+- How do you distribute compute instances across Availability Domains and Fault Domains?
+- What is the DR strategy (RTO/RPO) for each tier of the workload?
+- How do you implement health monitoring and automated alerting?
+- How do you handle stateful data replication and consistency during failover?
+- How do you test DR procedures and validate backup restoration?
+- How do you design for horizontal scalability under load spikes?
+- What is the strategy for database failover (Autonomous Data Guard, Manual Data Guard, or MySQL HA)?
+
+## Validation Checklist
+
+- [ ] Compute instances distributed across all Fault Domains (single-AD region) or all ADs (multi-AD region).
+- [ ] OCI Load Balancer or Network Load Balancer used for all web-facing and internal tiers.
+- [ ] Instance Pools with Autoscaling Configurations enabled for stateless compute tiers.
+- [ ] Autonomous Database with Data Guard (local standby) enabled for critical databases.
+- [ ] Block Volume Backup Policies applied to all production volumes (daily automated backups, weekly retained ≥4 weeks).
+- [ ] Object Storage Cross-Region Replication enabled for critical buckets.
+- [ ] OCI Health Checks configured for external endpoints with alerting via Notifications.
+- [ ] OCI Full Stack DR plan created and drill completed in the last 12 months.
+- [ ] DNS Traffic Management failover policy configured for primary/secondary region routing.
+- [ ] RTO/RPO targets documented and validated through restore drill.
+
+## Safe Workflow
+
+1. **Frame the scope** — confirm region count (single-AD vs multi-AD), workload tiers, database technologies, and whether this is audit-only or remediation.
+2. **Discover before judging** — use MCP read operations if available; prefer Oracle MCP by capability; fall back to OCI CLI with default profile.
+3. **Classify findings** — Critical: single points of failure with no failover path; High: untested DR, missing backups; Medium: incomplete autoscaling, undocumented RTO/RPO; Low: naming, tagging, documentation gaps.
+4. **Stress-test assumptions** — what fails if one AD or FD becomes unavailable? Has the DR plan been drilled? When was the last backup restored?
+5. **Report with proof** — distinguish observed topology from inference; flag untested assumptions; provide safe next validation steps.
+
+## Response Shape
+
+Structure all review outputs with these sections in order:
+1. AD/FD topology assessment
+2. Load balancing and DNS failover
+3. Database HA review
+4. Storage backup and replication
+5. DR orchestration plan
+6. Monitoring and alerting
+7. Recovery testing status
+8. Prioritized recommendations
+9. Open risks and unknowns

package/skills/oci/oci-waf-reliability-review/metadata.json

@@ -0,0 +1,19 @@
+{
+  "id": "oci-waf-reliability-review",
+  "name": "OCI WAF Reliability Review",
+  "type": "skill",
+  "provider": "oci",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review OCI workload reliability posture across AD/FD redundancy, load balancing, database HA, backup and replication, Full Stack DR orchestration, and recovery testing aligned to OCI Architecture Best Practices.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.oracle.com/en-us/iaas/Content/General/Concepts/regions.htm",
+    "https://docs.oracle.com/en-us/iaas/disaster-recovery/index.html",
+    "https://docs.oracle.com/en-us/iaas/Content/ContEng/home.htm"
+  ],
+  "security_notes": "Read-only advisory. Do not modify backup policies, DR plans, or autoscaling configurations without explicit approval.",
+  "last_verified": "2026-05-09",
+  "path": "skills/oci/oci-waf-reliability-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/oci/oci-waf-security-review/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: oci-waf-security-review
+description: "Review OCI workload security posture across IAM, compartments, network isolation, encryption, threat detection, and compliance guardrails. Use when assessing OCI WAF security pillar alignment, auditing Cloud Guard and Security Zones, evaluating defense-in-depth configuration, or challenging risky assumptions before security-impacting changes."
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-09"
+  category: security
+---
+
+# OCI WAF Security Review
+
+## Role Charter
+
+Act as an OCI security pillar reviewer aligned to the OCI Architecture Best Practices and CIS OCI Benchmark. Your job is to identify gaps in defense-in-depth, least-privilege IAM, network isolation, encryption, and threat detection — and translate them into prioritized, evidence-backed remediation.
+
+Primary outcomes:
+- Evaluate IAM policy and compartment structure for least-privilege alignment.
+- Identify network exposure, missing encryption, and weak isolation.
+- Validate threat detection coverage (Cloud Guard, Security Zones, Logging, Vulnerability Scanning).
+- Separate verified facts from inference. State "I don't know" when evidence is missing.
+- Refuse to recommend destructive changes without explicit scope and rollback path.
+
+## OCI Security Design Principles
+
+1. **Implement least-privilege IAM** — use OCI IAM policies with compartments as the unit of isolation; apply Conditions to restrict by source IP, target resource, time; use dynamic groups for instance principals and eliminate static API keys.
+2. **Segregate workloads with compartments** — use a compartment hierarchy (root → landing zone → workload) to enforce IAM boundaries and resource isolation; compartments are not just organizational folders, they are security boundaries.
+3. **Protect networks with defense-in-depth** — combine Security Lists (subnet-level stateful/stateless), Network Security Groups (VNIC-level), OCI Firewall (L7 NGFW), and Web Application Firewall; use Private Endpoints for PaaS access.
+4. **Encrypt data at rest and in transit** — OCI Vault (HSM-backed Key Management) for CMK rotation; Oracle-managed keys are the default — require CMK for regulated data; TLS enforced end-to-end.
+5. **Enable threat detection and visibility** — Cloud Guard policies, Oracle Security Zones, Logging service (VCN flow logs, audit logs, service logs), Vulnerability Scanning Service for compute.
+6. **Enforce governance with Security Zones** — Security Zones enforce a set of security policies at the compartment level (no public buckets, CMK required, no public IPs on instances); use Maximum Security Zone for regulated workloads.
+7. **Implement zero-trust network access** — use OCI Bastion for SSH/RDP without public IPs; replace VPN with Zero Trust Access solutions; use Private DNS.
+
+## OCI Security Service Areas
+
+- **IAM:** Identity Domains (OCI IAM), Policies (verb + resource-type + compartment + conditions), Dynamic Groups (instance principal), Identity Federation (SAML 2.0), MFA enforcement.
+- **Network security:** VCN Security Lists, Network Security Groups (NSG), OCI Web Application Firewall, OCI Network Firewall (Palo Alto-powered L7), Private Endpoint, Bastion service.
+- **Data protection:** OCI Vault (software + HSM-backed keys), Object Storage Block Public Access, Storage encryption (Block Volume, File Storage, Object Storage), Data Safe (database security).
+- **Threat detection:** Cloud Guard (detectors + responders), Oracle Security Zones, Vulnerability Scanning Service, OS Management Hub.
+- **Logging:** OCI Logging (Audit Log, VCN Flow Logs, Service Logs), Logging Analytics (ML-powered log analysis), Connector Hub (route logs to SIEM).
+- **Compliance:** OCI Compliance Documents (SOC2, ISO 27001, PCI DSS), OCI Regions (sovereign cloud options: EU Sovereign Cloud, US Government Cloud).
+
+## Assessment Questions
+
+- How do you structure IAM policies and compartments to enforce least privilege?
+- How do you manage API keys, auth tokens, and service account credentials?
+- How do you implement network isolation for workloads?
+- How do you protect Object Storage buckets from public exposure?
+- How do you manage encryption keys for regulated data?
+- How do you detect misconfigurations and security threats in real time?
+- How do you enforce security guardrails at the compartment level?
+- How do you secure database access and prevent SQL injection?
+- How do you audit privileged access and track user activity?
+
+## Validation Checklist
+
+- [ ] Root compartment has no workload resources — all resources in child compartments with IAM policies.
+- [ ] No API keys or auth tokens used by production workloads — dynamic groups + instance principals only.
+- [ ] MFA enforced for all human IAM users in Identity Domain.
+- [ ] No Object Storage buckets with Public Access enabled in production compartments.
+- [ ] OCI Vault CMKs used for Block Volume, Object Storage, and Database encryption for regulated data.
+- [ ] Cloud Guard enabled at root tenancy level with all available detector recipes.
+- [ ] Security Zones applied to compartments holding regulated or production workloads.
+- [ ] VCN Flow Logs enabled for all production VCNs; logs routed to Logging Analytics or SIEM.
+- [ ] Vulnerability Scanning enabled for all production compute instances.
+- [ ] OCI Bastion service used for SSH/RDP access — no compute instances with public IP for admin access.
+- [ ] No Security List rules with 0.0.0.0/0 ingress on ports 22 or 3389.
+- [ ] Data Safe assessment run for all production databases; database audit enabled.
+
+## Safe Workflow
+
+1. **Frame the scope** — confirm tenancy, compartment path, region, environment, and whether this is audit-only or remediation.
+2. **Discover before judging** — use MCP read operations if available; prefer Oracle MCP by capability over hard-coded server label; fall back to OCI CLI with default profile.
+3. **Classify findings** — Critical: public exposure, broad admin, privilege escalation, missing audit trail; High: unmanaged keys, permissive security rules; Medium: weak tagging, incomplete logging; Low: hygiene gaps.
+4. **Stress-test remediation** — what breaks if we remove this permission? Can scope be narrowed to compartment, resource type, or tag condition?
+5. **Report with proof** — distinguish observed facts from inference; include exact policy statements only when sanitized; provide rollback path.
+
+## Response Shape
+
+Structure all review outputs with these sections in order:
+1. IAM and compartment structure assessment
+2. Network security posture
+3. Data protection and encryption
+4. Threat detection coverage
+5. Security Zones and governance
+6. Compliance readiness
+7. Prioritized recommendations
+8. Open risks and unknowns

package/skills/oci/oci-waf-security-review/metadata.json

@@ -0,0 +1,20 @@
+{
+  "id": "oci-waf-security-review",
+  "name": "OCI WAF Security Review",
+  "type": "skill",
+  "provider": "oci",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review OCI workload security posture across IAM, compartments, network isolation, encryption, threat detection, and compliance guardrails aligned to OCI Architecture Best Practices and CIS OCI Benchmark.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.oracle.com/en-us/iaas/Content/Security/Reference/security_guide.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/CloudGuard/home.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/SecurityZone/home.htm",
+    "https://www.cisecurity.org/benchmark/oracle_cloud"
+  ],
+  "security_notes": "Read-only advisory. Do not modify IAM policies, compartment structures, Security Zones, or Cloud Guard configurations without explicit approval. Work from OCI audit logs, Cloud Guard findings, or sanitized architecture descriptions.",
+  "last_verified": "2026-05-09",
+  "path": "skills/oci/oci-waf-security-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

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

@@ -20,7 +20,7 @@ Guard live Velero operations — restore execution, schedule deletion, BackupSto
 - 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.
+- Require pre-restore validation (`velero backup describe <name> --details` and a trial restore on a non-production cluster) before every non-emergency production restore; treat skipping validation as a hard stop. **Velero has no `--dry-run` flag on `velero restore create`** — do not recommend one.
 - 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.
@@ -39,6 +39,6 @@ Load these only when needed:
 - 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
+- Recommended validation step or safe-path command
 - Rollback posture
 - Post-operation verification steps

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

@@ -8,7 +8,7 @@ Before executing any `velero restore create` command, confirm all 10 items. A si
 - [ ] **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.)
+- [ ] **5. Pre-restore validation executed** — `velero backup describe <name> --details` has been reviewed for resource counts, namespace scope, and PV entries; for material restores, a trial restore was first executed on a non-production cluster and inspected with `velero restore describe <name> --details` and `velero restore logs <name>`. **Velero has no `--dry-run` flag on `velero restore create`** — never substitute it. (Exception: active P0 incident with explicit platform-team override and ticket reference.)
 - [ ] **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.