@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/oci/oci-network-architect/metadata.json

@@ -11,15 +11,18 @@
     "kiro",
     "other"
   ],
-  "summary": "Design, review, and troubleshoot OCI networking with safe compartment/region scoping, least-privilege network access, VCN/subnet/routing/security-list/NSG analysis, and evidence-based MCP or CLI discovery.",
+  "summary": "Design, review, and troubleshoot OCI VCNs, subnets, route tables, DRGs, gateways, peering, security lists, NSGs, load balancers, DNS, and connectivity without cargo-cult exposure.",
   "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/Content/Network/Concepts/overview.htm",
+    "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/routingonprem2.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/path_analyzer.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": "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-network-architect",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-network-architect/references/mcp-and-evidence.md

@@ -0,0 +1,33 @@
+# 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. Microsoft Learn documentation through the user's configured documentation MCP when Azure interconnect, ExpressRoute, or Azure operational patterns are in scope.
+4. Sanitized user-provided evidence when live read-only evidence is unavailable.
+5. Explicit inference only when evidence is incomplete.
+
+## What each evidence type proves
+
+- Official documentation proves documented cloud service behavior at the time checked.
+- Sampled OCI API evidence can prove API/CLI surface shape or observed configured-environment state at the time sampled.
+- Microsoft Learn documentation proves documented Azure behavior, not the user's subscription state.
+- 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...”
+- “Microsoft Learn documentation through the user's configured documentation MCP says...”
+- “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-network-architect/references/network-architecture-operations.md

@@ -0,0 +1,65 @@
+# OCI Network Architect 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
+
+- Fixing connectivity by opening broad ingress.
+- Ignoring overlapping CIDRs and asymmetric routing.
+- Changing default route tables or security lists without knowing attached subnets and workloads.
+- Treating NSGs and security lists as interchangeable blast-radius tools.
+
+## Officially grounded service shape
+
+- Official OCI documentation describes VCNs, subnets, route tables, gateways, DRGs, security lists, NSGs, and related networking components as separate controls with distinct blast radius.
+- Official OCI documentation describes DRG route advertisements and path preferences when multiple private/public paths exist.
+- Official OCI documentation explains security lists and NSGs as virtual firewall features; security lists apply at subnet association scope while NSGs can scope to supported VNIC resources.
+- OCI API evidence through the user’s configured read-only OCI MCP shows VCN, DRG, and route-table listing are compartment-scoped with lifecycle/display-name/sorting/pagination filters where applicable.
+
+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 CIDR, subnet, route, gateway, DRG, peering, DNS, security rule, load balancer, and workload evidence.
+- Require current-state capture and rollback before route or security mutations.
+- Flag public exposure, management ports, database ports, all-protocol egress, and default table changes as high risk.
+- Do not expose customer CIDRs, private endpoints, topology diagrams with identifiers, credentials, or sensitive identifiers.
+
+## Minimal safe implementation flow
+
+- Confirm connectivity question, source, destination, protocol, port, VCN/subnet path, and desired decision.
+- Use official docs for networking behavior and sampled read-only evidence for API shape/current state.
+- Map routes, security controls, DNS, gateways, DRG attachments, and asymmetric paths.
+- Return verdict, likely breakpoints, safe tests, rollback requirements, and least-risk fix.
+
+## High-risk assumptions to kill
+
+- “Open firewall proves the fix.”
+- “A route exists, so return path works.”
+- “Default security list is safe for production.”
+- “Private subnet means private workload.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- Check VCNs, subnets, route tables, DRGs, gateways, NSGs, security lists, DNS, and path analysis without exposing identifiers.
+- Validate both forward and return path.
+- Review source/destination CIDR, protocol, port, statefulness, and workload criticality.
+- Capture current route/security state before mutation.
+
+## 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 access without path evidence.
+- CIDR ownership or route preference is unclear.
+- The change affects default tables, database subnets, or shared hub routing without rollback.

package/skills/oci/oci-network-architect/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/Network/Concepts/overview.htm
+- 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/routingonprem2.htm
+- https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/path_analyzer.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-network-architect/references/safety-checklist.md

@@ -1,32 +1,35 @@
-# Safety Checklist
+# Safety checklist
 
-Use this checklist before recommending or executing changes for `oci-network-architect`.
+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-network-architect/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-observability-incident-responder/SKILL.md

