5.6 KiB
5.6 KiB
name, description, license, metadata
| name | description | license | metadata | |||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| athena-operator | Operate and extend the Athena AI platform safely. | MIT |
|
Athena Operator Skill
Operate, diagnose, extend, and recover the Athena AI platform through its platform-context and operator MCPs. Keep durable truth in the versioned Athena repository and use live measurements only as evidence of current state.
When to Use
- Use for Athena, MikeAI, Docker-stack, router, inference-profile, model, benchmark, MCP, Hermes, Open WebUI, TTS, STT, image, Git-deploy, and recovery work on the Athena host.
- Use when a user asks how Athena is built or whether an Athena component is running, configured, documented, reproducible, or recoverable.
- Do not use as the primary tool for Home Assistant, Unraid, Sonarr, Radarr, Navidrome, or GitHub data when their specialist MCP is available.
Prerequisites
- Require
Athena Plattformwissenfor architecture and versioned knowledge. - Require
Athena Operatorfor live host inspection and execution. - Treat missing or failed tools as missing evidence. Never invent state, output, files, logs, or completed actions.
- Never request, reveal, copy into chat, or commit secret values.
Tool Selection
- Identify the target system before calling a tool.
- For Athena itself, begin with
athena_operator_inspect. Useathena_get_overviewwhen architectural context is needed. - For external services, prefer the narrow specialist MCP. Use
athena_get_external_servicesbefore planning a duplicate service. - Use
athena_operator_search_sourceandathena_operator_read_sourcefor deployed code. Useathena_search_knowledgeandathena_read_sourcefor documentation. Do not guess paths or configuration. - Use
athena_operator_terminalas the broad Athena escape hatch only when a structured tool is too narrow. Keep commands focused and outputs bounded.
Procedure
- Establish evidence. Inspect only the relevant live subject and read the smallest authoritative source section. Completion: runtime facts and source facts are separately identified.
- Check drift. Compare live state with versioned source and current reference documentation. Completion: any mismatch is named before changes.
- Protect the active workload. Check jobs and active containers. Do not restart, recreate, switch profiles, alter shared configuration, or consume required GPU capacity while an important request or benchmark is active. Completion: work is either proven idle or the change is staged only.
- Plan rollback. Name the files, services, validation, rollback artifact, and expected user-visible effect. Completion: rollback is possible without relying on chat history.
- Change the source of truth. Modify repository sources, not only a live
container. Prefer
athena_operator_prepare; show its full preview and stop for the exact user confirmation beforeathena_operator_execute. Completion: the approved ticket matches the intended content. - Deploy narrowly. Change only named services. Never restart the entire stack merely to activate one component. Completion: unrelated containers and the active inference request remain undisturbed.
- Verify behavior. Run syntax/config checks, focused tests, service health, and one bounded functional test. A running container alone is not proof. Completion: expected behavior and rollback path are both verified.
- Close the maintenance loop. Update relevant docs, publish the Git change, create a newer recovery bundle, then check maintenance status. Completion: source commit, deployed state, docs, and recovery agree.
Persistent Versus Temporary Work
- "Use" a missing helper for one task: place it in a task-specific temporary location or ephemeral container and remove it afterward.
- "Install", "add", "deploy", or "make permanent": implement it in repository source, documentation, installation flow, and recovery.
- Do not create a second backend merely because an existing service is stopped, inaccessible, or absent from one tool catalogue.
Remote-Safety Boundary
- Athena has no physical console or KVM. Never attempt power control or changes to Athena SSH, LAN, WireGuard, firewall, boot, kernel, drivers, mounts, or partitions through this workflow.
- Do not stop or restart the WireGuard gateway as a side effect of ordinary deployment. Bind user services to the VPN path; keep them unavailable from the university LAN.
- Inside the trusted VPN, normal service communication and Internet access are allowed. Do not add extra egress restrictions unless the user requests them.
Pitfalls
- Profile names are not simultaneous models; exactly one text profile is active.
- A profile switch can terminate active generation and invalidate prompt cache.
- A healthy container can still expose the wrong model, route, or tool set.
/opt/mike-ai/stackis deployed source, not automatically the canonical Git worktree. Complete durable changes through the documented Git workflow.- New skills are loaded at the next Hermes session; absence in the current session is expected.
Verification
- State the tools that supplied each important live claim.
- List every modified source file and every deployed service.
- Report focused test and health results, not vague success language.
- If Git publication or recovery creation is incomplete, call it unfinished maintenance rather than declaring the task fully complete.