@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

package/skills/oci/oci-devops-container-platform-engineer/metadata.json

@@ -11,15 +11,17 @@
     "kiro",
     "other"
   ],
-  "summary": "Engineer and review Oracle Cloud Infrastructure DevOps, OKE, OCIR, build/deploy pipelines, Kubernetes platform, and container runtime workflows. Use when asked to inspect OCI Container Engine clusters, DevOps projects, OCIR repositories,...",
+  "summary": "Engineer and review OCI DevOps, OKE, OCIR, build/deploy pipelines, Kubernetes platform operations, image promotion, IAM, rollout safety, and container reliability.",
   "source_type": "adapted",
   "official_docs": [
-    "https://docs.oracle.com/en-us/iaas/Content/home.htm",
-    "https://www.oracle.com/cloud/"
+    "https://docs.oracle.com/en-us/iaas/Content/ContEng/home.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/devops/using/home.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/devops/using/environments.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/Registry/home.htm"
   ],
-  "security_notes": "OCI skills may inspect or mutate cloud resources. Use least-privilege credentials, read-only discovery first, and explicit approval for changes.",
-  "last_verified": "2026-04-27",
+  "security_notes": "Read-only advisory by default. Use least privilege, sanitize evidence, and require explicit approval plus rollback for risky OCI DevOps Container Platform Engineer changes.",
+  "last_verified": "2026-06-05",
   "path": "skills/oci/oci-devops-container-platform-engineer",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-devops-container-platform-engineer/references/devops-container-operations.md

@@ -0,0 +1,70 @@
+# OCI DevOps Container Platform Engineer Operations
+
+> Version note: OCI service behavior and tooling change over time. Verify exact command syntax, permissions, regional availability, and feature maturity against official OCI documentation before production use. Do not paste secrets or sensitive identifiers into commands, files, or chat.
+
+Use this reference for current, source-grounded service behavior and the hard review gates that the lean `SKILL.md` intentionally does not carry.
+
+## What people get wrong
+
+- Assuming OCI IAM permissions are the same as Kubernetes RBAC.
+- Pushing images or rolling deployments without promotion, scanning, rollback, and owner checks.
+- Treating a cluster list as enough to judge networking, node pools, admission controls, or workload health.
+- Granting tenancy-wide pipeline permissions for convenience.
+- Making repositories public accidentally or ignoring retention.
+
+## Officially grounded service shape
+
+- Official OCI documentation describes the service behavior and lifecycle concepts for this domain, but it does not prove the user's tenancy, compartments, IAM policies, limits, deployed resources, or production readiness.
+- OCI API evidence through the user’s configured read-only OCI MCP shows OKE cluster list, DevOps project list, and container repository list operations expose compartment, lifecycle, name/display-name, subtree/public repository, sorting, and pagination filters. Treat this as API shape evidence, not cluster or pipeline readiness.
+- Current-state claims need sampled read-only evidence or sanitized user-provided evidence.
+
+Documentation evidence proves documented OCI service behavior. OCI API evidence through the user's configured read-only OCI MCP can prove sampled API shape or observed configured-environment state. Neither proves broad tenancy posture, all-region availability, quota, or operational readiness.
+
+## Non-negotiable design rules
+
+- Confirm compartment, region, project/cluster/repository, namespace, environment, and owner before action.
+- Separate OCI IAM, registry permissions, Kubernetes RBAC, and workload identity.
+- Require image provenance, scanning/signing, promotion rules, and rollback before production deployment.
+- Use read-only discovery before pipeline, cluster, node-pool, repository, or deployment mutation.
+- Never request kubeconfigs, tokens, private keys, registry passwords, or customer identifiers in chat.
+
+## Minimal safe implementation flow
+
+- Classify cluster, pipeline, registry, or rollout task.
+- Collect official docs plus sampled read-only evidence for projects, clusters, repositories, and deployment targets.
+- Review IAM/RBAC, network, image, deployment, observability, and rollback posture.
+- Identify unsafe mutations and missing gates.
+- Return safe plan, approvals, validation checks, and rollback.
+
+## High-risk assumptions to kill
+
+- “A green pipeline means production is safe.”
+- “A cluster exists, so workloads are healthy.”
+- “Registry push access implies deployment access should also be granted.”
+- “Rollback is automatic because Kubernetes has rollout history.”
+- “Public repositories are acceptable for non-production images.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- List projects, OKE clusters, and container repositories in confirmed scope.
+- Check cluster lifecycle, node-pool health, Kubernetes version, network, admission/policy controls, and observability before operations.
+- Review pipeline stages, artifacts, triggers, deployment environments, approvals, and rollback configuration.
+- Check repository public/private state, retention, image tags/digests, scan/signature evidence, and pull principals.
+- Require explicit approval for cluster/node-pool changes, pipeline mutation, repository deletion, or production rollout.
+
+## Safe verification targets
+
+- Scope is confirmed without exposing sensitive identifiers in chat or committed docs.
+- Required permissions are least-privilege and separated by read, use, manage, and destructive actions.
+- Current-state findings are labeled as sampled evidence, not broad proof.
+- Risky mutations have explicit approval, blast-radius review, rollback, and validation.
+- Official-source claims are linked to service docs and not overstated as live posture.
+
+## When to push back
+
+- The user asks for a write/delete/start/stop/update/remediate action before scope and owner are clear.
+- The answer would depend on live infrastructure state but only documentation evidence exists.
+- The proposed access is broader than the task requires.
+- The plan has no rollback, owner, or validation step.

