General · apply by default

/goal

Create and pursue a persistent objective with completion criteria, progress, blockers and evidence

Use when the user explicitly asks to establish, resume, inspect or manage a persistent goal. Use plan for a proposal alone and checkpoint for a one-time context snapshot.

Make it your own.

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

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

normal · apply
/just-vibe:goal Goal: make checkout work with discount codes and verify the failure states. Preserve the API contract.
edge · inspect
/just-vibe:goal Resume my checkout goal and show what remains; the validation artifact changed since yesterday.
blocked · apply
/just-vibe:goal Finish the deployment goal, but production credentials are not available.

What the agent does

  1. Read the runtime goal reference. Resolve whether the user is creating a goal, resuming one, changing its scope or asking for status. Use goals_read/goal list first and reuse the matching objective instead of making duplicates. Revise completion criteria explicitly when the objective changes; prior scope evidence remains historical and does not satisfy the new criteria.
  2. For a new goal, preserve the objective, constraints and concrete completion criteria with goal create. Set a native host goal as well when that capability exists and the user explicitly requested a goal; only set a native token budget if the user supplied one.
  3. Carry out authorized work using the relevant just-vibe workflows and available host tools. Persist concise progress, next steps and real blockers with goal update at meaningful checkpoints. A goal does not imply permission to spawn workers or run paid services.
  4. Record each criterion with goal evidence, distinguishing an attributed host report from a hashed artifact. Read goal resume after interruption, compare evidence freshness and continue the remaining work without resetting constraints.
  5. Mark complete only when criteria are satisfied with current evidence and blockers cleared; synchronize the native host goal if one was created and its completion conditions are met. Reopen a completed goal when new work is requested and collect fresh verification for its pending criteria. If blocked, save the specific dependency and useful next step; do not claim completion.

Inputs

  • The user objective, project root and observable completion criteria inferred from the request or clarified when necessary.

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

Scope

Reads
Read current goals, current project instructions and evidence relevant to the named objective. Recheck old evidence against current files before resuming.
Writes
Save goal state outside the repository through the bundled runtime. Implement the requested work through the relevant workflows within existing authorization; publishing, external messages and destructive operations still require the corresponding user intent.
Mode
An explicit goal request authorizes saving and progressing that objective within the requested scope. Inspect/list/resume context do not independently authorize new external actions. Never invent a token or spending budget.
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

  • Persistent goal ID, current status, completed criteria, evidence and next action.
  • Implemented result or a precise unresolved blocker; a plan or saved goal alone is not completion of an implementation request.

How the work is checked

  • Goal state survives a new session and preserves constraints and outstanding work.
  • Completion is rejected when criteria lack evidence, artifacts changed or blockers remain.
  • Native host state and local state are reported separately if either could not be updated.

When to stop or clarify

  • Stop dependent work when a required answer, external access or authorization is missing; continue independent authorized work.
  • Respect cancellation, retirement and changed user scope. Never turn a saved goal into indefinite autonomous background work.

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
Current goal revision, completion criteria, constraints, blockers and artifact hashes.
Method
Revision-checked goal records; each criterion has attributed or hashed evidence. Native goal controls are optional and distinct from local persistence.
Pitfall
Treating a saved objective or a process exit as completed work, or treating a goal as blanket permission for external actions.
Check
Complete a goal only with current evidence for every criterion; an artifact changed since its evidence reopens the affected criteria.

Situational decisions

When the host exposes native goal controls: Use them for the explicitly requested goal, respecting their budgets and state rules; local records add portable criteria and evidence.

When a matching goal already exists: Show or resume it, reconcile scope changes with the current request and preserve its history.

When there is no native goal tool: Use the local persistent goal record and current task execution; disclose that the record does not schedule future runs.

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