How do I install the Td Feature Release skill?

Run npx skillmds@latest add hybridlabor-api/td-feature-release-2 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 Td Feature Release safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Td Feature 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 Td Feature Release free to use?

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

Who published Td Feature Release?

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

Td Feature Release by hybridlabor-api

Name: Td Feature Release
Author: hybridlabor-api

Td Feature Release

Release tdmcp: write the Keep-a-Changelog entry, bump the SemVer version across every manifest, then (autonomously, per project policy) commit, tag, and push — gated on a td-qa PASS, with hard git safety rails. Use when releasing/shipping/cutting a tdmcp version, writing the CHANGELOG, bumping the version, or tagging a release.

File contents

td-feature-release — cut and push a version

You convert QA-passed features into a released, pushed version. Project policy authorizes autonomous commit + tag + push. Autonomy ≠ recklessness — the hard rails below always hold.

Gate first

Do not release unless td-qa's report is PASS for everything shipping. Features marked FAIL or critical-UNVERIFIED are held for the next cycle — say which, don't quietly drop or ship them.

Procedure

CHANGELOG (CHANGELOG.md) — Keep a Changelog format. Add a dated version section with ### Added / ### Changed / ### Fixed. One bullet per feature: what it delivers + its CLI command (pull these from the integrator's shipped-features list). Update the version link reference at the bottom to the new tag.
Version bump (SemVer) — minor for new features, patch for fixes. Bump every manifest that carries a version and confirm they're identical afterward (a cross-manifest version mismatch is a classic release bug): package.json, the .dxt/plugin manifest, and any version synced into scripts/setup.mjs / docs. Grep the repo for the old version string to catch them all.
Commit — match the repo's commit style (read git log: feat/fix/docs/chore(release)). Stage by explicit path, message via HEREDOC, end with the Co-Authored-By: Claude trailer.
Tag vX.Y.Z and push the commit + tag.

Hard safety rails (always, even autonomous)

Stage by explicit path — never git add -A / git add .. Concurrent agents may have in-flight files on this branch; stage only what this release intends.
Never commit secrets (.env, credentials, tokens). If staged, unstage and flag.
New commits only — never --amend a shared/published commit.
Never skip hooks (--no-verify / --no-gpg-sign). If a pre-commit hook fails, the commit did NOT happen — fix the cause, re-stage, and make a NEW commit (do not amend).
Never force-push to main/master. If push is rejected (remote ahead), fetch + reconcile; never force a shared branch.

Output

The CHANGELOG edit + version bumps + commit + tag + push, and a release note at _workspace/05_release.md: the version, commit SHA, tag, what shipped, and what was held back (with reason). Done when the tagged commit is pushed and the tree is clean (except deliberately-unstaged concurrent work).

Follow-up releases

If _workspace/05_release.md exists, read the last shipped version, compute the next bump from it, and add a new CHANGELOG section — never re-tag the same version.

---name: td-feature-release-2description: "Release tdmcp: write the Keep-a-Changelog entry, bump the SemVer version across every manifest, then (autonomously, per project policy) commit, tag, and push — gated on a td-qa PASS, with hard git safety rails. Use when releasing/shipping/cutting a tdmcp version, writing the CHANGELOG, bumping the version, or tagging a release."---# td-feature-release — cut and push a versionYou convert QA-passed features into a released, pushed version. Project policy authorizes autonomous commit + tag + push. Autonomy ≠ recklessness — the hard rails below always hold.## Gate firstDo not release unless `td-qa`'s report is **PASS** for everything shipping. Features marked FAIL or critical-UNVERIFIED are held for the next cycle — say which, don't quietly drop or ship them.## Procedure1. **CHANGELOG** (`CHANGELOG.md`) — Keep a Changelog format. Add a dated version section with `### Added` / `### Changed` / `### Fixed`. One bullet per feature: what it delivers + its CLI command (pull these from the integrator's shipped-features list). Update the version link reference at the bottom to the new tag.2. **Version bump (SemVer)** — minor for new features, patch for fixes. Bump **every** manifest that carries a version and confirm they're identical afterward (a cross-manifest version mismatch is a classic release bug): `package.json`, the `.dxt`/plugin manifest, and any version synced into `scripts/setup.mjs` / docs. Grep the repo for the old version string to catch them all.3. **Commit** — match the repo's commit style (read `git log`: `feat`/`fix`/`docs`/`chore(release)`). Stage by explicit path, message via HEREDOC, end with the `Co-Authored-By: Claude` trailer.4. **Tag** `vX.Y.Z` and **push** the commit + tag.## Hard safety rails (always, even autonomous)- **Stage by explicit path — never `git add -A` / `git add .`.** Concurrent agents may have in-flight files on this branch; stage only what this release intends.- **Never commit secrets** (`.env`, credentials, tokens). If staged, unstage and flag.- **New commits only — never `--amend`** a shared/published commit.- **Never skip hooks** (`--no-verify` / `--no-gpg-sign`). If a pre-commit hook fails, the commit did NOT happen — fix the cause, re-stage, and make a NEW commit (do not amend).- **Never force-push to `main`/`master`.** If push is rejected (remote ahead), fetch + reconcile; never force a shared branch.## OutputThe CHANGELOG edit + version bumps + commit + tag + push, and a release note at `_workspace/05_release.md`: the version, commit SHA, tag, what shipped, and what was held back (with reason). Done when the tagged commit is pushed and the tree is clean (except deliberately-unstaged concurrent work).## Follow-up releasesIf `_workspace/05_release.md` exists, read the last shipped version, compute the next bump from it, and add a new CHANGELOG section — never re-tag the same version.

Frequently asked questions