@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

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

@@ -3,17 +3,25 @@
   "name": "OCI WAF Reliability Review",
   "type": "skill",
   "provider": "oci",
-  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
-  "summary": "Review OCI workload reliability posture across AD/FD redundancy, load balancing, database HA, backup and replication, Full Stack DR orchestration, and recovery testing aligned to OCI Architecture Best Practices.",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "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.",
   "source_type": "original",
   "official_docs": [
     "https://docs.oracle.com/en-us/iaas/Content/General/Concepts/regions.htm",
-    "https://docs.oracle.com/en-us/iaas/disaster-recovery/index.html",
-    "https://docs.oracle.com/en-us/iaas/Content/ContEng/home.htm"
+    "https://docs.oracle.com/en-us/iaas/disaster-recovery/doc/how-disaster-recovery-works.html",
+    "https://docs.oracle.com/en-us/iaas/disaster-recovery/doc/overview-protection-groups.html",
+    "https://docs.oracle.com/iaas/Content/Block/Tasks/backingupavolume.htm"
   ],
-  "security_notes": "Read-only advisory. Do not modify backup policies, DR plans, or autoscaling configurations without explicit approval.",
-  "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-reliability-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-waf-reliability-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-reliability-review/references/oci-waf-reliability-review-operations.md

@@ -0,0 +1,58 @@
+# OCI WAF Reliability Review Operations Reference
+
+## What people get wrong
+
+- Multi-AD deployment automatically means highly available application behavior.
+- Backups prove recovery without a restore drill.
+- A DR plan is valid because it exists.
+- Load balancer health is the same as end-to-end transaction health.
+- Regional services remove the need for dependency mapping.
+
+## Officially grounded service shape
+
+- OCI regions contain availability domains and fault domains; placement evidence must be tied to the service’s actual regional or AD-scoped behavior.
+- Full Stack Disaster Recovery orchestrates DR configurations and plans for supported OCI resource types and Oracle recommends cross-region DR for region-wide outage protection.
+- Backups, replication, monitoring alarms, and DR plans are separate evidence classes; none alone proves the application can meet RTO/RPO.
+- Monitoring alarm listing is compartment-scoped, can traverse subcompartments only with tenancy-level permission, and is subject to documented service limits.
+
+## Non-negotiable design rules
+
+- Force explicit RTO, RPO, dependency graph, failover owner, rollback owner, test date, and evidence source.
+- Require approval before failover, DNS change, scaling, replication reconfiguration, backup deletion, or DR plan execution.
+- Label observed alarms, backups, or DR objects as sampled current-state evidence, not proof of production readiness.
+- Treat single-region dependencies, manual runbooks, stale alarms, untested restores, and quota gaps as blockers.
+- Never commit tenancy, region-subscription, compartment, resource, or customer topology identifiers.
+
+## Minimal safe implementation flow
+
+- Define workload and reliability target.
+- Ground region, AD, fault-domain, backup, and Full Stack DR behavior in official docs.
+- Use OCI API evidence through the user’s configured read-only OCI MCP for sanitized alarm, backup, and resource-list shape where relevant.
+- Map single points of failure and untested assumptions.
+- Return blockers, safe next actions, and evidence gaps before recommending failover or mutations.
+
+## 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 equates resource distribution with application recovery.
+- The request asks to execute or alter DR plans without explicit approval.
+- No restore, failover, or monitoring test evidence exists for the claimed RTO/RPO.

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

@@ -0,0 +1,15 @@
+# Official Sources
+
+## OCI documentation URLs
+
+- https://docs.oracle.com/en-us/iaas/Content/General/Concepts/regions.htm
+- https://docs.oracle.com/en-us/iaas/disaster-recovery/doc/how-disaster-recovery-works.html
+- https://docs.oracle.com/en-us/iaas/disaster-recovery/doc/overview-protection-groups.html
+- https://docs.oracle.com/iaas/Content/Block/Tasks/backingupavolume.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 is representative command-shape evidence only; it must not be overclaimed as tenancy-wide posture.
+- 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-reliability-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-reliability-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-security-review/SKILL.md

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

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

@@ -3,18 +3,25 @@
   "name": "OCI WAF Security Review",
   "type": "skill",
   "provider": "oci",
