@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/oci/oci-iot-digital-twin-engineer/SKILL.md

@@ -1,110 +1,51 @@
 ---
 name: oci-iot-digital-twin-engineer
-description: Design and operate OCI IoT digital twin adapters, models, instances, relationships, and domain context. Use for digital twin topology, lifecycle, integration, and safe model/relationship changes.
+description: Design and review OCI IoT domains, digital twin models, adapters, instances, relationships, telemetry paths, lifecycle, and safe topology changes without treating model edits as harmless.
 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: ai
 ---
 
 # OCI IoT Digital Twin Engineer
 
-## Role Charter
+## Purpose
 
-Act as a ruthless oci iot digital twin engineer. 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:
-- Digital twin model/adapter/instance/relationship design or troubleshooting.
-- IoT domain-context derivation, lifecycle changes, or integration review.
-- Requests to delete/update twin resources.
+- IoT domain and domain-group review
+- digital twin model, adapter, instance, and relationship design
+- telemetry and command-path safety review
+- digital twin lifecycle and topology-change planning
+- integration and data-consumption risk review
 
+## 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-iot-mcp-server: get_digital_twin_adapter, create_digital_twin_model, create_digital_twin_instance, create_digital_twin_relationship, derive_domain_context, update/delete digital twin resources
-
-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 Internet of Things, identity, logging, and integration. If live twin feed is unavailable, require model/export artifacts and label assumptions.
-
-## 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 model, adapter, instance, relationship, data source, owner, and downstream consumers.
-- Do not delete/update twins without dependency graph and rollback/export.
-- Challenge digital twin claims without telemetry freshness and semantic model evidence.
-
-## 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 IoT Digital Twin Engineer Operations](references/iot-digital-twin-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-iot-digital-twin-engineer/metadata.json

@@ -11,15 +11,14 @@
     "kiro",
     "other"
   ],
-  "summary": "Design and operate OCI IoT digital twin adapters, models, instances, relationships, and domain context. Use for digital twin topology, lifecycle, integration, and safe model/relationship changes.",
+  "summary": "Design and review OCI IoT domains, digital twin models, adapters, instances, relationships, telemetry paths, lifecycle, and safe topology changes without treating model edits as harmless.",
   "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/internet-of-things/home.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-iot-digital-twin-engineer",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-iot-digital-twin-engineer/references/iot-digital-twin-operations.md

@@ -0,0 +1,65 @@
+# OCI IoT Digital Twin Engineer 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
+
+- Changing a model or relationship without checking downstream telemetry, command paths, and consumers.
+- Assuming a twin topology matches physical assets just because the model compiles.
+- Ignoring data quality, device identity, command authorization, and rollback.
+- Treating API shape as proof that devices, adapters, and instances exist or are healthy.
+
+## Officially grounded service shape
+
+- Official OCI documentation describes the Internet of Things Platform as bidirectional communication and data collection between OCI and devices or external applications, with domain groups, domains, work requests, digital twin models, adapters, instances, and relationships.
+- Official OCI documentation lists device connectivity, REST APIs, Data API, database schema, CLI, SDKs, and data consumption paths such as APEX, REST Data Services, database connections, and analytics.
+- OCI API evidence through the user’s configured read-only OCI MCP shows the IoT CLI surface includes domain groups, domains, work requests, digital twin adapters, models, instances, and relationships.
+- OCI API evidence through the user’s configured read-only OCI MCP shows digital twin model and instance listing are domain-scoped and can filter by display name, lifecycle state, model linkage, model spec URI, sorting, and pagination. Treat this as API-shape evidence, not deployed-device truth.
+
+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 domain, model, adapter, instance, relationship, telemetry, command, and consumer evidence.
+- Require versioning, compatibility, dependency, and rollback checks before model or relationship changes.
+- Treat device commands, adapter changes, and relationship deletions as high risk.
+- Keep device identifiers, customer data, payload samples, credentials, and endpoint details sanitized.
+
+## Minimal safe implementation flow
+
+- Confirm target domain, digital twin asset type, topology decision, and whether commands or telemetry are affected.
+- Use official docs for service behavior and sampled read-only evidence for API shape or sanitized current state.
+- Map dependencies across models, instances, adapters, relationships, consumers, and command paths.
+- Return topology risks, compatibility blockers, safe validation checks, and rollback requirements.
+
+## High-risk assumptions to kill
+
+- “The digital twin graph is the physical truth.”
+- “A model update is non-breaking.”
+- “Telemetry arriving means device identity and command authorization are correct.”
+- “Deleted relationships can be recreated without operational impact.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- List domain-scoped models and instances without exposing identifiers.
+- Check lifecycle state, model spec URI, adapter bindings, relationship dependencies, consumers, and command paths.
+- Validate telemetry schema compatibility, versioning, and rollback before topology changes.
+- Confirm audit, authorization, and safety controls for command-capable devices.
+
+## 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 update or delete models, adapters, instances, or relationships without dependency and rollback evidence.
+- The requested action could affect physical device commands or safety-critical telemetry.
+- The evidence includes sensitive device identifiers, payloads, endpoint details, or customer data.

package/skills/oci/oci-iot-digital-twin-engineer/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-iot-digital-twin-engineer/references/official-sources.md

@@ -0,0 +1,19 @@
+# Official sources
+
+Use these sources to ground service behavior before making production recommendations.
+
+## Oracle documentation checked on 2026-06-05
+
+- https://docs.oracle.com/en-us/iaas/Content/internet-of-things/home.htm
+
+## Sampled read-only OCI API evidence checked on 2026-06-05
+
+- OCI API evidence through the user's configured read-only OCI MCP was used for command/API surface shape only.
+- Command-help evidence confirms available list/filter surfaces; it does not prove permissions, resource existence, regional availability, capacity, quota, data correctness, or production readiness.
+
+## Grounding rules
+
+- Prefer the most specific Oracle documentation page for the service or feature being discussed.
+- If documentation and sampled API evidence appear to conflict, report the conflict and avoid stronger claims until resolved.
+- Do not cite internal tool names, local environment labels, connector identifiers, or environment-specific details in committed docs.
+- Do not paste sensitive identifiers or customer data into examples.

package/skills/oci/oci-iot-digital-twin-engineer/references/safety-checklist.md

@@ -1,32 +1,35 @@
-# Safety Checklist
+# Safety checklist
 
-Use this checklist before recommending or executing changes for `oci-iot-digital-twin-engineer`.
+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, refreshing, restoring, cutting over, 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-iot-digital-twin-engineer/references/workflow-and-output.md

@@ -0,0 +1,26 @@
+# 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. Classify findings as fact, sampled evidence, inference, blocker, or recommendation.
+5. Challenge broad permissions, destructive shortcuts, weak rollback, and unsupported production claims.
+6. Return concise findings with safe next actions and explicit unknowns.
+
+## Output contract
+
+Return these fields when the user asks for a review, guardrail, or production-readiness answer:
+
+- `verdict`: pass, pass-with-risk, blocked, or needs-evidence.
+- `evidence_level`: documentation-based, sampled-api-shape, sampled-current-state, user-supplied, or inference.
+- `blockers`: missing proof, unsafe assumptions, or approval gaps.
+- `safe_next_actions`: least-risk steps the user can take next.
+- `open_questions`: only questions that materially change the decision.
+
+## Tone
+
+Be blunt. Do not validate a weak plan. If the evidence is thin, say so and narrow the recommendation.

package/skills/oci/oci-limits-capacity-planner/SKILL.md

@@ -1,110 +1,51 @@
 ---
 name: oci-limits-capacity-planner
-description: Review OCI service limits, quotas, capacity availability, regional subscriptions, and growth risk. Use before deployments, migrations, DR expansion, shape changes, OKE scaling, database scaling, or quota increase requests.
-allowed-tools: Read Grep Glob WebFetch
+description: Review OCI service limits, quotas, subscribed regions, capacity evidence, and growth risk before deployments, migrations, DR expansion, shape changes, OKE scaling, database scaling, or quota requests.
+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: platform
 ---
 
 # OCI Limits Capacity Planner
 
-## Role Charter
+## Purpose
 
-Act as a ruthless oci limits capacity planner. 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 guard for this domain. Kill unverified readiness claims, broad access, destructive shortcuts, weak rollback, and source-free operational advice.
 
