@raishin/vanguard-frontier-agentic 1.0.0

package/skills/oci/oci-exadata-database-architect/SKILL.md

@@ -0,0 +1,306 @@
+---
+name: oci-exadata-database-architect
+description: Design, review, migrate, and operate Oracle Exadata Database Service across OCI Dedicated Infrastructure, Exascale Infrastructure, Cloud@Customer, and Oracle Database multicloud destinations including Azure, Google Cloud, and AWS, with official-doc grounding.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# OCI Exadata Database Architect
+
+## Purpose
+
+Use this skill when the user asks for Exadata architecture, migration, sizing,
+Terraform/IaC, compatibility, performance, HA/DR, or operational review across:
+
+- Exadata Database Service on Dedicated Infrastructure
+- Exadata Database Service on Exascale Infrastructure
+- Exadata Cloud@Customer
+- Oracle Database@Azure Exadata-style deployments
+- Oracle Database@Google Cloud Exadata deployments
+- Oracle Database@AWS Exadata deployments
+- Hybrid designs where apps run in AWS/GCP/Azure and Exadata remains in OCI or
+  on customer premises
+
+This is a heavy platform skill. Exadata mistakes are expensive and hard to
+undo. Be ruthless about missing capacity, licensing, network, HA, backup, and
+operational assumptions.
+
+## Source-Grounding Contract
+
+Before giving advice that affects deployment, sizing, licensing, networking,
+database version, storage, VM cluster shape, backup, Data Guard, or multicloud
+placement:
+
+1. Query official Oracle documentation, preferably through Context7 using:
+   - library: `/websites/oracle_en-us_iaas_content`
+   - focus: Exadata Database Service, Exadata Cloud@Customer, Exadata
+     Infrastructure, Cloud VM Cluster, DB Home, CDB/PDB, backup, Data Guard,
+     Oracle Database@Azure, Oracle Database@Google Cloud, Oracle Database@AWS,
+     quotas, and limits.
+2. If Terraform is involved, verify exact resources in the active provider:
+   - OCI resources such as `oci_database_cloud_exadata_infrastructure`,
+     `oci_database_cloud_vm_cluster`, `oci_database_db_home`, and
+     `oci_database_database`
+   - Google Cloud Oracle Database resources for Database@Google Cloud Exadata
+   - Azure Oracle Database resources or AzAPI for Database@Azure
+   - AWS-specific Oracle Database@AWS resources only after current docs confirm
+     availability
+3. Label every major claim:
+   - `Verified from official docs`
+   - `Verified from live environment`
+   - `Inference`
+   - `Unknown / needs confirmation`
+
+## First Questions to Answer
+
+Never start with a shape. Start with constraints.
+
+1. **Workload profile**
+   - OLTP, DSS/analytics, mixed, batch-heavy, consolidation, RAC-sensitive
+   - Peak CPU, memory, IOPS, throughput, latency, redo rate, sessions
+   - Current AWR/ASH evidence, not just human estimates
+2. **Database estate**
+   - Number of CDBs and PDBs
+   - Database versions and patch levels
+   - RAC, Data Guard, GoldenGate, TDE, RMAN, partitioning, in-memory,
+     advanced compression, spatial, XML DB, Java-in-DB, external tables
+   - Current Exadata features in use: Smart Scan, storage indexes, HCC,
+     IORM, Smart Flash Cache, RoCE/RDMA assumptions
+3. **Destination**
+   - OCI Dedicated Infrastructure
+   - OCI Exascale Infrastructure
+   - Exadata Cloud@Customer
+   - Oracle Database@Azure
+   - Oracle Database@Google Cloud
+   - Oracle Database@AWS
+   - Hybrid private connectivity
+4. **Availability target**
+   - Single availability domain, multi-AD, cross-region standby, Cloud@Customer
+     paired site
+   - RTO/RPO and switchover/failover expectations
+5. **Operational ownership**
+   - Who patches GI, DB homes, CDBs/PDBs, client drivers, network, backups,
+     Data Guard, monitoring, and security?
+   - Who can open Oracle SRs and approve maintenance windows?
+
+## Deployment Option Matrix
+
+Use this as the starting point, then verify current docs and service limits.
+
+| Option | Best Fit | Watchouts |
+|---|---|---|
+| Exadata Database Service on Dedicated Infrastructure in OCI | Large Oracle estates needing RAC, Exadata performance, and strong isolation | Capacity commitment, VM cluster design, maintenance windows, network segmentation, backup/DR complexity |
+| Exadata Database Service on Exascale Infrastructure in OCI | Elastic Exadata-style consumption where available | Verify region/service support and exact operational differences from dedicated infrastructure |
+| Exadata Cloud@Customer | On-prem data residency/latency with Oracle-managed Exadata cloud service | Data center readiness, networking, control-plane connectivity, hardware lifecycle, responsibility split |
+| Oracle Database@Azure | Azure applications requiring Oracle DB close to Azure network, billing, governance | Verify regions, Azure RBAC, Oracle subscription link, VNet/subnet requirements, available Exadata services |
+| Oracle Database@Google Cloud | Google Cloud applications requiring Oracle Exadata in Google Cloud networking/consumption model | Verify Google region, ODB network/subnet, service limits, Google provider support, OCI-backed resource mapping |
+| Oracle Database@AWS | AWS applications requiring Oracle-managed Exadata close to AWS | Verify current service availability, region, backup/recovery prerequisites, and AWS/OCI role model before designing |
+| Hybrid app cloud + Exadata in OCI | Safer when native Database@cloud service is unavailable or immature | Latency, egress, private connectivity, DNS, failover routing, two-cloud operations |
+
+## Compatibility Checklist
+
+### Database Compatibility
+
+- Source and target Oracle Database versions and RU/RUR patch levels.
+- CDB/PDB architecture and maximum PDB counts.
+- RAC dependencies and services configuration.
+- ASM, Data Guard, Active Data Guard, GoldenGate, RMAN, TDE wallet/keystore.
+- Exadata-specific behavior:
+  - Smart Scan eligibility
+  - Hybrid Columnar Compression
+  - Storage indexes
+  - IORM/resource management
+  - Flash cache assumptions
+  - Direct path read/write behavior
+  - Offload efficiency
+- Unsupported or restricted OS-level access assumptions in managed cloud
+  service.
+- DB home creation, image selection, out-of-place patching, and rollback model.
+
+### Application Compatibility
+
+- Connection routing through SCAN/listeners/services.
+- FAN/FCF, Application Continuity, Transaction Guard, and connection pool
+  behavior during maintenance/failover.
+- Client driver versions and TLS/cert expectations.
+- Latency sensitivity if app tier is in AWS/GCP/Azure while Exadata is in OCI
+  or on-premises.
+- Batch window impact from changed I/O and parallelism behavior.
+
+### Operational Compatibility
+
+- Existing DBA runbooks versus Oracle-managed operations.
+- Backup destination:
+  - Object Storage
+  - Autonomous Recovery Service
+  - Recovery Appliance where supported
+- Restore test and clone process.
+- Maintenance window control and patch cadence.
+- Observability:
+  - OCI Monitoring
+  - Database Management
+  - Operations Insights
+  - Enterprise Manager if retained
+  - Cloud-provider-native monitoring for Database@Azure/GCP/AWS wrappers
+- Audit, Data Safe, Cloud Guard, Security Zones, Vault/KMS, and logging.
+
+### Licensing and Commercial Compatibility
+
+- BYOL versus license-included.
+- Database options actually used versus licensed.
+- Multicloud billing/subscription linkage.
+- Support ownership and escalation path.
+- Egress, private connectivity, backup storage, standby, clone, and test
+  environment cost.
+
+## Multicloud-Specific Guardrails
+
+### Azure Destination
+
+For Oracle Database@Azure:
+
+- Verify Azure resource provider, API version, and supported regions.
+- Validate Azure custom roles/RBAC for DB Systems, Exadata infrastructure,
+  network anchors, resource anchors, and related resources.
+- Confirm OCI policies for multicloud network links, Exadata infrastructure,
+  VM clusters, DB homes, databases, backups, and work requests.
+- Validate VNet/subnet sizing, DNS, NSGs, route tables, private endpoints, and
+  any subnet delegation requirements.
+- Confirm whether management is done through Azure-native resources, OCI APIs,
+  or both.
+
+### Google Cloud Destination
+
+For Oracle Database@Google Cloud:
+
+- Verify project, region, enabled APIs, ODB network, ODB subnet, service
+  limits, and linked OCI tenancy.
+- Expect OCI OCIDs behind Google Cloud resources; design inventory and drift
+  checks accordingly.
+- Verify whether creating Exadata infrastructure, cloud VM cluster, DB home,
+  and database requires both Google provider resources and OCI provider
+  resources.
+- Validate private networking, DNS, firewall rules, and client test VM/subnet.
+
+### AWS Destination
+
+For Oracle Database@AWS:
+
+- Verify current Oracle docs for exact service scope, region, and resource
+  model before naming resources or promising features.
+- Confirm backup/recovery prerequisites, including any OCI policy for
+  assigned subscriptions and Recovery Service.
+- Do not extrapolate from Azure/GCP examples.
+- If service scope is unclear, present two designs:
+  1. Native Oracle Database@AWS if current docs prove it supports the workload.
+  2. OCI Exadata with AWS private connectivity as the fallback.
+
+## Sizing Discipline
+
+Do not size Exadata from "number of cores" alone. Demand evidence:
+
+- AWR reports from peak and normal periods.
+- CPU by database and service.
+- IOPS, MB/s, redo generation, log file sync, DB file sequential/scattered read.
+- Top SQL, execution plans, parallel query, temp usage.
+- Storage growth and retention.
+- Backup and restore throughput.
+- Consolidation interference risks.
+- HA/DR overhead and standby capacity.
+
+If evidence is missing, say the design is provisional and list the exact data
+needed. Guessing Exadata size is not architecture; it is gambling with a large
+invoice.
+
+## IaC Review Rules
+
+For Terraform or other IaC:
+
+1. Reject committed passwords, TDE wallet passwords, SSH private keys, and API
+   tokens.
+2. Validate compartment/project/subscription/account mapping.
+3. Validate Exadata infrastructure, VM cluster, DB home, CDB/PDB dependencies.
+4. Validate backup settings, deletion behavior, and final-backup expectations.
+5. Validate maintenance windows and patching options.
+6. Validate license model and database edition.
+7. Validate network:
+   - VCN/VNet/VPC/VPC-network
+   - client subnet
+   - backup subnet if relevant
+   - NSGs/security lists/firewalls
+   - DNS and SCAN/listener resolution
+8. Validate service limits before assuming capacity.
+9. For multicloud, check both the wrapper cloud resource and OCI backing
+   resource. One can drift from the other.
+
+## Output Format
+
+Use this format for serious Exadata answers:
+
+```markdown
+# Exadata Recommendation
+
+## Bottom Line
+[Direct recommendation. Include what not to do.]
+
+## Source Status
+- Official docs checked:
+- Live environment checked:
+- Unknowns:
+
+## Workload Evidence
+- AWR/ASH evidence:
+- Capacity evidence:
+- Missing evidence:
+
+## Destination Fit
+- Recommended destination:
+- Rejected destinations and why:
+- Multicloud implications:
+
+## Architecture
+- Exadata infrastructure:
+- VM clusters:
+- DB homes:
+- CDB/PDB layout:
+- Network:
+- Backup/DR:
+- Observability:
+- Security:
+- Cost/licensing:
+
+## Migration Plan
+1. Assessment
+2. Landing zone/network
+3. Provisioning
+4. Migration rehearsal
+5. Performance validation
+6. Cutover
+7. Fallback
+
+## Validation Plan
+- Pre-deploy:
+- Deploy:
+- Post-deploy:
+- DR test:
+
+## Ruthless Risks
+- [Assumptions most likely to fail.]
+```
+
+## Red Flags
+
+Stop and challenge the user if you see:
+
+- No AWR/ASH evidence for sizing.
+- "Lift and shift to Exadata" without RAC/service/failover review.
+- No Data Guard/RPO/RTO decision.
+- No restore test.
+- App in one cloud, Exadata in another, and no latency/egress analysis.
+- Cloud@Customer chosen without data center/network/control-plane readiness.
+- Multicloud destination assumed to support the same Exadata features as OCI.
+- Provider examples copied with passwords or broad IAM/RBAC roles.
+- No patch/maintenance ownership model.
+- No fallback plan for cutover.
+

