@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/oci/oci-maestro/references/maestro-routing-operations.md

@@ -0,0 +1,64 @@
+# OCI Maestro Routing Skill Operations
+
+> Version note: OCI service behavior, catalog entries, and tooling change over time. Verify exact command syntax, permissions, regional availability, feature maturity, and catalog targets before production use. Do not paste secrets or sensitive identifiers into commands, files, or chat.
+
+Use this reference for current, source-grounded service behavior and the hard review gates that the lean `SKILL.md` intentionally does not carry.
+
+## What people get wrong
+
+- Routing to a broad team when one specialist is enough.
+- Auto-dispatching live-guard skills for production-changing actions.
+- Answering as a generic OCI expert instead of routing or narrowing.
+- Mixing Azure, AWS, and OCI specialists because the words sound similar.
+
+## Officially grounded service shape
+
+- Official OCI documentation provides service behavior and cloud concepts, but it does not prove which marketplace agent should be invoked or the user’s live posture.
+- The repo catalog defines the available OCI specialists and is the source of truth for route targets in this workspace.
+- OCI API evidence through the user’s configured read-only OCI MCP may support current-state scoping for a specialist, but the maestro must not turn sampled evidence into production approval.
+
+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
+
+- Narrowest specialist wins for single-domain tasks.
+- Use parallel routing only for genuinely multi-domain tasks and cap the team.
+- Never auto-dispatch live-guard specialists without explicit human confirmation, blast-radius assessment, and rollback path.
+- If the task is not OCI, say so and route to the correct provider only if that provider is available.
+
+## Minimal safe implementation flow
+
+- Classify provider, domain, risk level, and whether live mutation is requested.
+- Select one specialist unless the task clearly spans multiple domains.
+- For live-guard routing, require explicit confirmation and evidence of rollback/blast-radius review.
+- Return route decision, why, evidence level, blockers, and next safe handoff.
+
+## High-risk assumptions to kill
+
+- “More agents means better answer.”
+- “A live-guard can inspect safely and then decide to mutate.”
+- “Provider-neutral means any cloud specialist is acceptable.”
+- “Routing is complete even if the target agent is missing from the catalog.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- Check catalog target exists before naming it as routable.
+- Check live-guard status before dispatch.
+- Check provider and domain taxonomy before routing.
+- Record evidence level and open questions when routing depends on missing context.
+
+## Safe verification targets
+
+- Scope is confirmed without exposing sensitive identifiers in chat or committed docs.
+- Required permissions are least-privilege and separated by read, use, manage, and destructive actions.
+- Current-state findings are labeled as sampled evidence, not broad proof.
+- Risky mutations or live-guard dispatch have explicit approval, blast-radius review, rollback, and validation.
+- Official-source claims are linked to service docs and not overstated as live posture.
+
+## When to push back
+
+- The user asks to auto-dispatch a live-guard for destructive work.
+- The requested provider is not OCI.
+- The task is too vague to choose a specialist without inventing scope.

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

@@ -0,0 +1,22 @@
+# Official sources
+
+Use these sources to ground service behavior before making production recommendations or routing decisions.
+
+## Oracle documentation checked on 2026-06-05
+
+- https://docs.oracle.com/en-us/iaas/Content/home.htm
+- https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/overview.htm
+- https://docs.oracle.com/en-us/iaas/Content/Security/Concepts/securityoverview.htm
+- https://docs.oracle.com/en-us/iaas/Content/General/Concepts/regions.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 where applicable.
+- Command-help evidence confirms available list/filter surfaces; it does not prove permissions, resource existence, regional availability, capacity, quota, data correctness, traffic safety, catalog correctness, or production readiness.
+
+## Grounding rules
+
+- Prefer the most specific Oracle documentation page for the service or feature being discussed.
+- If documentation, catalog, and sampled API evidence appear to conflict, report the conflict and avoid stronger claims until resolved.
+- Do not cite internal tool names, local environment labels, connector identifiers, or environment-specific details in committed docs.
+- Do not paste sensitive identifiers or customer data into examples.

package/skills/oci/oci-maestro/references/safety-checklist.md

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

package/skills/oci/oci-maestro/references/workflow-and-output.md

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

package/skills/oci/oci-migration-cutover-architect/SKILL.md

@@ -1,110 +1,52 @@
 ---
 name: oci-migration-cutover-architect
-description: Plan OCI migrations and cutovers with Cloud Migrations, dependency discovery, waves, rollback, DNS, data sync, validation, and support readiness. Use for migration assessment, move groups, cutover runbooks, and go/no-go reviews.
+description: Plan OCI migrations and cutovers with dependency discovery, waves, replication, DNS, identity, data validation, rollback, support readiness, and go/no-go evidence.
 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: delivery
 ---
 
 # OCI Migration Cutover Architect
 
-## Role Charter
+## Purpose
 
-Act as a ruthless oci migration cutover architect. 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 or incident advice.
 
-## Trigger Situations
+Use this skill for:
 
-Use this skill when the user asks to:
-- OCI migration planning, cutover, rollback, wave design, or readiness review.
-- Application/database/server migration into OCI or between OCI compartments/regions.
-- Requests to accelerate cutover without dependency proof.
+- OCI migration assessment and cutover reviews
+- Cloud Migrations project and migration-plan readiness
+- wave planning, freeze windows, DNS, and dependency mapping
+- data sync, validation, and rollback runbooks
+- go/no-go decisions and support bridge readiness
 
+## 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-migration-mcp-server: list_migrations, get_migration
-
-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.
+- 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.
 
-Live OCI MCP data beats documentation. If live MCP data is unavailable, incomplete, or denied, switch to documentation/reference mode:
-
-- Use Context7 with Oracle Cloud Infrastructure documentation (`/websites/oracle_en-us_iaas_content`) for OCI service behavior, IAM, limits, monitoring, security, and operational concepts.
-- Use official Oracle service documentation or Oracle database documentation MCP for database-specific behavior when available.
-- Ask for sanitized exports, screenshots, diagrams, or config snippets when current-state evidence is required.
-- Label every conclusion as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`.
-- Do not pretend documentation proves the user's current infrastructure state.
-
-Use Context7 Oracle OCI docs for Cloud Migrations, dependency planning, networking, DNS, monitoring, and IAM. If no live migration feed exists, require sanitized migration plan artifacts.
-
-## 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 source, target, owners, dependencies, data sync, freeze window, DNS, IAM, and rollback criteria.
-- No cutover without success metrics, abort threshold, support bridge, and post-cutover monitoring.
-- Challenge lift-and-shift assumptions that preserve bad network/IAM/database design.
-
-## 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 Migration Cutover Architect Operations](references/migration-cutover-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.
 
-## 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-migration-cutover-architect/metadata.json

@@ -11,15 +11,16 @@
     "kiro",
     "other"
   ],
-  "summary": "Plan OCI migrations and cutovers with Cloud Migrations, dependency discovery, waves, rollback, DNS, data sync, validation, and support readiness. Use for migration assessment, move groups, cutover runbooks, and go/no-go reviews.",
+  "summary": "Plan OCI migrations and cutovers with dependency discovery, waves, replication, DNS, identity, data validation, rollback, support readiness, and go/no-go evidence.",
   "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/cloud-migration/home.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/cloud-migration/cloud-migration-overview.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/cloud-migration/cloud-migration-create-migration-project.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-migration-cutover-architect",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-migration-cutover-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-migration-cutover-architect/references/migration-cutover-operations.md

@@ -0,0 +1,65 @@
+# OCI Migration Cutover 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
+
+- Cutting over because replication exists while dependencies, DNS, IAM, and rollback are unproven.
+- Treating migration tooling as application readiness.
+- Ignoring freeze windows, data reconciliation, monitoring, and support bridge ownership.
+- Preserving bad network, IAM, or database design because lift-and-shift is faster.
+
+## Officially grounded service shape
+
+- Official OCI documentation describes Oracle Cloud Migrations as a service for discovering external VMware virtual machines and AWS EC2 instances, organizing workloads, replicating data, planning, and launching OCI compute.
+- Official OCI documentation describes the migration workflow as phases for managing assets, planning migrations, and launching migrated resources.
+- OCI API evidence through the user’s configured read-only OCI MCP shows migration listing can filter by compartment, lifecycle state, display name, migration identifier, sorting, and pagination. Treat this as API-shape evidence, not cutover readiness.
+- Resource Search command-help evidence can support inventory-style discovery across viewable compartments, but it proves only the searchable API surface and caller-visible scope.
+
+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 asset discovery, migration plan, replication, launch, validation, DNS, IAM, network, data, rollback, and support evidence.
+- Require explicit go/no-go criteria, abort thresholds, owner approvals, and rollback path before cutover.
+- Label readiness as unverified unless backed by current state or sanitized runbook evidence.
+- Do not expose customer systems, hostnames, IPs, database names, migration identifiers, or sensitive identifiers.
+
+## Minimal safe implementation flow
+
+- Confirm source, target, wave, owner, business criticality, and cutover decision.
+- Use official docs for Cloud Migrations behavior and sampled read-only evidence for API shape/current migration state.
+- Map dependencies, data sync, DNS, identity, network, monitoring, backup, support, and rollback.
+- Return go/no-go verdict, blockers, cutover sequence, rollback triggers, and validation checks.
+
+## High-risk assumptions to kill
+
+- “Replication complete means cutover ready.”
+- “A migrated VM means the application works.”
+- “DNS rollback is quick.”
+- “Support can be called after problems start.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- Check migration lifecycle and asset inventory without exposing identifiers.
+- Validate dependency map, replication status, data reconciliation, DNS TTLs, IAM, routes, security rules, and monitoring.
+- Confirm freeze window, owner approvals, support bridge, rollback procedure, and abort criteria.
+- Run post-cutover application, data, security, and observability checks.
+
+## 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 accelerate cutover without dependency and rollback proof.
+- Data validation or DNS rollback is missing.
+- The evidence includes unsanitized customer inventory or sensitive identifiers.

package/skills/oci/oci-migration-cutover-architect/references/official-sources.md

@@ -0,0 +1,22 @@
+# 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/cloud-migration/home.htm
+- https://docs.oracle.com/en-us/iaas/Content/cloud-migration/cloud-migration-overview.htm
+- https://docs.oracle.com/en-us/iaas/Content/cloud-migration/cloud-migration-create-migration-project.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-migration-cutover-architect/references/safety-checklist.md

@@ -1,32 +1,35 @@
-# Safety Checklist
+# Safety checklist
 
-Use this checklist before recommending or executing changes for `oci-migration-cutover-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-migration-cutover-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.