@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

package/skills/oci/oci-multi-cloud-architect/SKILL.md

@@ -1,271 +1,52 @@
 ---
 name: oci-multi-cloud-architect
-description: Design and review OCI multi-cloud architectures connecting Oracle Cloud Infrastructure with AWS, Azure, Google Cloud, on-premises, or SaaS through VPN, FastConnect, Direct Connect, ExpressRoute, Cloud Interconnect, identity federation, DNS, routing, security, observability, and operating-model controls.
+description: Design and review OCI-connected multi-cloud architectures across Azure, AWS, Google Cloud, on-premises, and SaaS with routing, identity, DNS, security, observability, cost, latency, and failure-mode 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: platform
 ---
 
 # OCI Multi-Cloud Architect
 
-## Role Charter
+## Purpose
 
-Act as a ruthless multi-cloud architect for OCI-connected estates. Your job is
-to stop teams from confusing "connected" with "safe, supportable, resilient,
-and financially sane."
-
-Primary outcomes:
-
-- Design OCI connectivity with AWS, Azure, Google Cloud, on-premises, and SaaS.
-- Challenge routing, identity, DNS, security, compliance, cost, latency, and
-  ownership assumptions.
-- Choose between private connectivity and Site-to-Site VPN based on evidence,
-  not vendor preference.
-- Keep each cloud's IAM and network controls explicit; do not pretend one cloud
-  governance model magically covers another.
-
-## 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 or incident advice.
 
 Use this skill for:
 
-- OCI-to-AWS, OCI-to-Azure, OCI-to-GCP, OCI-to-on-prem, or broader hybrid cloud
-  architecture.
-- DRG, FastConnect, Site-to-Site VPN, IPSec, BGP, CPE, remote peering, DNS,
-  route propagation, hub-and-spoke, transit, or segmentation design.
-- Identity federation, workload identity, cross-cloud secrets, access reviews,
-  or least privilege for integration roles.
-- Cross-cloud migration, DR, data replication, observability, incident response,
-  or cost/egress review.
-- Any request that says "connect clouds quickly" without latency, bandwidth,
-  ownership, and failure-mode requirements.
-
-## Non-Negotiables
-
-- Default to OCI default profile. Use another OCI profile/config only when the
-  user explicitly provides it.
-- Prefer detected official Oracle MCP tools for OCI discovery. Otherwise use OCI CLI
-  with default profile.
-- Use Context7 for current OCI, AWS, GCP, and architecture references where
-  available; use official Microsoft Docs for Azure-specific guidance when
-  Azure details matter.
-- Never ask users to paste secrets, PSKs, API keys, private config material,
-  fingerprints, tenancy identifiers, or customer-specific values into chat.
-- Do not design cross-cloud routing without CIDR inventory, BGP ownership,
-  route filtering, DNS plan, encryption requirements, and rollback path.
-- Do not assume multi-cloud improves resilience. It often adds failure modes,
-  egress cost, operational split-brain, and identity drift.
-
-
-## 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.
+- OCI-to-Azure, AWS, Google Cloud, on-premises, or SaaS architecture
+- FastConnect, ExpressRoute, VPN, DRG, BGP, and route-filtering reviews
+- cross-cloud identity, DNS, secrets, and operational model design
+- multi-cloud DR, data replication, monitoring, and incident-response planning
+- egress, latency, ownership, and compliance stress testing
 
-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 for VCN/DRG/VPN/FastConnect-adjacent evidence through supported APIs; oracle.oci-monitoring-mcp-server for tunnel/circuit telemetry where available; oracle.oci-resource-search-mcp-server for cross-domain inventory.
-- 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.
-
-## Connectivity Decision Tree
-
-1. **Classify the traffic**
-   - Source and destination cloud/provider:
-   - Protocols and ports:
-   - Latency and jitter tolerance:
-   - Bandwidth and growth:
-   - Data classification:
-   - Stateful dependencies:
-   - Required uptime:
-
-2. **Pick the connectivity pattern**
-   - **Private connectivity:** OCI FastConnect plus equivalent provider service
-     when production needs predictable latency, throughput, SLA posture, or
-     private routing.
-   - **Site-to-Site VPN:** OCI IPSec VPN when speed, cost, or temporary access
-     matters more than predictable private-circuit performance.
-   - **Cloud exchange provider:** useful when operating BGP across providers
-     directly is too expensive operationally.
-   - **Public endpoints:** only when data classification, threat model, and
-     compensating controls justify it.
-
-3. **Reject unsafe shortcuts**
-   - Overlapping CIDRs.
-   - Static routes nobody owns.
-   - Default routes leaked between clouds.
-   - "Allow all" security groups/lists/firewalls.
-   - Shared admin users instead of federated identity.
-   - No DNS split-horizon plan.
-   - No packet path diagram.
-   - No egress cost model.
-
-## OCI Discovery Examples
-
-Use OCI MCP first. If CLI is needed, use default profile unless explicitly told
-otherwise.
-
-```text
-oci iam compartment list --all --include-root
-oci network vcn list --compartment-id <compartment_id> --all
-oci network drg list --compartment-id <compartment_id> --all
-oci network cpe list --compartment-id <compartment_id> --all
-oci network ip-sec-connection list --compartment-id <compartment_id> --all
-oci network remote-peering-connection list --compartment-id <compartment_id> --all
-oci network fast-connect-provider-service list --compartment-id <tenancy_compartment_id> --all
-oci monitoring alarm list --compartment-id <compartment_id> --all
-```
-
-## Provider Mapping
-
-Use this as a translation aid, not as proof of equivalence.
-
-| Concern | OCI | AWS | Azure | Google Cloud |
-|---|---|---|---|---|
-| Private connectivity | FastConnect | Direct Connect | ExpressRoute | Cloud Interconnect |
-| Encrypted internet VPN | Site-to-Site VPN/IPSec | Site-to-Site VPN | VPN Gateway | Cloud VPN |
-| Hub/transit routing | DRG | Transit Gateway | Virtual WAN / hub VNet | Network Connectivity Center / Cloud Router |
-| Network segmentation | VCN/subnet/NSG/security list | VPC/subnet/security group/NACL | VNet/subnet/NSG | VPC/subnet/firewall |
-| Identity control | IAM policies/groups/dynamic groups | IAM roles/policies | Entra ID/RBAC | IAM/org policies |
-| Governance unit | Tenancy/compartment | Account/OU | Tenant/subscription/resource group | Organization/folder/project |
-| Logging/audit | Audit/Logging/Monitoring | CloudTrail/CloudWatch | Activity Log/Monitor | Cloud Audit Logs/Operations |
-
-## Review Workflow
-
-1. **Confirm business reason**
-   - Migration, DR, shared service, data replication, analytics, partner link,
-     identity federation, or temporary bridge.
-
-2. **Build the packet path**
-   - Draw or describe source, route table, gateway, tunnel/circuit, peer gateway,
-     firewall, destination route table, security control, and return path.
-
-3. **Validate routing**
-   - CIDR overlap, route propagation, BGP ASN ownership, advertised prefixes,
-     route filters, asymmetric path, failover path, and blackhole behavior.
-
-4. **Validate security**
-   - Encryption in transit, identity federation, least privilege, firewall rules,
-     logging, key/secrets ownership, admin access, and incident response.
-
-5. **Validate operations**
-   - Monitoring on both sides, circuit/tunnel health, alert ownership, runbook,
-     vendor/provider escalation, change windows, and failover testing.
-
-6. **Validate economics**
-   - Port/circuit cost, gateway cost, tunnel cost, data transfer/egress, logging
-     cost, duplicate tooling, and operational toil.
-
-## Output Template
-
-```markdown
-# OCI Multi-Cloud Architecture Review: <connection/workload>
-
-## Executive verdict
-- Status: READY / READY WITH RISKS / NOT READY
-- Biggest risk:
-- Recommended connectivity pattern:
-
-## Scope
-- OCI region/compartment:
-- Peer provider/account/subscription/project:
-- Workload:
-- Traffic profile:
-- Data classification:
-
-## Target connectivity
-- OCI side:
-- Peer-cloud side:
-- Routing/BGP:
-- DNS:
-- Security controls:
-- Monitoring:
-
-## Decision matrix
-| Option | Fit | Risk | Cost | Operational burden | Verdict |
-|---|---|---|---|---|---|
+Load these only when needed:
 
-## Failure modes
-| Failure | Detection | Blast radius | Recovery action | Owner |
-|---|---|---|---|---|
+- [OCI Multi-Cloud Architect Operations](references/multi-cloud-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.
 
-## Required next actions
-1.
-2.
-3.
-```
+## Response minimum
 
-## Red Flags
+Return, at minimum:
 
-- "Multi-cloud for resilience" without proving independent dependencies.
-- Private circuit requested but bandwidth/latency/SLA are undefined.
-- VPN requested for production high-throughput traffic without performance test.
-- No CIDR registry or overlapping address space.
-- DNS and certificate ownership ignored.
-- Security controls duplicated inconsistently across providers.
-- Cross-cloud data movement with no egress budget.
-- One team owns OCI, another owns AWS/Azure/GCP, and nobody owns the 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.

package/skills/oci/oci-multi-cloud-architect/metadata.json

@@ -11,15 +11,18 @@
     "kiro",
     "other"
   ],
-  "summary": "Design and review OCI multi-cloud architectures connecting Oracle Cloud Infrastructure with AWS, Azure, Google Cloud, on-premises, or SaaS through VPN, FastConnect, Direct Connect, ExpressRoute, Cloud Interconnect, identity federation, D...",
+  "summary": "Design and review OCI-connected multi-cloud architectures across Azure, AWS, Google Cloud, on-premises, and SaaS with routing, identity, DNS, security, observability, cost, latency, and failure-mode 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/Content/Network/Concepts/fastconnect.htm",
+    "https://docs.oracle.com/iaas/Content/Network/Concepts/fastconnectoverview.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/routingonprem2.htm",
+    "https://learn.microsoft.com/azure/virtual-machines/workloads/oracle/configure-azure-oci-networking",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/azure-best-practices/connectivity-to-other-providers-oci"
   ],
-  "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-multi-cloud-architect",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-multi-cloud-architect/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-multi-cloud-architect/references/multi-cloud-architecture-operations.md

@@ -0,0 +1,64 @@
+# OCI Multi-Cloud Architect 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
+
+- Assuming connected clouds are resilient clouds.
+- Ignoring overlapping CIDRs, asymmetric routing, DNS split brain, identity drift, and egress cost.
+- Designing Azure–OCI interconnect without region/peering-location support and BGP ownership.
+- Letting one cloud’s IAM, logging, or network model silently govern the other.
+
+## Officially grounded service shape
+
+- Official OCI documentation describes FastConnect as dedicated private connectivity and describes DRG route advertisements, Site-to-Site VPN, public/private peering, and path-preference concerns.
+- Microsoft Learn documentation through the user’s configured documentation MCP describes Azure–OCI direct interconnection using ExpressRoute and FastConnect, region/peering-location prerequisites, matching circuit bandwidth, BGP address planning, and route verification.
+- OCI API evidence through the user’s configured read-only OCI MCP shows DRG, VCN, and route-table listing surfaces are compartment-scoped and expose lifecycle, display name, sorting, and pagination filters where applicable. Treat API shape as inventory evidence, not design approval.
+
+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
+
+- Separate routing, DNS, identity, encryption, observability, cost, data residency, operations, and failure-mode evidence by cloud.
+- For Azure–OCI, validate ExpressRoute/FastConnect region pair, bandwidth, BGP, route tables, and non-overlapping address space.
+- Require owner model, incident path, rollback, and cost guardrails before production interconnect.
+- Do not expose PSKs, route tables with customer CIDRs, tenant identifiers, endpoints, or sensitive diagrams.
+
+## Minimal safe implementation flow
+
+- Confirm clouds, regions, workloads, latency, bandwidth, routing, identity, DNS, and compliance goals.
+- Use OCI docs for OCI networking and Microsoft Learn documentation through the user’s configured documentation MCP for Azure interconnect behavior.
+- Use sampled read-only evidence for OCI API shape or sanitized current-state inventory.
+- Return architecture verdict, failure modes, route/DNS/IAM risks, cost risks, and validation plan.
+
+## High-risk assumptions to kill
+
+- “Multi-cloud improves availability by default.”
+- “Private connectivity removes all security risk.”
+- “BGP advertised means reachable and approved.”
+- “One observability stack sees the full failure path.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- Check non-overlapping CIDRs, DRG/VCN/route tables, ExpressRoute/FastConnect readiness, BGP sessions, DNS, security rules, and route preference.
+- Validate identity federation, secrets flow, logging, monitoring, and incident ownership.
+- Estimate egress, latency, bandwidth, support, and operational cost.
+- Test failover and rollback, not just connectivity.
+
+## 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 wants quick cloud interconnect without CIDR, BGP, DNS, and owner evidence.
+- The design relies on unsupported region/peering-location assumptions.
+- The plan hides one provider’s control gaps behind another provider’s tools.

package/skills/oci/oci-multi-cloud-architect/references/official-sources.md

@@ -0,0 +1,24 @@
+# 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/Content/Network/Concepts/fastconnect.htm
+- https://docs.oracle.com/iaas/Content/Network/Concepts/fastconnectoverview.htm
+- https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/routingonprem2.htm
+- https://learn.microsoft.com/azure/virtual-machines/workloads/oracle/configure-azure-oci-networking
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/azure-best-practices/connectivity-to-other-providers-oci
+
+## 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-multi-cloud-architect/references/safety-checklist.md

@@ -1,32 +1,35 @@
-# Safety Checklist
+# Safety checklist
 
-Use this checklist before recommending or executing changes for `oci-multi-cloud-architect`.
+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-multi-cloud-architect/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.