-  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
-  "summary": "Review OCI workload security posture across IAM, compartments, network isolation, encryption, threat detection, and compliance guardrails aligned to OCI Architecture Best Practices and CIS OCI Benchmark.",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review OCI Well-Architected security posture with source-grounded checks for IAM, network exposure, encryption, logging, Cloud Guard, Security Zones, Vulnerability Scanning, and evidence-labeled findings.",
   "source_type": "original",
   "official_docs": [
     "https://docs.oracle.com/en-us/iaas/Content/Security/Reference/security_guide.htm",
-    "https://docs.oracle.com/en-us/iaas/Content/CloudGuard/home.htm",
-    "https://docs.oracle.com/en-us/iaas/Content/SecurityZone/home.htm",
-    "https://www.cisecurity.org/benchmark/oracle_cloud"
+    "https://docs.oracle.com/en-us/iaas/Content/cloud-guard/home.htm",
+    "https://docs.oracle.com/en-us/iaas/scanning/using/scanning-with-cloud-guard.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/cloud-adoption-framework/security-strategy.htm"
   ],
-  "security_notes": "Read-only advisory. Do not modify IAM policies, compartment structures, Security Zones, or Cloud Guard configurations without explicit approval. Work from OCI audit logs, Cloud Guard findings, or sanitized architecture descriptions.",
-  "last_verified": "2026-05-09",
+  "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-security-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-waf-security-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-security-review/references/oci-waf-security-review-operations.md

@@ -0,0 +1,58 @@
+# OCI WAF Security Review Operations Reference
+
+## What people get wrong
+
+- No Cloud Guard findings means secure.
+- Administrator access is acceptable because the account is trusted.
+- Security Zones can be bolted on after risky design without migration planning.
+- Public SSH, broad ingress, public buckets, and wildcard policies are normal until incident response.
+- Encryption keys prove governance without rotation, access, audit, and backup checks.
+
+## Officially grounded service shape
+
+- OCI security posture evidence spans IAM policies, compartments, network controls, encryption, logging, Cloud Guard, Security Zones, and vulnerability scanning.
+- Cloud Guard problem listing is compartment-scoped by default and can include subtree traversal only when allowed; filters include risk level, detector type, resource type, target, lifecycle, and Security Zone category.
+- Vulnerability Scanning results are regional and can surface as Cloud Guard problems in the global reporting region.
+- Security Zones can prevent policy-violating operations for associated compartments, while Cloud Guard can identify policy violations in existing resources.
+
+## Non-negotiable design rules
+
+- Require least-privilege IAM, network exposure, logging, encryption, vulnerability, and detector evidence before issuing a positive security verdict.
+- Require explicit approval before IAM, network, key, Cloud Guard, Security Zone, or scanner mutations.
+- Label Cloud Guard and scanner evidence as sampled configured-environment evidence unless the exact scope and timestamp are proven.
+- Treat public exposure, wildcard IAM, disabled logging, unmanaged keys, inactive detectors, and missing scanner recipes as blockers until justified.
+- Never commit policies, identifiers, customer topology, vulnerability details, or logs that reveal sensitive data.
+
+## Minimal safe implementation flow
+
+- Classify workload and security boundary.
+- Ground security controls in official OCI security, Cloud Guard, Security Zone, and scanner docs.
+- Use OCI API evidence through the user’s configured read-only OCI MCP only for sanitized problem-list or resource-list shape and sampled observations.
+- Rank findings by exploitability, blast radius, compliance impact, and reversibility.
+- Return verdict, blockers, safe next actions, and open questions.
+
+## 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 asks for a clean verdict from incomplete evidence.
+- The user wants to mutate IAM, network, detector, or key controls without approval.
+- The prompt would disclose sensitive topology, vulnerabilities, logs, or identifiers.

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

@@ -0,0 +1,15 @@
+# Official Sources
+
+## OCI documentation URLs
+
+- https://docs.oracle.com/en-us/iaas/Content/Security/Reference/security_guide.htm
+- https://docs.oracle.com/en-us/iaas/Content/cloud-guard/home.htm
+- https://docs.oracle.com/en-us/iaas/scanning/using/scanning-with-cloud-guard.htm
+- https://docs.oracle.com/en-us/iaas/Content/cloud-adoption-framework/security-strategy.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 is representative command-shape evidence only; it must not be overclaimed as tenancy-wide posture.
+- 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-security-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-security-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/oracle-oci-mcp-grounded-advisor/SKILL.md

