@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/oci/oci-observability-incident-responder/references/observability-incident-operations.md

@@ -0,0 +1,66 @@
+# OCI Observability Incident Responder Operations
+
+> Version note: OCI service behavior and tooling change over time. Verify exact command syntax, permissions, regional availability, and feature maturity against official 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
+
+- Treating an alarm as actionable without a runbook.
+- Muting or deleting alarms to reduce noise before proving business impact.
+- Searching logs without time window, compartment, service, and severity scope.
+- Granting broad admin to responders because the incident is urgent.
+
+## Officially grounded service shape
+
+- Official OCI documentation describes Monitoring as metrics and alarms for active/passive monitoring, with alarms sending messages when metric streams meet triggers.
+- Official OCI documentation describes event-based alarm notifications and repeat-notification behavior for point-in-time events.
+- Official OCI documentation describes Logging as a managed interface to access, enable, manage, and search logs; log groups are access-control boundaries for logs.
+- OCI API evidence through the user’s configured read-only OCI MCP shows alarm listing is compartment-scoped, supports subtree traversal only from root with tenancy-level permissions, and can filter by display name, lifecycle state, severity sorting, and pagination.
+- OCI API evidence through the user’s configured read-only OCI MCP shows log-group listing is compartment-scoped and can optionally traverse nested compartments.
+
+Documentation evidence proves documented service behavior. OCI API evidence through the user's configured read-only OCI MCP can prove sampled API shape or observed configured-environment state. Microsoft Learn documentation through the user's configured documentation MCP can prove documented Azure behavior. None of these prove broad tenancy/subscription posture, all-region availability, quota, or operational readiness.
+
+## Non-negotiable design rules
+
+- Separate symptom, signal, scope, severity, timeline, impact, owner, containment, and recovery evidence.
+- Require time window, compartment, service, metric/log source, alarm destination, and runbook before conclusions.
+- Treat alarm suppression, routing changes, log deletion, and automation permissions as high risk.
+- Do not expose log payloads, customer data, endpoints, identities, or sensitive identifiers.
+
+## Minimal safe implementation flow
+
+- Confirm incident scope, severity, service, time window, owner, and decision needed.
+- Use official docs for Monitoring/Logging behavior and sampled read-only evidence for API shape/current telemetry state.
+- Build evidence timeline from alarms, metrics, logs, events, notifications, service health, and recent changes.
+- Return verdict, impact, likely cause, containment, validation, and follow-up actions.
+
+## High-risk assumptions to kill
+
+- “No alarm means no incident.”
+- “FIRING means root cause is known.”
+- “Dashboard green means users are fine.”
+- “Admin access is required for response.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- Check alarm lifecycle, severity, destinations, query, suppression, metric namespace, and notification path.
+- Check log groups, logs, search permissions, time window, and sensitive payload handling.
+- Correlate metrics, logs, events, service health, and recent changes.
+- Validate containment and recovery with user-impact evidence.
+
+## 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 suppress alarms without owner and impact evidence.
+- The time window, compartment, service, or severity is vague.
+- The evidence contains unsanitized logs, customer data, credentials, or sensitive identifiers.

package/skills/oci/oci-observability-incident-responder/references/official-sources.md

@@ -0,0 +1,24 @@
+# Official sources
+
+Use these sources to ground service behavior before making production recommendations.
+
+## Official documentation checked on 2026-06-05
+
+- https://docs.oracle.com/en-us/iaas/Content/Monitoring/Concepts/monitoringoverview.htm
+- https://docs.oracle.com/en-us/iaas/Content/Monitoring/Tasks/update-alarm-event.htm
+- https://docs.oracle.com/en-us/iaas/Content/Logging/
+- https://docs.oracle.com/en-us/iaas/Content/Logging/Task/managinglogs.htm
+- https://docs.oracle.com/iaas/Content/Logging/Concepts/searchinglogs.htm
+
+## Sampled read-only 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.
+- Microsoft Learn documentation through the user's configured documentation MCP was used only where Azure interconnect behavior is in scope.
+- Command-help evidence confirms available list/filter surfaces; it does not prove permissions, resource existence, regional availability, capacity, quota, data correctness, traffic safety, or production readiness.
+
+## Grounding rules
+
+- Prefer the most specific official 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-observability-incident-responder/references/safety-checklist.md

@@ -1,32 +1,35 @@
-# Safety Checklist
+# Safety checklist
 
-Use this checklist before recommending or executing changes for `oci-observability-incident-responder`.
+Use this checklist before producing guidance, requesting evidence, or proposing changes.
 
-## Scope
+## Evidence labels
 
-- 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.
+- `documentation-based`: grounded in official 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.
 
-## Access
+## Credential and identifier boundaries
 
-- 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.
+- 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.
 
-## Change safety
+## Mutation boundary
 
-- 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.
+Require explicit approval before creating, updating, deleting, moving, scaling, rotating, patching, enabling, disabling, migrating, cutting over, changing traffic, changing routes, loading data, executing SQL writes, changing alarms, or changing access.
 
-## Platform portability
+## Approval gates
 
-- 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.
+- 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-observability-incident-responder/references/workflow-and-output.md

@@ -0,0 +1,27 @@
+# Workflow and output contract
+
+Use this workflow for full reviews and incident-style triage.
+
+## 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. Use Microsoft Learn documentation through the user's configured documentation MCP when Azure-specific connectivity or operations are in scope.
+5. Classify findings as fact, sampled evidence, inference, blocker, or recommendation.
+6. Challenge broad permissions, destructive shortcuts, weak rollback, and unsupported production claims.
+7. Return concise findings with safe next actions and explicit unknowns.
+
+## Output contract
+
+Return these fields when the user asks for a review, guardrail, migration, architecture, 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-recovery-service-operator/SKILL.md

@@ -1,110 +1,51 @@
 ---
 name: oci-recovery-service-operator
-description: Operate OCI Recovery Service protected databases, protection policies, recovery service subnets, backup health, redo status, and recovery metrics. Use for database recovery posture, protected database health, and restore readiness.
+description: Operate and review OCI Recovery Service protected databases, protection policies, recovery service subnets, backup health, redo status, recovery windows, and restore readiness without confusing backup configuration with recoverability.
 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: resilience
 ---
 
 # OCI Recovery Service Operator
 
-## Role Charter
+## Purpose
 
-Act as a ruthless oci recovery service operator. 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 blunt OCI reviewer for this domain. Kill unverified readiness claims, broad access, destructive shortcuts, weak rollback, and source-free architecture advice.
 
-## Trigger Situations
+Use this skill for:
 
-Use this skill when the user asks to:
-- Recovery Service protected database review.
-- Backup health, redo status, protection policy, recovery subnet, or recovery-window concern.
-- Database restore readiness and resilience review.
+- protected database backup and restore-readiness reviews
+- protection policy, retention, and retention-lock assessment
+- redo status, backup health, recovery window, and storage-location checks
+- Recovery Service subnet and network dependency review
+- database resilience, RPO/RTO, and restore validation planning
 
+## 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-recovery-mcp-server: list_protected_databases, get_protected_database, summarize_protected_database_health, summarize_protected_database_redo_status, summarize_backup_space_used, list_protection_policies, get_recovery_service_metrics
-
-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, kubeconfigs, connection strings, 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 Recovery Service, Database backups, Data Guard, Monitoring, and IAM. If live recovery feed is unavailable, label output as docs-based and request sanitized backup evidence.
-
-## 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 protected database, policy, subnet, recovery window, redo status, and last successful backup.
-- A configured protection policy is not proof of recoverability; require restore/validation evidence.
-- Escalate missing redo, failed backups, policy drift, or subnet/network dependency gaps.
-
-## 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 Recovery Service Operator Operations](references/recovery-service-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-recovery-service-operator/metadata.json

@@ -11,15 +11,16 @@
     "kiro",
     "other"
   ],
-  "summary": "Operate OCI Recovery Service protected databases, protection policies, recovery service subnets, backup health, redo status, and recovery metrics. Use for database recovery posture, protected database health, and restore readiness.",
+  "summary": "Operate and review OCI Recovery Service protected databases, protection policies, recovery service subnets, backup health, redo status, recovery windows, and restore readiness without confusing backup configuration with recoverability.",
   "source_type": "adapted",
   "official_docs": [
-    "https://docs.oracle.com/en-us/iaas/Content/home.htm",
-    "https://www.oracle.com/cloud/"
+    "https://docs.oracle.com/iaas/recovery-service/doc/overview-protection-policy.html",
+    "https://docs.oracle.com/en-us/iaas/recovery-service/doc/protected-database-recovery-policy.html",
+    "https://docs.oracle.com/en-us/iaas/recovery-service/doc/supported-recovery-service-policies.html"
   ],
