@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/oci/oci-support-incident-coordinator/references/mcp-and-evidence.md

@@ -0,0 +1,25 @@
+# MCP and Evidence Discipline
+
+## Evidence classes
+
+- **Official OCI documentation evidence**: proves documented service behavior, supported concepts, command references, and stated caveats. 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**: can prove sampled command shape, API availability, and sanitized configured-environment observations. It does not prove broad regional availability or full account posture.
+- **Inference**: mark as inference when connecting evidence to a risk, remediation, or operational recommendation.
+- **Unknown**: say unknown when the available evidence does not prove the claim.
+
+## Boundaries
+
+- Use read-only discovery first.
+- Do not expose local connector labels, profile names, internal tool names, account-specific identifiers, or environment-specific paths in committed docs or final reports.
+- Do not ask for credentials, tokens, private keys, wallets, tenancy identifiers, compartment identifiers, resource identifiers, support identifiers, customer data, or config contents.
+- Do not treat documentation as evidence of the user's deployed state.
+- Do not treat sampled API evidence as complete coverage.
+
+## Reporting labels
+
+Use these labels in final output:
+
+- `official_docs`: documented OCI behavior with URL.
+- `sampled_api_evidence`: sanitized read-only observation or command/API shape.
+- `inference`: risk or recommendation derived from evidence.
+- `unknown`: missing proof.

package/skills/oci/oci-support-incident-coordinator/references/oci-support-incident-coordinator-operations.md

@@ -0,0 +1,58 @@
+# OCI Support Incident Coordinator Operations Reference
+
+## What people get wrong
+
+- Opening a support request transfers incident ownership to Oracle.
+- Severity is a feeling instead of impact, scope, workaround, and time-to-mitigation evidence.
+- Raw logs can be pasted into prompts or ticket drafts without redaction.
+- A closed ticket proves the operational problem is fixed.
+- Listing support requests is safe to quote verbatim in public docs.
+
+## Officially grounded service shape
+
+- Support requests are visible according to support-request user-group privileges and current user permissions.
+- Oracle documents technical, billing, and service-limit support-request categories and paid-account eligibility caveats.
+- The support incident list API is tenancy-scoped and supports lifecycle, severity/date sorting, problem type, pagination, and support-account context fields.
+- Support evidence can prove ticket metadata and workflow state, not root cause, SLA compliance, customer impact, or production readiness by itself.
+
+## Non-negotiable design rules
+
+- Redact support identifiers, tokens, usernames, tenancy details, resource identifiers, stack traces with secrets, customer data, and private topology.
+- Keep a timeline with exact timestamps, impact, affected services, changes, mitigations, owners, evidence source, and next action.
+- Require approval before creating, updating, escalating, or attaching artifacts to a support request.
+- Label support-request evidence as sampled configured-environment evidence, not general OCI behavior.
+- Do not ask the user to paste support tokens, identifiers, tenancy IDs, or private logs into chat.
+
+## Minimal safe implementation flow
+
+- Classify incident type, severity, business impact, and blast radius.
+- Use official support docs to ground what support requests can show.
+- Use OCI API evidence through the user’s configured read-only OCI MCP only for sanitized request-listing shape or current-state sampling.
+- Build a redacted support packet with timeline, evidence, suspected cause, mitigations, and explicit asks.
+- Return escalation blockers before recommending ticket mutation.
+
+## High-risk assumptions to kill
+
+- Documentation proves service behavior; it does not prove the user's deployed posture.
+- Sampled API evidence proves only the sampled command shape or observation.
+- Read-only discovery is not approval for mutation.
+- Missing evidence is a blocker, not a detail to smooth over.
+
+## Safe command/code verification targets
+
+- Prefer schema, manifest, link, and asset-integrity validation for repository edits.
+- Prefer read-only list/get/help operations for cloud evidence.
+- Redact or omit identifiers and sensitive values from notes and reports.
+
+## Safe verification targets
+
+- Official OCI documentation URL is attached to each service-behavior claim.
+- Sampled API evidence is labeled with scope and limitation.
+- Approval gates are explicit for every proposed mutation.
+- Evidence gaps are listed as open questions.
+
+## When to push back
+
+- The request lacks impact or severity rationale.
+- The user asks to include credentials, customer data, tokens, tenancy details, or raw private logs.
+- The requested action would update support records without explicit approval.