@@ -1,38 +1,43 @@
 ---
 name: oracle-oci-mcp-grounded-advisor
-description: Use this skill when the user asks about Oracle MCP servers, SQLcl MCP, OCI MCP, Oracle Database agent access, OCI automation, or cloud/database advice that must be grounded in official Oracle sources.
-allowed-tools: Read Grep Glob WebFetch
+description: Ground Oracle, OCI, SQLcl, database, and Model Context Protocol recommendations in official Oracle sources and read-only evidence before advising.
+allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
-  version: 0.1.0
-  updated: "2026-05-05"
-  category: ai
+  version: 0.1.2
+  updated: "2026-06-06"
+  category: compliance
 ---
 
 # Oracle and OCI MCP Grounded Advisor
 
 ## Purpose
 
-Prevent hallucinated Oracle and OCI guidance by forcing official-source verification before recommendations.
+Ground Oracle, OCI, SQLcl, database, and Model Context Protocol advice in official Oracle sources, documented tool behavior, source verification, least-privilege boundaries, and read-only evidence discipline.
 
-## Workflow
+## Use When
 
-1. Identify whether the question is about Oracle Database, SQLcl MCP, OCI, MySQL, documentation MCP, or general MCP architecture.
-2. Verify current behavior against official Oracle pages or repositories when the answer affects installation, authentication, supported versions, or permissions.
-3. Distinguish Oracle-official MCP servers from community projects.
-4. State authentication and data-access risks clearly.
-5. Prefer read-only exploration and documentation lookup before tool execution.
+- 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.
 
-## Output
+## Operating Rules
 
-Return:
+- 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.
 
-- recommendation,
-- source-backed facts,
-- uncertainty or version caveats,
-- setup/security notes,
-- next validation command or official document to read.
+## Reference Pack
 
-## Security notes
+- `references/oracle-oci-mcp-grounded-advisor-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.
 
-Database MCP access can expose production data. Do not recommend connecting an agent to a database unless the user has scoped credentials, audit expectations, and read/write boundaries.
+## Response Contract
+
+Return `verdict`, `evidence_level`, `blockers`, `safe_next_actions`, and `open_questions`. Be blunt when evidence is insufficient.

package/skills/oci/oracle-oci-mcp-grounded-advisor/metadata.json

@@ -11,16 +11,17 @@
     "kiro",
     "other"
   ],
-  "summary": "Ground Oracle, OCI, SQLcl, database, and MCP recommendations in official Oracle sources before advising.",
+  "summary": "Ground Oracle, OCI, SQLcl, database, and Model Context Protocol advice in official Oracle sources, documented tool behavior, source verification, least-privilege boundaries, and read-only evidence discipline.",
   "source_type": "original",
   "official_docs": [
     "https://www.oracle.com/mcp",
     "https://github.com/oracle/mcp",
-    "https://docs.oracle.com/en-us/iaas/Content/home.htm"
+    "https://www.oracle.com/database/model-context-protocol-mcp/",
+    "https://docs.oracle.com/en-us/iaas/tools/oci-cli/latest/oci_cli_docs/"
   ],
-  "security_notes": "Oracle database and OCI MCP tools can expose sensitive data or mutate cloud resources. Verify auth model and permissions before recommending use.",
-  "last_verified": "2026-04-27",
+  "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-06",
   "path": "skills/oci/oracle-oci-mcp-grounded-advisor",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/oci/oracle-oci-mcp-grounded-advisor/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/oracle-oci-mcp-grounded-advisor/references/official-sources.md

@@ -0,0 +1,15 @@
+# Official Sources
+
+## OCI documentation URLs
+
+- https://www.oracle.com/mcp
+- https://github.com/oracle/mcp
+- https://www.oracle.com/database/model-context-protocol-mcp/
+- https://docs.oracle.com/en-us/iaas/tools/oci-cli/latest/oci_cli_docs/
+
+## Current evidence notes
+
+- Verified on 2026-06-06 against official OCI documentation and sampled read-only command-shape evidence where applicable.
+- Official Oracle Model Context Protocol documentation proves documented packages and integration guidance, not local runtime configuration, permissions, or configured-environment observations.
+- 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.