terryyin/tty-assert-release

tty-assert: cut an npm release

Human-oriented detail: docs/release.md.

Preconditions

• Default release branch is main unless the user specifies another branch.
• Working tree should be clean before committing; resolve or stash unrelated changes first.
• If the target version is unclear, ask for X.Y.Z (semver) before editing files.

Steps (execute in order)

1. CHANGELOG — In CHANGELOG.md, insert a new section immediately after # Changelog:

   ## [X.Y.Z] - YYYY-MM-DD
   
   - Concise bullets: what changed for users or integrators.
   

   Use today’s date in ISO form (YYYY-MM-DD). The heading must be exactly ## [X.Y.Z] (no v); this string is what .github/workflows/release.yml greps for.

2. Version — Set "version": "X.Y.Z" in package.json to match.

3. Verify — From repo root, run (use nix develop -c before these if the user’s environment requires it):

   pnpm lint && pnpm test && pnpm build
   

   Fix any failures before committing.

4. Commit — Stage at least CHANGELOG.md and package.json:

   git add CHANGELOG.md package.json
   git commit -m "chore: release vX.Y.Z"
   

5. Tag — Create an annotated or lightweight tag vX.Y.Z on that commit:

   git tag vX.Y.Z
   

6. Push — Push the branch first, then the tag (replace main if needed):

   git push origin main
   git push origin vX.Y.Z
   

7. Handoff — Tell the user to watch GitHub → Actions → Release for the run triggered by vX.Y.Z. Remind them that Trusted Publishing must already link this repo to npm (see docs/release.md).

Do not

• Push a tag without the matching ## [X.Y.Z] block in CHANGELOG.md (CI will fail).
• Skip pnpm lint, pnpm test, or pnpm build before the release commit unless the user explicitly accepts that risk.