General · plan by default
/spec
Produce requirements, acceptance criteria, and edge cases
Use to define observable product behavior before implementation; a PRD is a specification, and plan derives the implementation plan from it.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select spec from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv spec, /just-vibe spec and /jv:spec in Claude. See shortcut setup and context examples.
/just-vibe:spec Specify organization invitations, including expiry and already-registered users./just-vibe:spec Specify account deletion with a pending subscription and recoverable failure./just-vibe:spec Draft a specification with unknown retention policy; leave that decision explicit.What the agent does
- Inspect current behavior, then write actors, preconditions and state transitions with normal and error paths.
- Give observable acceptance examples, record exclusions, and turn ambiguity into explicit assumptions or decisions, separating business decisions from implementation preferences.
Inputs
- feature brief, users, constraints, and relevant existing contracts.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Requirements and observable behavior; no code changes or invented business policy.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Plan; feature brief, users, constraints, and relevant existing contracts.
- 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
- Requirements with IDs, acceptance examples, edge cases, compatibility needs, exclusions and unresolved questions with their decision owners; save only when requested.
How the work is checked
- Each requirement has an observable completion condition; conflicting requirements are flagged before downstream implementation.
When to stop or clarify
- Do not silently choose billing, privacy, or access policy that needs the user's decision. Continue specifying independent behavior.
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
- Resolve actors, desired outcomes, existing contracts and meaningful exclusions.
- Method
- Define observable acceptance criteria and state transitions, including invalid, interrupted and recovered behavior where material.
- Pitfall
- Implementation detail can prematurely constrain a product requirement; vague adjectives cannot establish completion.
- Check
- Walk a representative user scenario and a failure scenario against the criteria and expose unresolved choices.
Situational decisions
When two requirements conflict on the same transition: Surface the concrete conflicting example and resolve that decision before specifying dependent behavior.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.