About olares-doctor
olares-doctor is a diagnostic skill for Olares app and system runtime problems, intended for users investigating stalled installs, crashes, image pulls, unreachable entrances, or resource pressure. It routes evidence from Market, Cluster, and Dashboard and is read-only by default.
Key features
- 01Route common runtime symptoms
- 02Inspect app lifecycle states
- 03Gather pod, event, and log evidence
- 04Review local image inventory
- 05Check resource pressure and utilization
- 06Optional approved domain repair
Use cases
- 01Investigate installs that do not reach running
- 02Diagnose repeated app crashes or image pull failures
- 03Check an unreachable app entrance
- 04Examine slowdowns or rejected resource bindings
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/olares-doctorin Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
references/olares-doctor-app-crash.mdolares-doctor-app-stuck.mdolares-doctor-image.mdolares-doctor-resources.mdolares-doctor-running-unhealthy.mdolares-doctor-thirdleveldomain.mdDetails
From the project READMEdoctor (runtime diagnosis)
Shared front door: load
../olares-shared/SKILL.mdfor suite routing, active-profile selection, platform entry points, and the auth proceed/stop gate. Load its auth reference only when login, profile switching, token storage, or auth recovery is actually needed.
This skill is a thin diagnostic router over Market, Cluster, and Dashboard. Load the shared application-state model when interpreting lifecycle states, TTLs, serialized downloads, or running. Use olares-cli doctor <verb> --help for syntax.
When to use
- An install/upgrade is stuck or never reaches
running; an app won't start. - An app crashes / restarts repeatedly (CrashLoopBackOff, exit codes, config errors).
- An image won't pull (
ImagePullBackOff/ErrImagePull/ wrong arch), or you want to find unused local images. - An app is
runningbut its entrance is unreachable / errors / times out. - The system or an app is slow, or a GPU/resource binding is rejected (
node-pressure).
Both catalog apps (installed via market) and your own dev apps (deployed via chart) route runtime failures here. Once the root cause is found, the fix for a dev app you authored is usually a chart edit — hand back to ../olares-chart/SKILL.md.
Mental model:
doctoranswers "why is this broken and what do I do next?" Diagnosis is read-only by default; the only mutation is the explicitly approvedthirdleveldomain --force-deduperepair. The four-skill develop->deploy->debug combo ischart+market+olares-shared+doctor.
Symptom routing
| Symptom | Reference |
|---|---|
Install/upgrade stuck; never reaches running; sits in pending / downloading / installing / initializing; a fresh install ended in stopped | references/olares-doctor-app-stuck.md |
App crashes / restarts (CrashLoopBackOff, non-zero exit, CreateContainerConfigError, permission errors) | references/olares-doctor-app-crash.md |
Image won't pull (ImagePullBackOff / ErrImagePull / InvalidImageName / arch mismatch); finding unused local images | references/olares-doctor-image.md |
App is running but the entrance is unreachable / 5xx / times out / blank | references/olares-doctor-running-unhealthy.md |
System or app slow; resource pressure; GPU/compute binding rejected (node-pressure) | references/olares-doctor-resources.md |
A model that is configured but does not answer is diagnosed one layer up first: olares-router separates the gateway, its access control and the model application's own download/engine state from the pod-level failures here, and routes back when the cause is below the application.
First, rule out the normal queue. Before declaring an install stuck, check whether another app is
downloading— app-service runs one download at a time, so apendingrow is often just queuing (see the appstate reference and the app-stuck reference).
Verb index
| Command | Purpose | Read when triggered |
|---|---|---|
images | Full local image inventory annotated with workload references; unused candidates | image diagnosis |
thirdleveldomain | Audit duplicate/reserved third-level domains; optional repair | domain audit and repair |
How doctor gathers evidence (orchestration, not ownership)
- Lifecycle state/source comes from
olares-market. - Pods, events, logs, and workloads come from
olares-cluster. - Pressure and utilization come from
olares-dashboard. - Namespace discovery follows the shared platform model.
Correlate evidence by time and object ownership. A Market timeout is not failure; running proves only entrance TCP reachability; a fresh install can settle at stopped after scheduling failure without a *Failed lifecycle state.
Safety and escalation
- Diagnosis is read-only by default. Do not restart, delete, scale, cancel, prune, or edit a chart as an automatic diagnostic step.
thirdleveldomain --force-dedupemutates Application resources. Show the proposed changes and obtain explicit approval first.- An unused-image report is evidence, not authorization to remove images.
- System namespace evidence commonly requires admin visibility. On 403/404, use the app's own evidence and report the missing visibility; do not switch identities without approval.
- Stop when the app/user/namespace is ambiguous, required logs need a higher role, or the fix crosses into chart editing, lifecycle mutation, or host administration.