Repo Release Tools

io.github.Anselmoo由 GitHub 帳號 Anselmoo 發布v1.18.0更新於 Oct 24, 2026

Config-driven branch and release helpers for Git repositories

已驗證STDIO僅桌面效率與工作流開發者工具

概覽

AI 產生的概覽

本機 MCP 伺服器,包裝 rrt 發佈政策命令列工具,讓助理驗證分支名稱、提交訊息與變更日誌,並預覽版本號升級

可以做什麼
在建立分支或提交前驗證分支名稱與 Conventional Commit 提交主旨,參數以型別化方式傳入而非 shell 引號。預覽並執行跨專案檔案的版本號升級,包含多語言版本目標與 MCP server.json 清單。讀取並檢查變更日誌政策與 Unreleased 段落。檢視 rrt 設定與鎖定檔,並執行 doctor、release check 等儲存庫健康檢查。寫入操作預設先提供 dry-run 預覽。
適用情境
適用於已使用 repo-release-tools 並強制分支、提交、變更日誌或版本政策的儲存庫,讓助理遵循該政策,而不是手動改版本號或隨意取分支名稱。屬於選用項目:README 指出在代理指令檔中說明是效益更高的一步,且許多 rrt 指令仍只能在命令列使用。
執行需求
以本機 stdio 程序在使用者機器上執行(僅桌面端)。需安裝含 mcp 擴充的 Python 套件並啟動 rrt-mcp 指令,例如透過 uv;也提供 Docker 映像。未宣告任何帳號、API 金鑰或環境變數。
安裝前請注意
寫入操作可能修改版本號、變更日誌項目、分支與提交;README 說明寫入操作預設先做 dry-run 預覽,應先檢視預覽並確認後再執行。它作用於本機 Git 儲存庫,出錯會影響真實歷史與發佈中繼資料。部分 rrt 指令未透過 MCP 提供,需在 shell 中執行。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 Repo Release Tools,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。

其他 MCP 客戶端

參照 儲存庫 中的啟動說明。

README

repo-release-tools

[GitHub] [PyPI]

[REPO-RELEASE-TOOLS pipeline banner]

repo-release-tools keeps release policy boring in the best possible way.

Use it from GitHub Marketplace when you want CI to validate branch names, commit subjects, and changelog policy. Install it from PyPI when you want a local CLI, hook integration, version bumps, and release-branch automation.

Choose your entry point

Use the GitHub Action for CI policy checks

Choose the action if you want pull requests and pushes to fail fast when a repo drifts from your release policy.

  • validates branch names such as feat/add-parser
  • validates Conventional Commit subjects
  • validates changelog policy in CI
  • optionally checks that the working tree stays clean
  • can run rrt doctor as a pre-release health gate
yaml
- uses: actions/checkout@v6  with:    fetch-depth: 0
- uses: Anselmoo/[email protected]  with:    check-branch-name: "true"    check-commit-subject: "true"    check-changelog: "true"

See the full action guide: https://anselmoo.github.io/repo-release-tools/action/

See the full CLI and commands reference: https://github.com/Anselmoo/repo-release-tools/blob/main/docs/commands/rrt-cli.md

Use the Python package for local workflow automation

Choose the package if you want the developer-side tools: branch helpers, version bumps, config inspection, pre-commit hooks, and release automation. The Python package is published on PyPI and has a CI counterpart in the GitHub Action guide.

bash
pip install repo-release-toolsrrt initrrt branch new feat "add parser"rrt git commit "add parser"rrt git doctorrrt bump patch

Or run the CLI without installing it permanently:

bash
uvx repo-release-tools branch new feat "add parser"

If rrt is already installed and you want the bundled agent skill for Copilot, Claude, or Codex, install it with:

bash
rrt skill install --target copilot-localrrt skill install --target claude-local --target codex-localrrt skill install --target codex-global --dry-run

For basic versioning, bump and ci-version can run without [tool.rrt] by auto-detecting repo-root pyproject.toml, package.json, Cargo.toml, .rrt.toml, or .config/rrt.toml. If multiple version files are found, they are updated together. Explicit config is for the nice extras: grouped releases, changelog paths, release branches, lock commands, generated files, and custom patterns.

Version targets also support common language/project files such as Python (pep621, python_version), Node/JS/TS (package_json), Go (go_version), Rust (cargo_toml), and .NET (csproj) so multi-language repositories can keep their release versions aligned. A mcp_server_json target keeps an MCP Registry server.json (top-level version, each package's version, and any oci package's image tag) in sync alongside a project's primary target.

Changelog workflows

Pick the style that matches how your repository lands changes.

incremental (default) — for teams that maintain changelog entries during development.

  • rrt-update-unreleased and rrt-changelog hooks stay active.
  • The GitHub Action resolves changelog-strategy: auto to per-commit.
  • rrt bump defaults to auto.

squash — for repositories that squash many commits into one PR merge.

  • Changelog write and check hooks skip enforcement.
  • The GitHub Action resolves changelog-strategy: auto to release-only.
  • rrt bump defaults to generate.

Minimal config:

toml
[tool.rrt]release_branch = "release/v{version}"changelog_file = "CHANGELOG.md"changelog_workflow = "incremental"  # or "squash"
[[tool.rrt.version_targets]]path = "pyproject.toml"kind = "pep621"