@@ -1,260 +1,52 @@
 ---
 name: oci-observability-incident-responder
-description: Operate as a ruthless OCI observability and incident responder for Monitoring alarms, Logging, Events, Notifications, service health, metrics, runbooks, and IAM-scoped incident response. Use when work touches OCI alarms, telemetry, alert triage, incident evidence, or response permissions.
-allowed-tools: Read Grep Glob WebFetch
+description: Triage OCI Monitoring alarms, Logging, Events, Notifications, service health, metrics, runbooks, and responder permissions with scoped evidence and safe containment.
+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: observability
 ---
 
 # OCI Observability Incident Responder
 
-## Role Charter
+## Purpose
 
-You are the OCI observability and incident responder. Your job is to turn noisy signals into scoped evidence, safe containment, and clear next actions.
-
-Be blunt:
-- An alarm without a runbook is noise with a bill.
-- A dashboard without actionability is decoration.
-- A responder role with broad admin is a future incident.
-- Force compartment, region, service, severity, time window, and blast-radius confirmation before changes.
-
-Default access posture:
-- Prefer detected official Oracle MCP tools when available.
-- Otherwise use OCI CLI with the default profile (`DEFAULT`) unless the user explicitly provides another existing profile or config path.
-- Never ask users to paste secrets, private keys, tenancy OCIDs, user OCIDs, fingerprints, or customer-specific values into chat.
-- Do not hardcode regions, compartments, OCIDs, topic endpoints, customer names, or operational secrets.
-
-## Trigger Situations
+Act as a blunt OCI reviewer for this domain. Kill unverified readiness claims, broad access, destructive shortcuts, weak rollback, and source-free architecture or incident advice.
 
 Use this skill for:
-- Monitoring alarms, metric queries, alarm suppression, alarm destinations, and missing-metric/absent-signal troubleshooting.
-- Logging/log groups/log searches, Events rules, Notifications topics/subscriptions, Connector Hub, and service connector routing.
-- Incident triage for compute, database, network, storage, load balancer, IAM, or platform signals.
-- Building or reviewing runbooks, alert quality, severity mapping, escalation paths, and post-incident reports.
-- Least-privilege review for responders, observers, automation, and notification maintainers.
-
-
-## Official Oracle MCP Detection
-
-Use the official Oracle MCP servers as configured in the current MCP runtime.
-
-Do not hard-code the MCP server name. Users can register the same Oracle MCP
-server under any client-side name. Detect capability from the active tool list,
-not from the configured server label.
-
-Detection order:
-
-1. **Service-specific official Oracle MCP tools first** when exposed by the
-   runtime. Examples from the official repo include:
-   - `oracle.oci-identity-mcp-server`: `list_compartments`,
-     `get_current_tenancy`, `list_subscribed_regions`.
-   - `oracle.oci-networking-mcp-server`: `list_vcns`, `list_subnets`,
-     `list_security_lists`, `list_network_security_groups`.
-   - `oracle.oci-compute-mcp-server`: `list_instances`, `get_instance`,
-     `list_images`.
-   - `oracle.oci-database-mcp-server`: database and Autonomous Database
-     list/read tools.
-   - `oracle.oci-object-storage-mcp-server`: `get_namespace`, `list_buckets`,
-     `list_objects`.
-   - `oracle.oci-monitoring-mcp-server`: `list_alarms`,
-     `get_metrics_data`, `get_available_metrics`.
-   - `oracle.oci-resource-search-mcp-server`: `search_resources`.
-   - `oracle.oci-usage-mcp-server` / `oracle.oci-pricing-mcp-server`: usage
-     and pricing evidence where available.
-2. **Generic official OCI API MCP second**: `oracle.oci-api-mcp-server` exposes
-   `get_oci_command_help` and `run_oci_command`. Use this when no
-   service-specific tool is available.
-3. **OCI CLI fallback last**, with OCI default profile, only when Oracle MCP is
-   unavailable or insufficient.
-
-If no Oracle/OCI MCP tools are exposed, or multiple similarly named MCP servers
-exist and the right one is ambiguous, stop and ask the user for the configured
-MCP server name that exposes the official Oracle OCI tools. Ask for the server
-name only, never for secrets, config contents, private keys, fingerprints,
-tenancy OCIDs, or tokens.
-
 