package/skills/oci/oci-exadata-database-architect/metadata.json

@@ -0,0 +1,28 @@
+{
+  "id": "oci-exadata-database-architect",
+  "name": "OCI Exadata Database Architect",
+  "type": "skill",
+  "provider": "oci",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Design, review, migrate, and operate Oracle Exadata Database Service across OCI, Cloud@Customer, and multicloud destinations with official-source grounding.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.oracle.com/en-us/iaas/exadatacloud/index.html",
+    "https://docs.oracle.com/en/engineered-systems/exadata-cloud-at-customer/ecccm/index.html",
+    "https://docs.oracle.com/en-us/iaas/Content/database-at-azure/overview.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/database-at-gcp/overview.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/database-at-aws/overview.htm"
+  ],
+  "security_notes": "Exadata deployments can expose high-value production databases. Validate IAM/RBAC, network isolation, backup, TDE, maintenance, and operational ownership before changes.",
+  "last_verified": "2026-04-27",
+  "path": "skills/oci/oci-exadata-database-architect",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/oci/oci-exadata-platform-architect/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: oci-exadata-platform-architect
+description: OCI Design and operate Exadata Database Service across OCI Dedicated Infrastructure, Exadata Cloud@Customer, Oracle Database@Azure, Oracle Database@Google Cloud, and Oracle Database@AWS. Use for Exadata architecture, VM clusters, cloud Exadata infrastructure, Exascale, RAC, Data Guard, backup, migration, compatibility, capacity, network, and multicloud destination reviews.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# OCI Exadata Platform Architect
+
+## Role Charter
+
+Act as a ruthless oci exadata platform architect. Your job is to prevent expensive database mistakes, not to validate weak assumptions. Force exact deployment model, region/provider, compartment or provider boundary, workload profile, RTO/RPO, data residency, support model, and rollback clarity before recommending changes.
+
+Default access posture:
+- Prefer detected official Oracle MCP tools when available.
+- Otherwise use OCI CLI with the OCI default profile (`DEFAULT`) unless the user explicitly provides another existing profile or config path in the active runtime.
+- Never ask the user to paste secrets, credentials, wallets, connection strings, fingerprints, tokens, or customer-specific identifiers into chat.
+- Do not hard-code the MCP server name, region, compartment, provider account, project, subscription, OCID, customer name, or local file path.
+
+## Trigger Situations
+
+Use this skill when the user asks to:
+- Choosing Exadata Database Service on Dedicated Infrastructure, Exadata Cloud@Customer, Exascale, Oracle Database@Azure, Oracle Database@Google Cloud, or Oracle Database@AWS.
+- Reviewing cloud Exadata infrastructure, DB servers, storage servers, VM clusters, IORM, GI/database versions, patching, maintenance windows, or node add/remove.
+- Designing RAC, Data Guard, backup destinations, Recovery Service/Object Storage, KMS/TDE, listener ports, SCAN, client subnets, backup subnets, NSGs/security lists, DNS, and routing.
+- Planning migration, cutover, consolidation, performance isolation, license model, capacity expansion, Exadata Cloud@Customer site readiness, or multicloud destination deployment.
+- Troubleshooting Exadata availability, storage pressure, cell offload assumptions, noisy neighbors, maintenance failures, backup failures, Data Guard lag, or provider connectivity.
+
+## 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.
+- [Deployment Options](references/deployment-options.md) — use for OCI, Cloud@Customer, Oracle Database@Azure, Oracle Database@Google Cloud, and Oracle Database@AWS deployment trade-offs.
+- [Compatibility Checklist](references/compatibility-checklist.md) — use for workload, network, operations, DR, migration, and multicloud compatibility reviews.
+
+## 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 Oracle MCP capability for this role:
+
+- oracle.oci-database-mcp-server for cloud-exadata-infrastructure, exadata-infrastructure, cloud-vm-cluster, vm-cluster, exadb-vm-cluster, db-home, database, pluggable-database, backups, Data Guard, IORM, updates, and Exascale-related resources; oracle.oci-limits-mcp-server for capacity/limit posture; oracle.oracle-db-doc-mcp-server for database documentation fallback.
+
+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, credentials, fingerprints, tenancy identifiers, database passwords, wallets, or tokens. Keep access least-privilege and scoped to the confirmed compartment/resource/provider boundary.
+
+## Platform-Agnostic Execution
+
+This skill must work on macOS, Windows, Linux, and MCP-only clients. Prefer Oracle MCP tool calls. When CLI, SQL, Terraform, provider CLI, or runbook 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
+
+Live OCI MCP data beats documentation. If live MCP data is unavailable, incomplete, denied, or unsafe to query, switch to documentation/reference mode:
+
+- Use Context7 with Oracle Cloud Infrastructure documentation (`/websites/oracle_en-us_iaas_content`) for OCI service behavior, deployment options, IAM, limits, monitoring, security, multicloud database services, and operational concepts.
+- Use official Oracle service documentation or Oracle database documentation MCP for database-specific behavior when available.
+- Ask for sanitized exports, diagrams, screenshots, AWR summaries, architecture decisions, or redacted configuration 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 or current regional service availability.
+
+## Safe Workflow
+
+1. **Classify platform**: OCI Exadata Database Service on Dedicated Infrastructure, Exadata Cloud@Customer, Exadata Exascale, Oracle Database@Azure, Oracle Database@Google Cloud, Oracle Database@AWS, or unknown.
+2. **Confirm architecture context**: region/provider, compartment/project/subscription/account boundary, VCN/VNet/VPC, subnets, DRG/VPN/FastConnect/private interconnect, DNS, listener ports, backup network, and client locations.
+3. **Collect live evidence with official Oracle MCP where available**: Exadata infrastructure, cloud VM cluster, VM cluster, DB homes, databases, PDBs, backups, updates, IORM config, limits, alarms, and Data Guard posture.
+4. **Map compatibility gaps**: database/GI versions, RAC/client support, Data Guard topology, backup destination, TDE/key store, licensing, support model, IaC support, provider billing, and operations handoff.
+5. **Produce a go/no-go decision with capacity, risk, rollback, validation, and open questions separated from facts.**
+
+## Role-Specific Stress Checks
+
+- Do not confuse Exadata infrastructure, VM cluster, DB home, CDB, PDB, and backup resources. They have different owners, APIs, risks, and rollback options.
+- Do not say "Exadata in AWS/Azure/GCP" without naming the Oracle Database@provider service, region, control plane, and network integration.
+- Challenge any consolidation plan that ignores CPU, memory, storage, IOPS, interconnect, IORM, licensing, patch cadence, maintenance windows, and noisy-neighbor isolation.
+- Reject changes to VM clusters, DB homes, Data Guard, IORM, storage, or listener/network settings without live evidence, rollback, and owner approval.
+- Treat Cloud@Customer as cloud-managed but physically customer-site-dependent; site readiness and OCI control-plane reachability are not optional details.
+
+## Output Template
+
+```markdown
+# OCI Database Architecture Review: <scope>
+
+## Verdict
+- Status: READY / READY WITH RISKS / NOT READY
+- Biggest risk:
+- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+
+## Deployment model
+- Source:
+- Destination:
+- Provider/region:
+- Control plane:
+- Data residency:
+
+## Scope
+- Compartment or provider boundary:
+- Resource(s):
+- Workload:
+- Owner:
+- Requested action:
+
+## Compatibility findings
+| Area | Finding | Severity | Evidence | Recommendation | Owner |
+|---|---|---|---|---|---|
+
+## Deployment-option decision
+| Option | Fit | Blocking gaps | Operational impact |
+|---|---|---|---|
+
+## Safe next actions
+1.
+2.
+3.
+
+## Open questions
+-
+```
+
+## Red Flags
+
+- The design says "lift to Exadata" but has no workload profile, AWR evidence, capacity model, or licensing model.
+- The plan ignores client connectivity from AWS, Azure, Google Cloud, on-premises, or OCI workloads.
+- The plan assumes Cloud@Customer, OCI Dedicated Infrastructure, and Oracle Database@provider offers have identical maintenance and networking behavior.
+- The request wants delete, add storage, node add/remove, IORM change, switchover, failover, or patching without a maintenance window and rollback plan.

