Dot Release

Use the checkout's release task as the single owner of preparation and publication. The global release guide owns generic versioning and publication verification; this skill owns dot's preconditions and recovery.

Workflow

1. Confirm authority: the release command commits, pushes, and refreshes the installed CLI. An explicit /dot-release invocation or release request authorizes the whole flow below, including verification fixes, commits, the push to main, and the delivery fixes and follow-up release below; loading this skill for reference, review, or reconciling a past release does not.
2. Qualify first: run dot-verify on the checkout and resolve its findings. Stop and report instead of releasing when a finding needs the user's decision or a gate stays red.
3. Commit the candidate: group verified work into logical Conventional Commits (the changelog is generated from them), then git fetch and push main so HEAD equals upstream; pre-push hooks rerun the network checks and tests. If upstream moved, integrate it without rewriting history only when its commits do not overlap the candidate; otherwise stop.
4. Know the preconditions: the task stops before writing unless dprint, git, git-cliff, mise, and uv exist, the tree is clean on main, HEAD equals the fetched origin/main, and the next tag is absent locally; without new Conventional Commits it releases nothing. Preserve unrelated work when a precondition fails.
5. Run the owner: use the commands below from the repository; the task runs from source (uv run --frozen --directory dot python -m dot_tasks.release), not the possibly stale installed CLI.
6. Read the result: the task bumps dot/pyproject.toml, CHANGELOG.md, and dot/uv.lock (only those files may change), formats the changelog with dprint (CD rejects a tree its formatter changes, so this never depends on Git hooks), gates the bumped commit (check:network, which refreshes the vulnerability data CD rechecks, test:starters, which re-resolves unlocked upstream packages since CI ran, build, and the host-only check:completions), then commits with the Lefthook output visible, tags, pushes both with git push --atomic, and runs mise run deploy.
7. Verify delivery: the tag triggers cd.yml: a read-only gate job reruns mise run all and extracts the git-cliff notes; a publish job holding only contents: write, with no checkout, creates the GitHub release. Confirm with gh run list --workflow cd.yml --branch <tag> and gh release view <tag>. Local command success does not prove CD completion.
8. Monitor and fix CI/CD: watch the release commit's CI run (including the macOS job) and the tag's CD run to completion with gh run watch <id> --exit-status. On failure, read gh run view <id> --log-failed, fix the root cause forward on main (never rerun to hide a flake), push, and watch CI again; a failed CD gate then needs the next release per Recovery. Repeat until CI is green and gh release view <tag> succeeds; stop and report when a fix needs the user's decision.

mise run release        # interactive release (after dot-verify)
mise run release -- -y  # non-interactive, within an authorized release

Recovery

Inspect git status --short, the release commit, local tag, and remote state before retrying. release.py owns the flow; its failure cases are exercised in test_release.py.

Documentation

• Releases: fmind/dot · changelog
• Companion skills: dot-verify (pre-release qualification), dot-development (implementation and installation proof), commit messages (commit grammar).