npm - @raishin/vanguard-frontier-agentic - Versions diffs - 2.7.1 → 2.9.0 - Mend

@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (2104) hide show

package/skills/oci/oci-certificates-issuer-review/references/workflow-and-output.md CHANGED Viewed

@@ -1,207 +1,24 @@
-# Workflow and Output Contract
+# Workflow and output contract
-## Review Workflow
+Use this reference for full OCI Certificates Issuer Review reviews.
-### Step 1 — Identify the CA and issuer configuration
+## Workflow
-Retrieve the OCI cert-manager issuer resource:
+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.
-```bash
-kubectl get issuer -A -o yaml | grep -A20 "oci\|oracle"
-kubectl get clusterissuer -o yaml | grep -A20 "oci\|oracle"
-```
+## Output contract
-Extract the CA OCID from the issuer spec. Then inspect the CA in OCI:
+Return:
-```bash
-oci certs-mgmt certificate-authority get \
-  --certificate-authority-id <ca-ocid>
-```
-Key fields to check:
-- `type` — must be `SUBORDINATE` (not `ROOT`)
-- `lifecycleState` — must be `ACTIVE`
-- `issuerCertificateAuthorityId` — should reference a ROOT CA that is itself INACTIVE or not used for direct issuance
-### Step 2 — Validate CA type (root vs subordinate)
-```bash
-oci certs-mgmt certificate-authority get \
-  --certificate-authority-id <ca-ocid> \
-  --query data.config-type \
-  --raw-output
-```
-Expected values:
-- `SUBORDINATE_CA_ISSUED_BY_INTERNAL_CA` — correct for cert-manager usage
-- `ROOT_CA_GENERATED_INTERNALLY` — CRITICAL finding; root directly exposed to cert-manager
-Also check the issuer CA's status:
-```bash
-oci certs-mgmt certificate-authority get \
-  --certificate-authority-id <ca-ocid> \
-  --query data.lifecycle-state \
-  --raw-output
-```
-### Step 3 — Review issuance rules
-List issuance rules configured on the CA:
-```bash
-oci certs-mgmt certificate-authority get \
-  --certificate-authority-id <ca-ocid> \
-  --query "data.certificate-authority-rules"
-```
-Check for:
-```json
-{
-  "ruleType": "CERTIFICATE_AUTHORITY_MAX_VALIDITY_RULE",
-  "certificateMaxValidityDuration": "P90D"
-}
-```
-And key algorithm restriction:
-```json
-{
-  "ruleType": "CERTIFICATE_AUTHORITY_ISSUANCE_EXPIRY_RULE",
-  "leafCertificateMaxValidityDuration": "P90D",
-  "certificateAuthorityMaxValidityDuration": "P3650D"
-}
-```
-**Flags:**
-- No issuance rules configured (no validity cap) — MEDIUM (cert-manager can issue 10-year workload certs)
-- Max validity > 365d for leaf certificates — MEDIUM
-- No key algorithm restriction — MEDIUM (RSA-1024 issuance possible)
-### Step 4 — Identify authentication method
-Check the cert-manager configuration for OCI auth method:
-```bash
-# Check if OKE Workload Identity is configured
-kubectl get serviceaccount cert-manager -n cert-manager \
-  -o jsonpath='{.metadata.annotations}'
-```
-For OKE Workload Identity, the ServiceAccount should have OCI annotations:
-```yaml
-annotations:
-  oci.oraclecloud.com/role-binding: "<dynamic-group-name>"
-```
-For Instance Principal auth, check if the cert-manager pod uses the instance metadata endpoint:
-```bash
-# Check the cert-manager deployment for OCI config
-kubectl get deployment cert-manager -n cert-manager -o yaml | grep -i "oci\|instance\|workload"
-```
-**Auth method comparison:**
-| Method | Scope | Risk |
-|--------|-------|------|
-| OKE Workload Identity | ServiceAccount-bound (pod-level) | Correct — minimum scope |
-| Instance Principal | Node-level (all pods on node) | HIGH — any pod can issue certs |
-| User auth (API key) | User credentials in secret | HIGH — credential rotation required |
-### Step 5 — Review IAM policy
-Retrieve the IAM policy for cert-manager:
-```bash
-oci iam policy list --compartment-id <compartment-id> --all \
-  --query "data[?contains(statements[0], 'certificate-authority')]"
-```
-Minimum required policy statement:
-```
-Allow dynamic-group CertManagerDynamicGroup to use certificate-authorities
-  in compartment <compartment-name>
-  where request.permission='CREATE_CERTIFICATE_REQUEST'
-```
-**Flag as HIGH if the policy includes any of:**
-- `manage certificate-authorities` (grants delete, update, disable, schedule-deletion)
-- `manage certificates` without compartment scoping (affects all certs)
-- Wildcard resources or compartment `tenancy` instead of scoped compartment
-Additional permissions needed for cert-manager to retrieve issued certs:
-```
-Allow dynamic-group CertManagerDynamicGroup to read certificates
-  in compartment <compartment-name>
-```
-### Step 6 — Check OCSP reachability
-The OCI OCSP endpoint is `ocsp.pki.oraclecloud.com`. Verify reachability from OKE worker nodes:
-```bash
-# From within an OKE node or debug pod
-curl -sv https://ocsp.pki.oraclecloud.com/
-```
-For OKE clusters with no internet gateway or restrictive security group rules:
-```bash
-# Check security list / NSG rules for outbound HTTPS to OCI OCSP
-oci network security-list list --vcn-id <vcn-id> \
-  --query "data[].egress-security-rules[]"
-```
-OCI OCSP endpoints use HTTPS (443). Ensure the OKE worker node security group allows outbound TCP/443 to OCI service endpoints. Using a Service Gateway with the `OCI Services in Oracle Services Network` service covers OCI PKI endpoints.
-**Flags:**
-- No Service Gateway configured and no internet gateway (OCI OCSP unreachable) — MEDIUM
-- Security group blocks TCP/443 outbound to OCI service network — MEDIUM
-### Step 7 — Review certificate version count
-```bash
-oci certs-mgmt certificate list-certificate-versions \
-  --certificate-id <cert-ocid> \
-  --all \
-  --query "length(data)"
-```
-Each cert rotation by cert-manager creates a new version. Old versions should be cleaned up to avoid high version counts.
-**Flags:**
-- Certificate version count > 10 — LOW (storage cost and management overhead)
-- No automated cleanup of old versions configured — LOW
----
-## Output Format
-### Finding: `<short title>`
-| Field | Value |
-|-------|-------|
-| Severity | CRITICAL / HIGH / MEDIUM / LOW |
-| Resource | CA OCID, IAM policy name, or cert name |
-| Evidence | documentation-based / live evidence / inference |
-| Description | What is wrong and its impact on PKI trust |
-| Remediation | OCI CLI command, IAM policy statement, or configuration change |
----
-### Overall OCI PKI Trust Posture
-| Category | Status |
-|----------|--------|
-| CA hierarchy (subordinate only) | PASS / FAIL |
-| Issuance rules (validity caps) | PASS / FAIL |
-| Authentication method (Workload Identity) | PASS / FAIL |
-| IAM policy scope (minimum permissions) | PASS / FAIL |
-| OCSP reachability | PASS / FAIL |
-| Certificate version lifecycle | PASS / FAIL |
-**Verdict:** TRUSTED / UNTRUSTED / CONDITIONAL (list conditions)
+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-cloud-guard-responder/SKILL.md CHANGED Viewed

