Skip to main content

tty-assert-release

Prepares an npm release for tty-assert: edits CHANGELOG.md and package.json, verifies lint/test/build, commits, tags vX.Y.Z, and pushes branch plus tag to trigger GitHub Actions Release. Use when the user asks to release, publish to npm, ship a version, cut a tag, or bump the package version for tty-assert.

Source facts

Repository
terryyin/tty-assert
Last source activity
April 12, 2026 at 23:02
Detected SKILL.md language
English
Stars
0
Forks
0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
tty-assert-release
description
Prepares an npm release for tty-assert: edits CHANGELOG.md and package.json, verifies lint/test/build, commits, tags vX.Y.Z, and pushes branch plus tag to trigger GitHub Actions Release. Use when the user asks to release, publish to npm, ship a version, cut a tag, or bump the package version for tty-assert.
# tty-assert: cut an npm release Human-oriented detail: [docs/release.md](../../../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`: ```markdown ## [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): ```bash pnpm lint && pnpm test && pnpm build ``` Fix any failures before committing. 4. **Commit** — Stage at least `CHANGELOG.md` and `package.json`: ```bash 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: ```bash git tag vX.Y.Z ``` 6. **Push** — Push the **branch** first, then the **tag** (replace `main` if needed): ```bash 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.
View on GitHub