-  "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": "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-recovery-service-operator",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-recovery-service-operator/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-recovery-service-operator/references/official-sources.md

@@ -0,0 +1,21 @@
+# Official sources
+
+Use these sources to ground service behavior before making production recommendations.
+
+## Oracle documentation checked on 2026-06-05
+
+- https://docs.oracle.com/iaas/recovery-service/doc/overview-protection-policy.html
+- https://docs.oracle.com/en-us/iaas/recovery-service/doc/protected-database-recovery-policy.html
+- https://docs.oracle.com/en-us/iaas/recovery-service/doc/supported-recovery-service-policies.html
+
+## 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, control coverage, 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-recovery-service-operator/references/recovery-service-operations.md

@@ -0,0 +1,65 @@
+# OCI Recovery Service Operator 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
+
+- Treating a protection policy as proof of recoverability.
+- Ignoring redo status, last successful backup, subnet/network dependency, and restore-test evidence.
+- Assuming retention lock fixes bad backup scope or failed backups.
+- Claiming RPO/RTO compliance without restore validation.
+
+## Officially grounded service shape
+
+- Official OCI documentation says Recovery Service uses protection policies to control backup retention, backup storage location, and backup protection for protected databases.
+- Official OCI documentation says each protected database must be associated with one protection policy, with Oracle-defined and user-defined policy options.
+- Official OCI documentation says user-defined protection policies support a backup retention period from 14 to 95 days, and retention lock can restrict modification or deletion until retention ends.
+- OCI API evidence through the user’s configured read-only OCI MCP shows protected database listing is compartment-scoped and can filter by lifecycle state, display name, protected database, protection policy, recovery service subnet, sorting, and pagination. Treat that as API-shape evidence, not restore readiness.
+
+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 protected database state, policy, retention, redo, backup health, subnet, storage location, and restore-test evidence.
+- Require current backup and restore validation before resilience claims.
+- Treat delete, policy change, retention change, or subnet changes as high risk.
+- Do not expose database names, backup identifiers, subnet identifiers, customer data, or sensitive identifiers.
+
+## Minimal safe implementation flow
+
+- Confirm database scope, policy, RPO/RTO, retention, owner, and restore-readiness decision.
+- Use official docs for Recovery Service behavior and sampled read-only evidence for API shape/current state.
+- Check backup health, redo, recovery window, network dependencies, policy drift, and restore-test evidence.
+- Return verdict, blockers, restore-readiness gaps, safe next actions, and validation plan.
+
+## High-risk assumptions to kill
+
+- “Backups configured means restore works.”
+- “Policy attached means RPO is met.”
+- “Retention lock is a substitute for restore testing.”
+- “No failed backup alarm means healthy.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- List protected databases and policies without exposing identifiers.
+- Check lifecycle, redo status, last backup, recovery window, subnet health, and policy mapping.
+- Validate restore drill evidence and business RPO/RTO.
+- Confirm monitoring, alerts, and escalation ownership.
+
+## 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 restore-readiness approval without restore-test evidence.
+- Backup health or redo status is missing.
+- The request would delete/change policy or retention without explicit approval.

package/skills/oci/oci-recovery-service-operator/references/safety-checklist.md

@@ -1,32 +1,35 @@
-# Safety Checklist
+# Safety checklist
 
-Use this checklist before recommending or executing changes for `oci-recovery-service-operator`.
+Use this checklist before producing guidance, requesting evidence, or proposing changes.
 
-## Scope
+## Evidence labels
 
-- 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.
+- `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.
 
-## Access
+## Credential and identifier boundaries
 
-- 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.
+- 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.
 
-## Change safety
+## Mutation boundary
 
-- 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.
+Require explicit approval before creating, updating, deleting, moving, scaling, rotating, patching, enabling, disabling, deleting backups, deleting images, changing retention, remediating security findings, changing access, or changing production state.
 
-## Platform portability
+## Approval gates
 
-- 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.
+- 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-recovery-service-operator/references/workflow-and-output.md

@@ -0,0 +1,26 @@
+# Workflow and output contract
+
+Use this workflow for full reviews, inventory work, security posture checks, and resilience 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, inventory, 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.