[Feature]: Allow update to @latest release

@latest

Problem Statement

Currently I have to run a small script just to be able to determine what the current release is. Omitting the version number results in .dev builds being installed.

LATEST_TAG="$(
  python3 - <<'PY'
import json
import urllib.request

with urllib.request.urlopen('https://api.github.com/repos/github/spec-kit/releases/latest') as response:
	print(json.load(response)['tag_name'])
PY
)"

uv tool install specify-cli --force --from "git+https://github.com/github/spec-kit.git@${LATEST_TAG}"
specify init --here --force --ai copilot

Proposed Solution

Initial and subsequent installs should only use released versions, automatically. Similar to the copilot cli, the specify cli should indicate when there is an upgrade available and should be capable of self updating, OR there should be a way to refer to an @latest tag only.

Alternatives Considered

No response

Component

Specify CLI (initialization, commands)

AI Agent (if applicable)

None

Use Cases

When upgrading spec kit

Acceptance Criteria

No response

Additional Context

No response

@rcollette

Hi @rcollette and @mnriem — I think a useful small PR here would be a read-only specify upgrade --check subcommand that:

calls the GitHub Releases API and compares it with the installed version
prints the upgrade command if a newer release exists
avoids any destructive action and does not try to detect the user's install method in this PR
falls back gracefully when offline or rate-limited

A new upgrade subcommand seems like a better fit than extending specify version, since version is a local-info command today, and specify integration upgrade already establishes upgrade as the verb in Spec Kit.

A follow-up PR could later add specify upgrade --apply for the actual self-update flow. I kept that out of scope here because it would need install-method detection (uv tool, uvx, source checkout, etc.) and failure/recovery handling, which seem like a design discussion of their own.

One design question before I start: should bare specify upgrade behave like --check, or should --check be required until --apply exists?

If that scope sounds right, I can take it.

Go for it, but will a small change. Please introduce specify self check and specify self upgrade

feat(cli): add specify self check and self upgrade stub (#2316)

@rcollette

Following up on Phase 1, I’d like to continue with Phase 2 as well. I’ll make sure to implement it as you intended, @rcollette @mnriem

feat(cli): implement specify self upgrade

@rcollette

This has finally landed via #2475.

Thank you @rcollette for raising the original issue and describing the upgrade pain point clearly. It took quite a while to get this over the line, but the review rounds made the final result much better.

Thanks again for bringing this up.

feat(cli): add specify self check and self upgrade stub (github#2316)

Navigation Menu

Repository navigation

[Feature]: Allow update to @latest release #2282

Problem Statement

Proposed Solution

Alternatives Considered

Component

AI Agent (if applicable)

Use Cases

Acceptance Criteria

Additional Context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Feature]: Allow update to @latest release #2282

Description

Problem Statement

Proposed Solution

Alternatives Considered

Component

AI Agent (if applicable)

Use Cases

Acceptance Criteria

Additional Context

Activity

chordpli commented on Apr 22, 2026

mnriem commented on Apr 22, 2026

chordpli commented on Apr 23, 2026

chordpli commented on Jun 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions