@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/oci/oci-compute-platform-operator/metadata.json

@@ -11,15 +11,15 @@
     "kiro",
     "other"
   ],
-  "summary": "Operate OCI Compute instances and platform capacity safely with compartment/region confirmation, instance lifecycle guardrails, least-privilege IAM checks, MCP/CLI discovery, and rollback-aware change plans.",
+  "summary": "Operate OCI Compute instances and platform capacity with compartment/region confirmation, lifecycle guardrails, least-privilege IAM, image/shape/network review, and rollback-aware changes.",
   "source_type": "adapted",
   "official_docs": [
-    "https://docs.oracle.com/en-us/iaas/Content/home.htm",
-    "https://www.oracle.com/cloud/"
+    "https://docs.oracle.com/iaas/Content/Compute/Tasks/instances.htm",
+    "https://docs.oracle.com/iaas/Content/Compute/Tasks/launchinginstance.htm"
   ],
-  "security_notes": "OCI skills may inspect or mutate cloud resources. Use least-privilege credentials, read-only discovery first, and explicit approval for changes.",
-  "last_verified": "2026-04-27",
+  "security_notes": "Read-only advisory by default. Use least privilege, sanitize evidence, and require explicit approval plus rollback for risky OCI Compute Platform Operator changes.",
+  "last_verified": "2026-06-05",
   "path": "skills/oci/oci-compute-platform-operator",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-compute-platform-operator/references/compute-platform-operations.md

@@ -0,0 +1,69 @@
+# OCI Compute Platform Operator Operations
+
+> Version note: OCI service behavior and tooling change over time. Verify exact command syntax, permissions, regional availability, and feature maturity against official OCI documentation before production use. Do not paste secrets or sensitive identifiers into commands, files, or chat.
+
+Use this reference for current, source-grounded service behavior and the hard review gates that the lean `SKILL.md` intentionally does not carry.
+
+## What people get wrong
+
+- Stopping, rebooting, resizing, or terminating before owner and dependency checks.
+- Assuming display names uniquely identify instances.
+- Judging exposure from instance list alone instead of VNIC, subnet, route, NSG/security-list, and public-IP evidence.
+- Granting broad compute/volume/network management for routine read-only operations.
+
+## Officially grounded service shape
+
+- Official OCI documentation describes the service behavior and lifecycle concepts for this domain, but it does not prove the user's tenancy, compartments, IAM policies, limits, deployed resources, or production readiness.
+- OCI API evidence through the user’s configured read-only OCI MCP shows compute instance list operations expose compartment, availability domain, display name, lifecycle state, capacity reservation, compute cluster, sort, and pagination filters. It also notes VNIC attachment and VNIC calls are needed for IP details. Treat this as API shape evidence, not full posture proof.
+- Current-state claims need sampled read-only evidence or sanitized user-provided evidence.
+
+Documentation evidence proves documented OCI service behavior. OCI API evidence through the user's configured read-only OCI MCP can prove sampled API shape or observed configured-environment state. Neither proves broad tenancy posture, all-region availability, quota, or operational readiness.
+
+## Non-negotiable design rules
+
+- Confirm region, compartment, instance identity, lifecycle state, owner, and dependency map before mutation.
+- Prefer read-only discovery before lifecycle actions.
+- Check VNICs, public IPs, metadata, image age, boot/block volumes, backups, monitoring, and instance principals.
+- Require explicit approval and rollback/failback for stop, reboot, resize, detach, delete, terminate, or image changes.
+- Separate compute, volume, network, image, capacity, and instance-principal permissions.
+
+## Minimal safe implementation flow
+
+- Classify inventory, troubleshooting, posture review, or lifecycle mutation.
+- Confirm exact target and business owner.
+- Collect compute, VNIC, volume, backup, monitoring, IAM, and dependency evidence.
+- Plan minimal reversible action with maintenance window and rollback.
+- Validate lifecycle, reachability, logs/metrics, access boundaries, and unintended collateral impact.
+
+## High-risk assumptions to kill
+
+- “Instance list output proves network exposure.”
+- “A stopped instance has no cost, dependency, or recovery concerns.”
+- “Terminating and recreating is faster than understanding ownership.”
+- “Instance principals are harmless because they are “inside OCI.””
+- “Shape availability in documentation means capacity is available now.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- List instances in confirmed compartment and do not rely on display name uniqueness.
+- Fetch VNIC attachments and VNIC details for public/private IP exposure.
+- Review boot/block volume attachment, backup policy, image source, metadata, cloud-init, monitoring alarms, and instance-agent posture.
+- Check IAM policies/dynamic groups for instance principal and operator blast radius.
+- Require owner approval and rollback before lifecycle or attachment mutations.
+
+## Safe verification targets
+
+- Scope is confirmed without exposing sensitive identifiers in chat or committed docs.
+- Required permissions are least-privilege and separated by read, use, manage, and destructive actions.
+- Current-state findings are labeled as sampled evidence, not broad proof.
+- Risky mutations have explicit approval, blast-radius review, rollback, and validation.
+- Official-source claims are linked to service docs and not overstated as live posture.
+
+## When to push back
+
+- The user asks for a write/delete/start/stop/update/remediate action before scope and owner are clear.
+- The answer would depend on live infrastructure state but only documentation evidence exists.
+- The proposed access is broader than the task requires.
+- The plan has no rollback, owner, or validation step.

