Omega Cloud -- Using Your AI Assistant Skill

With your handover pack you received tenant-skill/, a skill package for Claude (Anthropic's AI assistant). Installed into your own project, it teaches your assistant how to operate your Omega Cloud environment correctly: which of your three accounts to use for which job, which permission errors are deliberate platform boundaries, and how to behave safely on a live environment. This page explains how to install it and how to get the most out of it.

What the skill is

A folder of plain-text instructions your AI assistant loads when you ask it to do cloud work:

SKILL.md -- the core: account selection, the boundary model, authentication, safety rules, and a routing table.
references/ -- detailed, on-demand pages the assistant loads per topic: day-2 operations (networks, VMs, volumes, load balancers), Kubernetes, CI/automation, and troubleshooting.

Your copy was instantiated for you at handover: it already contains your short name, endpoints, and region. It contains NO credentials -- it tells the assistant how to authenticate, never what your secrets are.

Installing it

Claude Code (terminal / IDE): copy the delivered tenant-skill/ directory into your project as .claude/skills/omega-cloud-tenant/ (the directory name must be exactly omega-cloud-tenant). The skill is picked up automatically; asking "what skills are available?" should list it.
claude.ai (web): add the skill files to your project so they are part of its knowledge, or use your organization's skill-upload feature where available. Claude Code with terminal access is the better fit for hands-on cloud work, since the assistant can run the OpenStack CLI itself.

Give the assistant a working CLI environment: the OpenStack client installed, your clouds.yaml configured per the CI/Automation Integration Guide, and the delivered CA bundle on disk. Credential secrets belong in your environment (or your secret store), never pasted into the chat.

Getting the best out of it

Just describe the task. "Create a VM reachable from our office network", "why did the pipeline get a permission error", "stand up a Kubernetes cluster for staging". The skill triggers on cloud work by itself; you do not need to name it.
Let it read before it writes. The skill instructs the assistant to audit current state with list/show commands before changing anything, and to ask your confirmation before anything destructive. Expect (and welcome) those confirmation questions.
Expect it to respect boundaries. If you ask for something the platform deliberately refuses -- raising your own quota, creating a cluster from an automation credential, granting admin -- a correctly working assistant will decline the workaround and point you at the request path instead. That is the skill doing its job.
Never paste secrets into the conversation. Passwords, credential secrets, kubeconfig contents, and private keys stay out of the chat. The assistant is instructed never to print them; help it by never supplying them in-line. When a password login is needed, it will have you enter it at a prompt.
Keep the companions nearby. The Handover Pack, Self-Service Guide, CI/Automation Integration Guide, and Acceptance Checklist are the authoritative long-form documents; the skill is the operating layer over them. If the assistant's answer and a delivered document ever disagree, the document wins -- and we would like to hear about it via your account contact.
A good first test. Ask the assistant to run the delivered read-only audit script (bash scripts/tenancy-audit.sh from your document pack). It proves authentication, the CA bundle, endpoint discovery, and the skill itself in one pass, and changes nothing.

Keeping it current

The skill is versioned with your document pack. When we ship an updated pack, replace the installed skill directory with the new copy -- do not hand-edit it, or your edits will be lost at the next update. Requests to change what the skill teaches go through your account contact like any other document feedback.