General · inspect by default

/compare

Compare specific implementation approaches and their tradeoffs

Use for a factual side-by-side comparison; decide recommends adoption and decision-matrix handles weighted priorities.

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select compare from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv compare, /just-vibe compare and /jv:compare in Claude. See shortcut setup and context examples.

Example · inspect
/just-vibe:compare Compare queue-backed jobs with our existing database job runner.
edge · inspect
/just-vibe:compare Compare two queues when ordering is required only within an account.
blocked · inspect
/just-vibe:compare Compare these proposals without usage or pricing data; leave costs bounded or unknown.
Example · apply
/just-vibe:compare Build two alternative account switchers, preview both and apply the one I choose.

What the agent does

  1. Normalize workload, feature requirements, time horizon and other assumptions; include a baseline/current option.
  2. Compare behavior, complexity, maintenance, migration and relevant cost, distinguishing switching cost from steady-state cost; identify where evidence is missing.
  3. Keep an ordinary comparison in inspect/plan mode. When the brief explicitly asks to build or try alternatives, define two or three distinct approaches with the same requirements and budget, inspect the Git root and starting changes, and create a lab using the working-alternatives guide.
  4. Implement each approach in its returned owned worktree. Preserve initial user edits and use equivalent dependency/test conditions; record meaningful environment differences. Read and run the same declared checks for all variants and inspect actual renders before describing visual behavior.
  5. For previewable projects, launch a bounded lease with the real loopback server command and literal {port} placeholder; verify its response and open the comparison report and previews. Compare observable behavior and subjective tradeoffs separately, with no invented universal quality score.
  6. Apply the selected variant only after the user selects it or has explicitly delegated that choice. Require fresh checks and unchanged original files/index in the affected scope. Use lab select to journal the application and produce an undo task; preserve unrelated original edits.
  7. Stop owned preview processes and clean up reviewed workspace snapshots when requested or as agreed for the task. Preserve wanted alternatives first. Recover interrupted selection through lab recover; never force-clean a stale or unowned workspace.

Inputs

  • named approaches, project requirements, and important tradeoffs. Requires enough evidence to evaluate each option.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads
Compare concrete alternatives; weighted decision policy belongs to `decision-matrix`.
Writes
Inspect/plan: compare from evidence; save requested artifacts only. Apply (a request to build or try alternatives): write only in owned lab worktrees under .just-vibe/workspaces, run owned preview processes, and apply the chosen variant through lab select with an undo record only after the user selects it. No commit, push or deploy.
Mode
Inspect; named approaches, project requirements, and important tradeoffs. Requires enough evidence to evaluate each option. A request to build or try alternatives uses apply mode.
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

  • Side-by-side comparison on shared assumptions with evidence-backed differences, the conditions that change the result, a conditional recommendation and a discriminating test if needed.
  • Working variants, shared check evidence, preview/report links, selected changes and an undo record when applied.

How the work is checked

  • Options solve the same stated problem; a hard compatibility constraint can disqualify an otherwise attractive option.

When to stop or clarify

  • Do not invent benchmark or cost figures. If requirements are unresolved, give conditional choices rather than an arbitrary winner.

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
Identify alternatives, common requirements, evaluation conditions and whether working implementations were requested.
Method
Compare like-for-like behavior; use isolated variants with shared checks when building alternatives is in scope.
Pitfall
Unequal feature completeness or different datasets can manufacture a winner; human preference remains attributed judgment.
Check
Apply the same checks to every variant and distinguish measured results, subjective acceptance and blocked evidence.

Situational decisions

When options meet different hard requirements: Eliminate infeasible choices before ranking and explain the decisive incompatibility.

When the user asks to build alternatives: Use isolated lab worktrees, equal checks and actual previews, then apply only the authorized selection.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring