/release

Make it your own.

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

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

What the agent does

1. Resolve the verified previous release boundary and map artifacts to the exact candidate revision.
2. Inspect changes since that boundary, group user-facing outcomes, and surface breaking contracts with their migration guidance.
3. Review the required checks for the candidate revision.
4. All changes are owned by the user. Add no agent/model self-attribution, AI-generated signature, badge, or agent Co-authored-by trailer to commits, PRs, comments, release notes or messages. Use the existing user Git identity; preserve legitimate human attribution and required third-party notices.

Inputs

• release range/version, audience, compatibility expectations, and release process.

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

Scope

Reads

Release notes and readiness; tagging, publication, and deployment require explicit requested actions.

Writes

Inspect/plan: prepare notes and readiness checks; save requested artifacts only. Apply: edit only the requested changelog and version files and run relevant checks. Tagging, publishing and deployment need their own exact request; github-release handles GitHub publication.

Mode

Plan; release range/version, audience, compatibility expectations, and release process. Apply for requested local preparation of changelog and version files; tagging, publishing and deployment need their explicit action.

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

• Release notes for the candidate version/ref grouped by change category, with migration notes, outstanding release gates and ordered release/recovery steps.

How the work is checked

• Included changes fall within the release range; an unresolved breaking migration blocks a ready-to-release claim.
• Review newly prepared commit/PR/message text, including template or hook additions, for agent self-attribution before submission; verify the resulting artifact when available. Do not silently rewrite existing history or remove human credits.

When to stop or clarify

• Do not invent version history or assign semantic-version significance without examining compatibility.

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 version, release range, artifact contents, compatibility and validation records.

Method

Prepare notes and readiness gates from actual changes; bind tested artifacts to hashes and identify recovery limits.

Pitfall

Source version changes do not publish a package; a rebuilt archive differs from the one previously tested.

Check

Inspect the exact candidate archive and version/manifest consistency and keep unpublished or pending platform checks explicit.

Situational decisions

When release history or artifact provenance is ambiguous: Block a ready claim for that evidence while drafting confirmed changes.

When a tag or publication is requested on a host other than GitHub: Resolve the exact registry or host, version and artifacts, confirm the changelog and version files match, and treat the tag and publish as separate external actions with their own target.

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