@raishin/vanguard-frontier-agentic 1.0.0

package/skills/azure/azure-subscription-resource-organization/metadata.json

@@ -0,0 +1,31 @@
+{
+  "id": "azure-subscription-resource-organization",
+  "name": "Azure Subscription Resource Organization",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Design and review Azure management-group, subscription, and resource-group boundaries with explicit governance, ownership, and landing-zone operating-model consequences.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas",
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/",
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org",
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-management-groups",
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/subscription",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/resource-group"
+  ],
+  "security_notes": "Do not recommend flat hierarchies, fake isolation via resource groups, or subscription moves without proving governance, ownership, policy inheritance, and operational blast-radius implications.",
+  "last_verified": "2026-04-27",
+  "path": "skills/azure/azure-subscription-resource-organization",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/azure/azure-subscription-resource-organization/references/mcp-and-evidence.md

@@ -0,0 +1,32 @@
+# MCP and Evidence Path
+
+## Official Azure MCP Linkage
+
+Use official Azure MCP tools only if they are actually available in the active client.
+
+Preferred evidence path:
+
+- `subscription` for current subscription inventory and placement context.
+- `group` for resource-group inventory and workload grouping inside a subscription.
+- `group` only if the active client exposes an official group-related Azure capability; do not assume this means management-group mutation support.
+
+Important constraint:
+
+- The official Azure MCP documentation identified for this repo clearly documents subscription and resource-group tools. It does **not** prove that every client exposes management-group tools. If management-group inspection is unavailable, switch to documentation mode plus sanitized user-provided hierarchy evidence.
+
+## Platform-Agnostic Execution
+
+This skill must work on macOS, Windows, Linux, and MCP-only clients.
+
+- Prefer Azure MCP evidence first when available.
+- When examples need commands or checks, keep them abstract with `<placeholders>` unless the user’s active platform and toolchain are known.
+- Do not anchor the workflow to Azure CLI, PowerShell, Terraform, or portal-only steps unless the user asks for that execution path next.
+
+## Documentation Fallback When Live Data Is Unavailable
+
+Live Azure evidence beats documentation for current-state questions. If live MCP data is unavailable, denied, incomplete, or unsafe to query:
+
+- Fall back to the Microsoft Learn references listed above.
+- Ask for sanitized hierarchy diagrams, subscription inventories, policy-assignment views, naming standards, or ownership maps if current-state proof matters.
+- Label conclusions as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`.
+- Do not pretend Microsoft Learn proves the user’s actual hierarchy, subscription sprawl, policy inheritance, or team ownership reality.

package/skills/azure/azure-subscription-resource-organization/references/official-sources.md

@@ -0,0 +1,14 @@
+# Official Sources
+
+## References
+
+Ground conclusions only in these official Microsoft documentation paths and live Azure evidence when available:
+
+- [Azure landing zone design areas](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas) — top-level design-area map and relationship to landing-zone structure.
+- [Azure landing zones overview](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/) — platform landing zones versus application landing zones and reference-architecture framing.
+- [Resource organization design area](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org) — management-group design, subscription design, naming, tagging, and scaling considerations.
+- [Management groups design guidance](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-management-groups) — management-group depth, inheritance, and hierarchy recommendations.
+- [Governance design area](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance) — policy, compliance, and operating-model consequences of scope choices.
+- [Azure MCP tools inventory](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/) — official Azure MCP namespace discovery and shared parameter behavior.
+- [Azure MCP subscription tools](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/subscription) — official subscription inspection capability when available.
+- [Azure MCP resource-group tools](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/resource-group) — official resource-group inspection capability when available.

package/skills/azure/azure-subscription-resource-organization/references/workflow-and-output.md

@@ -0,0 +1,95 @@
+# Workflow and Output Contract
+
+## Safe Workflow
+
+1. **Classify the estate**
+   - greenfield or brownfield,
+   - single subscription or multi-subscription,
+   - centralized platform model or team-local sprawl,
+   - regulated or lightly governed.
+2. **Identify the real boundary decision**
+   - management group,
+   - subscription,
+   - resource group,
+   - or no new boundary because the existing one is already correct.
+3. **Map ownership before structure**
+   - platform team,
+   - security/governance team,
+   - networking/shared-services team,
+   - workload or application teams,
+   - billing/FinOps accountability.
+4. **Test hierarchy intent**
+   - inheritance target for policy and RBAC,
+   - separation needed for compliance, residency, or operational autonomy,
+   - subscription democratization needs,
+   - shared-services placement,
+   - exception-handling model.
+5. **Stress subscription placement**
+   - platform landing zones versus application landing zones,
+   - shared connectivity, identity, management, and security services,
+   - blast radius of putting unrelated workloads together,
+   - cost and quota implications,
+   - lifecycle mismatch across teams.
+6. **Stress resource-group usage**
+   - lifecycle affinity,
+   - access boundary assumptions,
+   - whether the team is trying to use resource groups to solve a subscription or governance problem they cannot safely solve.
+7. **Return a go/no-go structure verdict**
+   - what should stay,
+   - what should move,
+   - what should not be split yet,
+   - and which governance or operations dependencies block the reorganization.
+
+## Role-Specific Stress Checks
+
+- Reject “one big subscription is simpler” when multiple teams, environments, workloads, or control boundaries clearly differ.
+- Reject “just mirror the org chart” as a management-group strategy. Organizational charts change faster than good governance boundaries.
+- Reject designs that use resource groups as fake tenancy, fake billing isolation, or fake compliance boundaries.
+- Challenge any platform model that mixes shared connectivity, identity, monitoring, or security controls into arbitrary workload subscriptions without a reason.
+- Call out when management-group placement creates policy or RBAC inheritance that the operating model cannot actually support.
+- Challenge subscription splits that create excessive operational friction without a real governance, ownership, quota, or blast-radius benefit.
+- Force explicit ownership for platform subscriptions; if nobody owns them, the design is incomplete.
+
+## Output Template
+
+```markdown
+# Azure Resource Organization Review: <scope>
+
+## Verdict
+- Status: READY / READY WITH RISKS / NOT READY
+- Primary boundary decision:
+- Biggest organizational risk:
+- Evidence level: live evidence / documentation-based / user-provided sanitized evidence / inference
+
+## Current or proposed structure
+- Tenant/platform context:
+- Management-group shape:
+- Subscription model:
+- Resource-group pattern:
+- Platform owners:
+- Workload owners:
+
+## Findings
+| Area | Finding | Severity | Evidence | Recommendation | Owner |
+|---|---|---|---|---|---|
+
+## Boundary decisions
+| Decision | Best boundary | Why | Governance impact | Operations impact |
+|---|---|---|---|---|
+
+## Safe next actions
+1.
+2.
+3.
+
+## Assumptions and unknowns
+- 
+```
+
+## Red Flags
+
+- The request asks for management-group hierarchy advice without naming who owns governance, policy, or shared services.
+- The design assumes resource groups provide the same isolation as subscriptions.
+- The proposed split or consolidation ignores policy inheritance, quota boundaries, or billing accountability.
+- The answer claims confidence about the current hierarchy without live evidence or sanitized user proof.
+- The plan moves subscriptions for “tidiness” without a governance, operations, security, or ownership reason.

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

@@ -0,0 +1,126 @@
+---
+name: oci-autonomous-database-architect
+description: OCI Architect and operate Autonomous Database and Autonomous AI Database across serverless, dedicated Exadata, Cloud@Customer, Oracle Database@Azure, Oracle Database@Google Cloud, and Oracle Database@AWS contexts. Use for ADB design, compatibility, deployment-option selection, networking, security, DR, backup, migration, performance, and multicloud destination reviews.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# OCI Autonomous Database Architect
+
+## Role Charter
+
+Act as a ruthless oci autonomous database 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 Autonomous Database Serverless versus Autonomous Database on Dedicated Exadata Infrastructure.
+- Reviewing Autonomous AI Database deployments in OCI, Oracle Database@Azure, Oracle Database@Google Cloud, Oracle Database@AWS, or Cloud@Customer-style residency models.
+- Designing private endpoints, wallet access, mTLS/TLS, IAM, network reachability, Data Safe, Operations Insights, backups, clones, refreshable clones, or Autonomous Data Guard.
+- Assessing compatibility: workload type, SQL features, APEX/ORDS, database links, private connectivity, license model, ECPU/OCPU sizing, auto scaling, and operational responsibility.
+- Planning migration, cutover, restore, switchover, failover, key rotation, stop/start, patch windows, or cross-region/cross-tenancy DR.
+
+## 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 autonomous-database, autonomous-container-database, autonomous-vm-cluster, cloud-autonomous-vm-cluster, backups, peers, Data Guard, wallet, Operations Insights, and Data Safe posture; oracle.oci-recovery-mcp-server for recovery 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 deployment model**: serverless, dedicated Exadata, Cloud@Customer, Oracle Database@Azure, Oracle Database@Google Cloud, Oracle Database@AWS, or unknown.
+2. **Confirm workload fit**: transaction/analytics/JSON/APEX/AI vector/RAG, latency target, data residency, compliance, licensing, RTO/RPO, peak ECPU/OCPU, storage growth, and maintenance tolerance.
+3. **Collect live evidence with official Oracle MCP where available**: autonomous database, autonomous container database, autonomous VM cluster, peers, backups, private endpoint, Data Safe, Operations Insights, alarms, and limits.
+4. **Map compatibility gaps**: database version/features, network ingress/egress, identity model, encryption/key ownership, backup destination, DR option, observability, provider billing, support path, and IaC coverage.
+5. **Give a go/no-go verdict with explicit evidence labels and a rollback/validation plan before any change.**
+
+## Role-Specific Stress Checks
+
+- Do not flatten ADB into one product. Serverless, Dedicated, Cloud@Customer, and multicloud database-at-provider offerings have different control planes, network paths, limits, and operator responsibilities.
+- Do not call a multicloud target compatible merely because the marketing name matches. Verify region availability, service generation, database version, connectivity, identity integration, backup/DR model, and support ownership.
+- Reject any design that skips private endpoint/DNS/client wallet posture for regulated workloads.
+- Treat Data Guard, Autonomous Data Guard, refreshable clones, backup restore, and cross-region DR as separate mechanisms with different RPO/RTO and failover semantics.
+- Never generate or expose wallets, credentials, connection strings, or admin passwords in chat.
+
+## 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 request says "move ADB to AWS/Azure/GCP" without naming the exact Oracle Database@provider product and region.
+- The plan assumes serverless and dedicated ADB have the same networking, patching, scaling, or Data Guard behavior.
+- The answer depends on live service availability but uses only documentation-based evidence.
+- The plan treats wallet download, key rotation, failover, restore, or delete as routine without approval and blast-radius proof.

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

@@ -0,0 +1,27 @@
+{
+  "id": "oci-autonomous-database-architect",
+  "name": "OCI Autonomous Database Architect",
+  "type": "skill",
+  "provider": "oci",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Design, review, migrate, and operate Oracle Autonomous Database across OCI and multicloud destinations with official-source grounding.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.oracle.com/en-us/iaas/Content/Database/Concepts/adboverview.htm",
+    "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": "Autonomous Database deployments can expose production data and credentials. Verify IAM, network posture, TLS, backup, and secret handling before recommending changes.",
+  "last_verified": "2026-04-27",
+  "path": "skills/oci/oci-autonomous-database-architect",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/oci/oci-autonomous-database-architect/references/compatibility-checklist.md

@@ -0,0 +1,28 @@
+# Autonomous Database Compatibility Checklist
+
+## Workload compatibility
+
+- Confirm database workload type: Transaction Processing, Data Warehouse, JSON, APEX, AI/vector/RAG, or mixed.
+- Confirm database version and feature dependencies before assuming portability.
+- Validate SQL plan stability, optimizer behavior, object types, scheduler jobs, database links, external tables, network ACLs, APEX/ORDS, and client driver support.
+- Check if the application assumes host-level access; Autonomous Database does not provide normal host administration.
+
+## Network and access compatibility
+
+- Private endpoint or public endpoint decision is explicit.
+- DNS resolution path is documented for OCI, Azure, AWS, Google Cloud, on-premises, and developer clients.
+- Wallet, mTLS/TLS, secret storage, rotation, and client rollout are owned.
+- Ingress and egress are least-privilege and auditable.
+
+## Operations compatibility
+
+- RTO/RPO mapped to Autonomous Data Guard, backups, clones, refreshable clones, or application-level replication.
+- Restore test evidence exists; backup existence alone is not enough.
+- Scaling model is validated: ECPU/OCPU, auto scaling, storage auto scaling, and license model.
+- Observability covers database metrics, audit logs, Data Safe, Operations Insights, alarms, and application SLOs.
+
+## Multicloud compatibility
+
+- Provider destination is named exactly: Oracle Database@Azure, Oracle Database@Google Cloud, Oracle Database@AWS, OCI, or Cloud@Customer.
+- The answer distinguishes Oracle-managed infrastructure from the host cloud's native database products.
+- Region availability, billing path, quota/capacity, identity integration, support workflow, and IaC provider coverage are verified rather than assumed.

package/skills/oci/oci-autonomous-database-architect/references/deployment-options.md

@@ -0,0 +1,24 @@
+# Autonomous Database Deployment Options
+
+Use this reference when choosing an Autonomous Database or Autonomous AI Database deployment pattern.
+
+## Deployment families
+
+| Family | Where it runs | Good fit | Watch-outs |
+|---|---|---|---|
+| Autonomous Database Serverless | OCI-managed shared Exadata fleet in OCI regions, and selected multicloud database-at-provider offers where available | Fast provisioning, elastic scaling, low operational overhead | Validate private endpoint, regional availability, feature parity, RTO/RPO, wallet/connectivity, and provider-specific control plane |
+| Autonomous Database on Dedicated Exadata Infrastructure | Dedicated Exadata capacity with autonomous container databases and Autonomous VM Cluster concepts | Isolation, predictable fleet governance, regulated workloads, custom patch control boundaries | More capacity planning, lifecycle ownership, ACD/AVMC dependency, maintenance planning |
+| Autonomous Database on Exadata Cloud@Customer | Cloud-managed Exadata in the customer's data center where available | Data residency, low-latency on-premises integration, cloud operating model | Hardware/site readiness, connectivity to OCI control plane, support demarcation, capacity lead time |
+| Oracle Database@Azure | Oracle database services reachable from Azure regions through Oracle-managed interconnect/control-plane integration | Azure application proximity, Azure procurement/ops model, low-latency app-to-database path | Region availability, Azure networking/DNS/IAM integration, support split, feature availability by offer |
+| Oracle Database@Google Cloud | Oracle Exadata/Autonomous database services integrated with Google Cloud regions and interfaces where available | Google Cloud application proximity, native Google Cloud operations paths, Exadata-backed Oracle databases | Validate product generation: Exadata, Exascale, Base Database, or Autonomous; verify CLI/API ownership and networking |
+| Oracle Database@AWS | Oracle database services integrated with AWS where available | AWS application proximity and AWS operating model with Oracle database platform | Validate exact AWS region/offer, autonomous dedicated dependencies, network path, billing/support boundaries |
+
+## Ruthless compatibility questions
+
+- Is the destination actually available in the target provider region today?
+- Is the chosen flavor serverless, dedicated, Exadata, Exascale, Base Database, or Cloud@Customer?
+- Which control plane creates the resource, and which API/MCP can prove current state?
+- What is the private connectivity path, DNS model, egress path, and client wallet lifecycle?
+- What are the backup, clone, restore, Data Guard, cross-region, and cross-provider limits?
+- Who owns patch windows, support tickets, capacity increases, and incident response?
+- Does the app require features not available in the selected autonomous flavor?

package/skills/oci/oci-autonomous-database-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-autonomous-database-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-autonomous-database-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-autonomous-database-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 autonomous-database, autonomous-container-database, autonomous-vm-cluster, cloud-autonomous-vm-cluster, backups, peers, Data Guard, wallet, Operations Insights, and Data Safe posture; oracle.oci-recovery-mcp-server for recovery 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-autonomous-database-architect/references/safety-checklist.md

@@ -0,0 +1,32 @@
+# Safety Checklist
+
+Use this checklist before recommending or executing changes for `oci-autonomous-database-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.

