just-vibeGeneral · plan by default
/tasks
Convert a brief or plan into ordered, verifiable tasks
Use to turn an accepted plan into independently verifiable work; plan resolves architecture and sequencing first, and github-issue files the tasks when submission is requested.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select tasks from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv tasks, /just-vibe tasks and /jv:tasks in Claude. See shortcut setup and context examples.
/just-vibe:tasks Break the accepted invitation spec into ordered tasks with acceptance checks./just-vibe:tasks Split a migration plan into tasks that leave every intermediate release usable./just-vibe:tasks Break down known work while keeping an unresolved provider choice as a dependency.What the agent does
- Preserve the requirements and map dependencies; keep inseparable schema/client changes in one task or state their compatibility bridge.
- Give each task one observable output, an acceptance check and its prerequisite edges; order the critical path and flag tasks that need a decision.
Inputs
- accepted brief/spec/plan and optional tracking format.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Break work into implementable units; external issue creation is separate and requires a request to submit.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Plan; accepted brief/spec/plan and optional tracking format.
- 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 tasks with IDs, the requirements each covers, prerequisites, deliverable and acceptance check.
How the work is checked
- Every required outcome maps to a task; tasks do not duplicate ownership of the same inseparable change.
When to stop or clarify
- Do not create estimates, owners, or external tickets as established facts when none were supplied.
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 accepted scope, dependency graph, owners where known and completion evidence.
- Method
- Create tasks with a verifiable outcome and prerequisites; split by coherent behavior rather than arbitrary file count.
- Pitfall
- Marking a task complete because its code exists overlooks unrun verification or blocked integration.
- Check
- Check that all acceptance criteria have an owner task and that dependent tasks cannot complete ahead of missing prerequisites.
Situational decisions
When tasks overlap the same shared interface: Define an integration order and owner boundary before parallel work is proposed.
When the user asks to file the tasks in a tracker: Prepare issue drafts; create them only on an explicit submit request, through github-issue or the epic plan and epic publish operations.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.