@@ -1,110 +1,51 @@
 ---
 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.
-allowed-tools: Read Grep Glob WebFetch
+description: Triage OCI Cloud Guard problems, targets, detector recipes, responder recipes, suppression, and remediation plans with evidence labels and approval gates.
+allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
-  version: 0.1.0
-  updated: "2026-05-05"
+  version: 0.1.1
+  updated: "2026-06-05"
   category: security
 ---
 # OCI Cloud Guard Responder
-## Role Charter
+## Purpose
-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.
+Act as a ruthless OCI Cloud Guard responder. Stop auto-remediation, dismissal, and compliance claims that lack scoped problem evidence, owner approval, responder blast-radius review, and rollback.
-## Trigger Situations
+Use this skill for:
-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.
+- Cloud Guard targets and scope
+- problem triage and severity/risk prioritization
+- detector and responder recipe behavior
+- dismissal, suppression, and remediation governance
+- security evidence for compliance reporting
+## Lean operating rules
-## 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
+- 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.
-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:
+## References
-## Findings
-| Finding | Severity | Evidence | Recommendation | Owner |
-|---|---|---|---|---|
+Load these only when needed:
-## Safe next actions
-1.
-2.
-3.
+- [OCI Cloud Guard Responder Operations](references/cloud-guard-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.
-## Open questions
--
-```
+## Response minimum
-## Red Flags
+Return, at minimum:
-- 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.
+- 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-cloud-guard-responder/metadata.json CHANGED Viewed

@@ -11,15 +11,15 @@
     "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...",
+  "summary": "Triage OCI Cloud Guard problems, targets, detector recipes, responder recipes, suppression, and remediation plans with evidence labels and approval gates.",
   "source_type": "adapted",
   "official_docs": [
-    "https://docs.oracle.com/en-us/iaas/Content/home.htm",
-    "https://www.oracle.com/cloud/"
+    "https://docs.oracle.com/en-us/iaas/cloud-guard/home.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/cloud-guard/using/cg-concepts.htm"
   ],
-  "security_notes": "OCI skills may inspect or mutate cloud resources. Use least-privilege credentials, read-only discovery first, and explicit approval for changes.",
-  "last_verified": "2026-04-27",
+  "security_notes": "Read-only advisory by default. Use least privilege, sanitize evidence, and require explicit approval plus rollback for risky OCI Cloud Guard Responder changes.",
+  "last_verified": "2026-06-05",
   "path": "skills/oci/oci-cloud-guard-responder",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-cloud-guard-responder/references/cloud-guard-operations.md ADDED Viewed

@@ -0,0 +1,69 @@
+# OCI Cloud Guard Responder 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
+- Closing or dismissing problems because they are noisy.
+- Enabling responder automation without checking what it can mutate.
+- Treating Oracle-managed recipe defaults as static forever.
+- Using root-compartment or subtree queries without understanding partial-access behavior.
+## 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 Cloud Guard problem list operations expose compartment, subtree/access-level, detector type, target, problem category, resource, risk level, lifecycle, and detection-time filters. Treat this as API shape evidence, not proof of full 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
+- Separate detection evidence from remediation opinion.
+- Never close, dismiss, suppress, or auto-remediate without owner, rationale, and blast-radius review.
+- Review detector and responder recipes before enabling automated actions.
+- Label Cloud Guard results as sampled evidence unless every target/scope was intentionally covered.
+- Keep current-state evidence separate from official docs.
+## Minimal safe implementation flow
+- Confirm target, compartment, resource type, environment, owner, and requested action.
+- Collect read-only problem, target, detector, and responder evidence when available.
+- Prioritize by risk level, resource criticality, exploitability, and recurrence.
+- Review responder side effects and IAM before remediation.
+- Return verdict, problem table, safe next actions, approvals, and open questions.
+## High-risk assumptions to kill
+- “Cloud Guard enabled means the tenancy is secure.”
+- “A problem can be dismissed because it appears expected.”
+- “Responder recipes are safe because Oracle provides defaults.”
+- “A list query from one compartment proves full-tenancy posture.”
+- “Compliance evidence is valid without target coverage and exception rationale.”
+Those are lazy assumptions.
+## Safe command/code verification targets
+- List problems only for confirmed scope and document access-level/subtree behavior.
+- Check detector type, resource, risk, first/last detected time, lifecycle detail, and target ID.
+- Review target coverage, detector recipe customizations, responder recipe enablement, and suppression rationale.
+- Require owner approval and rollback path before responder actions or problem status updates.
+- Correlate repeated problems with policy, IAM, network, and resource-owner remediation plans.
+## 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-cloud-guard-responder/references/mcp-and-evidence.md ADDED Viewed

@@ -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-cloud-guard-responder/references/official-sources.md ADDED Viewed

@@ -0,0 +1,19 @@
+# Official sources
+Use this reference when grounding current OCI behavior for `oci-cloud-guard-responder`.
+## Oracle documentation sources
+- https://docs.oracle.com/en-us/iaas/cloud-guard/home.htm
+- https://docs.oracle.com/en-us/iaas/Content/cloud-guard/using/cg-concepts.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-cloud-guard-responder/references/safety-checklist.md CHANGED Viewed

@@ -1,32 +1,16 @@
-# Safety Checklist
+# Safety checklist
-Use this checklist before recommending or executing changes for `oci-cloud-guard-responder`.
+Use before OCI Cloud Guard Responder production recommendations, privileged access, cloud mutations, remediation actions, or readiness claims.
-## Scope
+## Non-negotiables
-- Region confirmed.
-- Compartment or compartment tree confirmed.
-- Resource identity confirmed by name and, when available, live evidence.
-- Owner and business impact confirmed.
-- Environment confirmed: dev/test/stage/prod.
+- Do not ask for or print credentials, tokens, private keys, API keys, config files, tenancy identifiers, compartment identifiers, resource identifiers, customer data, wallets, 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 tenancy-wide grants unless risk-accepted.
-- No secrets requested or displayed.
-## Change safety
-- Read-only discovery first.
-- Explicit approval for write, delete, start, stop, update, policy, traffic, SQL, command execution, or remediation actions.
-- Rollback path documented.
-- Validation plan includes positive and negative checks.
-## Platform portability
-- Prefer MCP tool calls.
-- Use neutral `<placeholders>` in examples.
-- Do not assume Bash, PowerShell, cmd.exe, macOS, Windows, or Linux until execution context is known.
-- Do not embed machine-local paths.
+Use `documentation-based`, `sampled OCI API evidence`, `sampled current-state evidence`, `repo evidence`, `user-provided sanitized evidence`, or `inference`. Documentation alone never proves the user's live OCI posture.

package/skills/oci/oci-cloud-guard-responder/references/workflow-and-output.md ADDED Viewed

@@ -0,0 +1,24 @@
+# Workflow and output contract
+Use this reference for full OCI Cloud Guard Responder 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