@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/oci/oci-live-network-security-rule-guard/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-live-network-security-rule-guard/references/network-security-rule-operations.md

@@ -0,0 +1,65 @@
+# OCI Live Network Security Rule Guard 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
+
+- Adding open ingress for speed and promising to clean it later.
+- Changing a Security List without realizing every associated subnet/VNIC is affected.
+- Skipping current-state capture and calling that rollback.
+- Ignoring stateful/stateless behavior and path validation.
+
+## Officially grounded service shape
+
+- Official OCI documentation describes Security Lists and Network Security Groups as virtual firewall features using security rules at packet level.
+- Official OCI documentation recommends NSGs for finer scope where supported and explains that Security Lists apply to all VNICs in associated subnets.
+- Official OCI documentation explains security rules, stateful/stateless behavior, and comparisons between Security Lists and NSGs.
+- OCI API evidence through the user’s configured read-only OCI MCP shows Security List get requires the target security-list identifier and NSG rules listing can filter by direction, sorting, and pagination. Treat this as API-shape evidence, not approval to change rules.
+
+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
+
+- Capture current rule state before any mutation.
+- Flag open internet ingress, all-protocol egress, database ports, management ports, and database subnets as high risk.
+- Prefer narrow source/destination, NSG-based scope where supported, explicit protocol/port, owner approval, and timed rollback.
+- Do not expose network identifiers, private endpoints, customer CIDRs, credentials, or sensitive topology.
+
+## Minimal safe implementation flow
+
+- Confirm target VCN component, rule delta, business justification, owner, criticality, and rollback plan.
+- Use official docs for rule semantics and sampled read-only evidence for API shape/current state.
+- Classify rule risk by direction, source/destination, protocol, port, statefulness, and subnet criticality.
+- Return verdict, required approvals, rollback baseline, safer alternative, and post-change verification.
+
+## High-risk assumptions to kill
+
+- “One rule affects only one workload.”
+- “Open ingress is temporary, so it is safe.”
+- “Rollback exists because we can edit it again.”
+- “Connectivity success proves security acceptability.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- Capture current Security List or NSG rules before mutation.
+- Check direction, source/destination, protocol, port, statefulness, subnet attachment, and workload criticality.
+- Use path analysis or equivalent connectivity validation where appropriate.
+- Validate logs, reachability, and rollback after change.
+
+## 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 to open broad ingress or egress without justification and expiry.
+- Current rules were not captured before mutation.
+- The target component or blast radius is ambiguous.

package/skills/oci/oci-live-network-security-rule-guard/references/official-sources.md

@@ -1,21 +1,22 @@
-# Official Sources
+# Official sources
 
-Load these only when needed:
+Use these sources to ground service behavior before making production recommendations.
 
