Hindsight Release

Cut a core Hindsight release and open the accompanying changelog/blog PR. This is for the core product version (API, clients, CLI, control plane, Helm). Integrations are versioned independently — use scripts/release-integration.sh for those, not this skill.

The release is irreversible and outward-facing: it tags a version and pushes it straight to main, which triggers CI that publishes packages to PyPI / npm / Helm. Confirm the version number and that the intended fixes are already merged to main before you start.

Step 0 — Pre-flight

1. Decide the base. A release is cut from the latest origin/main, never from a feature branch. git fetch origin --tags first. Confirm the "couple of fixes" the user means are actually merged to main (git log v<prev>..origin/main --oneline).
2. Find where main is checked out. main is often already checked out in a sibling worktree (git worktree list). You cannot check out main in a second worktree — run the release in the worktree that already holds it. If that worktree is dirty with throwaway cruft (.next-* tsconfig paths, screenshots), git stash push -u, fast-forward to origin/main, run the release, then git stash pop.
3. Pitfall: never pipe the checkout in an && chain like git checkout main 2>&1 | tail && git reset --hard ... — the pipe's exit status is tail's (always 0), so a failed checkout won't stop the chain and the reset fires on the wrong branch. Check out as its own command and verify git branch --show-current before resetting.

Step 1 — Cut the release

Run from the worktree on a clean main:

./scripts/release.sh <version>     # e.g. 0.8.1  (no leading v)

release.sh bumps the version in every component, regenerates the OpenAPI spec + all client SDKs, updates docs versioning, commits Release v<version>, tags v<version>, and pushes the commit and tag directly to main. The push triggers the Release GitHub Actions workflow that builds and publishes the packages. It is not a PR.

Verify after: gh run list --limit 5 should show the Release v<version> workflow running, and git ls-remote --tags origin v<version> should return the tag.

Step 2 — Changelog + blog PR (separate)

Done after the tag exists, as its own PR (precedent: v0.8.0 = #2053, v0.8.1 = #2080). Work on a branch off the new main:

git checkout -b docs-changelog-<version> origin/main

Only spin up a separate worktree (git worktree add ../hindsight-changelog-<version> -b docs-changelog-<version> origin/main) if you can't get a clean checkout otherwise — e.g. main is held in another worktree and the current one has work you don't want to disturb.

Branch naming: use the docs- (hyphen) convention, e.g. docs-changelog-0.8.1. A remote branch literally named docs exists, so any docs/... branch is rejected on push with directory file conflict.

Changelog

uv run --directory hindsight-dev generate-changelog <version>

LLM-summarizes the commits between the previous tag and v<version> and prepends an entry to hindsight-docs/src/pages/changelog/index.md.

The entry ends with a Database Migrations section listing every Alembic migration added in the range, each linking to the PR that introduced it. That section is enumerated deterministically from git (--diff-filter=A over hindsight_api/alembic/versions/), not by the LLM — don't hand-edit it, and if a migration is missing, check that its commit actually added the file in the tag range. Requires OPENAI_API_KEY (already in the repo .env). It excludes hindsight-integrations/ source, but new integrations whose commits also touched docs will still appear — that matches precedent, leave them in the changelog.

Blog post

Hand-write hindsight-docs/blog/YYYY-MM-DD-version-X-Y-Z.md (mirror an existing one; patch releases are short — see 2026-06-02-version-0-7-2.md). Guidance:

• Explain user impact, not internals/mechanism. Lead with what the user can now do and what to set. Config/env-var names are fine (developer-facing), code symbols and internals are not.
• Do not list integrations in the release blog. The core blog covers core engine / API / ops changes; each integration ships its own changelog. (Integrations may still appear in the generated changelog/index.md — that's fine; just keep them out of the blog.)
• Call out an upgrade recommendation when there are operational/data-integrity fixes.
• Validate formatting: npx prettier --check <blog file>.

Sync the docs skill

./scripts/generate-docs-skill.sh

Refreshes skills/hindsight-docs/references/changelog/index.md. It will also bump skills/hindsight-docs/references/openapi.json by one version — release.sh regenerates the skill before bumping OpenAPI, so the skill copy lags a version in the release commit; this step syncs it. Expect a one-line version diff there; keep it.

Commit, push, PR

git add -A
git commit --no-verify -m "docs: changelog and blog post for v<version>"
git push -u origin docs-changelog-<version>
gh pr create --base main --title "docs: changelog and blog post for v<version>" --body "..."

Expected files in the PR: the changelog entry, the new blog post, the regenerated skill changelog mirror, and the skill openapi.json version sync.

Cleanup

If you created a temporary worktree, remove it once the PR is up (git worktree remove ../hindsight-changelog-<version>; the branch stays on origin). Restore any stash you popped in Step 0.