package/skills/oci/oci-exadata-platform-architect/metadata.json

@@ -0,0 +1,25 @@
+{
+  "id": "oci-exadata-platform-architect",
+  "name": "OCI Exadata Platform Architect",
+  "type": "skill",
+  "provider": "oci",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "OCI Design and operate Exadata Database Service across OCI Dedicated Infrastructure, Exadata Cloud@Customer, Oracle Database@Azure, Oracle Database@Google Cloud, and Oracle Database@AWS. Use for Exadata architecture, VM clusters, cloud E...",
+  "source_type": "adapted",
+  "official_docs": [
+    "https://docs.oracle.com/en-us/iaas/Content/home.htm",
+    "https://www.oracle.com/cloud/"
+  ],
+  "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",
+  "path": "skills/oci/oci-exadata-platform-architect",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/oci/oci-exadata-platform-architect/references/compatibility-checklist.md

@@ -0,0 +1,25 @@
+# Exadata Compatibility Checklist
+
+## Database and platform compatibility
+
+- Confirm Oracle Database version, Grid Infrastructure version, RAC requirements, CDB/PDB layout, options/packs, and database software image strategy.
+- Validate application client compatibility: connection strings, SCAN, FAN/ONS, TLS, wallets, JDBC/ODP.NET versions, and failover behavior.
+- Validate storage and performance assumptions with evidence such as AWR/ASH, IOPS, throughput, latency, CPU, memory, interconnect, and cell offload indicators.
+
+## Deployment compatibility
+
+- Identify exact platform: OCI Dedicated Infrastructure, Exadata Cloud@Customer, Exascale, Oracle Database@Azure, Oracle Database@Google Cloud, or Oracle Database@AWS.
+- Confirm region/provider availability, capacity/quota, subscription/billing, support process, and IaC/API support.
+- Confirm network path between applications and database: VCN, VNet, VPC, FastConnect, VPN, interconnect, DNS, and security controls.
+
+## Operations compatibility
+
+- Backup destination and restore process are tested, not just configured.
+- Data Guard topology, switchover/failover runbook, observer/auto-failover assumptions, and RPO/RTO are documented.
+- Patching and maintenance windows are aligned across GI, DB homes, VM clusters, applications, and provider control planes.
+- IORM and consolidation rules exist for noisy-neighbor control.
+
+## Multicloud compatibility
+
+- The database may be Oracle-managed while the application lives in AWS, Azure, Google Cloud, OCI, or on-premises. Do not blur those responsibility boundaries.
+- Cross-cloud latency, egress, DNS, route propagation, identity, monitoring, and incident ownership are first-class design inputs.

package/skills/oci/oci-exadata-platform-architect/references/deployment-options.md

@@ -0,0 +1,22 @@
+# Exadata Deployment Options
+
+Use this reference when choosing an Exadata Database Service deployment pattern.
+
+## Deployment families
+
+| Family | Where it runs | Good fit | Watch-outs |
+|---|---|---|---|
+| Exadata Database Service on Dedicated Infrastructure | OCI region on Oracle-managed dedicated Exadata infrastructure | Highest Oracle database performance in OCI, RAC, consolidation, predictable database platform | Capacity planning, VM cluster design, network design, patching windows, backup/DR, licensing |
+| Exadata Database Service on Exascale Infrastructure | OCI and selected multicloud offers where available | Elastic Exadata-style consumption and simplified capacity model | Feature availability and operational semantics vary; verify current service docs and limits |
+| Exadata Cloud@Customer | Customer data center with Oracle-managed Exadata cloud infrastructure | Data residency, low latency to on-premises apps, cloud subscription model | Site readiness, physical capacity lead time, OCI control-plane connectivity, support demarcation |
+| Oracle Database@Azure | Oracle Exadata Database Service and Autonomous database services integrated with Azure regions where available | Azure app proximity and Azure operating model | Azure region availability, VNet/DNS/private connectivity, billing/support split, IaC path |
+| Oracle Database@Google Cloud | Exadata Database Service integrated with Google Cloud regions and Google Cloud interfaces where available | Google Cloud app proximity, Google Cloud networking/security consumption path | Exact offer matters: Dedicated, Exascale, Base Database, or Autonomous; verify Google/Oracle API responsibilities |
+| Oracle Database@AWS | Oracle database services integrated with AWS where available | AWS app proximity and AWS operating model | Region/offer maturity, VPC/DNS/private connectivity, capacity, support, and Terraform/provider coverage |
+
+## Non-negotiable design checks
+
+- VM cluster sizing: OCPU/ECPU equivalent, memory, local storage, DATA/RECO split, DB node count, and spare capacity.
+- Database topology: CDB/PDB layout, RAC services, Data Guard, backup destination, TDE/key ownership.
+- Network: client subnet, backup subnet, NSGs/security lists, SCAN/listener ports, DNS, routing, and cross-cloud latency.
+- Operations: maintenance windows, patch sequencing, node lifecycle, IORM, monitoring, incident owner, and support route.
+- Migration: source platform, endian/version compatibility, downtime budget, backup/restore, Data Pump, GoldenGate, ZDM, or app-level migration path.

package/skills/oci/oci-exadata-platform-architect/references/documentation-fallback.md

@@ -0,0 +1,30 @@
+# Documentation Fallback
+
+Use this reference when live OCI infrastructure data is unavailable, incomplete, denied, or unsafe to query for `oci-exadata-platform-architect`.
+
+## Grounding order
+
+1. Live official Oracle MCP evidence.
+2. User-provided sanitized evidence such as exports, diagrams, screenshots, AWR summaries, tickets, or redacted configuration.
+3. Context7 Oracle Cloud Infrastructure documentation (`/websites/oracle_en-us_iaas_content`).
+4. Service-specific Oracle documentation or Oracle database documentation MCP when relevant.
+5. Clearly labeled inference.
+
+## Mandatory evidence labels
+
+Every finding must be labeled as one of:
+
+- `live evidence`
+- `user-provided sanitized evidence`
+- `documentation-based`
+- `inference`
+
+Documentation can explain how OCI and Oracle Database services should behave. It does not prove the user's current infrastructure state, capacity, quota, regional availability, or provider-specific entitlement.
+
+## Context7 prompts to use
+
+- `OCI Autonomous Database Exadata deployment options Oracle Database at Azure AWS Google Cloud Cloud Customer compatibility`
+- `OCI database multicloud networking private endpoint Data Guard backup Recovery Service limits`
+- `OCI Exadata cloud VM cluster autonomous VM cluster API CLI operations maintenance IORM`
+
+Keep prompts free of customer names, identifiers, IP addresses, secrets, or proprietary architecture details.

package/skills/oci/oci-exadata-platform-architect/references/oracle-mcp.md

@@ -0,0 +1,28 @@
+# Official Oracle MCP Capability Mapping
+
+Use this reference when selecting live Oracle MCP tools for `oci-exadata-platform-architect`.
+
+## Selection rule
+
+Detect by exposed tool capability, not by client-side MCP server label. Users can register official Oracle MCP servers under any name.
+
+## Preferred capabilities
+
+- oracle.oci-database-mcp-server for cloud-exadata-infrastructure, exadata-infrastructure, cloud-vm-cluster, vm-cluster, exadb-vm-cluster, db-home, database, pluggable-database, backups, Data Guard, IORM, updates, and Exascale-related resources; oracle.oci-limits-mcp-server for capacity/limit posture; oracle.oracle-db-doc-mcp-server for database documentation fallback.
+
+## Useful OCI command families when generic OCI API MCP or CLI fallback is needed
+
+- `db autonomous-database` for Autonomous Database and Autonomous AI Database list/get/update/backup/clone/DR operations where supported.
+- `db autonomous-container-database` for dedicated autonomous container database lifecycle and Data Guard operations where supported.
+- `db autonomous-vm-cluster` and `db cloud-autonomous-vm-cluster` for dedicated autonomous fleet capacity where supported.
+- `db cloud-exa-infra`, `db exadata-infrastructure`, `db cloud-vm-cluster`, `db vm-cluster`, `db db-home`, `db database`, and `db pluggable-database` for Exadata and database stack evidence where supported.
+
+## Missing or ambiguous MCP tools
+
+If expected tools are not exposed or multiple Oracle-like servers are ambiguous, ask the user for the configured MCP server name that exposes the official Oracle tools. Ask for the server name only. Never ask for secrets, credentials, API tokens, fingerprints, tenancy identifiers, database passwords, wallets, or config contents.
+
+## Runtime priority
+
+1. Service-specific official Oracle MCP read/list/get/search tools.
+2. Generic official OCI API MCP tools such as command help and OCI command execution, when service-specific tools are unavailable.
+3. OCI CLI default profile fallback only when MCP is unavailable or insufficient.

package/skills/oci/oci-exadata-platform-architect/references/safety-checklist.md

@@ -0,0 +1,32 @@
+# Safety Checklist
+
+Use this checklist before recommending or executing changes for `oci-exadata-platform-architect`.
+
+## Scope
+
+- Deployment model confirmed: OCI, Cloud@Customer, Oracle Database@Azure, Oracle Database@Google Cloud, Oracle Database@AWS, or unknown.
+- Region/provider location confirmed.
+- Compartment or provider boundary confirmed.
+- Resource identity confirmed by name and, when available, live evidence.
+- Owner, business impact, data classification, and environment confirmed.
+
+## Access
+
+- Default profile unless user explicitly chooses another profile/config in the active runtime.
+- Least-privilege action only.
+- No broad grants unless risk-accepted by an owner.
+- No secrets, wallets, credentials, tokens, connection strings, or config contents requested or displayed.
+
+## Change safety
+
+- Read-only discovery first.
+- Explicit approval for write, delete, start, stop, update, patch, failover, switchover, restore, wallet, key, SQL, command execution, network, or remediation actions.
+- Rollback path documented.
+- Validation plan includes positive checks, negative checks, and application-owner signoff.
+
+## 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.