just-vibeOperations · inspect by default
/ops-container
Diagnose container builds, runtime failures, and configuration differences
Use for image/build/runtime diagnosis; ops-restore handles recovery of persisted state.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select ops-container from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv ops-container, /just-vibe ops-container and /jv:ops-container in Claude. See shortcut setup and context examples.
/just-vibe:ops-container Diagnose why this multi-stage image lacks its runtime files./just-vibe:ops-container Diagnose a multi-stage image missing a required runtime file under a non-root user./just-vibe:ops-container Inspect a Dockerfile without building untrusted images or granting privileged mounts.What the agent does
- Compare build context, multi-stage copy paths, runtime user, working directory, ports and volume permissions with host assumptions.
- Inspect image metadata and logs from the intended image digest, and reproduce in an isolated build after evaluating its execution effects.
- Propose a focused fix, applying it in apply mode.
Inputs
- Dockerfile/image/runtime configuration, logs, and failing build/start behavior.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Container build context, dependencies, permissions, entrypoint, networking, resources, and health checks.
- Writes
- Inspect/plan: inspect or propose; save requested artifacts only. Apply: edit the requested local implementation and perform relevant bounded checks while preserving unrelated work. Live data changes, remote actions and paid jobs require their resolved target and existing session authorization.
- Mode
- Inspect; Dockerfile/image/runtime configuration, logs, and failing build/start behavior. Apply for a requested focused fix.
- Prerequisites
- Exact service/environment, time window, revision/configuration identity, authorized logs/metrics, and operational constraints. Prefer observation before intervention; live restarts, traffic changes, restores, and notifications require the requested target/action. Redact sensitive telemetry.
Expected output
- Diagnosis or patch with the build/runtime boundary, artifact identity, build/start evidence and remaining isolated-reproduction or environment gaps.
How the work is checked
- Required runtime files survive multi-stage builds; a non-root process can access only intended paths.
When to stop or clarify
- No privileged host mounts or deployment changes by default. Building/running untrusted images requires evaluating their execution effects first.
Handling missing context
- Infer
- Read service/environment, time window, revision, available telemetry and existing incident or recovery procedure.
- Assume
- Start from supplied logs and read-only observation; rank hypotheses without presenting an unexecuted intervention as recovery.
- Ask
- Resolve the precise target and missing authority before restart, restore, notification or traffic changes; continue evidence analysis while waiting.
Technical guidance
- Evidence
- Inspect build stages, image digest, architecture, user, filesystem permissions, entrypoint and signal handling.
- Method
- Separate build-time assets from runtime requirements; use least-needed privileges and remove secrets from build layers.
- Pitfall
- Deleting a secret in a later layer leaves it in earlier layers; a running process does not prove readiness or graceful shutdown.
- Check
- Build/run an isolated image, exercise readiness, SIGTERM and read-only/non-root requirements, and inspect final-image contents.
Situational decisions
When local build and deployed digest differ: Establish artifact identity before patching source or diagnosing runtime configuration.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.