-- [Security Lists](https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/securitylists.htm) — use for Security List model, ingress/egress rule structure, stateful vs stateless semantics, and maximum rule limits.
-- [Network Security Groups](https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/networksecuritygroups.htm) — use for NSG model, VNIC-level vs subnet-level application, and NSG vs Security List trade-offs.
-- [Managing NSG Security Rules](https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/manage-nsg-security-rules.htm) — use for `oci network nsg rules add`, `update`, `remove`, and `list` CLI syntax.
-- [Updating a Security List](https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/update-securitylist.htm) — use for `oci network security-list update` full-replace semantics and required parameters.
-- [Network Path Analyzer](https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/path_analyzer.htm) — use for simulating end-to-end network paths through Security Lists, NSGs, route tables, and gateways before approving a rule change.
-- [VCN Flow Logs](https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/vcn-flow-logs.htm) — use when enabling forensic coverage for a subnet before or after a security rule change.
-- [OCI IAM Policy Reference — Network](https://docs.oracle.com/en-us/iaas/Content/Identity/Reference/networkpolicyreference.htm) — use for least-privilege IAM policy statements covering `security-lists`, `network-security-groups`, and `virtual-network-family`.
+## Oracle documentation checked on 2026-06-05
 
-## Grounded insights worth carrying into the skill
+- https://docs.oracle.com/iaas/Content/Network/Concepts/securitylists.htm
+- https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/networksecuritygroups.htm
+- https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/securityrules.htm
+- https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/path_analyzer.htm
 
-- `oci network security-list update` performs a **full replace** of the entire ingress or egress rule set — partial updates are not possible. Always pass the complete desired rule list including rules you want to keep.
-- OCI Security Lists are **stateful by default** (`stateless: false`). Return traffic is automatically allowed. Stateless rules require explicit return rules and are a common source of asymmetric traffic failures.
-- NSG rule IDs are required for deletion (`oci network nsg rules remove`). Capture rule IDs from `oci network nsg rules list` before any mutation.
-- A Security List is attached to a subnet, not a VNIC. One change affects every instance in that subnet simultaneously — blast radius scales with subnet size.
-- NSGs are attached to individual VNICs, giving finer-grained control but requiring per-VNIC management. Prefer NSGs for production database servers over Security Lists for reduced blast radius.
-- VCN Flow Logs must be explicitly enabled per subnet — they are not on by default. Without them, there is no record of traffic through an accidentally opened rule.
-- The `0.0.0.0/0` ingress source in OCI context still includes traffic from peered VCNs, DRG-attached networks, and FastConnect circuits if routing allows — it is never safe to assume it means "internet only."
+## Sampled read-only OCI API evidence checked on 2026-06-05
+
+- OCI API evidence through the user's configured read-only OCI MCP was used for command/API surface shape only.
+- Command-help evidence confirms available list/filter surfaces; it does not prove permissions, resource existence, regional availability, capacity, quota, data correctness, or production readiness.
+
+## Grounding rules
+
+- Prefer the most specific Oracle documentation page for the service or feature being discussed.
+- If documentation and sampled API evidence appear to conflict, report the conflict and avoid stronger claims until resolved.
+- Do not cite internal tool names, local environment labels, connector identifiers, or environment-specific details in committed docs.
+- Do not paste sensitive identifiers or customer data into examples.

package/skills/oci/oci-live-network-security-rule-guard/references/safety-checklist.md

@@ -0,0 +1,35 @@
+# Safety checklist
+
+Use this checklist before producing guidance, requesting evidence, or proposing changes.
+
+## Evidence labels
+
+- `documentation-based`: grounded in official OCI documentation only.
+- `sampled-api-shape`: grounded in read-only command/API help or metadata evidence.
+- `sampled-current-state`: grounded in read-only observations from the configured environment.
+- `user-supplied`: grounded in sanitized user evidence.
+- `inference`: reasoned from incomplete evidence; never present it as fact.
+
+## Credential and identifier boundaries
+
+- Do not ask for credentials, tokens, private keys, API keys, config files, wallets, kubeconfigs, connection strings, customer data, or sensitive identifiers.
+- Do not commit environment-specific identifiers, internal tool names, local environment labels, connector IDs, or private endpoint details.
+- If the task requires live context, ask for a sanitized export or use approved read-only evidence paths.
+
+## Mutation boundary
+
+Require explicit approval before creating, updating, deleting, moving, scaling, rotating, patching, enabling, disabling, refreshing, restoring, cutting over, opening network access, changing quotas, changing budgets, or changing access.
+
+## Approval gates
+
+- Confirm scope, owner, environment criticality, maintenance window, rollback plan, and validation target.
+- Separate read-only discovery from write actions.
+- Prefer least privilege and reversible changes.
+- Stop if evidence conflicts or if the blast radius is unknown.
+
+## Final-answer minimum
+
+- State evidence level and scope.
+- List blockers and unsafe assumptions.
+- Give safe next actions before risky actions.
+- Name what was not proved.

package/skills/oci/oci-live-network-security-rule-guard/references/workflow-and-output.md

@@ -0,0 +1,26 @@
+# Workflow and output contract
+
+Use this workflow for full reviews and live-guard decisions.
+
+## Execution flow
+
+1. Confirm the target service, scope, environment criticality, and desired decision.
+2. Load official source guidance and this skill's operations reference.
+3. Gather read-only OCI API evidence through the user's configured read-only OCI MCP only when current-state or API-shape evidence is needed.
+4. Classify findings as fact, sampled evidence, inference, blocker, or recommendation.
+5. Challenge broad permissions, destructive shortcuts, weak rollback, and unsupported production claims.
+6. Return concise findings with safe next actions and explicit unknowns.
+
+## Output contract
+
+Return these fields when the user asks for a review, guardrail, or production-readiness answer:
+
+- `verdict`: pass, pass-with-risk, blocked, or needs-evidence.
+- `evidence_level`: documentation-based, sampled-api-shape, sampled-current-state, user-supplied, or inference.
+- `blockers`: missing proof, unsafe assumptions, or approval gaps.
+- `safe_next_actions`: least-risk steps the user can take next.
+- `open_questions`: only questions that materially change the decision.
+
+## Tone
+
+Be blunt. Do not validate a weak plan. If the evidence is thin, say so and narrow the recommendation.

package/skills/oci/oci-live-oke-rollout-guard/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: oci-live-oke-rollout-guard
-description: Guard OKE deployment rollouts via DevOps Service approval stages with canary and blue-green evidence, rollout health verification, and kubectl rollout undo gates.
-allowed-tools: Read Grep Glob WebFetch
+description: Guard OCI OKE and DevOps deployment rollouts with approval-stage, canary, blue-green, workload health, rollback, and Kubernetes safety evidence before promotion or rollback.
+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: delivery
 ---
 
@@ -13,40 +13,39 @@ metadata:
 
 ## Purpose
 
-Act as the guarded live OCI operator for oci-live-oke-rollout-guard work. Insist on preview evidence before execution and treat ambiguous target or approval state as a stop condition.
+Act as a blunt OCI guard or router for this domain. Kill unverified readiness claims, broad routing, destructive shortcuts, weak rollback, and source-free operational advice.
 
-## When to use
+Use this skill for:
 
-Use this skill when:
-
-- an OKE deployment rollout must advance through a DevOps Service pipeline approval stage
-- a blue-green or canary OKE deployment is in flight and the operator must decide to promote or rollback
-- a kubectl rollout is paused on a live OKE cluster and an undo or resume decision is required
+- OKE rollout promotion or rollback decisions
+- DevOps deployment approval-stage review
+- canary and blue-green deployment safety checks
+- Kubernetes workload health, PDB, and readiness-gate review
+- post-rollout verification and rollback planning
 
 ## Lean operating rules
 
-- Prefer OCI CLI (`oci`) official documentation when available; fall back to Oracle Cloud docs and sanitized user evidence.
-- Do not execute a live OCI change until tenancy, compartment, active principal, and resource ownership are explicit.
-- Prefer plan, detect-drift, inspect, read, describe, and rollback evidence before execution.
-- If the request skips preview or rollback design, push back.
-- Never print secrets, API keys, tenancy OCIDs, private key contents, or raw config values. Summarize sanitized evidence only.
-- Load references only when needed.
+- 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, production claims, and live-guard dispatch without evidence.
+- Keep the answer scoped, reversible where possible, least-privilege, and explicit about blockers or unknowns.
+- Never ask the user to paste credentials, tokens, private keys, API keys, config files, tenancy identifiers, compartment identifiers, resource identifiers, customer data, wallets, kubeconfigs, connection strings, or secrets.
 
 ## References
 
 Load these only when needed:
 
-- [Preflight commands](references/preflight-commands.md) — OCI CLI commands to run before any mutation.
-- [Rollback playbook](references/rollback-playbook.md) — concrete rollback steps for this service.
-- [Permission model](references/permission-model.md) — OCI IAM policy statements and dynamic group guidance.
-- [Official sources](references/official-sources.md) — authoritative OCI documentation links.
+- [OCI Live OKE Rollout Guard Operations](references/oke-rollout-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
 
 Return, at minimum:
 
-- confirmed tenancy, compartment, and active principal
-- preflight evidence (plan output, drift result, inspect/read, health check)
-- approval status for the proposed mutation
-- rollback posture or explicit statement of what cannot be rolled back
-- post-action verification steps or refusal reason
+- the scoped target and evidence level,
+- the main risks, control gaps, or routing decision,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/oci/oci-live-oke-rollout-guard/metadata.json

@@ -11,17 +11,18 @@
     "kiro",
     "other"
   ],
-  "summary": "Guard OKE deployment rollouts via DevOps Service approval stages with canary and blue-green evidence, rollout health verification, and kubectl rollout undo gates.",
+  "summary": "Guard OCI OKE and DevOps deployment rollouts with approval-stage, canary, blue-green, workload health, rollback, and Kubernetes safety evidence before promotion or rollback.",
   "source_type": "original",
   "official_docs": [
+    "https://docs.oracle.com/en-us/iaas/Content/devops/using/devops_overview.htm",
     "https://docs.oracle.com/en-us/iaas/Content/devops/using/deploy_oke.htm",
     "https://docs.oracle.com/en-us/iaas/Content/devops/using/bgoke_deploy.htm",
     "https://docs.oracle.com/en-us/iaas/Content/devops/using/canaryoke_deploy.htm",
     "https://docs.oracle.com/en-us/iaas/Content/ContEng/Concepts/contengoverview.htm"
   ],
-  "security_notes": "Never advance an OKE rollout past an approval stage without rollout status and PDB health evidence. kubectl rollout undo is irreversible in the sense that the prior version may not be identical to the deployed artifact \u2014 confirm target revision before undo.",
-  "last_verified": "2026-04-30",
+  "security_notes": "OCI skills must use official documentation and read-only discovery first, keep identifiers and secrets out of prompts and committed docs, and require explicit approval before mutations.",
+  "last_verified": "2026-06-05",
   "path": "skills/oci/oci-live-oke-rollout-guard",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-live-oke-rollout-guard/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-live-oke-rollout-guard/references/official-sources.md

@@ -1,18 +1,23 @@
-# Official Sources: OCI Live OKE Rollout Guard
+# Official sources
 
-## OCI Container Engine for Kubernetes (OKE)
+Use these sources to ground service behavior before making production recommendations or routing decisions.
 
+## Oracle documentation checked on 2026-06-05
+
+- https://docs.oracle.com/en-us/iaas/Content/devops/using/devops_overview.htm
+- https://docs.oracle.com/en-us/iaas/Content/devops/using/deploy_oke.htm
+- https://docs.oracle.com/en-us/iaas/Content/devops/using/bgoke_deploy.htm
+- https://docs.oracle.com/en-us/iaas/Content/devops/using/canaryoke_deploy.htm
 - https://docs.oracle.com/en-us/iaas/Content/ContEng/Concepts/contengoverview.htm
-- https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengupgradingk8sworkernode.htm
-- https://docs.oracle.com/en-us/iaas/Content/DevOps/Concepts/devopsoverview.htm
 
-## Kubernetes rolling updates
+## Sampled read-only OCI API evidence checked on 2026-06-05
 
-- https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment
-- https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-back-a-deployment
-- https://kubernetes.io/docs/tasks/run-application/configure-pdb/
+- OCI API evidence through the user's configured read-only OCI MCP was used for command/API surface shape only where applicable.
+- Command-help evidence confirms available list/filter surfaces; it does not prove permissions, resource existence, regional availability, capacity, quota, data correctness, traffic safety, catalog correctness, or production readiness.
 
-## Source-grounding rule
+## Grounding rules
 
-Use official Oracle Cloud Infrastructure and Kubernetes.io documentation as source of truth.
-OCI DevOps pipeline stage configuration details must be verified from current OCI docs.
+- Prefer the most specific Oracle documentation page for the service or feature being discussed.
+- If documentation, catalog, and sampled API evidence appear to conflict, report the conflict and avoid stronger claims until resolved.
+- Do not cite internal tool names, local environment labels, connector identifiers, or environment-specific details in committed docs.
+- Do not paste sensitive identifiers or customer data into examples.

package/skills/oci/oci-live-oke-rollout-guard/references/oke-rollout-operations.md

@@ -0,0 +1,65 @@
+# OCI Live OKE Rollout Guard Operations
+
+> Version note: OCI service behavior, catalog entries, and tooling change over time. Verify exact command syntax, permissions, regional availability, feature maturity, and catalog targets 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
+
+- Promoting because the deployment object succeeded while pods, PDBs, ingress, or metrics are unhealthy.
+- Treating canary or blue-green as safe without traffic-split and rollback evidence.
+- Running rollback without confirming target revision and artifact provenance.
+- Ignoring node capacity, image pull, secrets, network policy, and service health.
+
+## Officially grounded service shape
+
+- Official OCI documentation describes DevOps as CI/CD for deployments to OCI platforms including OKE and supports blue-green and canary strategies.
+- Official OCI documentation describes OKE as managed Kubernetes infrastructure, but Kubernetes rollout health still depends on workload, node, network, and application evidence.
+- OCI API evidence through the user’s configured read-only OCI MCP shows cluster listing is compartment-scoped and can filter by lifecycle state and name.
+- OCI API evidence through the user’s configured read-only OCI MCP shows DevOps deployment listing can filter by compartment, project, pipeline, lifecycle state, display name, time, sorting, and pagination.
+
+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
+
+- Separate DevOps control-plane status from Kubernetes workload health and application SLO evidence.
+- Require explicit approval before promote, rollback, resume, abort, or production traffic shift.
+- Validate readiness, liveness, PDBs, replicas, events, metrics, logs, ingress, backend health, and rollback revision.
+- Do not expose kubeconfigs, tokens, secrets, endpoint details, customer data, or sensitive identifiers.
+
+## Minimal safe implementation flow
+
+- Confirm cluster, namespace, workload, pipeline, strategy, traffic path, and requested decision using sanitized labels.
+- Use official docs for DevOps/OKE behavior and sampled read-only evidence for API shape/current deployment state.
+- Assess canary/blue-green health, workload readiness, traffic routing, and rollback target.
+- Return verdict, blockers, approval state, safe next actions, and post-action validation checks.
+
+## High-risk assumptions to kill
+
+- “Deployment SUCCEEDED means users are safe.”
+- “Canary passed because no one complained.”
+- “Rollout undo returns exactly to the previous production state.”
+- “Cluster ACTIVE means workload capacity is healthy.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- Check cluster and deployment lifecycle without exposing identifiers.
+- Check pods, replicas, events, PDBs, services, ingress, metrics, logs, and backend health from sanitized evidence.
+- Confirm traffic split, artifact version, rollback revision, and approval gate.
+- Validate post-action SLOs and alert state before closing.
+
+## 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 or live-guard dispatch 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 to promote or rollback without workload health evidence.
+- The rollback target or artifact provenance is unclear.
+- The evidence includes kubeconfig, tokens, secrets, endpoints, or customer data.

package/skills/oci/oci-live-oke-rollout-guard/references/safety-checklist.md

@@ -0,0 +1,35 @@
+# Safety checklist
+
+Use this checklist before producing guidance, requesting evidence, routing a task, or proposing changes.
+
+## Evidence labels
+
+- `documentation-based`: grounded in official OCI documentation only.
+- `sampled-api-shape`: grounded in read-only command/API help or metadata evidence.
+- `sampled-current-state`: grounded in read-only observations from the configured environment.
+- `user-supplied`: grounded in sanitized user evidence.
+- `inference`: reasoned from incomplete evidence; never present it as fact.
+
+## Credential and identifier boundaries
+
+- Do not ask for credentials, tokens, private keys, API keys, config files, wallets, kubeconfigs, connection strings, customer data, or sensitive identifiers.
+- Do not commit environment-specific identifiers, internal tool names, local environment labels, connector IDs, or private endpoint details.
+- If the task requires live context, ask for a sanitized export or use approved read-only evidence paths.
+
+## Mutation boundary
+
+Require explicit approval before creating, updating, deleting, moving, scaling, rotating, patching, enabling, disabling, deploying, applying, destroying, promoting, rolling back, deleting keys, changing traffic, changing access, or changing production state.
+
+## Approval gates
+
+- Confirm scope, owner, environment criticality, maintenance window, rollback plan, and validation target.
+- Separate read-only discovery from write actions.
+- Prefer least privilege and reversible changes.
+- Stop if evidence conflicts or if the blast radius is unknown.
+
+## Final-answer minimum
+
+- State evidence level and scope.
+- List blockers and unsafe assumptions.
+- Give safe next actions before risky actions.
+- Name what was not proved.

package/skills/oci/oci-live-oke-rollout-guard/references/workflow-and-output.md

@@ -0,0 +1,26 @@
+# Workflow and output contract
+
+Use this workflow for full reviews, routing decisions, and live-guard decisions.
+
+## Execution flow
+
+1. Confirm the target service, scope, environment criticality, and desired decision.
+2. Load official source guidance and this skill's operations reference.
+3. Gather read-only OCI API evidence through the user's configured read-only OCI MCP only when current-state or API-shape evidence is needed.
+4. Classify findings as fact, sampled evidence, inference, blocker, or recommendation.
+5. Challenge broad permissions, destructive shortcuts, weak rollback, and unsupported production claims.
+6. Return concise findings with safe next actions and explicit unknowns.
+
+## Output contract
+
+Return these fields when the user asks for a review, guardrail, route, or production-readiness answer:
+
+- `verdict`: pass, pass-with-risk, blocked, needs-evidence, or routed.
+- `evidence_level`: documentation-based, sampled-api-shape, sampled-current-state, user-supplied, or inference.
+- `blockers`: missing proof, unsafe assumptions, approval gaps, or routing gaps.
+- `safe_next_actions`: least-risk steps the user can take next.
+- `open_questions`: only questions that materially change the decision.
+
+## Tone
+
+Be blunt. Do not validate a weak plan. If the evidence is thin, say so and narrow the recommendation.

package/skills/oci/oci-live-resource-manager-stack-guard/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: oci-live-resource-manager-stack-guard
-description: Guard OCI Resource Manager stack plan, apply, and destroy jobs with drift detection, state-version rollback, stack auto-lock awareness, and approval gates.
-allowed-tools: Read Grep Glob WebFetch
+description: Guard OCI Resource Manager stack plan, apply, destroy, import-state, drift, and state-version decisions with plan review, state-lock awareness, approval, rollback, and blast-radius evidence.
+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: delivery
 ---
 
@@ -13,40 +13,39 @@ metadata:
 
 ## Purpose
 
-Act as the guarded live OCI operator for oci-live-resource-manager-stack-guard work. Insist on preview evidence before execution and treat ambiguous target or approval state as a stop condition.
+Act as a blunt OCI guard or router for this domain. Kill unverified readiness claims, broad routing, destructive shortcuts, weak rollback, and source-free operational advice.
 
-## When to use
+Use this skill for:
 
-Use this skill when:
-
-- an OCI Resource Manager stack apply or destroy job must be run against a live environment
-- drift has been detected on a stack and resolution requires an apply job with human approval
-- a Resource Manager stack state must be inspected, imported, or rolled back after a partial apply
+- Resource Manager plan/apply/destroy review
+- stack drift detection and remediation decisions
+- state import or rollback planning
+- Terraform execution-plan and job-log review
+- live infrastructure mutation approval gates
 
 ## Lean operating rules
 
-- Prefer OCI CLI (`oci`) official documentation when available; fall back to Oracle Cloud docs and sanitized user evidence.
-- Do not execute a live OCI change until tenancy, compartment, active principal, and resource ownership are explicit.
-- Prefer plan, detect-drift, inspect, read, describe, and rollback evidence before execution.
-- If the request skips preview or rollback design, push back.
-- Never print secrets, API keys, tenancy OCIDs, private key contents, or raw config values. Summarize sanitized evidence only.
-- Load references only when needed.
+- 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, production claims, and live-guard dispatch without evidence.
+- Keep the answer scoped, reversible where possible, least-privilege, and explicit about blockers or unknowns.
+- Never ask the user to paste credentials, tokens, private keys, API keys, config files, tenancy identifiers, compartment identifiers, resource identifiers, customer data, wallets, kubeconfigs, connection strings, or secrets.
 
 ## References
 
 Load these only when needed:
 
-- [Preflight commands](references/preflight-commands.md) — OCI CLI commands to run before any mutation.
-- [Rollback playbook](references/rollback-playbook.md) — concrete rollback steps for this service.
-- [Permission model](references/permission-model.md) — OCI IAM policy statements and dynamic group guidance.
-- [Official sources](references/official-sources.md) — authoritative OCI documentation links.
+- [OCI Live Resource Manager Stack Guard Operations](references/resource-manager-stack-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
 
 Return, at minimum:
 
-- confirmed tenancy, compartment, and active principal
-- preflight evidence (plan output, drift result, inspect/read, health check)
-- approval status for the proposed mutation
-- rollback posture or explicit statement of what cannot be rolled back
-- post-action verification steps or refusal reason
+- the scoped target and evidence level,
+- the main risks, control gaps, or routing decision,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.