package/skills/oci/oci-compute-platform-operator/references/mcp-and-evidence.md

@@ -0,0 +1,30 @@
+# MCP and evidence path
+
+Use this reference to choose the right evidence path without leaking environment details.
+
+## Evidence order
+
+1. Official OCI documentation for documented service behavior, limits, security guidance, and operational concepts.
+2. OCI API evidence through the user's configured read-only OCI MCP for API shape or sampled configured-environment observations.
+3. Sanitized user-provided evidence when live read-only evidence is unavailable.
+4. Explicit inference only when evidence is incomplete.
+
+## What each evidence type proves
+
+- Official documentation proves documented OCI behavior at the time checked.
+- Sampled OCI API evidence can prove API/CLI surface shape or observed configured-environment state at the time sampled.
+- User-provided evidence proves only what was provided and only if sanitized.
+- Inference is not proof; label it and keep recommendations conditional.
+
+## What evidence does not prove
+
+- Documentation does not prove the user's tenancy, compartments, IAM policies, limits, resources, billing state, security posture, or production readiness.
+- Sampled API evidence does not prove all regions, all compartments, all resources, future posture, or full operational readiness.
+- Command help proves command/API surface shape; it does not prove permission, resource existence, or safe execution.
+
+## Safe phrasing
+
+- “Official OCI documentation says...”
+- “OCI API evidence through the user's configured read-only OCI MCP shows...”
+- “The current state was not queried, so this remains an assumption.”
+- “This recommendation is documentation-based and needs environment validation before production change.”

package/skills/oci/oci-compute-platform-operator/references/official-sources.md

@@ -0,0 +1,19 @@
+# Official sources
+
+Use this reference when grounding current OCI behavior for `oci-compute-platform-operator`.
+
+## Oracle documentation sources
+
+- https://docs.oracle.com/iaas/Content/Compute/Tasks/instances.htm
+- https://docs.oracle.com/iaas/Content/Compute/Tasks/launchinginstance.htm
+
+## Current documentation refresh (2026-06-05)
+
+- Official OCI documentation is the primary source for documented service behavior.
+- OCI API evidence through the user's configured read-only OCI MCP is useful for API shape and sampled configured-environment observations.
+- Documentation evidence is not live customer-state evidence. It does not prove the user's tenancy, compartments, IAM policies, limits, deployed resources, billing state, security posture, or production readiness.
+- Use sampled read-only OCI API evidence only when current-state confirmation is required. Label it as sampled evidence, not broad proof.
+
+## Grounding rule
+
+Docs explain service behavior. Current-state claims require sampled read-only evidence or sanitized user-provided evidence. If current state was not queried or shown, say so.

package/skills/oci/oci-compute-platform-operator/references/safety-checklist.md

@@ -1,32 +1,16 @@
-# Safety Checklist
+# Safety checklist
 
-Use this checklist before recommending or executing changes for `oci-compute-platform-operator`.
+Use before OCI Compute Platform Operator production recommendations, privileged access, cloud mutations, remediation actions, or readiness claims.
 
-## Scope
+## Non-negotiables
 
-- Region confirmed.
-- Compartment or compartment tree confirmed.
-- Resource identity confirmed by name and, when available, live evidence.
-- Owner and business impact confirmed.
-- Environment confirmed: dev/test/stage/prod.
+- Do not ask for or print credentials, tokens, private keys, API keys, config files, tenancy identifiers, compartment identifiers, resource identifiers, customer data, wallets, or secrets.
+- Default to read-only discovery and advisory output.
+- Require explicit approval before any create, update, delete, start, stop, reboot, failover, restore, revoke, remediate, or command-execution action.
+- Keep permissions least-privilege and scoped to the confirmed resource boundary.
+- Separate documentation evidence from OCI API evidence through the user's configured read-only OCI MCP and sanitized user evidence.
+- Treat API availability and command help as API-shape evidence, not permission to mutate or proof of configured resources.
 
-## Access
+## Evidence labels
 
-- Default profile unless user explicitly chooses another profile/config in the active runtime.
-- Least-privilege action only.
-- No tenancy-wide grants unless risk-accepted.
-- No secrets requested or displayed.
-
-## Change safety
-
-- Read-only discovery first.
-- Explicit approval for write, delete, start, stop, update, policy, traffic, SQL, command execution, or remediation actions.
-- Rollback path documented.
-- Validation plan includes positive and negative checks.
-
-## Platform portability
-
-- Prefer MCP tool calls.
-- Use neutral `<placeholders>` in examples.
-- Do not assume Bash, PowerShell, cmd.exe, macOS, Windows, or Linux until execution context is known.
-- Do not embed machine-local paths.
+Use `documentation-based`, `sampled OCI API evidence`, `sampled current-state evidence`, `repo evidence`, `user-provided sanitized evidence`, or `inference`. Documentation alone never proves the user's live OCI posture.

package/skills/oci/oci-compute-platform-operator/references/workflow-and-output.md

@@ -0,0 +1,24 @@
+# Workflow and output contract
+
+Use this reference for full OCI Compute Platform Operator reviews.
+
+## Workflow
+
+1. **Classify scope** — domain, environment, owner, resource boundary, requested action, and production impact.
+2. **Ground in official docs** — use official OCI documentation for current service behavior and caveats.
+3. **Collect read-only evidence when available** — use OCI API evidence through the user's configured read-only OCI MCP for sampled API shape or current-state observations.
+4. **Stress test the plan** — identify broad permissions, destructive actions, unsupported assumptions, missing rollback, and missing owner validation.
+5. **Prioritize safe next actions** — prefer reversible discovery and staged changes before mutation.
+
+## Output contract
+
+Return:
+
+1. Scoped target and evidence level
+2. Verdict: ready, ready with risks, or not ready
+3. Top blockers
+4. Findings with severity, evidence label, recommendation, and owner
+5. Safe next actions in priority order
+6. Required approvals for any mutation
+7. Open questions and assumptions
+8. Official-source notes and sampled-evidence caveats

package/skills/oci/oci-cost-finops-analyst/SKILL.md

@@ -1,234 +1,51 @@
 ---
 name: oci-cost-finops-analyst
-description: "Analyze Oracle Cloud Infrastructure cost, usage, budgets, tagging, rightsizing, commitment coverage, and FinOps governance. Use when asked to explain OCI spend, investigate cost spikes, build savings plans, review underused resources, design chargeback/showback, or challenge cost-optimization assumptions without breaking reliability."
-allowed-tools: Read Grep Glob WebFetch
+description: Analyze OCI cost, usage, budgets, tagging, forecasts, commitments, rightsizing, and FinOps governance without turning savings into reliability or security risk.
+allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
-  version: 0.1.0
-  updated: "2026-05-05"
+  version: 0.1.1
+  updated: "2026-06-05"
   category: finops
 ---
 
 # OCI Cost FinOps Analyst
 