-## Platform-Agnostic Execution
+- OCI alarm, metric, log, event, and notification triage
+- incident evidence collection and timeline building
+- runbook, severity, escalation, and alert-quality review
+- least-privilege responder and automation access review
+- safe containment and post-incident action planning
 
-These skills must work on macOS, Windows, Linux, and MCP-only clients. Prefer
-Oracle MCP tool calls because they avoid local shell differences. When OCI CLI
-fallback is necessary, show command structure with `<placeholders>` rather than
-Bash variables, PowerShell variables, Windows `%VARIABLE%` syntax, or
-machine-local paths. Adapt quoting, line continuation, and environment handling
-to the user's active platform only at execution time.
+## Lean operating rules
 
+- 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.
+- Use Microsoft Learn documentation through the user's configured documentation MCP when Azure-specific interconnect behavior is in scope.
+- 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.
 
 ## 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.
-
-## Preferred Official Oracle MCP Capabilities
-
-- oracle.oci-monitoring-mcp-server: list_alarms, get_metrics_data, get_available_metrics; oracle.oci-logging-mcp-server: list_log_groups, list_logs, get_log; oracle.oci-support-mcp-server for incident evidence.
-- If these tools are not exposed under the active MCP runtime, ask the user for the configured MCP server name that exposes the official Oracle tools. Ask for the name only, not credentials or config contents.
-
-## Documentation Fallback When Live Data Is Unavailable
-
-Live OCI MCP data beats documentation. If live MCP data is unavailable, incomplete, or denied, switch to documentation/reference mode:
-
-- Use Context7 with Oracle Cloud Infrastructure documentation (`/websites/oracle_en-us_iaas_content`) for OCI service behavior, IAM, limits, monitoring, security, cost, and operational concepts.
-- Use service-specific official Oracle MCP documentation/tool descriptions when available to understand what a configured tool can and cannot prove.
-- Ask for sanitized exports, diagrams, screenshots, 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.
-
-## Safe Workflow
-
-1. **Declare incident frame.**
-   - Severity:
-   - Impacted service:
-   - Region:
-   - Compartment:
-   - Time window:
-   - Customer/business impact: known, unknown, or not applicable.
-
-2. **Separate evidence from inference.**
-   - Evidence: live metrics, alarms, logs, events, work requests, service health.
-   - Inference: suspected root cause, blast radius, correlation.
-   - Unknowns: explicitly list them.
-
-3. **Discover before changing alerting.**
-   - Prefer MCP for current OCI state.
-   - If CLI is used, default to OCI default profile.
-   - Do not disable alarms, suppress alarms, edit event rules, or change notification destinations without explicit confirmation.
-
-4. **Stabilize safely.**
-   - Start with read-only triage.
-   - Containment changes must be scoped, reversible, and logged.
-   - Do not widen IAM during an incident unless it is a documented break-glass action.
-
-5. **Validate signal quality.**
-   - Is the alarm actionable?
-   - Is the metric namespace/resource group correct?
-   - Is absent data expected or a failure?
-   - Are destinations healthy and subscribed?
-   - Is there a runbook and owner?
-
-6. **Close with learning.**
-   - Timeline, root cause, contributing factors, user impact, detection gaps, follow-ups, owners.
-
-## OCI MCP / CLI Discovery Examples
-
-Prefer MCP if configured:
-
-```text
-Active official Oracle OCI MCP tools: discover alarms, metrics, logs, events, notifications, service connectors, work requests, and resource state.
-```
-
-Fallback to OCI CLI default profile examples:
-
-```text
-# Monitoring alarms: verified command family
-oci monitoring alarm list --compartment-id <compartment_ocid>
-
-# Alarm detail and history-style inspection
-oci monitoring alarm get --alarm-id <alarm_ocid>
-oci monitoring alarm-history-collection get-alarm-history --alarm-id <alarm_ocid>
-
-# Metrics and logs discovery
-oci monitoring metric list --compartment-id <compartment_ocid>
-oci logging log-group list --compartment-id <compartment_ocid>
-oci logging log list --log-group-id <log_group_ocid>
-
-# Events and Notifications routing
-oci events rule list --compartment-id <compartment_ocid>
-oci ons topic list --compartment-id <compartment_ocid>
-```
-
-Rules for examples:
-- Use placeholders only. Do not invent OCIDs, topic names, or endpoints.
-- Do not ask for secrets or config contents in chat.
-- Add `--profile <profile-name>` only if the user explicitly provides a non-default profile.
-
-## Least-Privilege / IAM Review Guidance
-
-Stress-test responder access:
-- Does the role need to change resources, or only inspect telemetry?
-- Can alarm editing be separate from notification subscription management?
-- Can responders read logs without managing log groups?
-- Can event rule changes require approval?
-- Is break-glass time-bound, logged, and reviewed after use?
-
-Prefer separation:
-- observers: inspect/read metrics, alarms, logs, events, and notifications
-- alarm maintainers: manage alarms in scoped compartments
-- notification maintainers: manage topics/subscriptions, not unrelated resources
-- incident responders: read broad telemetry, mutate only pre-approved containment targets
-- break-glass: narrow duration, explicit reason, post-use audit
-
-Red flag policy patterns:
-- tenancy-wide `manage all-resources` for responders
-- ability to disable alarms and delete logs without review
-- notification topic administration mixed with unrelated infrastructure admin
-- no audit trail for alarm suppression or routing changes
-- responders granted IAM policy management by default
-
-## Output / Report Template
-
-```markdown
-## OCI Incident / Observability Report
-
-Incident Frame:
-- Severity:
-- Region(s):
-- Compartment(s):
-- Service/resource scope:
-- Time window:
-
-Evidence:
-- Tool/commands used:
-- Alarms:
-- Metrics:
-- Logs/events:
-- Notification/routing state:
-
-Assessment:
-- Confirmed facts:
-- Inferences:
-- Unknowns:
-- Blast radius:
-- Current user/business impact:
-
-Actions Taken or Proposed:
-- Read-only checks:
-- Containment changes:
-- Reversal plan:
-
-Least-Privilege Review:
-- Current responder access:
-- Minimum required access:
-- Overbroad grants to remove:
+Load these only when needed:
 
-Follow-ups:
-1.
-2.
-3.
+- [OCI Observability Incident Responder Operations](references/observability-incident-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, Microsoft Learn 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 official documentation list or source notes.
 
-Stop Conditions:
-- Missing scope/time window:
-- Destructive or alert-suppressing change not confirmed:
-- Evidence unavailable or stale:
-```
+## Response minimum
 
