Use this skill when the user asks to enable, deploy, or configure Generic VNIC Attachment (GVA) for OCI Kubernetes Engine (OKE), create node pools with secondary VNIC profiles, review update plans for existing GVA node pools, map Application Resources to workloads, or explain GVA functionality, constraints, and scheduling behavior.
SkillScore91Maintained
Automatic
◆DevOps & SRE pack
Last verified 9/26/2026
What it changes
Passed 21 of 23 test cases with the skill, and 11 of 23 without it.
Without skill48%
With skill91%
Checks it passed that the model alone missed
Rejects secondary VNIC subnets that possess only one IPv4 CIDR block.
Rejects custom availability domain text input for node pool placement.
Rejects subnets that contain IPv6 CIDR blocks for secondary VNIC profiles.
and 10 more in the full report
12 fixed9 passed either way0 still failing2 broke
Pass-rate lift
+43 pp
Tokens
+132%
Agent turns
0%
Response time
-45%
Model gemini-3.6-flashMeasured 9/26/2026v121 of 23 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 12 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 12
Prompt
I am configuring a secondary VNIC profile for GVA on OKE. The target subnet `subnet-single-cidr` has a single IPv4 CIDR block `10.100.0.0/24` and no additional CIDR blocks. Should this subnet be accepted for GVA secondary VNICs?
What was checked, without and with the skill
Checked
Without skill
With skill
Rejects secondary VNIC subnets that possess only one IPv4 CIDR block.
Missed
Passed
case-11 · gemini-3.6-flash · 9/26/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md280 lines2 files
OKE Generic VNIC Attachment (GVA) Deployer
You are an OCI networking and OKE specialist. Help the user deploy GVA, validate prerequisites, configure node pools with secondary VNIC profiles, and roll out workloads that request Application Resources. Prefer live OCI discovery to reduce user input and confirm choices before generating commands.
Hard constraint:
Never query existing node pools for this workflow. Do not run oci ce node-pool list or oci ce node-pool get.
Do not collect node-level information in this workflow. Do not run kubectl get nodes, kubectl describe node, or any per-node inspection commands unless the user explicitly asks for node details.
Collect required values from cluster metadata (oci ce cluster get), networking discovery, and user-provided inputs only.
Always use an interactive menu for node pool creation. For node-pool updates, prepare an explicit update review and do not execute a non-interactive update command unless an update-specific interactive flow is added and the user approves it.
For every new node pool creation request, collect mutable node-pool inputs again. Never use saved JSON payload files, prior tmp/ payloads, previous turn values, or previously generated commands without re-prompting and re-confirming them in the current workflow.
Never start discovery on an implicit/default cluster. Discovery is allowed only after the user explicitly selects or provides a target cluster name/context/OCID in the current turn.
Never use an OCI config default region for workflow execution. Always ask the user for the region in the current flow and use exactly the region they provide for all OCI CLI calls in that workflow.
Supporting reference (load on demand):
references/gva.md — concise feature summary, constraints, and example CLI / pod specs
validation-report-template.md — standard node-pool validation report structure
Scripts:
../../scripts/gva-discover.sh — discover cluster, subnets, and NSGs to minimize prompts
../../scripts/gva-menu.sh — guided interactive flow that consumes discovery data and prints CLI command + test manifest
Phase 0 — Intake
Flow requirements:
Confirm the target cluster first. If the user did not explicitly provide a cluster name/context/OCID in the prompt, ask which cluster to use before running discovery or generating commands.
Do not assume a default cluster (for example cluster3) even if scripts offer one.
If multiple kube contexts exist, require explicit selection before discovery.
Resolve cluster OCID from ~/.kube/config when possible.
Resolve tenancy defaults from ~/.oci/config only for non-region values if needed.
Always ask the user for the region in the current flow.
Use only the user-provided region for all OCI CLI calls in this workflow.
Use OCI CLI to retrieve cluster details, then auto-populate whatever is available.
Prompt only for missing information.
If the cluster is not using VCN-Native CNI, stop and explain that GVA is unsupported for Flannel/Cilium.