-## Role Charter
+## Purpose
 
-Act as a blunt OCI FinOps analyst. Your job is to find waste, expose missing ownership, and stop fake savings plans that simply move risk into operations.
-
-Primary outcomes:
-- Explain cost drivers with evidence, not vibes.
-- Separate optimization from degradation. Cheap but fragile is not FinOps.
-- Recommend scoped, reversible actions with owner, expected savings, risk, and validation.
-- Challenge broad access and require compartment/region/time-window confirmation before changes.
-
-## Trigger Situations
+Act as a blunt OCI FinOps analyst. Stop fake savings plans, unowned spend, destructive cleanup, and commitment purchases that only move cost risk into operations.
 
 Use this skill for:
-- OCI usage, billing, budget, forecast, commitment, or anomaly analysis.
-- Cost spike investigations by service, compartment, tag, region, or SKU.
-- Rightsizing compute, block volumes, object storage, databases, OKE, load balancers, logging, backups, or network egress.
-- FinOps governance: tagging, showback/chargeback, budgets, alerts, cost allocation.
-- Requests to delete, resize, stop, archive, or downgrade OCI resources for savings.
-
-## Non-Negotiables
-
-- Default to OCI default profile. Use another profile/config only when explicitly provided.
-- Prefer detected official Oracle MCP tools when available for safe discovery. Otherwise use OCI CLI default profile.
-- Never ask users to paste secrets or OCI config private material.
-- Do not include real tenancy OCIDs, user OCIDs, fingerprints, regions, or customer-specific values in skill outputs.
-- Cost usage data is under OCI CLI `usage-api`, not `ce`. In OCI CLI, `ce` is Container Engine.
-- Do not recommend destructive savings actions until scope, owner, backup/retention, rollback, and business criticality are known.
-
-
-## Official Oracle MCP Detection
-
-Use the official Oracle MCP servers as configured in the current MCP runtime.
-
-Do not hard-code the MCP server name. Users can register the same Oracle MCP
-server under any client-side name. Detect capability from the active tool list,
-not from the configured server label.
-
-Detection order:
-
-1. **Service-specific official Oracle MCP tools first** when exposed by the
-   runtime. Examples from the official repo include:
-   - `oracle.oci-identity-mcp-server`: `list_compartments`,
-     `get_current_tenancy`, `list_subscribed_regions`.
-   - `oracle.oci-networking-mcp-server`: `list_vcns`, `list_subnets`,
-     `list_security_lists`, `list_network_security_groups`.
-   - `oracle.oci-compute-mcp-server`: `list_instances`, `get_instance`,
-     `list_images`.
-   - `oracle.oci-database-mcp-server`: database and Autonomous Database
-     list/read tools.
-   - `oracle.oci-object-storage-mcp-server`: `get_namespace`, `list_buckets`,
-     `list_objects`.
-   - `oracle.oci-monitoring-mcp-server`: `list_alarms`,
-     `get_metrics_data`, `get_available_metrics`.
-   - `oracle.oci-resource-search-mcp-server`: `search_resources`.
-   - `oracle.oci-usage-mcp-server` / `oracle.oci-pricing-mcp-server`: usage
-     and pricing evidence where available.
-2. **Generic official OCI API MCP second**: `oracle.oci-api-mcp-server` exposes
-   `get_oci_command_help` and `run_oci_command`. Use this when no
-   service-specific tool is available.
-3. **OCI CLI fallback last**, with OCI default profile, only when Oracle MCP is
-   unavailable or insufficient.
-
-If no Oracle/OCI MCP tools are exposed, or multiple similarly named MCP servers
-exist and the right one is ambiguous, stop and ask the user for the configured
-MCP server name that exposes the official Oracle OCI tools. Ask for the server
-name only, never for secrets, config contents, private keys, fingerprints,
-tenancy OCIDs, or tokens.
 