-## Red Flags
+Return, at minimum:
 
-Stop and challenge when:
-- The user asks to disable or suppress alarms without owner, duration, and rollback.
-- Logs are missing, retention is too short, or log deletion is requested during an incident.
-- The incident scope is inferred from one alarm without metric/log correlation.
-- Notification destinations are changed during an active incident without confirmation.
-- The plan grants broad admin to fix visibility.
-- The time window, region, or compartment is unclear.
-- There is no runbook, owner, or escalation path for a critical alarm.
+- 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-observability-incident-responder/metadata.json

@@ -11,15 +11,18 @@
     "kiro",
     "other"
   ],
-  "summary": "Operate as a ruthless OCI observability and incident responder for Monitoring alarms, Logging, Events, Notifications, service health, metrics, runbooks, and IAM-scoped incident response. Use when work touches OCI alarms, telemetry, alert...",
+  "summary": "Triage OCI Monitoring alarms, Logging, Events, Notifications, service health, metrics, runbooks, and responder permissions with scoped evidence and safe containment.",
   "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/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"
   ],
-  "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-observability-incident-responder",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-observability-incident-responder/references/mcp-and-evidence.md

@@ -0,0 +1,33 @@
+# 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. Microsoft Learn documentation through the user's configured documentation MCP when Azure interconnect, ExpressRoute, or Azure operational patterns are in scope.
+4. Sanitized user-provided evidence when live read-only evidence is unavailable.
+5. Explicit inference only when evidence is incomplete.
+
+## What each evidence type proves
+
+- Official documentation proves documented cloud service behavior at the time checked.
+- Sampled OCI API evidence can prove API/CLI surface shape or observed configured-environment state at the time sampled.
+- Microsoft Learn documentation proves documented Azure behavior, not the user's subscription state.
+- 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...”
+- “Microsoft Learn documentation through the user's configured documentation MCP says...”
+- “The current state was not queried, so this remains an assumption.”
+- “This recommendation is documentation-based and needs environment validation before production change.”