General · inspect by default
/explain
Explain code or behavior at the requested depth
Use for what existing code does and why its observed branches matter; use teach for fundamentals or trace for an entire request path.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select explain from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv explain, /just-vibe explain and /jv:explain in Claude. See shortcut setup and context examples.
/just-vibe:explain Explain how session refresh works, including expired credentials./just-vibe:explain Explain how this function handles an empty array and a rejected dependency./just-vibe:explain Explain this module from source only; runtime configuration is unavailable.What the agent does
- Locate the definition and a real caller, and inspect the branches that matter for the question.
- Walk one concrete input through transformations, outputs, side effects and failure handling with file references, at the depth and in the terminology the brief asks for; distinguish what the source shows statically from observed runtime behavior.
Inputs
- symbol, file, behavior, or question plus desired depth. Requires relevant source access.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Explain the selected behavior and its necessary dependencies; no refactoring or unsolicited repository-wide tutorial.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Inspect; symbol, file, behavior, or question plus desired depth. Requires relevant source access.
- Prerequisites
- Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
Expected output
- A causal explanation that walks one concrete input to its output with cited source locations, the edge path that matters, and unresolved runtime assumptions.
How the work is checked
- Explains both the normal path and a meaningful edge path; missing runtime configuration remains explicitly unknown.
When to stop or clarify
- Request a target only when multiple interpretations materially change the answer. Do not invent business intent from implementation alone.
Handling missing context
- Infer
- Resolve the named files, existing scripts, current task and earlier corrections from the conversation and repository.
- Assume
- Use the narrowest interpretation that completes a reversible local task; state a consequential assumption once.
- Ask
- Ask when competing targets or incompatible success conditions would change the result; continue independent inspection first.
Technical guidance
- Evidence
- Read the target definition, at least one caller, data shapes and relevant error handling.
- Method
- Walk one concrete input through state changes, output and side effects at the requested depth.
- Pitfall
- Plausible business intent cannot be inferred solely from a function name; configuration-dependent behavior remains conditional.
- Check
- Reconcile the walkthrough with source branches and show an edge path that changes the outcome.
Situational decisions
When explanation depends on configuration or external behavior not supplied: Separate the source-established path from conditional behavior and name the missing evidence.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.