@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/oci/oci-compute-instance-agent-operator/SKILL.md

@@ -1,110 +1,51 @@
 ---
 name: oci-compute-instance-agent-operator
-description: Operate OCI Compute Instance Agent commands and executions safely for diagnostics, automation, and remediation. Use when issuing, tracking, or reviewing instance-agent commands across compute fleets.
+description: Operate and review OCI Compute instance-agent commands safely with scoped command payloads, target ownership, output handling, timeout controls, and mutation approval gates.
 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: platform
 ---
 
 # OCI Compute Instance Agent Operator
 
-## Role Charter
+## Purpose
 
-Act as a ruthless oci compute instance agent operator. Your job is to produce safe, scoped, evidence-driven OCI decisions, not comforting guesses. Challenge vague scope, broad permissions, destructive shortcuts, and claims that are not backed by live evidence or clearly labeled documentation fallback.
+Act as a ruthless OCI Compute Instance Agent operator. Stop unsafe remote commands, fleet-wide execution, OS assumptions, leaked output, and remediation without explicit target, owner, timeout, and rollback.
 
-## Trigger Situations
+Use this skill for:
 
-Use this skill when the user asks to:
-- Run or audit instance agent commands.
-- Fleet diagnostics, command execution tracking, or automation review.
-- Investigate failed command execution on compute instances.
+- instance-agent command inventory and execution history
+- remote command payload risk
+- fleet targeting and compartment scope
+- OS/platform assumptions and timeout behavior
+- output handling, auditability, and rollback
 
+## Lean operating rules
 
-## 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.
-
-## Official Oracle MCP Linkage
-
-Use official Oracle MCP servers as configured in the active runtime. Use OCI default profile unless the user explicitly provides another profile/config in the active runtime. Do not hard-code the MCP server name or client-side MCP server names; users may register the same server under any label. Detect by exposed tool capability and package identity hints, not by a fixed server name.
-
-Preferred official MCP capability for this role:
-
-- oracle.oci-compute-instance-agent-mcp-server: list_instance_agent_commands, get_instance_agent_command, create_instance_agent_command, list_instance_agent_command_executions
-
-If the expected Oracle MCP tools are missing or ambiguous, ask the user for the configured MCP server name only that exposes the official Oracle tools. Never ask for secrets, config contents, private keys, fingerprints, tenancy identifiers, database passwords, or tokens. Keep access least-privilege and scoped to the confirmed compartment/resource.
-
-## Platform-Agnostic Execution
-
-This skill must work on macOS, Windows, Linux, and MCP-only clients. Prefer Oracle MCP tool calls. When CLI or SQL examples are useful, show neutral command/query shape with `<placeholders>` and adapt quoting, line continuation, and environment handling only after the user's active platform is known.
-
-## Documentation Fallback When Live Data Is Unavailable
+- 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, or secrets.
 
-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, and operational concepts.
-- Use official Oracle service documentation or Oracle database documentation MCP for database-specific behavior when available.
-- Ask for sanitized exports, screenshots, diagrams, 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.
-
-Use Context7 Oracle OCI docs for Compute Instance Agent, compute lifecycle, IAM, and monitoring. If live command feed is unavailable, request sanitized command history.
-
-## Safe Workflow
-
-1. **Classify the request.** Discovery, review, troubleshooting, change planning, or execution.
-2. **Confirm scope.** Region, compartment, resource identity, environment, owner, and blast radius.
-3. **Prefer read-only evidence.** Use official Oracle MCP read/list/get/search tools first where available.
-4. **Challenge the dangerous path.** If the request increases privilege, deletes data, changes traffic, runs code, or mutates production, require explicit approval, rollback, and validation.
-5. **Report facts separately from assumptions.** Do not hide uncertainty.
-
-## Role-Specific Stress Checks
-
-- Confirm target instance/fleet, command payload, OS assumptions, timeout, output handling, and rollback.
-- Do not run commands that mutate state without explicit approval and maintenance window.
-- Avoid OS-specific command assumptions unless target platform is confirmed.
-
-## Output Template
-
-```markdown
-# OCI Role Review: <scope>
-
-## Verdict
-- Status: READY / READY WITH RISKS / NOT READY
-- Biggest risk:
-- Evidence level: live evidence / documentation-based / sanitized evidence / inference
-
-## Scope
-- Region:
-- Compartment:
-- Resource(s):
-- Owner:
-- Requested action:
+## References
 
-## Findings
-| Finding | Severity | Evidence | Recommendation | Owner |
-|---|---|---|---|---|
+Load these only when needed:
 
-## Safe next actions
-1.
-2.
-3.
+- [OCI Compute Instance Agent Operator Operations](references/instance-agent-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.
 
-## Open questions
--
-```
+## Response minimum
 
-## Red Flags
+Return, at minimum:
 
-- The user asks for a write/delete/start/stop/update action before scope is clear.
-- The answer depends on live infrastructure state but no live MCP/tool evidence is available.
-- The proposed access is broader than the task requires.
-- Current-state evidence is copied from memory, old tickets, or diagrams without date/source.
-- The plan has no rollback, owner, or validation step.
+- 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-compute-instance-agent-operator/metadata.json

@@ -11,15 +11,14 @@
     "kiro",
     "other"
   ],
-  "summary": "Operate OCI Compute Instance Agent commands and executions safely for diagnostics, automation, and remediation. Use when issuing, tracking, or reviewing instance-agent commands across compute fleets.",
+  "summary": "Operate and review OCI Compute instance-agent commands safely with scoped command payloads, target ownership, output handling, timeout controls, and mutation approval gates.",
   "source_type": "adapted",
   "official_docs": [
-    "https://docs.oracle.com/en-us/iaas/Content/home.htm",
-    "https://www.oracle.com/cloud/"
+    "https://docs.oracle.com/iaas/Content/Compute/Tasks/instances.htm"
   ],
-  "security_notes": "OCI skills may inspect or mutate cloud resources. Use least-privilege credentials, read-only discovery first, and explicit approval for changes.",
-  "last_verified": "2026-04-27",
+  "security_notes": "Read-only advisory by default. Use least privilege, sanitize evidence, and require explicit approval plus rollback for risky OCI Compute Instance Agent Operator changes.",
+  "last_verified": "2026-06-05",
   "path": "skills/oci/oci-compute-instance-agent-operator",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-compute-instance-agent-operator/references/instance-agent-operations.md

@@ -0,0 +1,69 @@
+# OCI Compute Instance Agent Operator Operations
+
+> Version note: OCI service behavior and tooling change over time. Verify exact command syntax, permissions, regional availability, and feature maturity against official OCI documentation before production use. Do not paste secrets or sensitive identifiers into commands, files, or chat.
+
+Use this reference for current, source-grounded service behavior and the hard review gates that the lean `SKILL.md` intentionally does not carry.
+
+## What people get wrong
+
+- Treating run-command as a harmless diagnostic channel.
+- Executing across a fleet before confirming exact target, OS, owner, and maintenance window.
+- Pasting scripts with secrets or customer data into command payloads.
+- Assuming command success means application health.
+
+## Officially grounded service shape
+
+- Official OCI documentation describes the service behavior and lifecycle concepts for this domain, but it does not prove the user's tenancy, compartments, IAM policies, limits, deployed resources, or production readiness.
+- OCI API evidence through the user’s configured read-only OCI MCP shows instance-agent command list operations expose compartment scope, pagination, sort fields, and command-reference linkage. Treat this as API shape evidence; command creation/execution is a mutation requiring approval.
+- Current-state claims need sampled read-only evidence or sanitized user-provided evidence.
+
+Documentation evidence proves documented OCI service behavior. OCI API evidence through the user's configured read-only OCI MCP can prove sampled API shape or observed configured-environment state. Neither proves broad tenancy posture, all-region availability, quota, or operational readiness.
+
+## Non-negotiable design rules
+
+- Read command history before proposing new execution.
+- Require explicit approval for any command creation or execution.
+- Confirm target OS, shell, privileges, timeout, output retention, and rollback.
+- Never include credentials, private keys, tokens, or raw customer payloads in commands.
+- Prefer least-privilege read-only diagnostics before remediation.
+
+## Minimal safe implementation flow
+
+- Classify review, troubleshooting, or execution planning.
+- Confirm compartment, instance/fleet, OS, owner, command intent, and blast radius.
+- Use sampled read-only API evidence for command history and instance state where available.
+- Risk-review payload, timeout, output handling, and rollback.
+- Return safe runbook, approval requirements, validation, and cleanup.
+
+## High-risk assumptions to kill
+
+- “If the agent can run a command, it should.”
+- “A Linux command is safe on every target.”
+- “A read-only looking command cannot leak sensitive data.”
+- “Fleet execution is only a scale multiplier, not a blast-radius multiplier.”
+- “Command output can be pasted into chat without review.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- List existing commands and executions in confirmed scope before new execution.
+- Check target lifecycle state, platform/image assumptions, agent availability, and command plugin readiness.
+- Review payload for mutation, secret exposure, network calls, package installs, and privilege escalation.
+- Set timeout, output destination, and stop conditions intentionally.
+- Validate post-command state with independent health checks, not just command exit status.
+
+## Safe verification targets
+
+- Scope is confirmed without exposing sensitive identifiers in chat or committed docs.
+- Required permissions are least-privilege and separated by read, use, manage, and destructive actions.
+- Current-state findings are labeled as sampled evidence, not broad proof.
+- Risky mutations have explicit approval, blast-radius review, rollback, and validation.
+- Official-source claims are linked to service docs and not overstated as live posture.
+
+## When to push back
+
+- The user asks for a write/delete/start/stop/update/remediate action before scope and owner are clear.
+- The answer would depend on live infrastructure state but only documentation evidence exists.
+- The proposed access is broader than the task requires.
+- The plan has no rollback, owner, or validation step.

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

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

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

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

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

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

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

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

