How do I install the Tty Assert Release skill?

Run npx skillmds@latest add terryyin/tty-assert-release in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Tty Assert Release safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Tty Assert Release?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Tty Assert Release free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Tty Assert Release?

terryyin (@terryyin) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Tty Assert Release by terryyin — Agent Skill

Name: Tty Assert Release
Author: terryyin

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.

terryyin 4470216 2.3 KB Updated Sep 17, 2026

File contents

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)

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.
Version — Set "version": "X.Y.Z" in package.json to match.
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.

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

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

Tag — Create an annotated or lightweight tag vX.Y.Z on that commit:
```
git tag vX.Y.Z
```
Push — Push the branch first, then the tag (replace main if needed):
```
git push origin main
git push origin vX.Y.Z
```
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.

---name: tty-assert-releasedescription: 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 releaseHuman-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.

Frequently asked questions