@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

package/skills/oci/oci-resource-search-inventory-analyst/references/resource-search-inventory-operations.md

@@ -0,0 +1,65 @@
+# OCI Resource Search Inventory 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
+
+- Calling a Resource Search result “all resources” without permission and region caveats.
+- Trusting names instead of tags, compartments, lifecycle, and dependency evidence.
+- Using inventory as authorization to delete resources.
+- Ignoring cross-region and availability-domain scoping.
+
+## Officially grounded service shape
+
+- Official OCI documentation says Search can find resources within a tenancy, Console pages, and documentation.
+- Official OCI CLI documentation says structured search queries resources matching query criteria and results include resources the caller has permission to view.
+- Official OCI documentation explains that resources can be cross-region, regional, or availability-domain scoped, so inventory completeness depends on scope and resource type.
+- OCI API evidence through the user’s configured read-only OCI MCP shows structured search accepts query text, pagination, matching context, and optional cross-tenancy tenant parameter. Treat search as caller-visible inventory evidence, not full posture proof.
+
+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
+
+- State query text, scope, permission caveat, region/resource-type caveat, and timestamp for every inventory.
+- Separate inventory, ownership, dependency, cost, security, and cleanup recommendations.
+- Require owner, dependency, backup, and business criticality before cleanup.
+- Do not expose resource identifiers, private endpoints, customer names, or sensitive tags.
+
+## Minimal safe implementation flow
+
+- Confirm inventory purpose, scope, regions, compartments, resource types, and output format.
+- Use official docs for Search behavior and sampled read-only evidence for query/API shape.
+- Classify resources by type, lifecycle, compartment, tag, owner, exposure, dependency, and confidence.
+- Return inventory summary, blind spots, risky resources, safe next actions, and follow-up queries.
+
+## High-risk assumptions to kill
+
+- “Search returns everything.”
+- “Untagged means unused.”
+- “Stopped means safe to delete.”
+- “One compartment proves the tenancy.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- Check query scope, permissions, region/resource-type coverage, lifecycle states, tags, and timestamps.
+- Cross-check critical resources with service-specific read-only evidence where decisions are high impact.
+- Validate owner and dependency before cleanup recommendations.
+- Label all inventory conclusions by evidence level.
+
+## 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 deletion from search output alone.
+- Scope or permissions are unclear.
+- The inventory contains sensitive identifiers or customer tags.

package/skills/oci/oci-resource-search-inventory-analyst/references/safety-checklist.md

@@ -1,32 +1,35 @@
-# Safety Checklist
+# Safety checklist
 
-Use this checklist before recommending or executing changes for `oci-resource-search-inventory-analyst`.
+Use this checklist before producing guidance, requesting evidence, or proposing changes.
 
-## Scope
+## Evidence labels
 
-- 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.
+- `documentation-based`: grounded in official OCI documentation only.
+- `sampled-api-shape`: grounded in read-only command/API help or metadata evidence.
+- `sampled-current-state`: grounded in read-only observations from the configured environment.
+- `user-supplied`: grounded in sanitized user evidence.
+- `inference`: reasoned from incomplete evidence; never present it as fact.
 
-## Access
+## Credential and identifier boundaries
 
-- 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.
+- Do not ask for credentials, tokens, private keys, API keys, config files, wallets, kubeconfigs, connection strings, customer data, or sensitive identifiers.
+- Do not commit environment-specific identifiers, internal tool names, local environment labels, connector IDs, or private endpoint details.
+- If the task requires live context, ask for a sanitized export or use approved read-only evidence paths.
 
-## Change safety
+## Mutation boundary
 
-- 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.
+Require explicit approval before creating, updating, deleting, moving, scaling, rotating, patching, enabling, disabling, deleting backups, deleting images, changing retention, remediating security findings, changing access, or changing production state.
 
-## Platform portability
+## Approval gates
 
-- 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.
+- Confirm scope, owner, environment criticality, maintenance window, rollback plan, and validation target.
+- Separate read-only discovery from write actions.
+- Prefer least privilege and reversible changes.
+- Stop if evidence conflicts or if the blast radius is unknown.
+
+## Final-answer minimum
+
+- State evidence level and scope.
+- List blockers and unsafe assumptions.
+- Give safe next actions before risky actions.
+- Name what was not proved.