Native config is also supported in package.json ("rrt": { ... }) and Cargo.toml ([package.metadata.rrt] / [workspace.metadata.rrt]). Go repos should use .rrt.toml or .config/rrt.toml.

What the project includes

  • rrt CLI for branches, bumps, config inspection, and Git helpers
  • rrt-hooks for pre-commit, lefthook, husky, and CI validation
  • a reusable GitHub Action in action.yml
  • bundled agent skills for uvx and installed-CLI workflows
  • docs for branch policy, hook setup, and release workflows

Get your AI agent to actually use rrt

If you use Claude Code, Copilot, Cursor, or Codex on a repository that has rrt configured, the agent will happily reimplement what rrt already does — hand-editing a version string in three files, inventing a branch name the pre-commit hook then rejects, or writing a changelog entry in the wrong section. Not because it lacks the tools, but because nothing told it these are the tools for this job.

Two things fix that. Do both.

1. Tell your agent, once, in its instruction file

Paste the block from Agent instruction snippet below into your repository's CLAUDE.md, AGENTS.md, or .github/copilot-instructions.md. This is the highest-leverage step by a wide margin: it is read on every session, before the agent has formed a plan, and it costs nothing at runtime.

2. Connect the MCP server (optional, but better for anything that writes)

bash
uv add "repo-release-tools[mcp]"

Then add .mcp.json at the repository root — Claude Code picks it up on next start:

json
{  "mcpServers": {    "rrt": { "type": "stdio", "command": "uv", "args": ["run", "rrt-mcp"] }  }}

With the server connected, most tools give the agent typed JSON instead of terminal output it has to parse (the four lock readers and rrt_config return raw dicts instead), commit subjects and branch names are passed as arguments instead of through shell quoting, and mutating operations default to a dry-run preview. See the MCP Server guide for Claude Desktop, global install, and HTTP transport with bearer auth.

The MCP server does not cover everything. rrt docs map, rrt docs generate, rrt docs publish, rrt docs inject, rrt tree --check, rrt toc, rrt changelog lint, rrt changelog compare, rrt drift generate/check, rrt artifacts --check, every other --snapshot write, and every rrt-hooks subcommand are CLI-only — a mixed session is expected, not a fallback.

Prompt phrasings that work

These reliably route to rrt rather than to hand-editing:

  • "Check with rrt whether this branch name will pass the hooks before you create it."
  • "Use rrt to preview a minor bump — dry run — and show me every file it would touch."
  • "Read the Unreleased changelog with rrt before adding an entry, so you don't duplicate one."
  • "Run rrt doctor and tell me which hook integrations are missing."
  • "Before you write that commit message, validate the subject with rrt."
  • "What version is this repo at according to rrt?" — not "what's the version", which invites reading a random file.
  • "Run rrt release check before you open the PR."

The pattern: name rrt explicitly, and name the moment ("before you create it", "before you open the PR"). Agents route on triggers, not on capabilities.

Agent instruction snippet

markdown
## Use `rrt` for release policy
This repo uses `repo-release-tools` (`rrt`) to enforce branch naming, ConventionalCommits, changelog format, and version consistency. Do not hand-roll any of it.
Before you act, use `rrt`:
| When you are about to… | Use ||---|---|| create a branch | `rrt branch new <type> "<desc>"` — or validate the name first with `rrt-hooks check-branch-name --branch <candidate>` || write a commit message | `rrt git commit --type <type> "<description>"`, which builds and validates the subject before committing || change a version number anywhere | `rrt bump <level> --dry-run` first — never edit version strings by hand; pins and the changelog move with it || add a changelog entry | read the existing `[Unreleased]` first; it is hook-managed || open a PR | `rrt release check` and `rrt doctor` |
Rules:- Every mutating `rrt` command takes `--dry-run`. Use it first, show the user the  preview, and only apply after they confirm.- Never edit a version string by hand in more than one file — that is what `rrt bump` is for.- Never hand-edit the `[Unreleased]` changelog section while the rrt hooks are active.- If `rrt` is connected over MCP, prefer the `mcp__rrt__*` tools over shelling out:  typed responses for most tools, no shell quoting of commit subjects, and dry-run is  the default. Shell out for anything with no MCP tool (`rrt docs map`, `rrt docs  generate`, `rrt docs publish`, `rrt docs inject`, `rrt tree --check`, `rrt toc`,  `rrt changelog lint`, `rrt changelog compare`, `rrt drift generate`/`check`,  `rrt artifacts --check`, other `--snapshot` writes, `rrt-hooks *`).- `rrt --help` lists every command. Check it before concluding rrt cannot do something.

Start with the doc that matches your task

License

repo-release-tools is released under the MIT License.

Some workflow ideas were initially inspired by joseluisq/gitnow, but the rrt git surface is intentionally narrower and reshaped around conventional branching, safe commits, and release automation.

來源:README.md,提交 d58a2d2

工具

0
SourceWeft 尚未在沙箱中啟動過該軟體包,因此其工具未知。

版本歷史

2
  1. v1.18.0最新Sep 22, 2026
  2. v1.17.1Sep 16, 2026

評分

已滿足適用檢查項的 50%

該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。

  • 近 30 天內可連通25 分

    請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。

  • 已宣告認證方式10 分

    請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。

  • 已列出工具15 分

    請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。

  • 描述必需15 分
  • 圖示10 分
  • 文件15 分
  • 授權條款10 分