+- cost analysis and usage reporting
+- budgets, alerts, forecasts, and cost allocation
+- tagging, showback, chargeback, and ownership hygiene
+- rightsizing and idle-resource review
+- commitment and pricing trade-off review
 
-## Platform-Agnostic Execution
-
-These skills must work on macOS, Windows, Linux, and MCP-only clients. Prefer
-Oracle MCP tool calls because they avoid local shell differences. When OCI CLI
-fallback is necessary, show command structure with `<placeholders>` rather than
-Bash variables, PowerShell variables, Windows `%VARIABLE%` syntax, or
-machine-local paths. Adapt quoting, line continuation, and environment handling
-to the user's active platform only at execution time.
+## Lean operating rules
 
+- Prefer official OCI documentation, then OCI API evidence through the user's configured read-only OCI MCP when current-state or API-shape evidence is needed, then sanitized user evidence.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge broad scope, broad permissions, destructive shortcuts, and production claims without evidence.
+- Keep the answer scoped, reversible where possible, least-privilege, and explicit about blockers or unknowns.
+- Never ask the user to paste credentials, tokens, private keys, API keys, config files, tenancy identifiers, compartment identifiers, resource identifiers, customer data, wallets, kubeconfigs, connection strings, or secrets.
 
 ## References
 
