just-vibeGeneral · plan by default
/plan
Inspect the project and produce a concrete implementation plan
Use for implementation sequencing against existing code; tasks breaks an accepted plan into work items.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select plan from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv plan, /just-vibe plan and /jv:plan in Claude. See shortcut setup and context examples.
/just-vibe:plan Plan adding saved filters to the existing search page without new dependencies./just-vibe:plan Plan a backward-compatible API change with old clients still active./just-vibe:plan Plan from this partial repository; external service schemas are unavailable.What the agent does
- Find affected modules and existing patterns, and separate discovery tasks from known changes.
- Order the steps by dependency, putting discovery before changes that depend on uncertain contracts; connect each step to actual files, interfaces and a completion check, and note rollout needs.
- For a multi-phase feature, fix, refactor or MVP, use the relevant phase contract in the composed-workflows guide. Keep simple work direct. Delegate only when authorized, and use the reviewed worker result and acceptance flow before dependent work. Offer the plan-review canvas only when browser feedback is useful or requested.
Inputs
- objective or existing spec plus constraints and scope. Requires repository inspection.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- An executable implementation sequence grounded in this project; no feature implementation.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Plan; objective or existing spec plus constraints and scope. Requires repository inspection.
- 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
- Ordered change table with target files or components, dependencies, a completion check per step, risks and rollback boundaries.
How the work is checked
- A developer can start the first task without guessing its target; a missing integration is an explicit prerequisite rather than assumed available.
When to stop or clarify
- Do not estimate unknown work as certain. Ask only for decisions that change the plan materially.
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
- Inspect relevant code, dependencies, current tests and the requested result.
- Method
- Order concrete changes by dependency and attach discriminating checks and recovery boundaries to consequential steps.
- Pitfall
- A list of filenames or tool names is not an implementation plan; invented repo structure produces unusable tasks.
- Check
- Ensure each step maps to an observed location or justified new artifact and contributes to a stated acceptance criterion.
Situational decisions
When a required integration cannot be inspected: Plan a contract seam and isolated fixture, then identify the live verification prerequisite separately.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.