package/skills/oci/oci-devops-container-platform-engineer/references/mcp-and-evidence.md

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

package/skills/oci/oci-devops-container-platform-engineer/references/official-sources.md

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

package/skills/oci/oci-devops-container-platform-engineer/references/safety-checklist.md

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

package/skills/oci/oci-devops-container-platform-engineer/references/workflow-and-output.md

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

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

@@ -1,11 +1,11 @@
 ---
 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.
+description: Design, review, migrate, and operate Oracle Exadata Database Service across OCI Dedicated Infrastructure, Exascale, Cloud@Customer, and Oracle Database multicloud destinations with official-source grounding.
 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: data
 ---
 
@@ -13,297 +13,39 @@ metadata:
 
 ## Purpose
 
-Use this skill when the user asks for Exadata architecture, migration, sizing,
-Terraform/IaC, compatibility, performance, HA/DR, or operational review across:
+Act as a ruthless Exadata architect. Stop shape-first sizing, vague migration claims, unsafe HA/DR assumptions, licensing blind spots, and multicloud placement decisions without current official evidence.
 
-- 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
+Use this skill for:
 
-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.
+- Exadata Dedicated Infrastructure and Exascale deployment choice
+- Cloud VM Cluster, DB Home, CDB/PDB, storage, and capacity design
+- backup, recovery, Data Guard, maintenance, and patching strategy
+- Cloud@Customer and Oracle Database multicloud destination boundaries
+- licensing, support, network, key-management, and operational ownership
 
-## Source-Grounding Contract
+## Lean operating rules
 
-Before giving advice that affects deployment, sizing, licensing, networking,
-database version, storage, VM cluster shape, backup, Data Guard, or multicloud
-placement:
+- Prefer official OCI documentation, then OCI API evidence through the user's configured read-only OCI MCP when current-state or API-shape evidence is needed, then sanitized user evidence.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge broad scope, broad permissions, destructive shortcuts, and production claims without evidence.
+- Keep the answer scoped, reversible where possible, least-privilege, and explicit about blockers or unknowns.
+- Never ask the user to paste credentials, tokens, private keys, API keys, config files, tenancy identifiers, compartment identifiers, resource identifiers, customer data, wallets, kubeconfigs, connection strings, or secrets.
 
-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`
+## References
 
-## First Questions to Answer
+Load these only when needed:
 
-Never start with a shape. Start with constraints.
+- [OCI Exadata Database Architect Operations](references/exadata-database-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, credential boundaries, and current-state caveats.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only OCI API evidence, or sanitized user evidence.
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when you need the detailed Oracle documentation list or source notes.
 
-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?
+## Response minimum
 
-## 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.
+Return, at minimum:
 
+- 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-exadata-database-architect/metadata.json

@@ -11,18 +11,19 @@
     "kiro",
     "other"
   ],
-  "summary": "Design, review, migrate, and operate Oracle Exadata Database Service across OCI, Cloud@Customer, and multicloud destinations with official-source grounding.",
+  "summary": "Design, review, migrate, and operate Oracle Exadata Database Service across OCI Dedicated Infrastructure, Exascale, Cloud@Customer, and Oracle Database 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-service/ecscm/exadata-database-service-dedicated-infrastructure-administrators-guide.pdf",
+    "https://docs.oracle.com/en/engineered-systems/exadata-database-exascale/exdxs/exadata-database-service-exascale-infrastructure-users-guide.pdf",
     "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",
+  "security_notes": "Read-only advisory by default. Use least privilege, sanitize evidence, and require explicit approval plus rollback for risky OCI Exadata Database Architect changes.",
+  "last_verified": "2026-06-05",
   "path": "skills/oci/oci-exadata-database-architect",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }