@raishin/vanguard-frontier-agentic 1.1.0 → 1.3.0

package/skills/cilium/cilium-network-policy-review/references/workflow-and-output.md

@@ -0,0 +1,130 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Identify the policy format
+
+Cilium supports three formats with different scopes and capabilities:
+
+1. **`NetworkPolicy`** (`networking.k8s.io/v1`) — Kubernetes-native, namespace-scoped, L3/L4 only.
+2. **`CiliumNetworkPolicy`** (`cilium.io/v2`, "CNP") — namespace-scoped, L3-L7 (HTTP, Kafka, DNS), FQDN matching, ICMP, identity-based selectors via Cilium endpoint identities.
+3. **`CiliumClusterwideNetworkPolicy`** (`cilium.io/v2`, "CCNP") — cluster-wide, same capabilities as CNP, applies across all namespaces.
+
+A namespace can have multiple policies of all three formats simultaneously. The effective policy is the **union** of allows: any policy that allows traffic permits it.
+
+Reference: [Network Policy overview](https://docs.cilium.io/en/stable/network/kubernetes/policy/).
+
+### Step 2 — Verify default-deny posture in the affected namespace
+
+Cilium follows the Kubernetes NetworkPolicy semantic: pods with **at least one ingress policy selecting them** become deny-by-default for ingress; pods with **at least one egress policy selecting them** become deny-by-default for egress. Without any policy selecting a pod, all traffic is allowed.
+
+Critical findings:
+
+- Removing the only ingress `NetworkPolicy` selecting a workload — the workload becomes reachable from any pod, any namespace, any cluster (if ClusterMesh).
+- Adding a workload to a namespace that has no namespace-wide `default-deny` policy — the new workload is allow-by-default.
+
+Recommended baseline: a `default-deny-all` `NetworkPolicy` per namespace plus explicit `CiliumNetworkPolicy` resources that allow specific intra-namespace and cross-namespace flows.
+
+### Step 3 — Audit L7 rules and Envoy proxy requirement
+
+`CiliumNetworkPolicy` and `CiliumClusterwideNetworkPolicy` support L7 rules via Cilium's embedded Envoy:
+
+- `toPorts.rules.http` — method, path, host, header matching.
+- `toPorts.rules.kafka` — Kafka API key matching, topic-level allow.
+- `toPorts.rules.dns` — DNS FQDN allowlist for egress.
+
+L7 rules require the Envoy proxy to be enabled. Without Envoy, policy with L7 fields **either fails admission or is enforced only at L3/L4**, depending on Cilium version. Confirm before relying on L7.
+
+Stress-tests:
+
+- L7 HTTP rule with `path: /admin` but the policy applies to a namespace where pods talk via gRPC — the HTTP path matcher does nothing for HTTP/2 stream multiplexing.
+- L7 DNS rule with FQDN `*.example.com` — wildcard match is supported for DNS but the destination port still matters; verify port 53 UDP/TCP allowed at L4.
+
+Reference: [L7 Policy in Cilium](https://docs.cilium.io/en/stable/security/policy/language/#layer-7-examples).
+
+### Step 4 — Audit egress (the exfiltration path)
+
+Egress is the most-overlooked side of network policy. Critical findings:
+
+- `egress` rules with `toCIDRSet: [{cidr: 0.0.0.0/0}]` and no `except` for internal CIDRs (RFC 1918, link-local, cloud metadata service IPs like `169.254.169.254`) — allows pod to reach the cloud metadata service and exfiltrate cloud credentials.
+- `egress` with `toEndpoints: []` (empty selector) — the empty selector matches **everything** in Cilium semantics; this is broader than `toEndpoints` not being present at all.
+- `egress` allowing `toFQDNs.matchPattern: '*'` — wildcard DNS matching with no narrow allowlist.
+
+Recommended baseline: explicit `toEndpoints` for in-cluster, `toCIDRSet` with `except` for the cloud metadata CIDR, `toFQDNs` for known external services.
+
+### Step 5 — Audit `CiliumEgressGatewayPolicy`
+
+`CiliumEgressGatewayPolicy` assigns a SNAT egress IP for selected pods exiting the cluster — used when external systems require a stable source IP for firewall allowlisting.
+
+Stress-tests:
+
+- Two `CiliumEgressGatewayPolicy` resources with the same `egressIP` — both policies match different pods, both rewrite to the same source IP, and the response routing on the gateway node breaks for one or both. The result is intermittent connection drops.
+- `egressIP` not actually assigned to a NIC on the chosen gateway node — Cilium silently fails to apply, traffic falls back to default node SNAT.
+- `nodeSelector` matches multiple nodes — only one acts as gateway; failover is not automatic.
+- `destinationCIDRs: ['0.0.0.0/0', '::/0']` — every external connection from the selected pods is SNATed; a more narrow CIDR is usually appropriate.
+- Missing `nodeSelector` — policy applies to all nodes, which is rarely the intent.
+
+Reference: [Cilium Egress Gateway](https://docs.cilium.io/en/stable/network/egress-gateway/egress-gateway/).
+
+### Step 6 — Audit ClusterMesh policy semantics
+
+When ClusterMesh is enabled, identity-based policy selectors (`namespaceSelector`, `endpointSelector`) match across cluster boundaries. Two semantics are possible:
+
+1. **`policy-default-local-cluster: false` (default in older versions)** — selectors match endpoints in any peer cluster. A `namespaceSelector: {kubernetes.io/metadata.name: prod}` matches `prod` in this cluster AND `prod` in every peer cluster.
+2. **`policy-default-local-cluster: true` (default in 1.16+)** — selectors match only the local cluster unless the policy explicitly sets `cluster: <peer-cluster>` on the selector.
+
+**A flag flip changes every existing policy's effective scope simultaneously.** Cilium ships `cilium clustermesh inspect-policy-default-local-cluster` specifically to preview which policies would be affected.
+
+Stress-tests:
+
+- ClusterMesh deployment with mixed clusters at different `policy-default-local-cluster` settings — confusing semantics; one cluster's policy may match peer endpoints while another's does not.
+- Migrating from `false` to `true` — every policy that previously matched cross-cluster identities now silently stops matching them. **This is a documented operational landmine.**
+
+Reference: [Cilium ClusterMesh](https://docs.cilium.io/en/stable/network/clustermesh/) and [`cilium clustermesh inspect-policy-default-local-cluster`](https://docs.cilium.io/en/stable/cmdref/cilium_clustermesh_inspect-policy-default-local-cluster/).
+
+### Step 7 — Use Hubble to verify enforcement
+
+Static policy review is not enough. Use Hubble to confirm what the policy actually does:
+
+```shell
+# Watch ingress drops to a workload — should be empty if allow rules are correct
+hubble observe --to-namespace <ns> --to-pod <pod-prefix> --verdict DROPPED --last 1000
+
+# Watch egress allows from a workload — confirms the workload reaches expected destinations
+hubble observe --from-namespace <ns> --from-pod <pod-prefix> --verdict FORWARDED --last 100
+
+# DNS resolution by FQDN policy
+hubble observe --type dns --last 100
+```
+
+Reference: [Hubble Observability](https://docs.cilium.io/en/stable/observability/hubble/).
+
+### Step 8 — Stress-test operational hygiene
+
+- Prefer `CiliumNetworkPolicy` over `NetworkPolicy` when L7 is needed — converting back later is harder than starting with the richer format.
+- Prefer named `endpointSelector` labels over IP CIDRs for in-cluster traffic — IPs change, labels survive pod recreation.
+- Prefer `toFQDNs` over `toCIDRSet` for external services with stable hostnames — DNS rotation no longer breaks the policy.
+- Avoid `CiliumClusterwideNetworkPolicy` for namespace-scoped concerns — cluster-wide blast radius.
+- Test policy changes in a dev or staging cluster first — eBPF program reload happens asynchronously, and a misordered apply during rollout can briefly break traffic.
+
+## Output
+
+Return:
+
+- **target**: which policy format and which scope,
+- **evidence level**: `live evidence` / `documentation-based` / `sanitized user evidence` / `inference`,
+- **default-deny posture** in the namespace(s),
+- **L7 enforcement assessment**: Envoy proxy enabled / required, whether L7 rules will actually run,
+- **egress posture**: cloud-metadata service blocked, CIDR scope, FQDN allowlist hygiene,
+- **ClusterMesh assessment** when applicable (cross-cluster semantics, `policy-default-local-cluster` value),
+- **risk findings** (with severity: high / medium / low),
+- **safest next actions** with sample manifest changes and `hubble observe` commands to verify,
+- **rollback plan**: how to revert the change without leaving pods unreachable,
+- **assumptions and missing facts**.
+
+## Security notes
+
+- Never recommend removing a default-deny policy without a confirmed replacement that explicitly allows required flows.
+- Never recommend `toCIDRSet: [{cidr: 0.0.0.0/0}]` without an `except` block covering the cloud metadata service IP and any other sensitive internal CIDRs.
+- Never recommend changing `policy-default-local-cluster` without first running `cilium clustermesh inspect-policy-default-local-cluster` and reviewing every affected policy.
+- Do not print Cilium ClusterMesh peer Secrets or agent service account tokens.

package/skills/falco/falco-runtime-threat-rules-review/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: falco-runtime-threat-rules-review
+description: Use this skill when reviewing Falco rules files, falco.yaml configuration, or runtime security posture for a Kubernetes workload. Trigger when a user provides Falco rules YAML, asks whether their Falco setup covers a specific threat, questions rule exception scope, or wants to validate that Falco alert output reaches their SIEM or incident response pipeline.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# Falco Runtime Threat Rules Review
+
+## Purpose
+This skill reviews Falco runtime security rules and configuration for correctness, coverage gaps, and operational safety. Falco is a CNCF kernel-level threat detection tool; a misconfigured exception or a silently unconfigured audit webhook means real attacks produce zero alerts. The review catches macro composition errors, overly broad exceptions, missing sensitive-path rules, K8s audit webhook gaps, and alert output routing failures before attackers can exploit them.
+
+## Lean operating rules
+- Treat any rule exception that whitelists an entire process name family (`proc.name in (java, python, node, sh, bash)`) for a sensitive syscall category as HIGH — this creates a full detection blind spot for those runtimes.
+- Treat any rule exception that uses `container.name in (my-app)` without an explicit syscall scope as HIGH — it disables all Falco detection for that container.
+- Treat the absence of rules covering `/proc/*/mem` access, `/etc/shadow` reads, and `/var/run/secrets` mounts as HIGH — these are high-signal kernel-level indicators of container escape and credential theft.
+- Treat K8s audit rules present in the ruleset but no K8s audit webhook configured in the API server as HIGH — the rules exist but never fire because audit events are never delivered.
+- Treat Falco output routed only to stdout with no log aggregation or Falco sidekick configured as HIGH — alerts are silently lost unless a logging pipeline captures stdout from the Falco pod.
+- Flag rules with priority set uniformly to EMERGENCY or CRITICAL for non-critical conditions as MEDIUM — miscalibrated priorities cause alert fatigue and operators begin ignoring or disabling Falco.
+- Flag macro composition that uses negation (`not`) without referencing container context macros — bare process-name rules fire on the host as well as in containers.
+- Do not recommend disabling or commenting out default Falco rules without stating the specific workload justification and residual risk.
+- Label all findings with evidence basis: rule text provided, documentation-based, or inference from missing config.
+
+## References
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review or formatting the final answer.
+
+## Response minimum
+Return, at minimum:
+- Macro and rule composition correctness findings
+- Exception scope assessment (process name, container name, syscall scope)
+- Sensitive-path coverage gaps (/proc/*/mem, /etc/shadow, /var/run/secrets)
+- K8s audit webhook connectivity assessment
+- Alert output channel findings (sidekick, gRPC, stdout-only risk)
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/falco/falco-runtime-threat-rules-review/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "falco-runtime-threat-rules-review",
+  "name": "Falco Runtime Threat Rules Review",
+  "type": "skill",
+  "provider": "falco",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review Falco rules for macro correctness, priority calibration, exception blast radius, sensitive-path coverage, and alert output routing.",
+  "source_type": "original",
+  "official_docs": [
+    "https://falco.org/docs/rules/",
+    "https://falco.org/docs/reference/rules/supported-syscalls/",
+    "https://falco.org/docs/install-operate/third-party/falco-sidekick/",
+    "https://falco.org/docs/reference/rules/exceptions/",
+    "https://falco.org/docs/install-operate/deployment/",
+    "https://github.com/falcosecurity/rules/tree/main/rules"
+  ],
+  "security_notes": "Falco with overly broad rule exceptions creates detection blind spots. A rule exception matching an entire process family (java, python, node) or a specific container name completely disables detection for that workload — attackers can exploit known exception patterns.",
+  "last_verified": "2026-05-02",
+  "path": "skills/falco/falco-runtime-threat-rules-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/falco/falco-runtime-threat-rules-review/references/workflow-and-output.md

@@ -0,0 +1,249 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide one or more of the following as sanitized YAML or JSON snippets (no real hostnames, no auth tokens, no kubeconfig inline):
+- Falco rules file(s) (`falco_rules.yaml`, custom rules YAML)
+- `falco.yaml` (main Falco configuration — output channels, driver type, grpc settings)
+- K8s API server audit policy (`audit-policy.yaml`) and webhook configuration (`audit-webhook-config.yaml`), if K8s audit rules are present
+- Falco sidekick configuration, if deployed
+- Optional: output of `falco --list` or `falcoctl rules list` showing loaded rules
+
+If the user provides only a partial set, note which sections are absent and scope findings accordingly.
+
+### Step 2 — Macro composition audit
+
+Review every macro definition and its use in rules.
+
+Check for:
+- Macros used in negation context (`not is_container`) that do not also scope by `container.id != host`
+- Macros that reference process names without syscall scope (e.g., a macro that matches `proc.name = bash` without specifying which syscalls it applies to)
+- Inheritance chains where a child macro overrides a parent silently (Falco macro override via `override: true` or duplicate macro name)
+
+Example macro composition risk:
+```yaml
+# RISKY — this macro matches bash on host AND in containers
+# If used in a NOT clause, it exempts bash everywhere
+- macro: bash_shell
+  condition: proc.name = bash
+
+# CORRECT — scope to container context
+- macro: bash_in_container
+  condition: proc.name = bash and container.id != host
+```
+
+Flag any macro that, when used in a negation, could suppress host-level detection as MEDIUM.
+
+### Step 3 — Rule priority calibration audit
+
+Review the `priority` field on all custom rules.
+
+Falco priority ladder (highest to lowest):
+`EMERGENCY` → `ALERT` → `CRITICAL` → `ERROR` → `WARNING` → `NOTICE` → `INFORMATIONAL` → `DEBUG`
+
+Check for:
+- All custom rules set to `CRITICAL` or `EMERGENCY` regardless of actual threat severity → MEDIUM (alert fatigue)
+- Rules covering expected or semi-expected behavior (e.g., a CI/CD pipeline running `kubectl exec`) set to `CRITICAL` → MEDIUM
+- Rules covering genuine high-severity threats (container escape attempts, `/proc/*/mem` access) set to `WARNING` or lower → HIGH (under-detection)
+
+Recommended calibration:
+```yaml
+# Container escape attempt — should be CRITICAL
+- rule: Read sensitive memory path
+  desc: Detects direct /proc/PID/mem access indicative of memory scraping
+  condition: open_read and fd.name startswith /proc and fd.name contains /mem
+  output: "Sensitive memory read (proc=%proc.name pid=%proc.pid file=%fd.name)"
+  priority: CRITICAL
+  tags: [container, process, mitre_credential_access]
+
+# Expected CI noise — should be NOTICE or lower
+- rule: Kubectl exec in CI namespace
+  condition: spawned_process and proc.name = kubectl and k8s.ns.name = ci
+  output: "kubectl exec in CI (pod=%k8s.pod.name)"
+  priority: NOTICE
+```
+
+### Step 4 — Exception scope audit
+
+Review every `exceptions:` block on every rule.
+
+**4a. Process name exceptions**
+```yaml
+# HIGH — whitelists all Java processes from shell spawn detection
+- rule: Spawned shell from non-shell binary
+  exceptions:
+    - name: java_apps
+      fields: [proc.pname]
+      comps: [pmatch]
+      values:
+        - [java]
+```
+Any exception that matches a broad process family (`java`, `python`, `node`, `ruby`, `sh`, `bash`) for a sensitive syscall or spawn category completely blinds Falco to attacks running inside those runtimes.
+
+**4b. Container name exceptions**
+```yaml
+# HIGH — disables ALL Falco detection for this container
+- rule: Write below binary dir
+  exceptions:
+    - name: my_app_exception
+      fields: [container.name]
+      comps: [=]
+      values:
+        - [my-privileged-app]
+```
+Container-name exceptions applied at the rule level disable only that rule for that container. But if the same pattern is repeated across multiple rules, the cumulative effect is full detection blindness for that container.
+
+**4c. Correct narrow exception pattern**
+```yaml
+# CORRECT — scopes exception to specific image + specific writable path
+- rule: Write below binary dir
+  exceptions:
+    - name: my_app_installer
+      fields: [container.image.repository, fd.directory]
+      comps: [=, =]
+      values:
+        - [my-org/my-app, /usr/local/bin/app-plugins]
+```
+
+Flag any exception where `fields` contains only `proc.name` or `container.name` without additional syscall or path scope as HIGH.
+
+### Step 5 — Sensitive path coverage audit
+
+Verify that rules exist (custom or inherited from the default ruleset) for:
+
+| Threat | Expected rule condition |
+|--------|------------------------|
+| Container memory scraping | `fd.name startswith /proc` and `fd.name contains /mem` |
+| Shadow file access | `fd.name = /etc/shadow` or `fd.name = /etc/gshadow` |
+| K8s service account token read | `fd.name startswith /var/run/secrets/kubernetes.io` |
+| Privileged container write to host path | `container.privileged = true` and `fd.name startswith /host` |
+| Binary directory write | `fd.directory in (/bin, /usr/bin, /usr/local/bin, /sbin)` |
+
+If any of these are absent and not covered by a loaded default ruleset, flag as HIGH.
+
+Check whether `falco_rules.yaml` references `- rule: ...` with `override: replace` that silently removes a default rule for one of the above categories.
+
+### Step 6 — Kubernetes audit rules audit
+
+Detect whether K8s audit rules are present in the ruleset:
+```yaml
+# K8s audit rules require k8s_audit macro
+- rule: K8s Secret Get or List
+  condition: k8s_audit and ka.verb in (get, list, watch) and ka.target.resource = secrets
+  priority: WARNING
+```
+
+If K8s audit rules exist, check:
+- Whether `falco.yaml` has a `webserver` section configured (Falco embedded audit webhook listener)
+- Whether the K8s API server has an audit webhook pointing to Falco (`--audit-webhook-config-file`)
+- Whether the audit policy includes `resources: [secrets, configmaps]` at a minimum
+
+```yaml
+# Required in falco.yaml for K8s audit
+webserver:
+  enabled: true
+  listen_port: 8765
+  k8s_audit_endpoint: /k8s-audit
+  ssl_enabled: false
+```
+
+If K8s audit rules are present but no webhook is configured or no audit policy is provided, flag as HIGH — the rules are dead weight.
+
+### Step 7 — Alert output channel audit
+
+Review `falco.yaml` `output` section and any sidekick deployment:
+
+**7a. stdout-only output**
+```yaml
+# RISKY — alerts go to pod stdout only
+stdout_output:
+  enabled: true
+file_output:
+  enabled: false
+grpc_output:
+  enabled: false
+```
+If only stdout is enabled and no log aggregation (Fluentd, Fluent Bit, Loki) is confirmed to be scraping the Falco pod, all alerts are silently lost when the pod restarts or the log buffer rolls over. Flag as HIGH.
+
+**7b. Falco sidekick**
+Falco sidekick is the recommended integration bridge (Slack, PagerDuty, Splunk, OpsGenie, SIEM webhooks):
+```yaml
+# Correct — gRPC to sidekick
+grpc_output:
+  enabled: true
+grpc:
+  enabled: true
+  bind_address: "unix:///var/run/falco/falco.sock"
+```
+Verify sidekick is deployed as a Deployment (not a DaemonSet sidecar) and has a live output target configured.
+
+**7c. Output throttling**
+```yaml
+# Check for rate limiting that drops high-volume events
+outputs:
+  rate: 1
+  max_burst: 1000
+```
+Very low `rate` values with small `max_burst` can silently throttle alerts during an active incident. Flag `rate < 10` combined with `max_burst < 100` as MEDIUM.
+
+### Step 8 — Driver type compatibility audit
+
+Identify the configured driver (`ebpf`, `module`, `modern_ebpf`) from `falco.yaml` or deployment manifests.
+
+- `modern_ebpf` (CO-RE) requires kernel 5.8+; check whether the node kernel version is compatible
+- Managed K8s (GKE Autopilot, EKS Fargate) restricts kernel module loading; eBPF or modern_ebpf is required
+- Some syscalls are not available on all drivers — verify critical syscall coverage against `falco --list`
+
+Flag driver/kernel incompatibility as HIGH if it means syscalls used in critical rules are not captured.
+
+### Step 9 — 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 adding broad process-name exceptions (`proc.name in (java, python, node)`) — this creates detection blind spots that attackers can exploit by running malicious code inside a whitelisted runtime.
+- Never recommend disabling the default Falco ruleset (`rules_file: []`) without a complete custom ruleset replacement.
+- Treat any exception that uses `container.name` as the sole discriminator across multiple rules as cumulative HIGH — the container effectively runs undetected.
+- Do not recommend stdout-only output as production-ready without confirming a log aggregation pipeline scrapes the Falco pod and forwards to a SIEM or alerting system.
+- Flag the absence of alerting on Falco's own health (`falco_events_total`, dropped events counter) — a crashing or throttled Falco pod goes unnoticed without self-monitoring.

package/skills/finops/README.md

@@ -0,0 +1,30 @@
+# 💰 FinOps Skills
+
+<p align="center">
+  <!-- 🖼️ Add a FinOps logo to assets/logos/cloud/finops/ and update this path -->
+  <span style="font-size:3.5em">💰</span>
+</p>
+
+This folder contains cross-cloud FinOps skills curated for this marketplace.
+
+## Local marketplace portfolio
+
+This folder contains **1** local FinOps skill:
+
+- `finops-cloud-price-advisor`
+
+## Portfolio posture
+
+Cross-cloud FinOps skills for live price lookup, cost estimation, provider comparison, and budget governance.
+
+These skills are intentionally conservative:
+
+- fetch prices from public unauthenticated APIs only — no billing credentials required
+- always distinguish on-demand list price from effective price (reserved instances, savings plans, committed use discounts not included by default)
+- prefer live API lookups over cached or memory-based price estimates — cloud prices change frequently
+- when comparing providers, normalize compute specs (vCPU, RAM, storage type) before comparing price
+- flag GPU and accelerated compute costs explicitly — they dominate bills and are often overlooked
+
+Providers covered: 🟧 AWS Price List API · 🟦 Azure Retail Prices API · 🟥 OCI public pricing API
+
+Run `npm run validate` after changing cataloged FinOps skills.

package/skills/finops/finops-cloud-price-advisor/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: finops-cloud-price-advisor
+description: Fetch live public prices and build cost estimates for AWS, Azure, and OCI using each cloud's public pricing API. Supports live-environment cost analysis (current resource inventory) and prototype cost planning (planned architecture spec). Currency defaults to USD; other currencies on request.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# FinOps Cloud Price Advisor
+
+## Purpose
+
+Act as a live cloud pricing advisor. Fetch current on-demand prices from each cloud provider's public pricing API and produce cost estimates for real or planned workloads.
+
+Two modes:
+- **Live environment**: enumerate running resources, fetch current prices, return a line-item cost estimate.
+- **Prototype**: accept a planned architecture spec, fetch prices for the described resource types, return a pre-provisioning cost estimate.
+
+## When to use
+
+Use this skill when:
+
+- the user asks "how much does X cost on AWS / Azure / OCI"
+- the user wants a monthly or annual cost estimate for a specific resource type or architecture
+- the user wants to compare equivalent resource costs across two or more clouds
+- the user needs a pre-provisioning cost estimate before deploying a prototype
+- the user wants to understand the live spend baseline of an existing inventory
+- the user requests cost estimates in a specific currency (EUR, GBP, JPY, etc.)
+
+## Lean operating rules
+
+- **Fetch live prices first.** Use WebFetch to call public pricing APIs (no auth required for any cloud). Do not rely on memory for prices — cloud pricing changes; stale numbers mislead.
+- **Label every price with its source date.** State the timestamp of the API response, not just the price.
+- **Default currency is USD.** Switch to another currency only when the user explicitly requests it; load currency-handling reference for conversion approach.
+- **Distinguish modes.** Label each output as `live-environment estimate` or `prototype estimate`.
+- **On-demand pricing only unless told otherwise.** Do not apply reserved instance, savings plan, committed use discount, or spot/preemptible pricing unless the user asks.
+- **Do not hallucinate prices.** If the API call fails or returns no match, say so and explain the fallback (documentation-based estimate, clearly marked as approximate).
+- **Region matters.** Confirm the target region before fetching; pricing varies materially by region.
+- **No credentials required or accepted.** All three pricing APIs are public and unauthenticated. Never ask for cloud credentials, billing account IDs, or cost management export access to fetch list prices.
+- Load references only when needed.
+
+## References
+
+Load these only when needed:
+
+- [Pricing APIs](references/pricing-apis.md) — public endpoint URLs, query parameters, and response field mapping for AWS, Azure, and OCI.
+- [Estimation workflow](references/estimation-workflow.md) — step-by-step workflow for live-environment and prototype estimates.
+- [Currency handling](references/currency-handling.md) — USD default behaviour and exchange-rate approach for other currencies.
+- [Official sources](references/official-sources.md) — authoritative pricing documentation links for each cloud.
+
+## Response minimum
+
+Return, at minimum:
+
+- confirmed cloud(s), region(s), and resource type(s)
+- pricing API source and timestamp (or fallback label if live fetch failed)
+- line-item table: resource | SKU / tier | quantity | unit price (USD) | monthly cost
+- total estimated monthly cost and annualized equivalent
+- key assumptions (on-demand, OS/license, data transfer excluded unless specified)
+- open unknowns that would change the estimate materially

package/skills/finops/finops-cloud-price-advisor/metadata.json

@@ -0,0 +1,26 @@
+{
+  "id": "finops-cloud-price-advisor",
+  "name": "FinOps Cloud Price Advisor",
+  "type": "skill",
+  "provider": "multi-cloud",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Fetch live public prices and build cost estimates for AWS, Azure, and OCI using each cloud's public pricing API. Supports live-environment and prototype cost planning. Currency defaults to USD.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/price-changes.html",
+    "https://learn.microsoft.com/en-us/rest/api/cost-management/retail-prices/azure-retail-prices",
+    "https://docs.oracle.com/en-us/iaas/Content/Billing/Concepts/costanalysisoverview.htm"
+  ],
+  "security_notes": "All three public pricing APIs require no authentication. Never accept or request cloud credentials, billing account IDs, cost export access, or tenant-specific data to fetch list prices.",
+  "last_verified": "2026-04-30",
+  "path": "skills/finops/finops-cloud-price-advisor",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/finops/finops-cloud-price-advisor/references/currency-handling.md

@@ -0,0 +1,100 @@
+# Currency Handling
+
+## Default: USD
+
+All cloud pricing APIs return prices in USD by default. Unless the user explicitly requests a different currency, return all estimates in USD.
+
+State the currency clearly in the output header:
+```
+Currency: USD (on-demand list price, no discounts applied)
+```
+
+---
+
+## Other Currencies — User Request
+
+When the user asks for a non-USD estimate:
+
+1. Fetch the USD price from the cloud pricing API.
+2. Convert using an exchange rate from one of these public sources (WebFetch):
+   - **Preferred** — ExchangeRate-API free endpoint: `https://open.er-api.com/v6/latest/USD` (no auth, returns JSON with major currencies).
+   - Fallback — European Central Bank daily reference rates: `https://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml` (no auth, EUR-denominated).
+
+> **Do not use** Open Exchange Rates (`openexchangerates.org`) for this skill. It requires
+> an `app_id` API key. This agent must not accept or store API keys. The two public
+> sources above are sufficient for approximation.
+
+### Preferred approach (ExchangeRate-API, no auth)
+
+```
+GET https://open.er-api.com/v6/latest/USD
+```
+
+Response:
+```json
+{
+  "base_code": "USD",
+  "time_last_update_utc": "2026-04-30 00:02:01",
+  "rates": {
+    "EUR": 0.9245,
+    "GBP": 0.7931,
+    "JPY": 144.52,
+    "AUD": 1.5521,
+    "CAD": 1.3802,
+    "SGD": 1.3357,
+    "HKD": 7.7823,
+    "BRL": 5.6741,
+    "INR": 83.47
+  }
+}
+```
+
+Usage: `amount_in_target_currency = usd_price × rates[TARGET_CURRENCY_CODE]`
+
+### Labelling converted amounts
+
+Always show both the USD source and the converted amount:
+
+```
+Monthly cost: $234.50 USD → €216.84 EUR (ECB rate 2026-04-30: 1 USD = 0.9245 EUR)
+```
+
+Never present a converted price without disclosing the exchange rate and its date.
+
+---
+
+## Azure Retail Prices API — Native Currency Support
+
+The Azure Retail Prices API accepts a `currencyCode` query parameter and returns prices in that currency natively:
+
+```
+GET https://prices.azure.com/api/retail/prices?api-version=2023-01-01-preview
+    &currencyCode=EUR
+    &$filter=armRegionName eq 'westeurope' and serviceName eq 'Virtual Machines'
+```
+
+Supported currency codes: EUR, GBP, JPY, AUD, CAD, SGD, HKD, BRL, INR, CHF, SEK, DKK, NOK, KRW, MXN, ZAR, and others. Check the API response; unsupported codes return HTTP 400.
+
+When using the Azure API for non-USD estimates, prefer the native `currencyCode` parameter over post-fetch conversion. Note the effective date from the response.
+
+---
+
+## AWS and OCI — USD Only from API
+
+AWS Price List API and OCI pricing API return USD only. For non-USD on these clouds, use the post-fetch conversion approach above.
+
+---
+
+## Rounding
+
+- Show unit prices to 4 decimal places (e.g., $0.0960/hr).
+- Show monthly totals to 2 decimal places (e.g., $70.08/month).
+- Annual totals: multiply monthly by 12, round to 2 decimal places.
+
+---
+
+## Disclaimer Template
+
+Include in every non-USD estimate:
+
+> Exchange rate applied: {RATE} (source: {SOURCE}, {DATE}). Cloud list prices are in USD; converted amounts are approximate. Actual billing currency and exchange rate depend on your cloud provider agreement and may differ.