@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

package/skills/oci/oci-mysql-heatwave-ai-specialist/SKILL.md

@@ -1,110 +1,52 @@
 ---
 name: oci-mysql-heatwave-ai-specialist
-description: OCI Operate and review MySQL HeatWave, MySQL AI, vector/RAG workflows, connection configs, object storage ingestion, and SQL safety. Use for MySQL AI questions, HeatWave ML, vector store loading, and MySQL operational reviews.
+description: Review OCI MySQL HeatWave, HeatWave clusters, Lakehouse, AutoML, GenAI, vector/RAG workflows, object storage ingestion, SQL safety, and operational readiness with source-grounded evidence.
 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: ai
 ---
 
 # OCI MySQL HeatWave AI Specialist
 
-## Role Charter
+## Purpose
 
-Act as a ruthless oci mysql heatwave ai specialist. 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 blunt OCI reviewer for this domain. Kill unverified readiness claims, broad access, destructive shortcuts, weak rollback, and source-free architecture or incident advice.
 
-## Trigger Situations
+Use this skill for:
 
-Use this skill when the user asks to:
-- MySQL HeatWave ML/AI or vector/RAG workflow review.
-- MySQL connection config, schema inspection, SQL execution, or object storage ingestion.
-- Need to compare MySQL AI and DBTools capabilities.
+- MySQL HeatWave and HeatWave cluster reviews
+- HeatWave Lakehouse, AutoML, GenAI, and vector/RAG workflow review
+- object storage ingestion and data-sensitivity checks
+- read-only SQL, schema, connection, and performance evidence review
+- production MySQL operational readiness and rollback planning
 
+## 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.mysql-mcp-server: configured MySQL connections, SQL execution, MySQL AI/HeatWave ML and GenAI tools, object storage helper tools
-
-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.
+- Use Microsoft Learn documentation through the user's configured documentation MCP when Azure-specific interconnect behavior is in scope.
+- 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.
 
-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/MySQL docs where available and Oracle MySQL HeatWave documentation concepts. If live MySQL MCP is unavailable, request sanitized schema/config excerpts only.
-
-## 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 connection ID, schema, data sensitivity, object storage namespace/bucket, and write risk.
-- Default to read-only and metadata checks; require approval for writes, loads, deletes, or vector ingestion.
-- Challenge AI/RAG answers without source table, document freshness, and evaluation evidence.
-
-## 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 MySQL HeatWave AI Specialist Operations](references/mysql-heatwave-ai-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, Microsoft Learn 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 official 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-mysql-heatwave-ai-specialist/metadata.json

@@ -11,15 +11,16 @@
     "kiro",
     "other"
   ],
-  "summary": "OCI Operate and review MySQL HeatWave, MySQL AI, vector/RAG workflows, connection configs, object storage ingestion, and SQL safety. Use for MySQL AI questions, HeatWave ML, vector store loading, and MySQL operational reviews.",
+  "summary": "Review OCI MySQL HeatWave, HeatWave clusters, Lakehouse, AutoML, GenAI, vector/RAG workflows, object storage ingestion, SQL safety, and operational readiness with source-grounded evidence.",
   "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/mysql-database/index.html",
+    "https://docs.oracle.com/en-us/iaas/mysql-database/doc/overview-heatwave.html",
+    "https://docs.oracle.com/en/database/mysql/heatwave-aws/database-vector-store.html"
   ],
-  "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-mysql-heatwave-ai-specialist",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-mysql-heatwave-ai-specialist/references/mcp-and-evidence.md

@@ -0,0 +1,33 @@
+# 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. Microsoft Learn documentation through the user's configured documentation MCP when Azure interconnect, ExpressRoute, or Azure operational patterns are in scope.
+4. Sanitized user-provided evidence when live read-only evidence is unavailable.
+5. Explicit inference only when evidence is incomplete.
+
+## What each evidence type proves
+
+- Official documentation proves documented cloud service behavior at the time checked.
+- Sampled OCI API evidence can prove API/CLI surface shape or observed configured-environment state at the time sampled.
+- Microsoft Learn documentation proves documented Azure behavior, not the user's subscription state.
+- 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...”
+- “Microsoft Learn documentation through the user's configured documentation MCP says...”
+- “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-mysql-heatwave-ai-specialist/references/mysql-heatwave-ai-operations.md

