Chronos Release Skill

Cut a release for the AllSource Chronos monorepo. Produces exactly one commit and one immutable annotated tag.

Immutable Tags Policy

NEVER move, delete, or re-create an existing tag. If a release has issues after tagging, bump the version and cut a new release (e.g., v0.10.4 instead of re-tagging v0.10.3).

Before starting, verify the requested tag does not already exist:

bash
1git tag -l "v<VERSION>"

If it exists, abort and tell the user to choose a higher version.

Procedure

1. Determine version

If the user provides a semver string, use it. If they say "patch", "minor", or "major", read the current version and increment:

bash
1grep 'version = ' apps/core/Cargo.toml | head -1 | grep -oE '[0-9]+\.[0-9]+\.[0-9]+'

2. Check preconditions

• Working tree must be clean (git status --porcelain empty) OR the user explicitly wants to include staged changes
• Current branch should be main (warn if not)
• Tag v<VERSION> must not exist

3. Bump versions

bash
1make set-version VERSION=<VERSION>

This updates: Cargo.toml, main.go, tracing.go, mix.exs (x2), K8s manifests, README.md.

After running, also update Cargo.lock:

bash
1cd apps/core && cargo update --workspace

Check for any other version references that set-version might miss:

• apps/control-plane/docs/openapi.yaml (info.version field)
• apps/core/README.md, apps/mcp-server-elixir/README.md (version badges/text)
• docs/ files referencing the old version

4. Run CI to green

IMPORTANT: Run the three quality gates in PARALLEL, not sequentially.

make ci runs Rust → Go → Elixir sequentially, which takes 10+ minutes per iteration. Instead, launch all three as background tasks:

bash
1# Launch all three in parallel (use run_in_background for each)
2make quality-rust 2>&1 | tail -5      # ~3-4 min (clippy + test + doc)
3make quality-go 2>&1 | tail -5        # ~30 sec
4make quality-elixir-full 2>&1 | tail -10  # ~4-5 min (dialyzer + tests)

Wait for all three to complete, then check results. This cuts CI time from 10+ min to ~4 min per iteration.

For targeted re-checks after fixes, only re-run the affected gate:

• Rust fix → make quality-rust
• Elixir fix → make quality-elixir-full
• Go fix → make quality-go

Pre-fix common issues before running gates to minimize iterations:

bash
1# Always run these before the first CI attempt:
2cargo +nightly fmt --all
3cargo +nightly sort --workspace
4cd apps/mcp-server-elixir && mix format && cd ../query-service && mix format && cd ../..

If CI fails, fix issues and re-run only the failing gate(s):

• Rust: cargo +nightly fmt --all, cargo +nightly sort --workspace, clippy fixes, doc link fixes
• Go: gofmt, golangci-lint fixes
• Elixir: mix format, mix deps.unlock --unused, credo fixes, test fixes

5. Commit (single squashed commit)

Stage all changes and create exactly ONE commit:

bash
1git add -A
2git commit -m "$(cat <<'EOF'
3release: v<VERSION> — <brief description of what changed>
4
5<bullet list of key changes>
6
7Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
8EOF
9)"

Critical: There must be exactly one new commit for the release. If you need multiple rounds of CI fixes, do NOT commit between rounds — only commit once everything is green.

6. Tag (immutable)

Create an annotated tag:

bash
1git tag -a v<VERSION> -m "v<VERSION> — <brief description>"

7. Verify

bash
1git log --oneline -3
2git show v<VERSION> --oneline --no-patch

Confirm: single new commit, tag points to it.

8. Report

Tell the user:

• Version: v<VERSION>
• Commit: <hash>
• Tag: v<VERSION>
• CI: green
• Remind them to git push && git push --tags when ready

Do NOT push automatically — let the user decide when to push.

Common CI Fix Patterns