Skip to main content

/tag — a version mark, not a release

· 2 min read
Carefree Investments LLC
Anchor maintainers

/tag answers one question — what's the next version, and can I mark it — without doing anything a release actually requires. It never pushes, and it is deliberately not a release.

Why split it out​

Ask an agent to "cut a release" and the easy failure mode is scope creep: a tag becomes a push, becomes a merge of whatever branches happened to be lying around, with no one having looked at what's actually landing. /tag refuses that shape entirely — it only ever touches one local, annotated tag.

What it does​

/tag              # detect scheme, show latest tag, suggest next version
/tag --suggest    # print only the next version — for scripting
/tag v0.2.0       # create a local annotated tag, after confirm

Scheme detection reads git tag --list and classifies what's already there — v-prefixed semver, bare semver, calver, or something else it asks about rather than guessing. With no tags yet, it defaults to annotated semver with a v prefix, seeded from a package manifest version when one looks right. Once a repo has a scheme, /tag never proposes a second one.

Guardrails​

  • Never pushes. Every invocation, tag or no tag — pushing is a separate, explicit step outside this skill entirely.
  • Never force-tags. An existing tag name is a hard stop, not a prompt to overwrite.
  • Dirty tree blocks creation by default; --allow-dirty overrides with a printed risk line.
  • --status / --suggest are read-only and never prompt.

Docs: /tag. Sources: .claude/commands/tag.md and .grok/skills/tag/SKILL.md, both scaffolded into projects by anchor.