package/skills/oci/oci-support-incident-coordinator/references/official-sources.md

@@ -0,0 +1,14 @@
+# Official Sources
+
+## OCI documentation URLs
+
+- https://docs.oracle.com/en-us/iaas/Content/GSG/support/list-incidents.htm
+- https://docs.oracle.com/en-us/iaas/tools/oci-cli/3.48.2/oci_cli_docs/cmdref/support/incident/list.html
+- https://docs.oracle.com/en-us/iaas/Content/General/Concepts/servicelimits.htm
+
+## Current evidence notes
+
+- Verified on 2026-06-05 against official OCI documentation and sampled read-only command-shape evidence where applicable.
+- Sampled API evidence confirmed support request listing shape and sensitive support-context parameters; committed docs must not include those values.
+- Documentation evidence proves documented behavior, not the user's tenant, compartments, IAM, deployed resources, limits, or production readiness.
+- OCI API evidence through the user’s configured read-only OCI MCP must be described as sampled configured-environment evidence.

package/skills/oci/oci-support-incident-coordinator/references/safety-checklist.md

@@ -1,32 +1,18 @@
 # Safety Checklist
 
-Use this checklist before recommending or executing changes for `oci-support-incident-coordinator`.
+## Non-negotiable gates
 
-## Scope
+- [ ] Scope is explicit: service, workload, region class, compartment boundary, and evidence window are defined without exposing identifiers.
+- [ ] Official OCI documentation is used for service behavior and caveats.
+- [ ] OCI API evidence through the user’s configured read-only OCI MCP is labeled as sampled evidence.
+- [ ] Secrets and identifiers are absent from prompts, notes, committed docs, and examples.
+- [ ] Mutations require explicit user approval and a rollback or recovery path.
+- [ ] Findings separate fact, inference, unknowns, and recommended action.
 
-- 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.
+## High-risk mutation boundary
 
-## Access
+Stop and require explicit approval before any action that creates, updates, deletes, enables, disables, rotates, attaches, detaches, escalates, fails over, resizes, purchases commitments, changes access, changes retention, or sends data to a support channel.
 
-- 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.
+## Credential boundary
 
-## 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.
+Never ask the user to paste credentials, tokens, tenant or tenancy identifiers, subscription-like identifiers, compartment identifiers, resource identifiers, support identifiers, customer data, private keys, wallets, fingerprints, connection strings, kubeconfigs, or config contents. Ask for a sanitized description or permission to inspect through already configured read-only tooling instead.

package/skills/oci/oci-support-incident-coordinator/references/workflow-and-output.md

@@ -0,0 +1,24 @@
+# Workflow and Output Contract
+
+## Execution flow
+
+1. Restate the workload, service boundary, and decision to be made.
+2. Gather official OCI documentation evidence for service behavior.
+3. Gather only read-only, sanitized OCI API evidence through the user’s configured read-only OCI MCP when current-state or command-shape evidence is needed.
+4. Compare evidence against the asset-specific risk checklist.
+5. Identify stale, missing, risky, vague, over-permissive, or ungrounded guidance.
+6. Return blockers before optional improvements.
+
+## Final response minimum
+
+Return:
+
+- `verdict`: pass, caution, or block.
+- `evidence_level`: official_docs, sampled_api_evidence, inference, or unknown.
+- `blockers`: risks that prevent a safe positive recommendation.
+- `safe_next_actions`: read-only or approved actions only.
+- `open_questions`: missing facts that materially change the recommendation.
+
+## Tone
+
+Be direct. Do not validate weak assumptions. If evidence is missing, say so.

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

@@ -1,95 +1,43 @@
 ---
 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."
+description: Review OCI Well-Architected cost optimization posture across usage, budgets, tags, idle resources, rightsizing, quotas, forecasts, and Cloud Advisor recommendations.
 allowed-tools: Read Grep Glob
 metadata:
-  author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-09"
+  author: github: Raishin
+  version: 0.1.1
+  updated: "2026-06-05"
   category: finops
 ---
 
 # OCI WAF Cost Optimization Review
 
-## Role Charter
+## Purpose
 
-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.
+Review OCI Well-Architected cost posture with documented Cost Analysis, Budgets, Cloud Advisor, usage API, tagging, ownership, forecast caveats, and safe-change approval gates.
 
-## Background
+## Use When
 
-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.
+- Reviewing this OCI domain for stale, missing, risky, vague, over-permissive, or under-specified guidance.
+- Comparing current official OCI documentation against existing operational assumptions.
+- Producing a source-grounded advisory that separates documented behavior, sampled configured-environment evidence, inference, and unknowns.
 
-## OCI Cost Optimization Design Principles
+## Operating Rules
 
-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
+- Keep primary responses lean; put detailed service behavior and caveats in references.
+- Use official OCI documentation for documented service behavior.
+- Use OCI API evidence through the user’s configured read-only OCI MCP only for command shape or sanitized sampled current-state observations.
+- Do not mention local connector names, internal tool names, profile names, account-specific identifiers, or environment-specific paths.
+- Never ask for credentials, tokens, tenancy details, compartment or resource identifiers, customer data, private keys, wallets, or config contents.
+- Require explicit approval before any mutation or external support-channel action.
 
-## OCI Cost Tools and Services
+## Reference Pack
 
-- **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
+- `references/oci-waf-cost-optimization-review-operations.md` — service shape, wrong assumptions, operating rules, and pushback triggers.
+- `references/safety-checklist.md` — risk gates, mutation boundaries, credential boundaries, and evidence labels.
+- `references/mcp-and-evidence.md` — official docs versus sampled OCI API evidence discipline.
+- `references/workflow-and-output.md` — execution flow and final response contract.
+- `references/official-sources.md` — official OCI source URLs and current evidence notes.
 
-## Key OCI Pricing Insights
+## Response Contract
 
-- **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
+Return `verdict`, `evidence_level`, `blockers`, `safe_next_actions`, and `open_questions`. Be blunt when evidence is insufficient.

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

@@ -3,17 +3,25 @@
   "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.",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review OCI Well-Architected cost posture with documented Cost Analysis, Budgets, Cloud Advisor, usage API, tagging, ownership, forecast caveats, and safe-change approval gates.",
   "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/"
+    "https://docs.oracle.com/en-us/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/CloudAdvisor/Concepts/cloudadvisoroverview.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/General/Concepts/resourcequotas.htm"
   ],
-  "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",
+  "security_notes": "OCI skills must use official documentation and read-only discovery first, keep identifiers and secrets out of prompts and committed docs, and require explicit approval before mutations.",
+  "last_verified": "2026-06-05",
   "path": "skills/oci/oci-waf-cost-optimization-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-waf-cost-optimization-review/references/mcp-and-evidence.md

@@ -0,0 +1,25 @@
+# MCP and Evidence Discipline
+
+## Evidence classes
+
+- **Official OCI documentation evidence**: proves documented service behavior, supported concepts, command references, and stated caveats. 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**: can prove sampled command shape, API availability, and sanitized configured-environment observations. It does not prove broad regional availability or full account posture.
+- **Inference**: mark as inference when connecting evidence to a risk, remediation, or operational recommendation.
+- **Unknown**: say unknown when the available evidence does not prove the claim.
+
+## Boundaries
+
+- Use read-only discovery first.
+- Do not expose local connector labels, profile names, internal tool names, account-specific identifiers, or environment-specific paths in committed docs or final reports.
+- Do not ask for credentials, tokens, private keys, wallets, tenancy identifiers, compartment identifiers, resource identifiers, support identifiers, customer data, or config contents.
+- Do not treat documentation as evidence of the user's deployed state.
+- Do not treat sampled API evidence as complete coverage.
+
+## Reporting labels
+
+Use these labels in final output:
+
+- `official_docs`: documented OCI behavior with URL.
+- `sampled_api_evidence`: sanitized read-only observation or command/API shape.
+- `inference`: risk or recommendation derived from evidence.
+- `unknown`: missing proof.

package/skills/oci/oci-waf-cost-optimization-review/references/oci-waf-cost-optimization-review-operations.md