-Load these only when needed, following progressive disclosure:
-
-- [Official Oracle MCP Capability Mapping](references/oracle-mcp.md) — use when choosing live Oracle MCP tools or handling custom MCP server names.
-- [Documentation Fallback](references/documentation-fallback.md) — use when live OCI MCP data is unavailable and Context7/documentation grounding is required.
-- [Safety Checklist](references/safety-checklist.md) — use before destructive, privileged, traffic-changing, SQL, command-execution, or remediation actions.
-
-## Preferred Official Oracle MCP Capabilities
-
-- oracle.oci-usage-mcp-server: list_usage_reports, get_usage_report; oracle.oci-pricing-mcp-server: pricing_get_sku, pricing_search_name; oracle.oci-limits-mcp-server for capacity-vs-cost constraints.
-- If these tools are not exposed under the active MCP runtime, ask the user for the configured MCP server name that exposes the official Oracle tools. Ask for the name only, not credentials or config contents.
-
-## Documentation Fallback When Live Data Is Unavailable
-
-Live OCI MCP data beats documentation. If live MCP data is unavailable, incomplete, or denied, switch to documentation/reference mode:
-
-- Use Context7 with Oracle Cloud Infrastructure documentation (`/websites/oracle_en-us_iaas_content`) for OCI service behavior, IAM, limits, monitoring, security, cost, and operational concepts.
-- Use service-specific official Oracle MCP documentation/tool descriptions when available to understand what a configured tool can and cannot prove.
-- Ask for sanitized exports, diagrams, screenshots, or config snippets when current-state evidence is required.
-- Label every conclusion as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`.
-- Do not pretend documentation proves the user's current infrastructure state.
-
-## Safe Workflow
-
-1. **Confirm scope**
-   - Time window, currency/reporting basis, compartment(s), region(s), environment, and whether amortized or actual spend matters.
-   - Confirm if the user wants analysis-only, recommendations, or implementation planning.
-
-2. **Collect evidence**
-   - Prefer MCP read-only discovery if configured.
-   - Use CLI default profile examples with placeholders for local execution.
-   - Ask for sanitized CSV/JSON exports when live usage access is unavailable.
-
-3. **Normalize spend**
-   - Group by service, compartment, region, tag, SKU, and usage quantity.
-   - Compare current period vs baseline period. Do not call a spike without a baseline.
-   - Separate one-time setup, growth, waste, and pricing/commitment effects.
-
-4. **Find optimization candidates**
-   - Idle: stopped/unused compute, detached volumes, orphaned IPs, stale load balancers.
-   - Oversized: low CPU/memory/network utilization, overprovisioned databases, oversized node pools.
-   - Retention: logs, backups, snapshots, object storage tiers.
-   - Governance: missing tags, budgets, owner, lifecycle policy, environment boundary.
-
-5. **Rank actions**
-   - Savings estimate, confidence, operational risk, reversibility, owner, deadline, validation command.
-   - Prefer reversible and no-downtime actions first.
-
-## OCI MCP / CLI Discovery Examples
-
-Use MCP when available. Otherwise these examples assume OCI CLI default profile and local placeholder substitution:
-
-```text
-# Identity/region sanity check without exposing secrets
-oci iam region-subscription list
-
-# Usage and cost summary: exact command family verified for OCI CLI
-oci usage-api usage-summary request-summarized-usages \
-  --tenant-id <tenancy_ocid> \
-  --time-usage-start <yyyy-mm-ddThh:mm:ssZ> \
-  --time-usage-ended <yyyy-mm-ddThh:mm:ssZ> \
-  --granularity MONTHLY \
-  --query-type COST
-
-# Budget discovery
-oci budgets budget list --compartment-id <compartment_ocid> --all
-
-# Inventory candidates for cost analysis
-oci compute instance list --compartment-id <compartment_ocid> --all
-oci bv volume list --compartment-id <compartment_ocid> --all
-oci lb load-balancer list --compartment-id <compartment_ocid> --all
-oci os bucket list --compartment-id <compartment_ocid> --all
-oci ce cluster list --compartment-id <compartment_ocid> --all
-```
-
-Do not ask for real OCIDs in chat. Ask users to run locally and share sanitized outputs or aggregated summaries.
-
-## Least-Privilege / IAM Review Guidance
-
-For FinOps work, fight the lazy assumption that billing review needs admin.
-
-Review:
-- Can the analyst use read-only usage, budget, tag, and inventory permissions?
-- Can remediation be split from analysis? Analysts identify; service owners approve changes.
-- Are automation principals scoped by compartment and resource family?
-- Are delete/update privileges separated from read/report privileges?
-- Are budgets and alerts managed by a controlled FinOps group, not every project team?
-
-Reject:
-- Tenancy admin for cost reporting.
-- Broad resource deletion rights for "cleanup scripts".
-- Cross-production rights without approval workflow.
-- Unowned automation that can stop, resize, or delete resources.
-
-## Output / Report Template
-
-```markdown
-# OCI Cost / FinOps Review
-
-## Scope
-- Profile/config: default OCI profile unless otherwise stated
-- Period:
-- Baseline:
-- Compartments/regions:
-- Data source: MCP / CLI / export / estimate
-
-## Executive Verdict
-- Spend trend:
-- Biggest cost drivers:
-- Savings range:
-- Confidence: High / Medium / Low
-
-## Cost Drivers
-| Rank | Service/SKU | Compartment/Tag | Current Cost | Change vs Baseline | Likely Cause |
-|---|---|---|---:|---:|---|
-
-## Recommendations
-| Priority | Action | Est. Savings | Risk | Reversible? | Owner | Validation |
-|---|---|---:|---|---|---|---|
+Load these only when needed:
 