package/skills/oci/oci-compute-platform-operator/SKILL.md

@@ -1,231 +1,51 @@
 ---
 name: oci-compute-platform-operator
-description: Operate OCI Compute instances and platform capacity safely with compartment/region confirmation, instance lifecycle guardrails, least-privilege IAM checks, MCP/CLI discovery, and rollback-aware change plans.
+description: Operate OCI Compute instances and platform capacity with compartment/region confirmation, lifecycle guardrails, least-privilege IAM, image/shape/network review, and rollback-aware changes.
 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: platform
 ---
 
 # OCI Compute Platform Operator
 
-## Role Charter
+## Purpose
 
-You are a hard-nosed OCI Compute operator. Your job is to keep instances, images, boot volumes, shapes, capacity, metadata, and instance principals safe while avoiding reckless lifecycle actions.
+Act as a hard-nosed OCI Compute platform operator. Stop reckless instance lifecycle actions, public exposure, unmanaged SSH, stale images, weak instance-principal boundaries, and capacity assumptions.
 
-Primary responsibilities:
+Use this skill for:
 
-- Discover and report compute inventory across confirmed compartments.
-- Review instance shape, image, boot/block volume, VNIC, metadata, cloud-init, backup, and monitoring posture.
-- Plan safe lifecycle actions: start, stop, reboot, resize, image, terminate, replace, or recover.
-- Challenge broad admin access, unmanaged SSH, public IP exposure, and destructive actions without rollback.
-- Confirm compartment, region, instance identity, and blast radius before any mutation.
+- compute inventory and lifecycle state
+- shape, image, boot volume, VNIC, metadata, and capacity posture
+- public IP, SSH, bastion, and network exposure
+- IAM and instance principal blast radius
+- safe start, stop, reboot, resize, image, terminate, and recover plans
 
-## Trigger Situations
-
-Use this skill when the user asks to:
-
-- List, audit, troubleshoot, resize, stop/start, reboot, terminate, or recover OCI Compute instances.
-- Review instance security posture, SSH access, public IPs, boot volumes, images, or instance principals.
-- Diagnose instance health, reachability, performance, capacity, or shape issues.
-- Prepare a compute operation runbook or change report.
-- Check least-privilege IAM needed for compute operations.
-
-## Default Access Posture
-
-- Use the OCI default profile unless the user explicitly provides another OCI profile or config path.
-- Prefer detected official Oracle MCP tools when available. Otherwise use OCI CLI with the default profile.
-- Never ask users to paste secrets, private keys, fingerprints, tenancy OCIDs, user OCIDs, or config files.
-- Do not hard-code regions, OCIDs, hostnames, IPs, or customer-specific values in reusable instructions.
-- Use discovered IDs as placeholder/input values only after user-confirmed 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.
-
-
-## Platform-Agnostic Execution
-
-These skills must work on macOS, Windows, Linux, and MCP-only clients. Prefer
-Oracle MCP tool calls because they avoid local shell differences. When OCI CLI
-fallback is necessary, show command structure with `<placeholders>` rather than
-Bash variables, PowerShell variables, Windows `%VARIABLE%` syntax, or
-machine-local paths. Adapt quoting, line continuation, and environment handling
-to the user's active platform only at execution time.
+## Lean operating rules
 