@@ -0,0 +1,58 @@
+# OCI WAF Cost Optimization Review Operations Reference
+
+## What people get wrong
+
+- A forecast is a bill.
+- A budget is an enforcement boundary.
+- Idle-looking resources can be stopped or deleted without owner and dependency checks.
+- Savings recommendations are safe without workload seasonality and reservation/commitment analysis.
+- Cloud Advisor recommendations replace human ownership or change approval.
+
+## Officially grounded service shape
+
+- Cost Analysis, Budgets, and usage-summary APIs support cost/usage views, grouping, filtering, time windows, and budget state; they do not prove ownership or business criticality.
+- Budgets can target compartments or tags; a budget alert is governance evidence, not an automatic cost-control guarantee unless an approved automation path exists.
+- Cloud Advisor analyzes tenancy resources and provides cost, performance, security, and availability recommendations, but sampled API evidence did not confirm a generic Cloud Advisor CLI surface in this run.
+- Usage-summary evidence can group by service, compartment, region, resource, tags, tenant, unit, and SKU dimensions when permissions and data are available.
+
+## Non-negotiable design rules
+
+- Separate actual spend, forecast spend, commitment/rate options, rightsizing, and deletion candidates.
+- Require owner, time window, service, compartment or tag scope, business criticality, and rollback path before recommending a mutation.
+- Do not propose stopping, deleting, resizing, or buying commitments without explicit approval and current utilization evidence.
+- Label Cloud Advisor as documentation-grounded unless current configured-environment evidence was sampled directly.
+- Never commit tenant, compartment, resource, invoice, or customer billing identifiers.
+
+## Minimal safe implementation flow
+
+- Define cost objective and measurement window.
+- Ground Cost Analysis, Budgets, Cloud Advisor, quotas, and usage APIs in official docs.
+- Use OCI API evidence through the user’s configured read-only OCI MCP for usage and budget command shape or sanitized observations.
+- Rank recommendations by evidence strength, savings confidence, reversibility, and blast radius.
+- Return no-regret governance fixes before destructive or commitment actions.
+
+## High-risk assumptions to kill
+
+- Documentation proves service behavior; it does not prove the user's deployed posture.
+- Sampled API evidence proves only the sampled command shape or observation.
+- Read-only discovery is not approval for mutation.
+- Missing evidence is a blocker, not a detail to smooth over.
+
+## Safe command/code verification targets
+
+- Prefer schema, manifest, link, and asset-integrity validation for repository edits.
+- Prefer read-only list/get/help operations for cloud evidence.
+- Redact or omit identifiers and sensitive values from notes and reports.
+
+## Safe verification targets
+
+- Official OCI documentation URL is attached to each service-behavior claim.
+- Sampled API evidence is labeled with scope and limitation.
+- Approval gates are explicit for every proposed mutation.
+- Evidence gaps are listed as open questions.
+
+## When to push back
+
+- The user asks for deletion or commitment purchase without owner approval.
+- The dataset lacks time window, tags, service scope, or forecast/actual separation.
+- The request would expose billing identifiers or customer data.

package/skills/oci/oci-waf-cost-optimization-review/references/official-sources.md

@@ -0,0 +1,15 @@
+# Official Sources
+
+## OCI documentation URLs
+
+- https://docs.oracle.com/en-us/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/CloudAdvisor/Concepts/cloudadvisoroverview.htm
+- https://docs.oracle.com/en-us/iaas/Content/General/Concepts/resourcequotas.htm
+
+## Current evidence notes
+
+- Verified on 2026-06-05 against official OCI documentation and sampled read-only command-shape evidence where applicable.
+- Sampled API evidence confirmed usage-summary and budget command shapes; sampled evidence did not confirm a generic Cloud Advisor CLI surface in this run.
+- Documentation evidence proves documented behavior, not the user's tenant, compartments, IAM, deployed resources, limits, or production readiness.
+- OCI API evidence through the user’s configured read-only OCI MCP must be described as sampled configured-environment evidence.

package/skills/oci/oci-waf-cost-optimization-review/references/safety-checklist.md