-## Governance Gaps
-- Missing tags:
-- Missing budgets:
-- Orphaned resources:
-- Policy/access concerns:
+- [OCI Cost FinOps Analyst Operations](references/cost-finops-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, credential boundaries, and current-state caveats.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only OCI API evidence, or sanitized user evidence.
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when you need the detailed Oracle documentation list or source notes.
 
-## Assumptions and Unknowns
-- Verified facts:
-- Inferences:
-- Unknowns blocking confidence:
-```
+## Response minimum
 
-## Red Flags
+Return, at minimum:
 
-- "Delete all unattached volumes" without snapshot/retention confirmation.
-- "Stop non-prod nightly" without dependency and timezone review.
-- Savings estimate with no baseline period.
-- Ignoring egress, logging, backup, and database costs because compute is easier to see.
-- Untagged spend above materiality threshold.
-- Treating OKE node count reduction as safe without pod disruption, autoscaling, and capacity review.
-- Using `oci ce` for cost queries; `ce` is Container Engine, not Cost Explorer.
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/oci/oci-cost-finops-analyst/metadata.json

@@ -11,15 +11,17 @@
     "kiro",
     "other"
   ],
-  "summary": "Analyze Oracle Cloud Infrastructure cost, usage, budgets, tagging, rightsizing, commitment coverage, and FinOps governance. Use when asked to explain OCI spend, investigate cost spikes, build savings plans, review underused resources, de...",
+  "summary": "Analyze OCI cost, usage, budgets, tagging, forecasts, commitments, rightsizing, and FinOps governance without turning savings into reliability or security risk.",
   "source_type": "adapted",
   "official_docs": [
-    "https://docs.oracle.com/en-us/iaas/Content/home.htm",
-    "https://www.oracle.com/cloud/"
+    "https://docs.oracle.com/iaas/Content/Billing/Concepts/costanalysisoverview.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/Billing/Tasks/managingbudgets.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/Tagging/Concepts/taggingoverview.htm",
+    "https://www.oracle.com/cloud/cost-management-and-governance/"
   ],
-  "security_notes": "OCI skills may inspect or mutate cloud resources. Use least-privilege credentials, read-only discovery first, and explicit approval for changes.",
-  "last_verified": "2026-04-27",
+  "security_notes": "Read-only advisory by default. Use least privilege, sanitize evidence, and require explicit approval plus rollback for risky OCI Cost FinOps Analyst changes.",
+  "last_verified": "2026-06-05",
   "path": "skills/oci/oci-cost-finops-analyst",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-cost-finops-analyst/references/cost-finops-operations.md

@@ -0,0 +1,70 @@
+# OCI Cost FinOps Analyst Operations
+
+> Version note: OCI service behavior and tooling change over time. Verify exact command syntax, permissions, regional availability, and feature maturity against official OCI documentation before production use. Do not paste secrets or sensitive identifiers into commands, files, or chat.
+
+Use this reference for current, source-grounded service behavior and the hard review gates that the lean `SKILL.md` intentionally does not carry.
+
+## What people get wrong
+
+- Starting with deletion or commitment buying before validating ownership, utilization, and business criticality.
+- Treating forecasted savings as guaranteed.
+- Confusing Container Engine CLI naming with cost tooling.
+- Ignoring support, backup, data transfer, logging, reliability, and security costs.
+- Using untagged spend as proof of waste instead of proof of missing accountability.
+
+## Officially grounded service shape
+
+- Official OCI documentation describes the service behavior and lifecycle concepts for this domain, but it does not prove the user's tenancy, compartments, IAM policies, limits, deployed resources, or production readiness.
+- OCI API evidence through the user’s configured read-only OCI MCP shows usage-summary requests require tenant scope, time window, granularity, query type, grouping, tag grouping, filters, and pagination; budget listing exposes compartment, lifecycle, display name, and target-type filters. Treat this as API shape evidence, not billing truth.
+- Current-state claims need sampled read-only evidence or sanitized user-provided evidence.
+
+Documentation evidence proves documented OCI service behavior. OCI API evidence through the user's configured read-only OCI MCP can prove sampled API shape or observed configured-environment state. Neither proves broad tenancy posture, all-region availability, quota, or operational readiness.
+
+## Non-negotiable design rules
+
+- Build cost findings from a confirmed time window, scope, service, compartment, and tag model.
+- Separate usage optimization from rate optimization and commitments.
+- Require owner, dependency, backup/retention, rollback, and business criticality before stop/delete/downgrade actions.
+- Label savings as estimate, forecast, sampled evidence, or unverified.
+- Do not expose billing exports with customer identifiers or sensitive business data.
+
+## Minimal safe implementation flow
+
+- Confirm billing scope, time window, granularity, currency/reporting expectation, and owner model.
+- Collect official docs plus sampled usage, budget, tag, and resource evidence where available.
+- Classify spend by service, compartment, tag, region, SKU, resource, and owner.
+- Prioritize reversible cleanup and rightsizing before commitments.
+- Return savings candidates, risk, approvals, validation checks, and follow-up measurement.
+
+## High-risk assumptions to kill
+
+- “Cost drop equals optimization.”
+- “Idle-looking means safe to delete.”
+- “A commitment is always better than pay-as-you-go.”
+- “Budget alerts enforce spending controls.”
+- “Forecasted savings are guaranteed.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- Query usage/cost by service, compartment, tag, region, SKU, and resource for the confirmed time window.
+- Check budgets and alert rules for target type, lifecycle state, owners, and alert routing.
+- Cross-check rightsizing candidates with utilization, dependency, backup, and business-calendar evidence.
+- Validate tag coverage before showback/chargeback conclusions.
+- Require approval before stop, delete, resize, retention, or commitment changes.
+
+## Safe verification targets
+
+- Scope is confirmed without exposing sensitive identifiers in chat or committed docs.
+- Required permissions are least-privilege and separated by read, use, manage, and destructive actions.
+- Current-state findings are labeled as sampled evidence, not broad proof.
+- Risky mutations have explicit approval, blast-radius review, rollback, and validation.
+- Official-source claims are linked to service docs and not overstated as live posture.
+
+## When to push back
+
+- The user asks for a write/delete/start/stop/update/remediate action before scope and owner are clear.
+- The answer would depend on live infrastructure state but only documentation evidence exists.
+- The proposed access is broader than the task requires.
+- The plan has no rollback, owner, or validation step.

package/skills/oci/oci-cost-finops-analyst/references/mcp-and-evidence.md

@@ -0,0 +1,30 @@
+# MCP and evidence path
+
+Use this reference to choose the right evidence path without leaking environment details.
+
+## Evidence order
+
+1. Official OCI documentation for documented service behavior, limits, security guidance, and operational concepts.
+2. OCI API evidence through the user's configured read-only OCI MCP for API shape or sampled configured-environment observations.
+3. Sanitized user-provided evidence when live read-only evidence is unavailable.
+4. Explicit inference only when evidence is incomplete.
+
+## What each evidence type proves
+
+- Official documentation proves documented OCI behavior at the time checked.
+- Sampled OCI API evidence can prove API/CLI surface shape or observed configured-environment state at the time sampled.
+- User-provided evidence proves only what was provided and only if sanitized.
+- Inference is not proof; label it and keep recommendations conditional.
+
+## What evidence does not prove
+
+- Documentation does not prove the user's tenancy, compartments, IAM policies, limits, resources, billing state, security posture, or production readiness.
+- Sampled API evidence does not prove all regions, all compartments, all resources, future posture, or full operational readiness.
+- Command help proves command/API surface shape; it does not prove permission, resource existence, or safe execution.
+
+## Safe phrasing
+
+- “Official OCI documentation says...”
+- “OCI API evidence through the user's configured read-only OCI MCP shows...”
+- “The current state was not queried, so this remains an assumption.”
+- “This recommendation is documentation-based and needs environment validation before production change.”

package/skills/oci/oci-cost-finops-analyst/references/official-sources.md

@@ -0,0 +1,21 @@
+# Official sources
+
+Use this reference when grounding current OCI behavior for `oci-cost-finops-analyst`.
+
+## Oracle documentation sources
+
+- https://docs.oracle.com/iaas/Content/Billing/Concepts/costanalysisoverview.htm
+- https://docs.oracle.com/en-us/iaas/Content/Billing/Tasks/managingbudgets.htm
+- https://docs.oracle.com/en-us/iaas/Content/Tagging/Concepts/taggingoverview.htm
+- https://www.oracle.com/cloud/cost-management-and-governance/
+
+## Current documentation refresh (2026-06-05)
+
+- Official OCI documentation is the primary source for documented service behavior.
+- OCI API evidence through the user's configured read-only OCI MCP is useful for API shape and sampled configured-environment observations.
+- Documentation evidence is not live customer-state evidence. It does not prove the user's tenancy, compartments, IAM policies, limits, deployed resources, billing state, security posture, or production readiness.
+- Use sampled read-only OCI API evidence only when current-state confirmation is required. Label it as sampled evidence, not broad proof.
+
+## Grounding rule
+
+Docs explain service behavior. Current-state claims require sampled read-only evidence or sanitized user-provided evidence. If current state was not queried or shown, say so.