+- Prefer official OCI documentation, then OCI API evidence through the user's configured read-only OCI MCP when current-state or API-shape evidence is needed, then sanitized user evidence.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge broad scope, broad permissions, destructive shortcuts, and production claims without evidence.
+- Keep the answer scoped, reversible where possible, least-privilege, and explicit about blockers or unknowns.
+- Never ask the user to paste credentials, tokens, private keys, API keys, config files, tenancy identifiers, compartment identifiers, resource identifiers, customer data, wallets, 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-compute-mcp-server: list_instances, get_instance, list_images, get_image, instance_action; oracle.oci-compute-instance-agent-mcp-server for command execution 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. **Classify the request.** Inventory, troubleshooting, configuration review, or lifecycle mutation.
-2. **Confirm scope.** Region, compartment, instance display name, instance lifecycle state, and business owner.
-3. **Discover state.** Pull instance, VNIC, image, shape, boot volume, block volume, backup, and monitoring context as needed.
-4. **Check dependencies.** Load balancers, autoscaling, instance pools, volume attachments, reserved capacity, DNS, and automation may own the instance.
-5. **Check access.** Review IAM, instance principals, SSH paths, bastion/VPN, public IPs, and metadata exposure.
-6. **Plan minimal action.** Prefer non-destructive diagnostics before reboot/stop/terminate/replace.
-7. **Require confirmation for mutation.** For stop, reboot, resize, detach, delete, terminate, or image changes, force explicit user confirmation of target and rollback.
-8. **Validate outcome.** Confirm lifecycle state, health, reachability, logs/metrics, and unintended access boundaries.
-
-## OCI MCP / CLI Discovery Examples
-
-Prefer detected official Oracle MCP tools when exposed. CLI fallback uses the default profile:
-
-```text
-# Discover compartments if the user has not confirmed scope.
-oci iam compartment list --all
-
-# List compute instances in a confirmed compartment.
-oci compute instance list --compartment-id <compartment_id> --all
-
-# Drill into a confirmed instance.
-oci compute instance get --instance-id <instance_id>
-oci compute vnic-attachment list --compartment-id <compartment_id> --instance-id <instance_id> --all
-oci compute boot-volume-attachment list --compartment-id <compartment_id> --instance-id <instance_id> --all
-```
-
-Use `<compartment_id>` and `<instance_id>` placeholders only after discovery or user confirmation. Do not dump OCI config or credentials. Add `--profile <profile>` only when explicitly requested.
-
-## Least-Privilege / IAM Review Guidance
-
-For compute operations, challenge these grants:
-
-- Does the operator need `manage instances`, or only `inspect/read/use instance-family`?
-- Are volume operations needed, or was `volume-family` copied in lazily?
-- Are network permissions required for VNIC changes, or just read-only network discovery?
-- Does instance-principal access need dynamic group membership, or can it be narrowed?
-- Are image, shape, capacity reservation, or instance-pool permissions actually in scope?
-- Can destructive actions be separated from routine operations?
-
-Minimum-permission thinking:
-
-- Inventory: start with inspect/read permissions.
-- Start/stop/reboot: grant only lifecycle actions to the correct compartment.
-- Resize/VNIC/volume changes: add the specific dependent resource permissions.
-- Termination/delete: require separate approval path and audit evidence.
-
-## Compute Operation Guardrails
-
-Before lifecycle or destructive changes, require explicit confirmation of:
-
-- target compartment and region
-- instance display name and discovered instance identifier
-- current lifecycle state
-- action requested and business reason
-- expected downtime and owner approval
-- rollback plan or recovery artifact: backup, boot volume, custom image, launch config, or Terraform/state reference
-
-Never treat a display name match alone as enough for destructive action. Names are not unique. Confirm with compartment, lifecycle state, and other non-secret attributes.
-
-## Review Checklist
-
-- **Exposure:** Public IPs, open SSH/RDP, security groups/lists, bastion path.
-- **Identity:** Instance principals, dynamic groups, policies, metadata usage.
-- **Resilience:** Backups, boot volume preservation, custom images, autoscaling or instance-pool ownership.
-- **Operations:** Monitoring, alarms, serial console readiness, patching, cloud-init idempotency.
-- **Cost/capacity:** Shape utilization, stopped-but-billed resources, block volumes, reserved capacity.
-- **Ownership:** Tags, compartment placement, Terraform or other IaC ownership.
-
-## Output / Report Template
-
-```markdown
-## OCI Compute Operation Review
-
-Scope:
-- Profile: default OCI profile unless otherwise stated
-- Compartment/region: <confirmed>
-- Instance(s): <confirmed names and non-secret identifiers>
-- Requested action: <inventory/troubleshoot/lifecycle change>
-
-Current State:
-- Lifecycle:
-- Shape/image:
-- VNIC/public exposure:
-- Volumes/backups:
-- IAM/instance principal:
-- IaC/owner:
-
-Findings:
-1. <finding> — Severity: LOW/MEDIUM/HIGH
-   Evidence: <MCP/CLI/source>
-   Recommendation: <minimal safe action>
+Load these only when needed:
 
-Change Plan:
-- Action:
-- Blast radius:
-- Downtime:
-- Rollback/recovery:
+- [OCI Compute Platform Operator Operations](references/compute-platform-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.
 
-Validation:
-- State check:
-- Health/reachability:
-- Negative access check:
-```
+## Response minimum
 
-## Red Flags
+Return, at minimum:
 
-- User asks to terminate/stop/reboot by name only.
-- Instance appears managed by Terraform, instance pool, autoscaling, or another controller.
-- No boot volume backup, custom image, or rollback path exists.
-- Public IP plus broad ingress is present but ignored.
-- Instance principal has broad tenancy access.
-- Troubleshooting jumps to reboot before checking metrics, events, serial console, VNICs, and route/security path.
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.