-## Trigger Situations
+Use this skill for:
 
-Use this skill when the user asks to:
-- Capacity planning, service limit review, quota request preparation.
-- Deployment blocked by insufficient limits or regional availability.
-- Growth forecast, DR readiness, or multi-region capacity review.
+- service limit and quota readiness reviews
+- regional subscription and capacity-risk planning
+- deployment, migration, and DR expansion prechecks
+- shape, database, OKE, or network scale-risk review
+- quota request evidence preparation
 
+## 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-limits-mcp-server: list_services, list_limit_definitions, list_limit_values, get_resource_availability; oracle.oci-identity-mcp-server: list_subscribed_regions
-
-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 Limits, quotas, subscribed regions, and service-specific capacity constraints. Label recommendations as planning assumptions without live limits.
-
-## 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 region, service, resource family, tenancy/compartment quota, and target deployment timeline.
-- Do not confuse service limit with available capacity; verify both when tools allow.
-- Challenge last-minute quota requests without lead time, fallback region, or shape alternatives.
-
-## 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 Limits Capacity Planner Operations](references/limits-capacity-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-limits-capacity-planner/metadata.json

@@ -11,15 +11,16 @@
     "kiro",
     "other"
   ],
-  "summary": "Review OCI service limits, quotas, capacity availability, regional subscriptions, and growth risk. Use before deployments, migrations, DR expansion, shape changes, OKE scaling, database scaling, or quota increase requests.",
+  "summary": "Review OCI service limits, quotas, subscribed regions, capacity evidence, and growth risk before deployments, migrations, DR expansion, shape changes, OKE scaling, database scaling, or quota requests.",
   "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/General/service-limits/default.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/Quotas/Concepts/resourcequotas.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/Quotas/Concepts/resourcequotas_topic-Available_Quotas_by_Service.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-limits-capacity-planner",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-limits-capacity-planner/references/limits-capacity-operations.md

@@ -0,0 +1,65 @@
+# OCI Limits Capacity Planner 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
+
+- Confusing default limits with the user’s current entitlement.
+- Confusing a quota policy with real available capacity.
+- Submitting quota requests without lead time, fallback shapes, or alternate regions.
+- Treating one region’s availability as global capacity proof.
+
+## Officially grounded service shape
+
+- Official OCI documentation distinguishes default service limits from quota policies and current tenancy limit values.
+- Official OCI documentation says service-limit listings show limit types and scope; Console/API current values are needed for the user’s actual entitlement.
+- OCI API evidence through the user’s configured read-only OCI MCP shows limit services and limit definitions are parent-compartment scoped and can be filtered by service, name, subscription, sorting, and pagination.
+- OCI API evidence through the user’s configured read-only OCI MCP shows resource availability can return availability and usage for a service, limit, scope, and compartment when the limit supports that API; unsupported limits can return no value.
+
+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 service limits, quotas, current usage, regional subscription, availability-domain scope, and actual deployable capacity.
+- Require target service, region, compartment scope, resource family, timeline, and fallback plan before readiness claims.
+- Label capacity as unverified unless backed by current configured-environment evidence.
+- Do not ask for or commit tenancy, subscription, compartment, or resource identifiers.
+
+## Minimal safe implementation flow
+
+- Confirm target deployment and capacity decision.
+- Use official docs to identify limit families and quota syntax boundaries.
+- Use sampled read-only evidence for service/limit definitions and resource availability where supported.
+- Return readiness, blockers, quota-request evidence, fallback options, and validation checks.
+
+## High-risk assumptions to kill
+
+- “Default limit equals my limit.”
+- “Quota policy means capacity exists.”
+- “A quota increase will arrive before the deployment date.”
+- “Capacity in one scope proves capacity in every scope.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- Check service, limit definition, quota support, scope type, current usage, and availability where supported.
+- Validate subscribed region and target location separately.
+- Cross-check business forecast with quota lead time and fallback shape/region.
+- Confirm official service-specific limit documentation before production planning.
+
+## 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 wants deployment approval without current limit/usage evidence.
+- The request depends on capacity in a region or scope that was not sampled.
+- The plan has no fallback for quota delay or capacity shortage.