package/skills/oci/oci-resource-search-inventory-analyst/references/workflow-and-output.md

@@ -0,0 +1,26 @@
+# Workflow and output contract
+
+Use this workflow for full reviews, inventory work, security posture checks, and resilience decisions.
+
+## Execution flow
+
+1. Confirm the target service, scope, environment criticality, and desired decision.
+2. Load official source guidance and this skill's operations reference.
+3. Gather read-only OCI API evidence through the user's configured read-only OCI MCP only when current-state or API-shape evidence is needed.
+4. Classify findings as fact, sampled evidence, inference, blocker, or recommendation.
+5. Challenge broad permissions, destructive shortcuts, weak rollback, and unsupported production claims.
+6. Return concise findings with safe next actions and explicit unknowns.
+
+## Output contract
+
+Return these fields when the user asks for a review, inventory, guardrail, or production-readiness answer:
+
+- `verdict`: pass, pass-with-risk, blocked, or needs-evidence.
+- `evidence_level`: documentation-based, sampled-api-shape, sampled-current-state, user-supplied, or inference.
+- `blockers`: missing proof, unsafe assumptions, or approval gaps.
+- `safe_next_actions`: least-risk steps the user can take next.
+- `open_questions`: only questions that materially change the decision.
+
+## Tone
+
+Be blunt. Do not validate a weak plan. If the evidence is thin, say so and narrow the recommendation.

package/skills/oci/oci-security-compliance-reviewer/SKILL.md

@@ -1,233 +1,51 @@
 ---
 name: oci-security-compliance-reviewer
-description: "Review Oracle Cloud Infrastructure security, IAM, network, logging, encryption, and compliance posture. Use when asked to audit OCI policies, compartments, tenancy security, Cloud Guard findings, buckets, vaults, security lists, NSGs, or least-privilege access; prepare compliance evidence; or challenge risky OCI admin assumptions before changes."
+description: Review OCI security, IAM, network exposure, logging, encryption, Cloud Guard, Vulnerability Scanning, Security Zones, and compliance evidence with least-privilege and source-grounded findings.
 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: compliance
 ---
 
 # OCI Security Compliance Reviewer
 
-## Role Charter
+## Purpose
 
-Act as a ruthless OCI security and compliance reviewer. Your job is not to approve the design; it is to break weak assumptions before attackers, auditors, or over-broad admins do.
-
-Primary outcomes:
-- Identify privilege escalation, public exposure, weak isolation, missing logs, weak encryption, and audit gaps.
-- Translate findings into least-privilege, compartment-scoped remediation.
-- Separate verified facts from inference. Say "I don't know" when scope or evidence is missing.
-- Refuse to perform or recommend destructive changes until compartment, region, resource scope, and rollback path are explicit.
-
-## Trigger Situations
+Act as a blunt OCI reviewer for this domain. Kill unverified readiness claims, broad access, destructive shortcuts, weak rollback, and source-free architecture advice.
 
 Use this skill for:
-- OCI IAM policy, group, dynamic-group, federation, or compartment access reviews.
-- Security posture checks for VCNs, subnets, security lists, NSGs, load balancers, buckets, vaults, databases, instances, OKE, or DevOps resources.
-- Compliance evidence requests: audit logging, retention, encryption, access review, separation of duties.
-- Cloud Guard / Vulnerability Scanning / Logging / Events / Notifications review.
-- Any request that sounds like "give admin", "allow all", "open to internet", "temporary broad access", or "fix permission fast".
-
-## Non-Negotiables
-
-- Default to OCI default profile. Use another profile, config file, region, or tenancy only when the user explicitly provides it.
-- Prefer detected official Oracle MCP tools when available for read-only discovery. Otherwise use OCI CLI with the default profile.
-- Never ask users to paste secrets, private keys, fingerprints, API keys, tenancy OCIDs, user OCIDs, or customer-specific values into chat. Ask them to run commands locally or provide sanitized outputs.
-- Do not invent tenancy structure. Confirm compartment path, region, environment, and target resource type.
-- Treat tenancy-wide permissions as guilty until proven necessary.
-- Do not apply policy, network, or security changes without explicit user approval and an exact scope.
-
-
-## 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.
+- OCI IAM, compartment, and least-privilege reviews
+- network, bucket, vault, database, compute, OKE, and DevOps security posture checks
+- Cloud Guard, Security Zones, Vulnerability Scanning, Logging, and audit evidence reviews
+- compliance evidence mapping and remediation prioritization
+- risky admin, public exposure, and broad-access challenge reviews
 