@@ -0,0 +1,18 @@
+# Safety Checklist
+
+## Non-negotiable gates
+
+- [ ] Scope is explicit: service, workload, region class, compartment boundary, and evidence window are defined without exposing identifiers.
+- [ ] Official OCI documentation is used for service behavior and caveats.
+- [ ] OCI API evidence through the user’s configured read-only OCI MCP is labeled as sampled evidence.
+- [ ] Secrets and identifiers are absent from prompts, notes, committed docs, and examples.
+- [ ] Mutations require explicit user approval and a rollback or recovery path.
+- [ ] Findings separate fact, inference, unknowns, and recommended action.
+
+## High-risk mutation boundary
+
+Stop and require explicit approval before any action that creates, updates, deletes, enables, disables, rotates, attaches, detaches, escalates, fails over, resizes, purchases commitments, changes access, changes retention, or sends data to a support channel.
+
+## Credential boundary
+
+Never ask the user to paste credentials, tokens, tenant or tenancy identifiers, subscription-like identifiers, compartment identifiers, resource identifiers, support identifiers, customer data, private keys, wallets, fingerprints, connection strings, kubeconfigs, or config contents. Ask for a sanitized description or permission to inspect through already configured read-only tooling instead.

package/skills/oci/oci-waf-cost-optimization-review/references/workflow-and-output.md

@@ -0,0 +1,24 @@
+# Workflow and Output Contract
+
+## Execution flow
+
+1. Restate the workload, service boundary, and decision to be made.
+2. Gather official OCI documentation evidence for service behavior.
+3. Gather only read-only, sanitized OCI API evidence through the user’s configured read-only OCI MCP when current-state or command-shape evidence is needed.
+4. Compare evidence against the asset-specific risk checklist.
+5. Identify stale, missing, risky, vague, over-permissive, or ungrounded guidance.
+6. Return blockers before optional improvements.
+
+## Final response minimum
+
+Return:
+
+- `verdict`: pass, caution, or block.
+- `evidence_level`: official_docs, sampled_api_evidence, inference, or unknown.
+- `blockers`: risks that prevent a safe positive recommendation.
+- `safe_next_actions`: read-only or approved actions only.
+- `open_questions`: missing facts that materially change the recommendation.
+
+## Tone
+
+Be direct. Do not validate weak assumptions. If evidence is missing, say so.

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

@@ -1,93 +1,43 @@
 ---
 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."
+description: Review OCI Well-Architected reliability posture across regions, availability domains, fault domains, backups, replication, monitoring, failover, and disaster recovery drills.
 allowed-tools: Read Grep Glob
 metadata:
-  author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-09"
+  author: github: Raishin
+  version: 0.1.1
+  updated: "2026-06-05"
   category: resilience
 ---
 
 # OCI WAF Reliability Review
 
-## Role Charter
+## Purpose
 
-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.
+Review OCI Well-Architected reliability posture with source-grounded checks for regions, domains, backups, replication, alarms, Full Stack DR, RTO/RPO, restore drills, and operational runbooks.
 
-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.
+## Use When
 
-## OCI Reliability Design Principles
+- Reviewing this OCI domain for stale, missing, risky, vague, over-permissive, or under-specified guidance.
+- Comparing current official OCI documentation against existing operational assumptions.
+- Producing a source-grounded advisory that separates documented behavior, sampled configured-environment evidence, inference, and unknowns.
 
-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.
+## Operating Rules
 
-## OCI Reliability Service Areas
+- Keep primary responses lean; put detailed service behavior and caveats in references.
+- Use official OCI documentation for documented service behavior.
+- Use OCI API evidence through the user’s configured read-only OCI MCP only for command shape or sanitized sampled current-state observations.
+- Do not mention local connector names, internal tool names, profile names, account-specific identifiers, or environment-specific paths.
+- Never ask for credentials, tokens, tenancy details, compartment or resource identifiers, customer data, private keys, wallets, or config contents.
+- Require explicit approval before any mutation or external support-channel action.
 
-- **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).
+## Reference Pack
 
-## OCI SLA Key Facts
+- `references/oci-waf-reliability-review-operations.md` — service shape, wrong assumptions, operating rules, and pushback triggers.
+- `references/safety-checklist.md` — risk gates, mutation boundaries, credential boundaries, and evidence labels.
+- `references/mcp-and-evidence.md` — official docs versus sampled OCI API evidence discipline.
+- `references/workflow-and-output.md` — execution flow and final response contract.
+- `references/official-sources.md` — official OCI source URLs and current evidence notes.
 
-- 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.
+## Response Contract
 
-## 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
+Return `verdict`, `evidence_level`, `blockers`, `safe_next_actions`, and `open_questions`. Be blunt when evidence is insufficient.