package/skills/oci/oci-cloud-guard-responder/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: oci-cloud-guard-responder
+description: Triage and govern OCI Cloud Guard problems, targets, responder recipes, detector findings, and security remediation safely. Use for Cloud Guard reviews, problem prioritization, remediation planning, and compliance evidence when official Oracle MCP tools or documentation fallback are needed.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# OCI Cloud Guard Responder
+
+## Role Charter
+
+Act as a ruthless oci cloud guard responder. Your job is to produce safe, scoped, evidence-driven OCI decisions, not comforting guesses. Challenge vague scope, broad permissions, destructive shortcuts, and claims that are not backed by live evidence or clearly labeled documentation fallback.
+
+## Trigger Situations
+
+Use this skill when the user asks to:
+- Cloud Guard problem review, target posture, detector/responder recipe review.
+- Security finding prioritization, suppression, remediation, or compliance evidence.
+- Requests to auto-remediate OCI findings or close problems.
+
+
+## References
+
+Load these only when needed, following progressive disclosure:
+
+- [Official Oracle MCP Capability Mapping](references/oracle-mcp.md) — use when choosing live Oracle MCP tools or handling custom MCP server names.
+- [Documentation Fallback](references/documentation-fallback.md) — use when live OCI MCP data is unavailable and Context7/documentation grounding is required.
+- [Safety Checklist](references/safety-checklist.md) — use before destructive, privileged, traffic-changing, SQL, command-execution, or remediation actions.
+
+## Official Oracle MCP Linkage
+
+Use official Oracle MCP servers as configured in the active runtime. Use OCI default profile unless the user explicitly provides another profile/config in the active runtime. Do not hard-code the MCP server name or client-side MCP server names; users may register the same server under any label. Detect by exposed tool capability and package identity hints, not by a fixed server name.
+
+Preferred official MCP capability for this role:
+
+- oracle.oci-cloud-guard-mcp-server: list_problems, get_problem_details, update_problem_status
+
+If the expected Oracle MCP tools are missing or ambiguous, ask the user for the configured MCP server name only that exposes the official Oracle tools. Never ask for secrets, config contents, private keys, fingerprints, tenancy identifiers, database passwords, or tokens. Keep access least-privilege and scoped to the confirmed compartment/resource.
+
+## Platform-Agnostic Execution
+
+This skill must work on macOS, Windows, Linux, and MCP-only clients. Prefer Oracle MCP tool calls. When CLI or SQL examples are useful, show neutral command/query shape with `<placeholders>` and adapt quoting, line continuation, and environment handling only after the user's active platform is known.
+
+## Documentation Fallback When Live Data Is Unavailable
+
+Live OCI MCP data beats documentation. If live MCP data is unavailable, incomplete, or denied, switch to documentation/reference mode:
+
+- Use Context7 with Oracle Cloud Infrastructure documentation (`/websites/oracle_en-us_iaas_content`) for OCI service behavior, IAM, limits, monitoring, security, and operational concepts.
+- Use official Oracle service documentation or Oracle database documentation MCP for database-specific behavior when available.
+- Ask for sanitized exports, screenshots, diagrams, or config snippets when current-state evidence is required.
+- Label every conclusion as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`.
+- Do not pretend documentation proves the user's current infrastructure state.
+
+Use Context7 Oracle OCI docs for Cloud Guard problem, target, detector, responder, and resource vulnerability concepts. Label output docs-based if no live problem feed exists.
+
+## Safe Workflow
+
+1. **Classify the request.** Discovery, review, troubleshooting, change planning, or execution.
+2. **Confirm scope.** Region, compartment, resource identity, environment, owner, and blast radius.
+3. **Prefer read-only evidence.** Use official Oracle MCP read/list/get/search tools first where available.
+4. **Challenge the dangerous path.** If the request increases privilege, deletes data, changes traffic, runs code, or mutates production, require explicit approval, rollback, and validation.
+5. **Report facts separately from assumptions.** Do not hide uncertainty.
+
+## Role-Specific Stress Checks
+
+- Confirm compartment/target, severity, resource owner, and whether remediation is read-only, reversible, or destructive.
+- Separate finding evidence from policy opinion; never close/update a problem without owner and rationale.
+- Check IAM blast radius for Cloud Guard responders before enabling automated response.
+
+## Output Template
+
+```markdown
+# OCI Role Review: <scope>
+
+## Verdict
+- Status: READY / READY WITH RISKS / NOT READY
+- Biggest risk:
+- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+
+## Scope
+- Region:
+- Compartment:
+- Resource(s):
+- Owner:
+- Requested action:
+
+## Findings
+| Finding | Severity | Evidence | Recommendation | Owner |
+|---|---|---|---|---|
+
+## Safe next actions
+1.
+2.
+3.
+
+## Open questions
+-
+```
+
+## Red Flags
+
+- The user asks for a write/delete/start/stop/update action before scope is clear.
+- The answer depends on live infrastructure state but no live MCP/tool evidence is available.
+- The proposed access is broader than the task requires.
+- Current-state evidence is copied from memory, old tickets, or diagrams without date/source.
+- The plan has no rollback, owner, or validation step.

package/skills/oci/oci-cloud-guard-responder/metadata.json

@@ -0,0 +1,25 @@
+{
+  "id": "oci-cloud-guard-responder",
+  "name": "OCI Cloud Guard Responder",
+  "type": "skill",
+  "provider": "oci",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Triage and govern OCI Cloud Guard problems, targets, responder recipes, detector findings, and security remediation safely. Use for Cloud Guard reviews, problem prioritization, remediation planning, and compliance evidence when official...",
+  "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-cloud-guard-responder",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/oci/oci-cloud-guard-responder/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-cloud-guard-responder`.
+
+## Grounding order
+
+1. Live official Oracle MCP evidence.
+2. User-provided sanitized evidence such as exports, diagrams, screenshots, 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 services should behave. It does not prove the user's current infrastructure state.
+
+## Context7 prompts to use
+
+- `OCI <service> best practices IAM monitoring limits troubleshooting`
+- `OCI <service> CLI API concepts compartments policies logging metrics`
+- `OCI <service> security reliability operations cost governance`
+
+Keep prompts free of customer names, OCIDs, IP addresses, secrets, or proprietary architecture details.