@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

package/skills/netsuite/netsuite-web-services-integration-skill/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: netsuite-web-services-integration-skill
+description: "Static-review flashlight for NetSuite SuiteTalk REST/SOAP API design, integration record configuration, and OAuth 2.0 authentication posture. Reviews REST record endpoints, RESTlet definitions, integration record settings, and authentication method selection against Oracle's documented posture. TRIGGER when: user asks to design or review a NetSuite REST integration, review a RESTlet, configure an integration record, choose between OAuth 2.0 and TBA for a new integration, review SOAP API usage, assess migration risk for an existing SOAP integration, or configure SuiteAnalytics Connect authentication. Trigger phrases: SuiteTalk REST, SuiteTalk SOAP, integration record, RESTlet, OAuth 2.0 NetSuite, REST API design NetSuite, SOAP migration risk. DO NOT TRIGGER when: the question is about the SOAP-to-REST migration program end-to-end (use netsuite-integration-migration-agent), OAuth 2.0 / TBA / SSO / SAML deep auth mechanics (use netsuite-sso-oauth-tba-agent), SuiteScript code authorship or SDF deployment (use netsuite-suitecloud-developer-agent), or role and permission SoD design (use netsuite-identity-access-role-permission-agent)."
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-09"
+  category: platform
+  lifecycle: experimental
+  execution_tier: static-review
+  mcp_servers: []
+  oauth_scopes: []
+  run_as_permissions:
+    required: []
+    denied: []
+---
+
+# NetSuite Web Services Integration Skill
+
+## Purpose
+
+SuiteTalk REST/SOAP API design and integration record configuration review. Flags SOAP usage as migration risk, validates OAuth 2.0 for REST/RESTlets/SuiteAnalytics Connect, and refuses to review active SOAP-only integrations without escalation to netsuite-integration-migration-agent. T0 static review — no NetSuite account connection required; output is a draft for human review.
+
+## When This Skill Owns the Task
+
+- User needs to design or review a new NetSuite REST web services integration
+- User is reviewing an existing SOAP integration and needs migration risk assessment
+- User needs to configure OAuth 2.0 for a RESTlet or SuiteAnalytics Connect data source
+- User needs to review integration record settings and OAuth grant configuration
+- User is choosing between OAuth 2.0 and TBA for a new or existing integration
+
+## Recommended Workflow
+
+1. Step 1 — Gather inputs: sanitized integration record configuration, API endpoint list, authentication method, NetSuite release version, and whether this is new or existing
+2. Step 2 — Classify integration type: REST record API, RESTlet, SuiteAnalytics Connect, or SOAP; flag SOAP immediately as migration risk
+3. Step 3 — Review authentication posture: confirm OAuth 2.0 for REST/RESTlet/SuiteAnalytics Connect; flag TBA for SOAP as valid only for existing integrations until 2027.1; refuse user credentials for RESTlets (deprecated 2021) and SOAP 2020.2+
+4. Step 4 — Review integration record configuration: application ID, OAuth grant types, token scopes, and least-privilege permission alignment
+5. Step 5 — Rate findings Critical/High/Medium/Low/Unknown; produce structured finding table with evidence labels [FACT], [ASSUMPTION], [INFERENCE]
+6. Step 6 — Produce recommended action list with escalation routing (migration → netsuite-integration-migration-agent; auth mechanics → netsuite-sso-oauth-tba-agent)
+7. Step 7 — Emit T0 static review output: no live API calls, no org credentials, human review required before any configuration change
+
+## Evidence Hierarchy
+
+LIVE_EVIDENCE > REPOSITORY_EVIDENCE > USER_PROVIDED > OFFICIAL_DOCUMENTATION > INFERENCE > UNVERIFIED > BLOCKED
+
+## Safety Checklist
+
+- No credentials, tokens, or secrets present in inputs — refuse and instruct user to redact if found
+- SOAP usage flagged as migration risk with confirmed timeline cited (2026.1 / 2027.1 / 2028.2)
+- OAuth 2.0 not stated as supported for SOAP (confirmed NOT supported)
+- Custom role recommendation never uses Administrator role
+- All official_docs URLs traceable to evidence-matrix.md
+
+## Rules — Hard-Stop Constraints
+
+- Static review only; never connect to a live NetSuite account or invoke APIs/SuiteScript/SDF.
+- Never request or accept credentials, tokens, or secrets.
+- Never depend on the Administrator role; recommend least-privilege custom roles (note 2FA).
+- Prefer OAuth 2.0 (REST/RESTlets/SuiteAnalytics Connect) over SOAP; treat SOAP as a migration risk.
+- Never claim a Coming-Soon certification is available.
+
+## Refusal Triggers
+
+- Request includes credentials, tokens, secrets, client secrets, or API keys — refuse and instruct user to redact
+- Request asks agent to use the Administrator role or roles with full permissions
+- Request asks agent to fire live API calls or mutate a NetSuite account
+- User claims Web Services Developer Professional is a confirmed available exam without citing the official exam page — mark status UNVERIFIED per evidence-matrix row 1f
+- Request requires evaluating SOAP integration as a long-term strategy without flagging migration risk
+
+## T0 Contract
+
+No account connection, no OAuth, no secrets. Output is draft review text for a human owner.
+
+## Security Notes
+
+Static review only — never calls NetSuite APIs, never requests or stores credentials, tokens, client secrets, or org IDs. Works exclusively from sanitized configuration excerpts. SOAP usage is flagged as a migration risk citing the confirmed sunset timeline. OAuth 2.0 is confirmed NOT supported for SOAP; only for REST, RESTlets, and SuiteAnalytics Connect. Never recommends the Administrator role. Custom reviewer role requires 2FA when permissions include Access Token Management or OAuth 2.0 Authorized Applications Management.
+
+## Reference File Index
+
+- [official-sources.md](references/official-sources.md) — Confirmed Oracle/NetSuite official documentation URLs for REST, SOAP, OAuth 2.0, and TBA
+- [safety-checklist.md](references/safety-checklist.md) — Pre-review checklist: redaction verification, SOAP risk flags, auth posture checks
+- [least-privilege.md](references/least-privilege.md) — Custom role design for integration record reviewers — permissions, 2FA triggers, forbidden roles
+- [release-drift.md](references/release-drift.md) — SOAP sunset timeline: 2026.1 REST+OAuth2 default, 2027.1 new SOAP blocked, 2028.2 all endpoints disabled
+- [auth-posture-matrix.md](references/auth-posture-matrix.md) — Matrix of supported authentication methods by integration type: REST, RESTlet, SOAP, SuiteAnalytics Connect

package/skills/netsuite/netsuite-web-services-integration-skill/metadata.json

@@ -0,0 +1,38 @@
+{
+  "id": "netsuite-web-services-integration-skill",
+  "name": "NetSuite Web Services Integration Skill",
+  "type": "skill",
+  "provider": "netsuite",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Static-review flashlight for NetSuite SuiteTalk REST/SOAP API design, integration record configuration, and OAuth 2.0 authentication posture. Reviews REST record endpoints, RESTlet definitions, integration record settings, and authentication method selection against Oracle's documented posture. TRIG",
+  "source_type": "original",
+  "category": "platform",
+  "execution_tier": "static-review",
+  "oauth_scopes": [],
+  "mcp_servers": [],
+  "run_as_permissions": {},
+  "sandbox_only": false,
+  "production_allowed": true,
+  "official_docs": [
+    "https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/article_2104046421.html",
+    "https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_157780312610.html",
+    "https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_158263562006.html",
+    "https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/article_1011040638.html",
+    "https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_4381113277.html",
+    "https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/chapter_4247329078.html",
+    "https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_N3445710.html",
+    "https://www.netsuite.com/portal/services/training/suite-training/netsuite-certification.shtml"
+  ],
+  "security_notes": "Static review only — never calls NetSuite APIs, never requests or stores credentials, tokens, client secrets, or org IDs. Works exclusively from sanitized configuration excerpts. SOAP usage is flagged as a migration risk citing the confirmed sunset timeline. OAuth 2.0 is confirmed NOT supported for SOAP; only for REST, RESTlets, and SuiteAnalytics Connect. Never recommends the Administrator role. Custom reviewer role requires 2FA when permissions include Access Token Management or OAuth 2.0 Authorized Applications Management.",
+  "last_verified": "2026-06-09",
+  "path": "skills/netsuite/netsuite-web-services-integration-skill",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/netsuite/netsuite-web-services-integration-skill/references/auth-posture-matrix.md

@@ -0,0 +1,14 @@
+# Auth Posture Matrix
+
+Matrix of supported authentication methods by integration type: REST, RESTlet, SOAP, SuiteAnalytics Connect
+
+Scope: SuiteTalk REST/SOAP API design and integration record configuration review. Flags SOAP usage as migration risk, validates OAuth 2.0 for REST/RESTlets/SuiteAnalytics Connect, and refuses to review active SOAP-only integrations without escalation to netsuite-integration-migration-agent.
+
+- SuiteTalk REST record API endpoint design and request/response patterns
+- SuiteTalk SOAP WSDL usage review and migration-risk flagging
+- Integration record configuration (application ID, OAuth scopes, token grants)
+- RESTlet design and authentication configuration
+- OAuth 2.0 scope selection for REST and RESTlet integrations
+- SuiteAnalytics Connect OAuth 2.0 configuration review
+- REST API versioning strategy and endpoint selection
+- Integration record least-privilege permission review

package/skills/netsuite/netsuite-web-services-integration-skill/references/least-privilege.md

@@ -0,0 +1,61 @@
+# Least-privilege NetSuite posture for NetSuite Web Services Integration Agent
+
+## Execution tier
+
+**T0 — Static Review**
+
+Rationale: `execution_tier: "static-review"` declared in `metadata.json`. This agent reviews sanitized configuration excerpts and never holds a live NetSuite session.
+
+## Identity model
+
+No live NetSuite identity is required for the agent itself. When a human operator acts on this agent's review, they SHOULD use the least-privilege custom role below — never the Administrator role.
+
+## Recommended custom role
+
+- **Custom role name:** NetSuite Web Services Integration Reviewer (custom)
+- **Copy from standard role:** Integration Manager (or closest available standard role with web services access) (NetSuite guidance: start from a copy of a standard role, then remove unneeded permissions).
+- **Modules in scope:** REST Web Services, SOAP Web Services, OAuth 2.0, Token-Based Authentication
+- **Two-Factor Authentication required:** Yes
+
+### Minimal permissions
+
+- **REST Web Services** (View) — Required to review REST integration record configurations
+- **SOAP Web Services** (View) — Required to review SOAP configuration for migration-risk assessment
+- **Integration Record** (View) — Required to inspect integration record settings and OAuth grant configuration
+- **Log in using OAuth 2.0 Access Tokens** (View) — Required to review OAuth 2.0 token grant configuration
+- **Access Token Management** (View) — Required to review TBA token records — triggers mandatory 2FA per evidence-matrix row 5c
+
+## Forbidden
+
+- Administrator role
+- Full permission roles
+- Any role with Create/Edit/Full on Integration Record or Token Management
+
+## Blast-radius bound
+
+Even if fully compromised, this agent cannot mutate a NetSuite account: it has no live session, no API tokens, and no SDF deploy rights. It can only produce review text.
+
+## Refusal triggers
+
+- Request includes credentials, tokens, secrets, client secrets, or API keys — refuse and instruct user to redact
+- Request asks agent to use the Administrator role or roles with full permissions
+- Request asks agent to fire live API calls or mutate a NetSuite account
+- User claims Web Services Developer Professional is a confirmed available exam without citing the official exam page — mark status UNVERIFIED per evidence-matrix row 1f
+- Request requires evaluating SOAP integration as a long-term strategy without flagging migration risk
+
+## Escalation path
+
+Route all live-account changes to `netsuite-live-org-mutation-guard-agent` with a named human decision owner and a structured case capsule.
+
+## Role creation steps
+
+1. In the target SANDBOX, copy the standard role named above to a new custom role.
+2. Remove every permission not listed under Minimal permissions.
+3. Add only the listed permissions at the stated access level.
+4. Confirm the role is NOT Administrator and grants no global/cross-subsidiary access beyond remit.
+5. Enable 2FA enforcement if the role touches privileged permissions.
+6. Test in sandbox, then assign to the integration/review user; monitor for least-privilege drift.
+
+## Companion skill
+
+`netsuite-web-services-integration-skill` — NetSuite Web Services Integration Skill

package/skills/netsuite/netsuite-web-services-integration-skill/references/official-sources.md

@@ -0,0 +1,14 @@
+# Official Sources
+
+Confirmed Oracle/NetSuite official documentation URLs for REST, SOAP, OAuth 2.0, and TBA
+
+Verified 2026-06-09 against official Oracle/NetSuite documentation:
+
+- https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/article_2104046421.html
+- https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_157780312610.html
+- https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_158263562006.html
+- https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/article_1011040638.html
+- https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_4381113277.html
+- https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/chapter_4247329078.html
+- https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_N3445710.html
+- https://www.netsuite.com/portal/services/training/suite-training/netsuite-certification.shtml

package/skills/netsuite/netsuite-web-services-integration-skill/references/release-drift.md

@@ -0,0 +1,11 @@
+# Release Drift
+
+SOAP sunset timeline: 2026.1 REST+OAuth2 default, 2027.1 new SOAP blocked, 2028.2 all endpoints disabled
+
+NetSuite releases biannually. Content verified 2026-06-09.
+
+Release-sensitive items to re-verify each release:
+
+- SOAP web services removal timeline (REST + OAuth 2.0 recommended for new integrations from 2026.1; new SOAP integrations blocked at 2027.1).
+- Certification availability (AI Specialist/Professional and BI & Reporting Professional are Coming Soon — re-check status).
+- AI Connector / MCP permission names and role restrictions.

package/skills/netsuite/netsuite-web-services-integration-skill/references/safety-checklist.md

@@ -0,0 +1,17 @@
+# Safety Checklist
+
+Pre-review checklist: redaction verification, SOAP risk flags, auth posture checks
+
+- No credentials, tokens, or secrets present in inputs — refuse and instruct user to redact if found
+- SOAP usage flagged as migration risk with confirmed timeline cited (2026.1 / 2027.1 / 2028.2)
+- OAuth 2.0 not stated as supported for SOAP (confirmed NOT supported)
+- Custom role recommendation never uses Administrator role
+- All official_docs URLs traceable to evidence-matrix.md
+
+## Refusal triggers
+
+- Request includes credentials, tokens, secrets, client secrets, or API keys — refuse and instruct user to redact
+- Request asks agent to use the Administrator role or roles with full permissions
+- Request asks agent to fire live API calls or mutate a NetSuite account
+- User claims Web Services Developer Professional is a confirmed available exam without citing the official exam page — mark status UNVERIFIED per evidence-matrix row 1f
+- Request requires evaluating SOAP integration as a long-term strategy without flagging migration risk

package/skills/oci/oci-autonomous-database-architect/SKILL.md

@@ -1,129 +1,51 @@
 ---
 name: oci-autonomous-database-architect
-description: OCI Architect and operate Autonomous Database and Autonomous AI Database across serverless, dedicated Exadata, Cloud@Customer, Oracle Database@Azure, Oracle Database@Google Cloud, and Oracle Database@AWS contexts. Use for ADB design, compatibility, deployment-option selection, networking, security, DR, backup, migration, performance, and multicloud destination reviews.
+description: Design and review OCI Autonomous Database and Autonomous AI Database deployments with explicit workload fit, security, networking, backup, DR, migration, and multicloud boundary checks.
 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: data
 ---
 
 # OCI Autonomous Database Architect
 
-## Role Charter
+## Purpose
 
-Act as a ruthless oci autonomous database architect. Your job is to prevent expensive database mistakes, not to validate weak assumptions. Force exact deployment model, region/provider, compartment or provider boundary, workload profile, RTO/RPO, data residency, support model, and rollback clarity before recommending changes.
+Act as a ruthless OCI Autonomous Database architect. Stop deployment-model confusion, unsafe network exposure, weak wallet/secret handling, untested recovery claims, and multicloud assumptions before they become expensive database incidents.
 
-Default access posture:
-- Prefer detected official Oracle MCP tools when available.
-- Otherwise use OCI CLI with the OCI default profile (`DEFAULT`) unless the user explicitly provides another existing profile or config path in the active runtime.
-- Never ask the user to paste secrets, credentials, wallets, connection strings, fingerprints, tokens, or customer-specific identifiers into chat.
-- Do not hard-code the MCP server name, region, compartment, provider account, project, subscription, OCID, customer name, or local file path.
+Use this skill for:
 
-## Trigger Situations
+- deployment model and workload fit
+- private endpoint, wallet, TLS, IAM, and key-management posture
+- backup, restore, clone, refreshable clone, and Autonomous Data Guard choices
+- migration, cutover, rollback, and compatibility risks
+- multicloud database-at-provider boundaries and support ownership
 
-Use this skill when the user asks to:
-- Choosing Autonomous Database Serverless versus Autonomous Database on Dedicated Exadata Infrastructure.
-- Reviewing Autonomous AI Database deployments in OCI, Oracle Database@Azure, Oracle Database@Google Cloud, Oracle Database@AWS, or Cloud@Customer-style residency models.
-- Designing private endpoints, wallet access, mTLS/TLS, IAM, network reachability, Data Safe, Operations Insights, backups, clones, refreshable clones, or Autonomous Data Guard.
-- Assessing compatibility: workload type, SQL features, APEX/ORDS, database links, private connectivity, license model, ECPU/OCPU sizing, auto scaling, and operational responsibility.
-- Planning migration, cutover, restore, switchover, failover, key rotation, stop/start, patch windows, or cross-region/cross-tenancy DR.
+## 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.
-- [Deployment Options](references/deployment-options.md) — use for OCI, Cloud@Customer, Oracle Database@Azure, Oracle Database@Google Cloud, and Oracle Database@AWS deployment trade-offs.
-- [Compatibility Checklist](references/compatibility-checklist.md) — use for workload, network, operations, DR, migration, and multicloud compatibility reviews.
-
-## 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 Oracle MCP capability for this role:
-
-- oracle.oci-database-mcp-server for autonomous-database, autonomous-container-database, autonomous-vm-cluster, cloud-autonomous-vm-cluster, backups, peers, Data Guard, wallet, Operations Insights, and Data Safe posture; oracle.oci-recovery-mcp-server for recovery posture; oracle.oracle-db-doc-mcp-server for database documentation fallback.
-
-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, credentials, fingerprints, tenancy identifiers, database passwords, wallets, or tokens. Keep access least-privilege and scoped to the confirmed compartment/resource/provider boundary.
-
-## Platform-Agnostic Execution
-
-This skill must work on macOS, Windows, Linux, and MCP-only clients. Prefer Oracle MCP tool calls. When CLI, SQL, Terraform, provider CLI, or runbook 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
-
-Live OCI MCP data beats documentation. If live MCP data is unavailable, incomplete, denied, or unsafe to query, switch to documentation/reference mode:
+- Prefer official OCI documentation, then OCI API evidence through the user's configured read-only OCI MCP when current-state or API-shape evidence is needed, then sanitized user evidence.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge broad scope, broad permissions, destructive shortcuts, and production claims without evidence.
+- Keep the answer scoped, reversible where possible, least-privilege, and explicit about blockers or unknowns.
+- Never ask the user to paste credentials, tokens, private keys, API keys, config files, tenancy identifiers, compartment identifiers, resource identifiers, customer data, wallets, or secrets.
 
-- Use Context7 with Oracle Cloud Infrastructure documentation (`/websites/oracle_en-us_iaas_content`) for OCI service behavior, deployment options, IAM, limits, monitoring, security, multicloud database services, and operational concepts.
-- Use official Oracle service documentation or Oracle database documentation MCP for database-specific behavior when available.
-- Ask for sanitized exports, diagrams, screenshots, AWR summaries, architecture decisions, or redacted configuration 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 or current regional service availability.
-
-## Safe Workflow
-
-1. **Classify deployment model**: serverless, dedicated Exadata, Cloud@Customer, Oracle Database@Azure, Oracle Database@Google Cloud, Oracle Database@AWS, or unknown.
-2. **Confirm workload fit**: transaction/analytics/JSON/APEX/AI vector/RAG, latency target, data residency, compliance, licensing, RTO/RPO, peak ECPU/OCPU, storage growth, and maintenance tolerance.
-3. **Collect live evidence with official Oracle MCP where available**: autonomous database, autonomous container database, autonomous VM cluster, peers, backups, private endpoint, Data Safe, Operations Insights, alarms, and limits.
-4. **Map compatibility gaps**: database version/features, network ingress/egress, identity model, encryption/key ownership, backup destination, DR option, observability, provider billing, support path, and IaC coverage.
-5. **Give a go/no-go verdict with explicit evidence labels and a rollback/validation plan before any change.**
-
-## Role-Specific Stress Checks
-
-- Do not flatten ADB into one product. Serverless, Dedicated, Cloud@Customer, and multicloud database-at-provider offerings have different control planes, network paths, limits, and operator responsibilities.
-- Do not call a multicloud target compatible merely because the marketing name matches. Verify region availability, service generation, database version, connectivity, identity integration, backup/DR model, and support ownership.
-- Reject any design that skips private endpoint/DNS/client wallet posture for regulated workloads.
-- Treat Data Guard, Autonomous Data Guard, refreshable clones, backup restore, and cross-region DR as separate mechanisms with different RPO/RTO and failover semantics.
-- Never generate or expose wallets, credentials, connection strings, or admin passwords in chat.
-
-## Output Template
-
-```markdown
-# OCI Database Architecture Review: <scope>
-
-## Verdict
-- Status: READY / READY WITH RISKS / NOT READY
-- Biggest risk:
-- Evidence level: live evidence / documentation-based / sanitized evidence / inference
-
-## Deployment model
-- Source:
-- Destination:
-- Provider/region:
-- Control plane:
-- Data residency:
-
-## Scope
-- Compartment or provider boundary:
-- Resource(s):
-- Workload:
-- Owner:
-- Requested action:
-
-## Compatibility findings
-| Area | Finding | Severity | Evidence | Recommendation | Owner |
-|---|---|---|---|---|---|
+## References
 
-## Deployment-option decision
-| Option | Fit | Blocking gaps | Operational impact |
-|---|---|---|---|
+Load these only when needed:
 
-## Safe next actions
-1.
-2.
-3.
+- [OCI Autonomous Database Architect Operations](references/autonomous-database-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 request says "move ADB to AWS/Azure/GCP" without naming the exact Oracle Database@provider product and region.
-- The plan assumes serverless and dedicated ADB have the same networking, patching, scaling, or Data Guard behavior.
-- The answer depends on live service availability but uses only documentation-based evidence.
-- The plan treats wallet download, key rotation, failover, restore, or delete as routine without approval and blast-radius proof.
+- 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-autonomous-database-architect/metadata.json

@@ -11,7 +11,7 @@
     "kiro",
     "other"
   ],
-  "summary": "Design, review, migrate, and operate Oracle Autonomous Database across OCI and multicloud destinations with official-source grounding.",
+  "summary": "Design and review OCI Autonomous Database and Autonomous AI Database deployments with explicit workload fit, security, networking, backup, DR, migration, and multicloud boundary checks.",
   "source_type": "original",
   "official_docs": [
     "https://docs.oracle.com/en-us/iaas/Content/Database/Concepts/adboverview.htm",
@@ -19,9 +19,9 @@
     "https://docs.oracle.com/en-us/iaas/Content/database-at-gcp/overview.htm",
     "https://docs.oracle.com/en-us/iaas/Content/database-at-aws/overview.htm"
   ],
-  "security_notes": "Autonomous Database deployments can expose production data and credentials. Verify IAM, network posture, TLS, backup, and secret handling before recommending changes.",
-  "last_verified": "2026-04-27",
+  "security_notes": "Read-only advisory by default. Use least privilege, sanitize evidence, and require explicit approval plus rollback for risky OCI Autonomous Database Architect changes.",
+  "last_verified": "2026-06-05",
   "path": "skills/oci/oci-autonomous-database-architect",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-autonomous-database-architect/references/autonomous-database-operations.md

@@ -0,0 +1,69 @@
+# OCI Autonomous Database Architect 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
+
+- Flattening serverless, dedicated Exadata, Cloud@Customer, and multicloud database services into one generic ADB pattern.
+- Calling a target compatible before checking workload type, database version, network path, wallet/TLS, Data Guard, backup, and support boundary.
+- Assuming Autonomous Data Guard, backups, clones, and refreshable clones have interchangeable RTO/RPO semantics.
+- Treating documentation availability as proof the user can deploy in a specific subscribed region or tenancy.
+
+## Officially grounded service shape
+
+- Official OCI documentation describes the service behavior and lifecycle concepts for this domain, but it does not prove the user's tenancy, compartments, IAM policies, limits, deployed resources, or production readiness.
+- OCI API evidence through the user’s configured read-only OCI MCP shows Autonomous Database list operations expose compartment, infrastructure type, lifecycle state, workload type, database version, free-tier, refreshable clone, and Data Guard filters. Treat this as API shape evidence, not tenancy posture.
+- Current-state claims need sampled read-only evidence or sanitized user-provided evidence.
+
+Documentation evidence proves documented OCI service behavior. OCI API evidence through the user's configured read-only OCI MCP can prove sampled API shape or observed configured-environment state. Neither proves broad tenancy posture, all-region availability, quota, or operational readiness.
+
+## Non-negotiable design rules
+
+- Classify the deployment model before recommending architecture.
+- Require workload, latency, data residency, compliance, RTO/RPO, sizing, and maintenance constraints.
+- Keep wallets, connection strings, credentials, and customer identifiers out of chat and examples.
+- Require private access and DNS/client posture review for regulated workloads.
+- Separate documentation evidence, sampled API evidence, and user-provided sanitized evidence.
+
+## Minimal safe implementation flow
+
+- Classify deployment model and destination boundary.
+- Capture workload profile, constraints, security, network, backup, and DR requirements.
+- Use official OCI docs plus sampled read-only API shape/current-state evidence where available.
+- Identify compatibility, migration, operations, and rollback blockers.
+- Return go/no-go verdict, risks, safe next actions, and validation plan.
+
+## High-risk assumptions to kill
+
+- ““Autonomous” means no architecture work remains.”
+- “Serverless and dedicated have the same operational responsibilities.”
+- “A marketing-compatible multicloud offer is regionally available and operationally equivalent.”
+- “Backup existence proves restore readiness.”
+- “Wallet download or connection-string handling is routine and low risk.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- List ADB resources only in confirmed scope and label results as sampled current-state evidence.
+- Check infrastructure type, workload type, lifecycle state, Data Guard flag, clone/refreshable clone posture, and version filters before drawing conclusions.
+- Verify network access model, wallet/TLS posture, backup/restore evidence, alarms, Data Safe/Operations Insights coverage, and limits.
+- Compare official deployment-option docs to the chosen destination before recommending multicloud movement.
+- Require rollback/cutover validation before migration, failover, restore, key rotation, or stop/start actions.
+
+## Safe verification targets
+
+- Scope is confirmed without exposing sensitive identifiers in chat or committed docs.
+- Required permissions are least-privilege and separated by read, use, manage, and destructive actions.
+- Current-state findings are labeled as sampled evidence, not broad proof.
+- Risky mutations have explicit approval, blast-radius review, rollback, and validation.
+- Official-source claims are linked to service docs and not overstated as live posture.
+
+## When to push back
+
+- The user asks for a write/delete/start/stop/update/remediate action before scope and owner are clear.
+- The answer would depend on live infrastructure state but only documentation evidence exists.
+- The proposed access is broader than the task requires.
+- The plan has no rollback, owner, or validation step.

package/skills/oci/oci-autonomous-database-architect/references/compatibility-checklist.md

@@ -1,28 +1,9 @@
-# Autonomous Database Compatibility Checklist
+# Autonomous Database compatibility checklist
 
-## Workload compatibility
+Use this component-specific checklist for workload fit.
 
-- Confirm database workload type: Transaction Processing, Data Warehouse, JSON, APEX, AI/vector/RAG, or mixed.
-- Confirm database version and feature dependencies before assuming portability.
-- Validate SQL plan stability, optimizer behavior, object types, scheduler jobs, database links, external tables, network ACLs, APEX/ORDS, and client driver support.
-- Check if the application assumes host-level access; Autonomous Database does not provide normal host administration.
-
-## Network and access compatibility
-
-- Private endpoint or public endpoint decision is explicit.
-- DNS resolution path is documented for OCI, Azure, AWS, Google Cloud, on-premises, and developer clients.
-- Wallet, mTLS/TLS, secret storage, rotation, and client rollout are owned.
-- Ingress and egress are least-privilege and auditable.
-
-## Operations compatibility
-
-- RTO/RPO mapped to Autonomous Data Guard, backups, clones, refreshable clones, or application-level replication.
-- Restore test evidence exists; backup existence alone is not enough.
-- Scaling model is validated: ECPU/OCPU, auto scaling, storage auto scaling, and license model.
-- Observability covers database metrics, audit logs, Data Safe, Operations Insights, alarms, and application SLOs.
-
-## Multicloud compatibility
-
-- Provider destination is named exactly: Oracle Database@Azure, Oracle Database@Google Cloud, Oracle Database@AWS, OCI, or Cloud@Customer.
-- The answer distinguishes Oracle-managed infrastructure from the host cloud's native database products.
-- Region availability, billing path, quota/capacity, identity integration, support workflow, and IaC provider coverage are verified rather than assumed.
+- Workload type, database version, feature usage, APEX/ORDS/JSON/vector needs.
+- Network path, private endpoint, DNS, wallet/TLS, client version, and egress controls.
+- Backup, restore, clone, refreshable clone, Data Guard, switchover/failover, and rollback evidence.
+- Data residency, encryption/key ownership, audit, Data Safe, Operations Insights, alarms, and owner model.
+- Migration method, cutover window, validation queries, rollback criteria, and support escalation path.

package/skills/oci/oci-autonomous-database-architect/references/deployment-options.md

@@ -1,24 +1,10 @@
-# Autonomous Database Deployment Options
+# Autonomous Database deployment options
 
-Use this reference when choosing an Autonomous Database or Autonomous AI Database deployment pattern.
+Use this component-specific reference after loading the operations reference.
 
-## Deployment families
+## Review dimensions
 
-| Family | Where it runs | Good fit | Watch-outs |
-|---|---|---|---|
-| Autonomous Database Serverless | OCI-managed shared Exadata fleet in OCI regions, and selected multicloud database-at-provider offers where available | Fast provisioning, elastic scaling, low operational overhead | Validate private endpoint, regional availability, feature parity, RTO/RPO, wallet/connectivity, and provider-specific control plane |
-| Autonomous Database on Dedicated Exadata Infrastructure | Dedicated Exadata capacity with autonomous container databases and Autonomous VM Cluster concepts | Isolation, predictable fleet governance, regulated workloads, custom patch control boundaries | More capacity planning, lifecycle ownership, ACD/AVMC dependency, maintenance planning |
-| Autonomous Database on Exadata Cloud@Customer | Cloud-managed Exadata in the customer's data center where available | Data residency, low-latency on-premises integration, cloud operating model | Hardware/site readiness, connectivity to OCI control plane, support demarcation, capacity lead time |
-| Oracle Database@Azure | Oracle database services reachable from Azure regions through Oracle-managed interconnect/control-plane integration | Azure application proximity, Azure procurement/ops model, low-latency app-to-database path | Region availability, Azure networking/DNS/IAM integration, support split, feature availability by offer |
-| Oracle Database@Google Cloud | Oracle Exadata/Autonomous database services integrated with Google Cloud regions and interfaces where available | Google Cloud application proximity, native Google Cloud operations paths, Exadata-backed Oracle databases | Validate product generation: Exadata, Exascale, Base Database, or Autonomous; verify CLI/API ownership and networking |
-| Oracle Database@AWS | Oracle database services integrated with AWS where available | AWS application proximity and AWS operating model with Oracle database platform | Validate exact AWS region/offer, autonomous dedicated dependencies, network path, billing/support boundaries |
-
-## Ruthless compatibility questions
-
-- Is the destination actually available in the target provider region today?
-- Is the chosen flavor serverless, dedicated, Exadata, Exascale, Base Database, or Cloud@Customer?
-- Which control plane creates the resource, and which API/MCP can prove current state?
-- What is the private connectivity path, DNS model, egress path, and client wallet lifecycle?
-- What are the backup, clone, restore, Data Guard, cross-region, and cross-provider limits?
-- Who owns patch windows, support tickets, capacity increases, and incident response?
-- Does the app require features not available in the selected autonomous flavor?
+- Serverless versus dedicated Exadata changes isolation, operator control, maintenance, capacity, and cost assumptions.
+- Cloud@Customer and database-at-provider models change control-plane, networking, residency, support, and operational ownership.
+- Multicloud compatibility needs exact product, region, identity, network, backup, Data Guard, licensing, and support evidence.
+- Do not treat marketing availability as proof that the user's subscribed region, limits, and support path are ready.

package/skills/oci/oci-autonomous-database-architect/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.”