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.

Example · plan
/just-vibe:spec Specify organization invitations, including expiry and already-registered users.
edge · plan
/just-vibe:spec Specify account deletion with a pending subscription and recoverable failure.
blocked · inspect
/just-vibe:spec Draft a specification with unknown retention policy; leave that decision explicit.

What the agent does

  1. Inspect current behavior, then write actors, preconditions and state transitions with normal and error paths.
  2. 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.

Keep exploring