@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

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

@@ -11,7 +11,7 @@
     "kiro",
     "other"
   ],
-  "summary": "Design, review, migrate, and operate Oracle Autonomous Database across OCI and multicloud destinations with official-source grounding.",
+  "summary": "Design and review OCI Autonomous Database and Autonomous AI Database deployments with explicit workload fit, security, networking, backup, DR, migration, and multicloud boundary checks.",
   "source_type": "original",
   "official_docs": [
     "https://docs.oracle.com/en-us/iaas/Content/Database/Concepts/adboverview.htm",
@@ -19,9 +19,9 @@
     "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",
+  "security_notes": "Read-only advisory by default. Use least privilege, sanitize evidence, and require explicit approval plus rollback for risky OCI Autonomous Database Architect changes.",
+  "last_verified": "2026-06-05",
   "path": "skills/oci/oci-autonomous-database-architect",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-autonomous-database-architect/references/autonomous-database-operations.md

@@ -0,0 +1,69 @@
+# OCI Autonomous Database Architect 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
+
+- Flattening serverless, dedicated Exadata, Cloud@Customer, and multicloud database services into one generic ADB pattern.
+- Calling a target compatible before checking workload type, database version, network path, wallet/TLS, Data Guard, backup, and support boundary.
+- Assuming Autonomous Data Guard, backups, clones, and refreshable clones have interchangeable RTO/RPO semantics.
+- Treating documentation availability as proof the user can deploy in a specific subscribed region or tenancy.
+
+## 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 Autonomous Database list operations expose compartment, infrastructure type, lifecycle state, workload type, database version, free-tier, refreshable clone, and Data Guard filters. Treat this as API shape evidence, not tenancy posture.
+- 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
+
+- Classify the deployment model before recommending architecture.
+- Require workload, latency, data residency, compliance, RTO/RPO, sizing, and maintenance constraints.
+- Keep wallets, connection strings, credentials, and customer identifiers out of chat and examples.
+- Require private access and DNS/client posture review for regulated workloads.
+- Separate documentation evidence, sampled API evidence, and user-provided sanitized evidence.
+
+## Minimal safe implementation flow
+
+- Classify deployment model and destination boundary.
+- Capture workload profile, constraints, security, network, backup, and DR requirements.
+- Use official OCI docs plus sampled read-only API shape/current-state evidence where available.
+- Identify compatibility, migration, operations, and rollback blockers.
+- Return go/no-go verdict, risks, safe next actions, and validation plan.
+
+## High-risk assumptions to kill
+
+- ““Autonomous” means no architecture work remains.”
+- “Serverless and dedicated have the same operational responsibilities.”
+- “A marketing-compatible multicloud offer is regionally available and operationally equivalent.”
+- “Backup existence proves restore readiness.”
+- “Wallet download or connection-string handling is routine and low risk.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- List ADB resources only in confirmed scope and label results as sampled current-state evidence.
+- Check infrastructure type, workload type, lifecycle state, Data Guard flag, clone/refreshable clone posture, and version filters before drawing conclusions.
+- Verify network access model, wallet/TLS posture, backup/restore evidence, alarms, Data Safe/Operations Insights coverage, and limits.
+- Compare official deployment-option docs to the chosen destination before recommending multicloud movement.
+- Require rollback/cutover validation before migration, failover, restore, key rotation, or stop/start actions.
+
+## 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-autonomous-database-architect/references/compatibility-checklist.md

@@ -1,28 +1,9 @@
-# Autonomous Database Compatibility Checklist
+# Autonomous Database compatibility checklist
 
-## Workload compatibility
+Use this component-specific checklist for workload fit.
 
-- 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.
+- Workload type, database version, feature usage, APEX/ORDS/JSON/vector needs.
+- Network path, private endpoint, DNS, wallet/TLS, client version, and egress controls.
+- Backup, restore, clone, refreshable clone, Data Guard, switchover/failover, and rollback evidence.
+- Data residency, encryption/key ownership, audit, Data Safe, Operations Insights, alarms, and owner model.
+- Migration method, cutover window, validation queries, rollback criteria, and support escalation path.

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

@@ -1,24 +1,10 @@
-# Autonomous Database Deployment Options
+# Autonomous Database deployment options
 
-Use this reference when choosing an Autonomous Database or Autonomous AI Database deployment pattern.
+Use this component-specific reference after loading the operations reference.
 
-## Deployment families
+## Review dimensions
 
-| 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?
+- Serverless versus dedicated Exadata changes isolation, operator control, maintenance, capacity, and cost assumptions.
+- Cloud@Customer and database-at-provider models change control-plane, networking, residency, support, and operational ownership.
+- Multicloud compatibility needs exact product, region, identity, network, backup, Data Guard, licensing, and support evidence.
+- Do not treat marketing availability as proof that the user's subscribed region, limits, and support path are ready.

package/skills/oci/oci-autonomous-database-architect/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-autonomous-database-architect/references/official-sources.md

@@ -0,0 +1,21 @@
+# Official sources
+
+Use this reference when grounding current OCI behavior for `oci-autonomous-database-architect`.
+
+## Oracle documentation sources
+
+- 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
+
+## 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-autonomous-database-architect/references/safety-checklist.md

@@ -1,32 +1,16 @@
-# Safety Checklist
+# Safety checklist
 
-Use this checklist before recommending or executing changes for `oci-autonomous-database-architect`.
+Use before OCI Autonomous Database Architect production recommendations, privileged access, cloud mutations, remediation actions, or readiness claims.
 
-## Scope
+## Non-negotiables
 
-- 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.
+- Do not ask for or print credentials, tokens, private keys, API keys, config files, tenancy identifiers, compartment identifiers, resource identifiers, customer data, wallets, 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, 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 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.
+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-autonomous-database-architect/references/workflow-and-output.md

@@ -0,0 +1,24 @@
+# Workflow and output contract
+
+Use this reference for full OCI Autonomous Database Architect 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-certificates-issuer-review/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: oci-certificates-issuer-review
-description: Use this skill when reviewing OCI Certificates Service issuer configurations for cert-manager on OKE. Trigger on any request to audit OCI CA hierarchy, issuance rules, OKE Workload Identity vs Instance Principal auth, IAM policy scope, OCSP reachability, or certificate version management.
+description: Review OCI Certificates Service and OKE cert-manager issuer posture with CA hierarchy, issuance rules, workload identity, IAM scope, OCSP reachability, and certificate lifecycle safeguards.
 allowed-tools: Read Grep Glob
 metadata:
-  author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  author: github: Raishin
+  version: 0.1.1
+  updated: "2026-06-05"
   category: security
 ---
 
@@ -13,28 +13,39 @@ metadata:
 
 ## Purpose
 
-Review Oracle Cloud Infrastructure (OCI) Certificates Service configurations used as cert-manager issuers on OKE (Oracle Kubernetes Engine). Identify CA hierarchy misconfigurations (root vs subordinate), missing issuance rules, overly broad IAM policies, Instance Principal authentication scope risks, OCSP reachability gaps, and certificate version accumulation. Output severity-labeled findings with evidence and remediation steps.
+Act as a ruthless OCI PKI issuer reviewer. Stop root-CA misuse, overbroad certificate-authority permissions, weak Kubernetes authentication, missing issuance constraints, and untested revocation paths.
+
+Use this skill for:
+
+- certificate authority hierarchy and issuer target
+- certificate and CA lifecycle rules
+- OKE workload identity versus broad instance-level authority
+- IAM policy scope for issuance
+- OCSP/revocation reachability and certificate version lifecycle
 
 ## Lean operating rules
 
-- Flag any OCI issuer that references a ROOT CA directly as CRITICAL — only a SUBORDINATE CA should be used for cert-manager issuance. The ROOT CA must be offline (disabled after subordinate creation) or kept entirely out of the Certificates Service.
-- Check whether OCI issuance rules are configured on the subordinate CA: flag missing validity caps (>90d) and missing key algorithm restrictions (RSA <2048 or EC <P-256) as MEDIUM.
-- Identify the authentication method used by cert-manager to call OCI APIs: flag Instance Principal auth as HIGH — any pod on the OKE node can call the OCI Certificates API via instance metadata. Correct method is OKE Workload Identity (SA-bound, pod-level).
-- Review the OCI IAM policy for cert-manager: flag `manage certificate-authorities` (grants delete/update CA) as HIGH. Minimum required: `use certificate-authorities` with `request.permission='CREATE_CERTIFICATE_REQUEST'`.
-- Check OCSP reachability from OKE worker nodes to `ocsp.pki.oraclecloud.com`. Flag unreachable OCSP endpoint as MEDIUM (soft-fail revocation = revoked certs accepted by most TLS stacks).
-- Review certificate version count; flag high version accumulation (> 10 versions per cert) as LOW (storage cost and management overhead).
-- Label all findings as live evidence, documentation-based, or inference.
+- 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, or secrets.
 
 ## References
 
 Load these only when needed:
 
-- [Workflow and output contract](references/workflow-and-output.md)
+- [OCI Certificates Issuer Review Operations](references/certificates-issuer-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.
 
 ## Response minimum
 
-- Severity-labeled findings list (CRITICAL / HIGH / MEDIUM / LOW)
-- Evidence source for each finding
-- Specific resource name, CA OCID, or IAM policy statement that caused the finding
-- Recommended remediation with example OCI CLI command or IAM policy snippet
-- Overall OCI PKI trust posture verdict
+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-certificates-issuer-review/metadata.json

@@ -3,18 +3,25 @@
   "name": "OCI Certificates Issuer Review",
   "type": "skill",
   "provider": "oci",
-  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
-  "summary": "Review OCI Certificates Service issuer configurations for cert-manager on OKE, covering CA hierarchy safety, issuance rule enforcement, OKE Workload Identity vs Instance Principal authentication, IAM policy scope minimization, OCSP reachability, and certificate version lifecycle management.",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review OCI Certificates Service and OKE cert-manager issuer posture with CA hierarchy, issuance rules, workload identity, IAM scope, OCSP reachability, and certificate lifecycle safeguards.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.oracle.com/en-us/iaas/Content/certificates/home.htm",
-    "https://docs.oracle.com/en-us/iaas/Content/certificates/managing-certificate-authority.htm",
-    "https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengusingworkloadidentity.htm",
-    "https://github.com/oracle/oci-native-ingress-controller"
+    "https://docs.oracle.com/iaas/Content/certificates/overview.htm",
+    "https://docs.oracle.com/iaas/Content/certificates/managing-certificates.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/Identity/Reference/certificatespolicyreference.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengusingworkloadidentity.htm"
   ],
-  "security_notes": "Instance Principal auth for cert-manager on OKE means ANY pod on the node can call the OCI Certificates API using the instance metadata endpoint — not just cert-manager. Use OKE Workload Identity to scope cert-issuance permissions to the cert-manager ServiceAccount only. IAM policy with 'manage certificate-authorities' grants delete and update CA permissions, which is excessive for cert-manager.",
-  "last_verified": "2026-05-02",
+  "security_notes": "Read-only advisory by default. Use least privilege, sanitize evidence, and require explicit approval plus rollback for risky OCI Certificates Issuer Review changes.",
+  "last_verified": "2026-06-05",
   "path": "skills/oci/oci-certificates-issuer-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-certificates-issuer-review/references/certificates-issuer-operations.md

@@ -0,0 +1,69 @@
+# OCI Certificates Issuer Review 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
+
+- Using a root CA directly for workload certificate issuance.
+- Granting broad certificate-authority management permissions to cert-manager or automation.
+- Assuming instance-level identity is equivalent to pod/service-account scoped workload identity.
+- Skipping OCSP/revocation reachability because most clients soft-fail.
+
+## 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 certificate and certificate-authority list operations expose compartment, lifecycle-state, name, issuer CA, certificate ID, and sorting filters. Treat this as API shape evidence, not proof of CA safety.
+- 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
+
+- Keep root CAs out of routine workload issuance.
+- Use subordinate CA and issuance rules for cert-manager-style automation.
+- Use least-privilege IAM scoped to issuance needs, not CA deletion/update authority.
+- Prefer workload identity for pod-scoped issuance over broad node-level authority.
+- Never expose private keys, CA material, certificate bundles with secrets, or customer identifiers in chat.
+
+## Minimal safe implementation flow
+
+- Identify issuer, CA hierarchy, OKE/authentication model, and namespace/service-account boundary.
+- Review official Certificates, IAM policy, and OKE workload identity guidance.
+- Collect sampled read-only API evidence for CAs/certificates where available.
+- Classify findings by CA hierarchy, issuance constraints, IAM, OCSP, and lifecycle.
+- Return severity, evidence label, remediation, approval needs, and safe validation.
+
+## High-risk assumptions to kill
+
+- “A certificate was issued, so the issuer is safe.”
+- “A root CA in the service is harmless if access is “limited.””
+- “Node/instance authority is close enough for cert-manager.”
+- “Broad manage permissions are needed for certificate requests.”
+- “Revocation checking can be ignored because clients usually soft-fail.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- List CA and certificate metadata in the confirmed compartment only.
+- Check CA type, issuer chain, lifecycle state, rule constraints, expiration, and certificate-version count.
+- Inspect IAM policy text for request-specific conditions and reject broad CA management unless explicitly justified.
+- Verify OKE workload identity binding and service account scope for issuer automation.
+- Check OCSP/revocation path reachability and documented fallback behavior before calling trust posture ready.
+
+## 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-certificates-issuer-review/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-certificates-issuer-review/references/official-sources.md

@@ -0,0 +1,21 @@
+# Official sources
+
+Use this reference when grounding current OCI behavior for `oci-certificates-issuer-review`.
+
+## Oracle documentation sources
+
+- https://docs.oracle.com/iaas/Content/certificates/overview.htm
+- https://docs.oracle.com/iaas/Content/certificates/managing-certificates.htm
+- https://docs.oracle.com/en-us/iaas/Content/Identity/Reference/certificatespolicyreference.htm
+- https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengusingworkloadidentity.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-certificates-issuer-review/references/safety-checklist.md

@@ -0,0 +1,16 @@
+# Safety checklist
+
+Use before OCI Certificates Issuer Review production recommendations, privileged access, cloud mutations, remediation actions, or readiness claims.
+
+## Non-negotiables
+
+- Do not ask for or print credentials, tokens, private keys, API keys, config files, tenancy identifiers, compartment identifiers, resource identifiers, customer data, wallets, 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, 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.
+
+## Evidence labels
+
+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.