osmo-admin

Use this skill for OSMO configuration administration from one user-provided config folder or values file. Keep this file as a router: load only the reference files needed for the current request.

First Action Gate

Before listing, searching, or reading the workspace:

• If the request is live workflow support, resource availability, pod/node diagnostics, events, logs, status, or scheduler troubleshooting, do not use this skill. Say it needs live workflow or cluster tooling, such as the namespace, kube context, or exported diagnostics. If that tooling is missing, ask for the missing access details or exported diagnostics and stop. Do not attempt local kubeconfig or workspace discovery as a fallback.
• If the request needs file-specific config data but omits an explicit config folder or values file path, ask for that path and stop. An environment, deployment, pool, backend, template, or role name alone is not a config path. Do not name a source file, current value, backend, or target YAML key path before reading the provided path. Do not read references or list files first; after this router confirms the missing path, the next response is the path request.
• If the request includes an explicit config folder or values file path, continue under that exact path string. Use it for discovery, reads, and citations unless a tool requires an internal filesystem remap.

Purpose

Route OSMO configuration-administration questions to verified service values or local file diffs. This skill is config-path agnostic: it does not assume a repo layout, environment name, identity provider, storage backend, approval process, or deployment mechanism.

Requirements

• A user-provided config folder or values file path containing OSMO service config values or docs.
• Permission to read files under the provided config path.
• Permission to edit local files only when the user asks for an admin change.
• Generic example-only requests do not require a config path, but the answer must use placeholder names and label the structure as illustrative.

Activation

For file-specific config questions, first check whether the user provided an explicit config folder or values file. If not, activate only to ask for that path; do not list, search, or read the working directory.

Before activating, confirm the request is about OSMO service-config desired state or local service-values files. Do not activate for live workflow support requests, including submitted or running workloads, stuck or pending workflows, workflow events/logs/status, workflow exec/port-forward/rsync, live resource or capacity availability, node/pod/scheduler diagnostics, raw Kubernetes troubleshooting, live cluster operations for workloads or resources, or incident response. Route those to live workflow or cluster support instead. Activate for direct live OSMO service-config API calls or service ConfigMap reads/writes only to refuse that live path and ask for an explicit config folder or values file for local config work. If live workflow terms appear, including workflow IDs, stuck, pending, events, logs, status, pod/node/scheduler diagnostics, resource availability, or GPU capacity, stop before reading references or local configs and ask for live workflow or cluster tooling.

Use this skill for OSMO admin questions about:

• pool, backend, platform, quota, maintenance, topology, template, or storage desired state
• service config, workflow config, backend, role, resource validation, pod template, group template, or backend test definitions
• read-only answers such as which pools are in maintenance, which roles grant access, which tests attach to a backend, or which mounts a pool resolves to
• local service-values diffs for requested admin changes
• config history or rollback only when history is available in the provided config workspace

If the user asks to read or mutate OSMO admin config through a direct live API or a Kubernetes ConfigMap, use this skill only to refuse the live path and ask for an explicit config folder or values file for local config work.

Do not use this skill for user workflow submission/debugging, OSMO installation/deployment, or generic Kubernetes help.

Core Rules

1. Require an explicit config folder or values file path before making file-specific claims or edits. Ask for it when missing. Generic example requests may be answered without a config path when clearly labeled as illustrative. A deployment, environment, pool, backend, template, or role name alone is not an explicit config folder or values file. Generic target descriptions such as the GPU pool, the production backend, or the default template are not exact target names. Do not search the working directory to infer missing paths or targets. If the request needs file-specific config data and the user did not provide a config folder or values file, stop and ask for that path before listing, searching, reading, editing local files, or suggesting source files, current values, backends, or target YAML key paths.
2. Preserve the user's config path string exactly. Construct paths under that location and cite files using that path or paths relative to it. Never replace it with the current working directory or another discovered checkout. If local tooling maps the supplied config path to another filesystem location, use that location only for actual reads; keep that mapping internal and cite the supplied path string or a path relative to it in the answer.
3. Read references/service-configs.md for services.configs questions before answering or editing.
4. Clarify ambiguous config path, deployment, pool, backend, template, role, or local-diff intent before editing. For edits, the config folder or values file, target deployment or values file, and exact target name must all be unambiguous before any file is changed.
5. Answer read-only questions from verified config files and cite the source file path plus YAML key path. For every file-specific answer, rerun source discovery from the supplied config path in the current turn. A file path or value resolved in an earlier turn is not evidence for the current answer.
6. For requested changes, capture the target value or bounded subtree before editing, prepare the smallest local file change, reread the same target, and report the exact before/after result plus local validation output when run, or the exact statement that no local validation command was found.
7. Do not invent deployment names, file paths, review steps, or config relationships. Infer only from provided config files, or use obvious placeholder names in clearly labeled examples.
8. Do not treat the working directory as the config path unless the user explicitly identifies it as the config path.
9. Never use direct OSMO API config calls, including read-only queries, history, or rollback operations. Answer from an explicit config folder or values file, or ask for one.
10. Never run live mutation commands, including cluster mutation, deployment sync, or rollout commands.
11. Never delete unrelated files, perform destructive cleanup, or rewrite repository history. For preview diffs, use read-only extraction and diff construction that does not require deleting temporary files.
12. Never print secret payloads. Refer only to secret names, key names, and reference paths.

Service Config Procedure

For services.configs read-only answers, previews, edits, history, and rollback diffs, follow only the relevant section of references/service-configs.md. Avoid dumping the whole reference when a bounded section is enough. rg, grep, find, ls, and other listings are locator-only; claims require direct reads or YAML extraction that include the exact source path, key path, and value or small subtree. After the required exact evidence is collected, stop gathering and answer.

Reference Routing

references/service-configs.md

Read for service-values work itself: discovering config files under the provided config path, services.configs key mapping, read-only answers, local edits, history when available, rollback diffs, safe removals, and admin-flow specifics for pool/backend/storage/role/template/validation/workflow/backend-test values.

Limitations

• This skill prepares local config file changes. It does not deploy, sync, patch, drain, cancel workflows, or verify live service state.
• If the supplied config path does not visibly use services.configs, say so from file evidence instead of substituting another deployment.
• If required deployment-specific details are missing, ask one targeted question and stop before editing.

Troubleshooting