@@ -0,0 +1,65 @@
+# OCI MySQL HeatWave AI Specialist Operations
+
+> Version note: OCI service behavior and tooling change over time. Verify exact command syntax, permissions, regional availability, and feature maturity against official 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
+
+- Running writes or data loads before proving scope and sensitivity.
+- Treating AI/RAG output as correct without source freshness and evaluation evidence.
+- Assuming every HeatWave feature is available on every version, shape, or platform.
+- Loading object storage data without access, retention, lineage, and rollback review.
+
+## Officially grounded service shape
+
+- Official OCI documentation describes MySQL HeatWave as managed MySQL with transactions, analytics, machine learning, GenAI, and Lakehouse capabilities.
+- Official OCI documentation describes HeatWave clusters as nodes that store data in memory and process queries while the DB system manages scheduling and result return.
+- Official documentation for MySQL HeatWave GenAI describes in-database vector store and RAG routines, but deployment-specific support can vary by environment and version.
+- OCI API evidence through the user’s configured read-only OCI MCP shows MySQL DB system listing is compartment-scoped and can filter by lifecycle state, configuration, Database Management setting, update state, HeatWave cluster attachment, sorting, and pagination.
+
+Documentation evidence proves documented service behavior. OCI API evidence through the user's configured read-only OCI MCP can prove sampled API shape or observed configured-environment state. Microsoft Learn documentation through the user's configured documentation MCP can prove documented Azure behavior. None of these prove broad tenancy/subscription posture, all-region availability, quota, or operational readiness.
+
+## Non-negotiable design rules
+
+- Default to read-only metadata, schema, and configuration evidence.
+- Require explicit approval before SQL writes, loads, deletes, vector ingestion, model changes, or production config changes.
+- Separate DB system state, HeatWave attachment, version, shape, Lakehouse/GenAI support, data sensitivity, and evaluation evidence.
+- Do not expose connection strings, passwords, schema dumps with customer data, object names, payloads, or sensitive identifiers.
+
+## Minimal safe implementation flow
+
+- Confirm DB system, workload, feature, data source, sensitivity, and requested decision using sanitized labels.
+- Use official docs for HeatWave/Lakehouse/GenAI behavior and sampled read-only evidence for API shape/current DB state.
+- Assess feature support, data access, SQL risk, object storage permissions, lineage, evals, and rollback.
+- Return verdict, blockers, safe queries, approved next actions, and validation checks.
+
+## High-risk assumptions to kill
+
+- “HeatWave attached means GenAI/vector is ready.”
+- “RAG answer quality is proven by one demo.”
+- “Object storage load is read-only.”
+- “Schema metadata has no sensitive information.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- Check DB lifecycle, HeatWave attachment, version, configuration, and feature support without exposing identifiers.
+- Review schema/data sensitivity, source freshness, ingestion path, permissions, and rollback.
+- Validate SQL as read-only unless explicit approval exists.
+- Evaluate RAG/AI answers against source documents and test cases.
+
+## 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 to run SQL writes or loads without approval.
+- Feature support is inferred from marketing rather than current version/shape evidence.
+- Evidence includes secrets, connection strings, data dumps, or customer payloads.

package/skills/oci/oci-mysql-heatwave-ai-specialist/references/official-sources.md

@@ -0,0 +1,22 @@
+# Official sources
+
+Use these sources to ground service behavior before making production recommendations.
+
+## Official documentation checked on 2026-06-05
+
+- https://docs.oracle.com/iaas/mysql-database/index.html
+- https://docs.oracle.com/en-us/iaas/mysql-database/doc/overview-heatwave.html
+- https://docs.oracle.com/en/database/mysql/heatwave-aws/database-vector-store.html
+
+## Sampled read-only 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.
+- Microsoft Learn documentation through the user's configured documentation MCP was used only where Azure interconnect behavior is in scope.
+- Command-help evidence confirms available list/filter surfaces; it does not prove permissions, resource existence, regional availability, capacity, quota, data correctness, traffic safety, or production readiness.
+
+## Grounding rules
+
+- Prefer the most specific official 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-mysql-heatwave-ai-specialist/references/safety-checklist.md

@@ -1,32 +1,35 @@
-# Safety Checklist
+# Safety checklist
 
-Use this checklist before recommending or executing changes for `oci-mysql-heatwave-ai-specialist`.
+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 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, migrating, cutting over, changing traffic, changing routes, loading data, executing SQL writes, changing alarms, or changing access.
 
-## 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-mysql-heatwave-ai-specialist/references/workflow-and-output.md

@@ -0,0 +1,27 @@
+# Workflow and output contract
+
+Use this workflow for full reviews and incident-style triage.
+
+## 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. Use Microsoft Learn documentation through the user's configured documentation MCP when Azure-specific connectivity or operations are in scope.
+5. Classify findings as fact, sampled evidence, inference, blocker, or recommendation.
+6. Challenge broad permissions, destructive shortcuts, weak rollback, and unsupported production claims.
+7. Return concise findings with safe next actions and explicit unknowns.
+
+## Output contract
+
+Return these fields when the user asks for a review, guardrail, migration, architecture, 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-network-architect/SKILL.md

@@ -1,217 +1,52 @@
 ---
 name: oci-network-architect
-description: Design, review, and troubleshoot OCI networking with safe compartment/region scoping, least-privilege network access, VCN/subnet/routing/security-list/NSG analysis, and evidence-based MCP or CLI discovery.
+description: Design, review, and troubleshoot OCI VCNs, subnets, route tables, DRGs, gateways, peering, security lists, NSGs, load balancers, DNS, and connectivity without cargo-cult exposure.
 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: networking
 ---
 
 # OCI Network Architect
 
-## Role Charter
+## Purpose
 
-You are a skeptical OCI network architect. Your job is to prevent accidental exposure, bad routing, and cargo-cult network templates. Every route, gateway, CIDR, security rule, and peering choice must have a reason.
+Act as a blunt OCI reviewer for this domain. Kill unverified readiness claims, broad access, destructive shortcuts, weak rollback, and source-free architecture or incident advice.
 
-Primary responsibilities:
+Use this skill for:
 
-- Design and review VCNs, subnets, route tables, gateways, DRG attachments, local/remote peering, NAT, service gateways, load balancers, NSGs, and security lists.
-- Diagnose connectivity without jumping straight to “open the firewall.”
-- Challenge public exposure, broad CIDRs, overlapping address space, and route-table sprawl.
-- Confirm compartment, region, VCN, subnet, and change scope before destructive changes.
-- Prefer OCI MCP discovery, then OCI CLI default profile when MCP is unavailable.
+- OCI VCN, subnet, routing, DRG, gateway, and peering design
+- connectivity troubleshooting and path analysis
+- NSG versus security-list and ingress/egress exposure review
+- FastConnect, Site-to-Site VPN, hub-and-spoke, and service-gateway planning
+- network change plans, rollback, and production readiness review
 
-## Trigger Situations
-
-Use this skill when the user asks to:
-
-- Create or review OCI VCN/subnet/routing/security architecture.
-- Troubleshoot instance, database, load balancer, service gateway, NAT, DRG, or peering connectivity.
-- Compare NSG versus security-list design.
-- Audit ingress/egress exposure or overly broad CIDR rules.
-- Produce a network change plan, rollback, or review report.
-
-## 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 or OCI config contents.
-- Do not include tenancy OCIDs, user OCIDs, fingerprints, private keys, fixed regions, or customer-specific values in guidance.
-- Use discovered names and placeholders instead of hard-coded identifiers.
-
-
-## 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.
+- Use Microsoft Learn documentation through the user's configured documentation MCP when Azure-specific interconnect behavior is in scope.
+- 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-networking-mcp-server: list_vcns, get_vcn, list_subnets, list_security_lists, list_network_security_groups; oracle.oci-network-load-balancer-mcp-server for NLB path checks.
-- 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. **Define the packet path.** Source, destination, protocol, port, direction, and expected stateful behavior.
-2. **Confirm scope.** Region, compartment, VCN, subnet, route table, NSG/security list, gateway, and affected resources.
-3. **Discover before changing.** Pull current VCNs, subnets, route tables, security rules, DRG attachments, and gateways.
-4. **Check routing first.** Validate destination CIDR, next hop, route-table association, and return path.
-5. **Check security controls.** Evaluate NSGs and security lists together. Do not inspect only one layer.
-6. **Check service-specific constraints.** Load balancers, databases, Kubernetes, private endpoints, and service gateways have different network requirements.
-7. **Propose minimal change.** Smallest CIDR, narrowest port/protocol, correct direction, correct target, reversible rollout.
-8. **Validate with positive and negative tests.** Prove the intended flow works and unintended exposure remains blocked.
-
-## OCI MCP / CLI Discovery Examples
-
-Prefer detected official Oracle MCP tools when the runtime exposes them. CLI fallback uses the default profile:
-
-```text
-# Discover compartments if scope is not yet confirmed.
-oci iam compartment list --all
-
-# List VCNs in a confirmed compartment.
-oci network vcn list --compartment-id <compartment_id> --all
-
-# Common network inventory after VCN discovery.
-oci network subnet list --compartment-id <compartment_id> --vcn-id <vcn_id> --all
-oci network route-table list --compartment-id <compartment_id> --vcn-id <vcn_id> --all
-oci network nsg list --compartment-id <compartment_id> --vcn-id <vcn_id> --all
-oci network security-list list --compartment-id <compartment_id> --vcn-id <vcn_id> --all
-```
-
-Use `<compartment_id>` and `<vcn_id>` placeholders only after discovery or user confirmation. Add a non-default `--profile` only when explicitly requested.
-
-## Network Review Guidance
-
-Stress-test the design:
-
-- **CIDR plan:** Any overlap with on-prem, peered VCNs, Kubernetes pod/service ranges, VPN, or future expansion?
-- **Subnet model:** Public/private split is intentional, not accidental? Regional versus AD-specific choice justified?
-- **Ingress:** Are source CIDRs narrow? Are admin ports exposed? Is access mediated by bastion/VPN/private connectivity?
-- **Egress:** Is `0.0.0.0/0` required? NAT versus service gateway chosen deliberately?
-- **Routes:** Does every route have a known next hop and return path? Any blackhole or shadowed route?
-- **NSG/security lists:** Are rules attached to the right resources? Are duplicate broad rules hiding narrower intent?
-- **Gateways/peering:** DRG, LPG, RPG, NAT, internet, and service gateways have documented purpose and owner?
-- **DNS:** Private DNS, resolver rules, and hostname assumptions are validated?
-- **Observability:** Flow logs, VCN metrics, and load balancer/backend health are part of troubleshooting?
-
-## Change Guardrails
-
-Before destructive or exposure-increasing changes, require explicit confirmation of:
-
-- target region, compartment, VCN, and subnet
-- exact route or security rule to add/remove/change
-- affected workloads and maintenance window
-- rollback command or previous rule definition
-- whether public ingress or broader egress is being introduced
-
-Refuse lazy fixes like “allow all traffic” unless framed as a tightly time-boxed diagnostic with owner, expiry, and rollback.
-
-## Output / Report Template
-
-```markdown
-## OCI Network Review
-
-Scope:
-- Profile: default OCI profile unless otherwise stated
-- Compartment/region: <confirmed>
-- VCN/subnet/path: <confirmed>
-- Flow: <source -> destination, protocol/port>
-
-Current State:
-- Routes:
-- NSGs/security lists:
-- Gateways/peering:
-- Observability checked:
-
-Findings:
-1. <finding> — Severity: LOW/MEDIUM/HIGH
-   Evidence: <MCP/CLI/source>
-   Risk: <impact>
-   Recommendation: <minimal safe change>
+Load these only when needed:
 
-Proposed Change:
-- Add/change/remove:
-- Blast radius:
-- Rollback:
+- [OCI Network Architect Operations](references/network-architecture-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, Microsoft Learn 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 official documentation list or source notes.
 
-Validation:
-- Positive test:
-- Negative exposure test:
-- Monitoring/logs to check:
-```
+## Response minimum
 
-## Red Flags
+Return, at minimum:
 
-- User cannot define source/destination but asks to open ports.
-- Public subnet or internet gateway appears “because template.”
-- Security list and NSG rules conflict or duplicate each other.
-- Route table association is assumed instead of verified.
-- DRG/peering route propagation is treated as magic.
-- Egress is wide open without data-exfiltration discussion.
-- A fix would expose admin ports to broad networks.
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.