Oci Application Engineering

OCI application engineering

Build application code around OCI without taking ownership of OCI control-plane resources. Classify data before it leaves the workspace: secret-bearing or restricted code stays local unless the user explicitly approves an eligible provider.

Workflow

1. Classify the request, constraints, data sensitivity, acceptance tests, and OCI ownership boundary.
2. Query DevVisualization and inspect the current repository before reasoning broadly or searching externally.
3. Search existing modules and reusable assets. Record each accepted or rejected candidate with fit, maintenance, license, security, integration cost, and test evidence.
4. Assess installed skills and plugins read-only. Recommend a new installation only with provenance and permission risks; never install or enable it without explicit approval.
5. Write a small implementation plan and tests first. Keep infrastructure requests with oci-product-development, delivery services with oci-developer-services, and independent AppSec gates with oci-security-compliance.
6. Implement, run allowlisted checks, and give independent reviewers the artifact rather than the author’s conclusion.
7. Record verification, rework, and the measurement result. If a MultiLLM/provider gate is unavailable, continue with the primary agent and record the skipped gate.

Committed workflow evidence conforms to ../../schemas/application-workflow.schema.json: classification, test IDs, independent-review IDs, verification IDs, and optional reuse decisions only. Set raw_content to false. Never commit prompts, patches, source excerpts, provider responses, or secrets as workflow evidence.

Optional Adaptive MultiLLM policy

MultiLLM is an optional local gateway, never a required dependency or an automatic routing change. Offer it when the user asks to compare models, optimize cost/latency, obtain an independent synthesis, or run the evaluation suite. Otherwise use the active primary agent normally. A user can decline it at any time without changing the application workflow.

When opted in, use one capable model for routine, low-risk work. Use auto for uncertainty. Force synthesized fusion only for architecture, security, material disagreement, or failed verification. Refresh model discovery at workflow start; discovered or unclassified models are not automatically promoted until official-provider verification and benchmarking. Do not hard-code a permanent “latest” model identifier.

llm_fusion is the forced deliberation interface. Prefer llm_adaptive for cheap-first work and retain the returned run ID, stages, confidence, token/cost totals, and decision trace. MultiLLM is optional (LLM_GATEWAY_URL defaults locally); its absence does not block implementation.

Common multi-step flows

| Request | Sequence | |---|---| | New application feature | classification → local knowledge → reuse ranking → TDD → implementation → independent review → verify → measure | | Existing-code review | classification → local knowledge → static/test evidence → independent code and security review → handoff findings | | Plugin selection | local reuse search → read-only plugin discovery → provenance/permission review → recommendation; explicit approval required to install | | OCI platform request | application boundary → oci-product-development bundle selection → service/domain owners materialize infrastructure |

Boundary

This skill performs no direct OCI mutation and emits no Terraform/service-resource implementation. It owns application-code workflow evidence only. Infrastructure, delivery controls, and security release authority remain with their named owners.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: adibirzu
• Source: adibirzu/oci-skills
• License: MIT

Install and usage instructions live in the source repository linked above.