+## Lean operating rules
 
-## 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.
-
+- 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-cloud-guard-mcp-server: list_problems, get_problem_details, update_problem_status; oracle.oci-identity-mcp-server for compartment/identity context; oracle.oci-resource-search-mcp-server for asset evidence.
-- 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. **Frame the scope**
-   - Ask for target: tenancy/compartment, region, environment, resource family, and whether this is audit-only or remediation.
-   - If scope is broad, narrow it. "Whole tenancy" is an audit scope, not a change scope.
-
-2. **Discover before judging**
-   - Use MCP read operations if available.
-   - If using CLI, state that commands assume OCI default profile and placeholders must be replaced locally.
-   - Capture command, region, timestamp, and whether output is raw, summarized, or sanitized.
-
-3. **Classify findings**
-   - Critical: public exposure, broad admin, privilege escalation, missing audit trail, unencrypted sensitive data.
-   - High: cross-compartment access without conditions, unmanaged keys, permissive security rules.
-   - Medium: weak tagging, unclear ownership, excessive read access, incomplete logging.
-   - Low: hygiene, naming, documentation, evidence gaps.
-
-4. **Stress-test remediation**
-   - What breaks if we remove this permission?
-   - Which principal truly needs access: user group, service, dynamic group, resource principal, or workload identity?
-   - Can the permission be compartment-scoped, resource-scoped, tag-scoped, or condition-scoped?
-   - Is there a rollback plan and audit evidence?
-
-5. **Report with proof**
-   - Distinguish observed facts from inference.
-   - Include exact policy statements or rule summaries only when sanitized.
-   - Provide minimal remediation, validation steps, and residual risk.
-
-## OCI MCP / CLI Discovery Examples
-
-Prefer MCP tools where available. Use CLI examples only as safe, local commands with placeholders:
-
-```text
-# Confirm CLI identity and configured region without exposing secrets
-oci iam region-subscription list
-
-# List compartments after the user confirms the root or parent scope locally
-oci iam compartment list --compartment-id <parent_compartment_or_tenancy_ocid> \
-  --compartment-id-in-subtree true --all
-
-# IAM policies: exact command family verified for OCI CLI
-oci iam policy list --compartment-id <compartment_ocid> --all
-
-# Security-relevant inventory examples
-oci network vcn list --compartment-id <compartment_ocid> --all
-oci network security-list list --compartment-id <compartment_ocid> --all
-oci network nsg list --compartment-id <compartment_ocid> --all
-oci os bucket list --compartment-id <compartment_ocid> --all
-oci kms management vault list --compartment-id <compartment_ocid> --all
-oci logging log-group list --compartment-id <compartment_ocid> --all
-```
-
-Do not require the user to reveal real OCIDs in chat. They can run commands and share sanitized summaries.
-
-## Least-Privilege / IAM Review Guidance
-
-Attack these patterns first:
-- `manage all-resources` at tenancy or broad compartment scope.
-- Policies granting write/admin access where `inspect`, `read`, or a narrower verb/resource type is enough.
-- Access for human users where a workload should use dynamic groups or resource principals.
-- Dynamic group rules matching too many instances, functions, or clusters.
-- Missing conditions for network source, request principal type, target compartment, or resource tags.
-- Policies that mix unrelated duties: deploy, operate, audit, billing, security administration.
-- Cross-environment access: dev principals touching prod, shared automation roles without guardrails.
-
-Review method:
-1. Identify principal, verb, resource type, scope, and condition.
-2. Map each permission to a business action.
-3. Remove unrelated actions. Narrow the scope before debating convenience.
-4. Prefer time-bound or ticket-bound exceptions for emergency access.
-5. Validate with a read-only command or policy simulator equivalent when available.
-
-## Output / Report Template
-
-```markdown
-# OCI Security Compliance Review
-
-## Scope
-- Profile/config: default OCI profile unless otherwise stated
-- Region(s):
-- Compartment(s):
-- Resource families:
-- Evidence source: MCP / CLI / user-provided sanitized output
-
-## Executive Verdict
-- Status: PASS / PASS WITH RISKS / FAIL / INCONCLUSIVE
-- Top risks:
-
-## Findings
-| Severity | Finding | Evidence | Impact | Minimal Fix | Validation |
-|---|---|---|---|---|---|
-
-## Least-Privilege Actions
-- Remove:
-- Narrow:
-- Add condition:
-- Separate duty:
+Load these only when needed:
 
-## Assumptions and Unknowns
-- Facts verified:
-- Inferences:
-- Unknowns blocking confidence:
+- [OCI Security Compliance Reviewer Operations](references/security-compliance-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.
 
-## Red-Team Questions
-- What would an over-privileged principal do next?
-- What internet path exists to sensitive data?
-- What audit evidence would fail under regulator review?
-```
+## Response minimum
 
-## Red Flags
+Return, at minimum:
 
-- "Just give tenancy admin temporarily."
-- Public bucket, public load balancer, or `0.0.0.0/0` rule without explicit business justification.
-- Security change requested without compartment and region.
-- Human long-lived credentials used by automation.
-- No Audit/Logging trail for admin actions.
-- Encryption assumed but vault/key ownership not verified.
-- "We will clean it later" with no expiry, owner, or ticket.
+- 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-security-compliance-reviewer/metadata.json

@@ -11,15 +11,19 @@
     "kiro",
     "other"
   ],
-  "summary": "Review Oracle Cloud Infrastructure security, IAM, network, logging, encryption, and compliance posture. Use when asked to audit OCI policies, compartments, tenancy security, Cloud Guard findings, buckets, vaults, security lists, NSGs, or...",
+  "summary": "Review OCI security, IAM, network exposure, logging, encryption, Cloud Guard, Vulnerability Scanning, Security Zones, and compliance evidence with least-privilege and source-grounded findings.",
   "source_type": "adapted",
   "official_docs": [
-    "https://docs.oracle.com/en-us/iaas/Content/home.htm",
-    "https://www.oracle.com/cloud/"
+    "https://docs.oracle.com/en-us/iaas/Content/cloud-adoption-framework/security-architecture.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/cloud-adoption-framework/oci-core-landing-zone.htm",
+    "https://docs.oracle.com/en-us/iaas/cloud-guard/using/trouble.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/cloud-guard/using/problems-page-about.htm",
+    "https://docs.oracle.com/en-us/iaas/scanning/using/scanning-with-cloud-guard.htm",
+    "https://docs.oracle.com/en-us/iaas/security-zone/using/security-zones.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": "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-security-compliance-reviewer",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-security-compliance-reviewer/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-security-compliance-reviewer/references/official-sources.md

@@ -0,0 +1,24 @@
+# Official sources
+
+Use these sources to ground service behavior before making production recommendations.
+
+## Oracle documentation checked on 2026-06-05
+
+- https://docs.oracle.com/en-us/iaas/Content/cloud-adoption-framework/security-architecture.htm
+- https://docs.oracle.com/en-us/iaas/Content/cloud-adoption-framework/oci-core-landing-zone.htm
+- https://docs.oracle.com/en-us/iaas/cloud-guard/using/trouble.htm
+- https://docs.oracle.com/en-us/iaas/Content/cloud-guard/using/problems-page-about.htm
+- https://docs.oracle.com/en-us/iaas/scanning/using/scanning-with-cloud-guard.htm
+- https://docs.oracle.com/en-us/iaas/security-zone/using/security-zones.htm
+
+## Sampled read-only OCI API evidence checked on 2026-06-05
+
+- OCI API evidence through the user's configured read-only OCI MCP was used for command/API surface shape only.
+- Command-help evidence confirms available list/filter surfaces; it does not prove permissions, resource existence, regional availability, capacity, quota, data correctness, control coverage, or production readiness.
+
+## Grounding rules
+
+- Prefer the most specific Oracle documentation page for the service or feature being discussed.
+- If documentation and sampled API evidence appear to conflict, report the conflict and avoid stronger claims until resolved.
+- Do not cite internal tool names, local environment labels, connector identifiers, or environment-specific details in committed docs.
+- Do not paste sensitive identifiers or customer data into examples.

package/skills/oci/oci-security-compliance-reviewer/references/safety-checklist.md

@@ -1,32 +1,35 @@
-# Safety Checklist
+# Safety checklist
 
-Use this checklist before recommending or executing changes for `oci-security-compliance-reviewer`.
+Use this checklist before producing guidance, requesting evidence, or proposing changes.
 
-## Scope
+## Evidence labels
 
-- 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.
+- `documentation-based`: grounded in official OCI documentation only.
+- `sampled-api-shape`: grounded in read-only command/API help or metadata evidence.
+- `sampled-current-state`: grounded in read-only observations from the configured environment.
+- `user-supplied`: grounded in sanitized user evidence.
+- `inference`: reasoned from incomplete evidence; never present it as fact.
 
-## Access
+## Credential and identifier boundaries
 
-- 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.
+- Do not ask for credentials, tokens, private keys, API keys, config files, wallets, kubeconfigs, connection strings, customer data, or sensitive identifiers.
+- Do not commit environment-specific identifiers, internal tool names, local environment labels, connector IDs, or private endpoint details.
+- If the task requires live context, ask for a sanitized export or use approved read-only evidence paths.
 
-## Change safety
+## Mutation boundary
 
-- 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.
+Require explicit approval before creating, updating, deleting, moving, scaling, rotating, patching, enabling, disabling, deleting backups, deleting images, changing retention, remediating security findings, changing access, or changing production state.
 
-## Platform portability
+## Approval gates
 
-- 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.
+- Confirm scope, owner, environment criticality, maintenance window, rollback plan, and validation target.
+- Separate read-only discovery from write actions.
+- Prefer least privilege and reversible changes.
+- Stop if evidence conflicts or if the blast radius is unknown.
+
+## Final-answer minimum
+
+- State evidence level and scope.
+- List blockers and unsafe assumptions.
+- Give safe next actions before risky actions.
+- Name what was not proved.

package/skills/oci/oci-security-compliance-reviewer/references/security-compliance-operations.md

@@ -0,0 +1,65 @@
+# OCI Security Compliance Reviewer 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
+
+- Treating “no findings” as secure without checking detector/target coverage.
+- Approving tenancy-wide admin because compliance is urgent.
+- Ignoring logging, key management, network exposure, and separation-of-duties evidence.
+- Calling documentation compliance evidence without sampled current state.
+
+## Officially grounded service shape
+
+- Official OCI Cloud Adoption Framework documentation emphasizes security architecture, isolation, and landing-zone controls across IAM, network, logging, key management, vulnerability scanning, bastion, notifications, Security Zones, and Cloud Guard.
+- Official OCI Cloud Guard documentation says missing detector recipes or target configuration can prevent problems from being detected.
+- Official OCI documentation describes using Cloud Guard to detect and respond to vulnerabilities identified by Vulnerability Scanning Service.
+- OCI API evidence through the user’s configured read-only OCI MCP shows Cloud Guard problem listing is compartment-scoped, can optionally traverse subcompartments with access-level controls, and filters by time, lifecycle, risk level, detector type, target, problem category, and resource type.
+
+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
+
+- Separate documented control intent, sampled current-state evidence, compliance mapping, and remediation advice.
+- Require detector coverage, target scope, IAM scope, logging, encryption, network exposure, and owner evidence before posture claims.
+- Treat public exposure, all-resources manage policies, disabled logging, weak encryption, and missing detector coverage as high risk.
+- Do not expose identities, customer data, logs, resource identifiers, or sensitive compliance artifacts.
+
+## Minimal safe implementation flow
+
+- Confirm framework/control objective, scope, systems, evidence level, and decision needed.
+- Use official docs for control behavior and sampled read-only evidence for Cloud Guard/API shape or current findings.
+- Review IAM, compartments, network, logging, encryption, scanning, Security Zones, Cloud Guard, and responder boundaries.
+- Return verdict, evidence gaps, prioritized findings, safe remediation, and audit caveats.
+
+## High-risk assumptions to kill
+
+- “No Cloud Guard problems means secure.”
+- “Admin access is needed for audit.”
+- “Encryption enabled means keys are governed.”
+- “A landing zone template equals compliant operations.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- Check Cloud Guard target/detector/responder coverage and problem filters.
+- Check IAM policy scope, broad principals, network exposure, logging, vault/key posture, scanning coverage, and Security Zone violations.
+- Map findings to controls with evidence level and timestamp.
+- Validate remediation with least privilege and rollback.
+
+## 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 compliance sign-off without sampled evidence.
+- Detector coverage or log retention is unknown.
+- The requested remediation is destructive or over-permissive.