mcpField
R
repo-release-tools

repo-release-tools

ローカル
github.com/Anselmooバージョン管理11 週間前に更新

repo-release-tools について

repo-release-toolsは、Gitリポジトリ向けに設定駆動のブランチ、バージョン管理、リリースのワークフローを提供し、開発者、CI、コーディングエージェントに対応します。CLI、GitHub Action、フック、任意のMCPサーバーを備えています。

主な機能

  1. 01ブランチ名とコミット文の検証
  2. 02バージョン更新とリリースブランチの自動化
  3. 03変更履歴ポリシーの検査
  4. 04pre-commitなどのフックとの連携
  5. 05GitHub ActionとCLIの提供
  6. 06エージェントスキルとMCPサーバーの提供

活用シーン

  1. 01CIでポリシー違反を防止
  2. 02ローカルで規則に沿ったブランチ作成とバージョン更新
  3. 03リポジトリ内の複数のバージョンファイルの同期
  4. 04エージェントによるリリース操作のプレビューと実行

MCP 対応

任意のMCPサーバーを通じて、一部の`rrt`操作をエージェントに提供します。構造化された結果を返し、変更操作はデフォルトでプレビューします。文書、変更履歴、ドリフト検査、フックの一部コマンドはCLI専用です。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

mcp.json · 共通設定
{
"mcpServers": {
"anselmoo-repo-release-tools": {
"command": "uvx",
"args": [
"repo-release-tools"
]
}
}
}
起動コマンドuvx repo-release-tools

ローカルサーバーにはマシン上の実行環境(Node.js 18 以上など)が必要です。設定ファイルの場所はクライアントごとに異なります。

パッケージ
pypirepo-release-tools1.18.0
ocighcr.io/anselmoo/repo-release-tools:1.18.0

ツール

27

掲載時のツール一覧 · 2 週間前に更新

このツールにパラメーターはありません。

詳細

repo-release-tools

GitHub PyPI

REPO-RELEASE-TOOLS pipeline banner

repo-release-tools は、リリースポリシーをできる限りシンプルに保ちます。

CI でブランチ名、コミットの件名、変更履歴のポリシーを検証する場合は、GitHub Marketplace から利用してください。ローカル CLI、フック連携、バージョン更新、リリースブランチの自動化を利用する場合は、PyPI からインストールしてください。

利用方法を選ぶ

CI ポリシーチェックには GitHub Action を使う

リポジトリがリリースポリシーから逸脱した場合、プルリクエストやプッシュをすぐに失敗させたいなら、このアクションを選んでください。

  • feat/add-parser などのブランチ名を検証します
  • Conventional Commit の件名を検証します
  • CI で変更履歴のポリシーを検証します
  • オプションで、作業ツリーがクリーンな状態に保たれているか確認します
  • リリース前のヘルスゲートとして rrt doctor を実行できます
- uses: actions/checkout@v6
  with:
    fetch-depth: 0

- uses: Anselmoo/[email protected]
  with:
    check-branch-name: "true"
    check-commit-subject: "true"
    check-changelog: "true"

アクションの完全なガイドはこちらをご覧ください: https://anselmoo.github.io/repo-release-tools/action/

CLI とコマンドの完全なリファレンスはこちらをご覧ください: https://github.com/Anselmoo/repo-release-tools/blob/main/docs/commands/rrt-cli.md

ローカルのワークフロー自動化には Python パッケージを使用する

ブランチヘルパー、バージョン更新、設定の確認、pre-commit フック、リリースの自動化など、開発者側のツールが必要な場合は、このパッケージを選んでください。 Python パッケージはPyPIで公開されており、GitHub Action ガイドに CI 用の同等機能があります。

pip install repo-release-tools
rrt init
rrt branch new feat "add parser"
rrt git commit "add parser"
rrt git doctor
rrt bump patch

または、永続的にインストールせずに CLI を実行します。

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

すでに rrt がインストールされていて、Copilot、Claude、Codex 用の同梱エージェントスキルを使用する場合は、次のコマンドでインストールします。

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

基本的なバージョン管理であれば、bump と ci-version は [tool.rrt] なしで実行でき、リポジトリのルートにある pyproject.toml、package.json、Cargo.toml、.rrt.toml、.config/rrt.toml を自動検出します。 複数のバージョンファイルが見つかった場合は、まとめて更新されます。明示的な設定は、グループ化されたリリース、変更履歴のパス、リリースブランチ、ロックコマンド、生成ファイル、カスタムパターンなどの便利な追加機能に使用します。

バージョンターゲットは、Python(pep621、python_version)、Node/JS/TS(package_json)、Go(go_version)、Rust(cargo_toml)、.NET(csproj)など、一般的な言語/プロジェクトファイルにも対応しています。これにより、多言語リポジトリでもリリースバージョンを揃えられます。mcp_server_json ターゲットを使用すると、MCP Registry の server.json(トップレベルの version、各パッケージの version、および oci パッケージのイメージタグ)を、プロジェクトの主要ターゲットと合わせて同期できます。

変更履歴のワークフロー

リポジトリで変更を取り込む方法に合ったスタイルを選んでください。

incremental(デフォルト) — 開発中に変更履歴のエントリを管理するチーム向けです。

  • rrt-update-unreleased と rrt-changelog フックが有効なままになります。
  • GitHub Action は changelog-strategy: auto を per-commit に解決します。
  • rrt bump のデフォルトは auto です。

squash — 多数のコミットを 1 つの PR マージにまとめるリポジトリ向けです。

  • 変更履歴の書き込みフックとチェックフックは、強制チェックをスキップします。
  • GitHub Action は changelog-strategy: auto を release-only に解決します。
  • rrt bump のデフォルトは generate です。

最小限の設定:

[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"

package.json("rrt": { ... })および Cargo.toml([package.metadata.rrt] / [workspace.metadata.rrt])でのネイティブ設定にも対応しています。Go リポジトリでは .rrt.toml または .config/rrt.toml を使用してください。

プロジェクトに含まれるもの

  • ブランチ、バージョン更新、設定の確認、Git ヘルパー用の rrt CLI
  • pre-commit、lefthook、husky、CI 検証用の rrt-hooks
  • 再利用可能な GitHub Action(action.yml)
  • uvx およびインストール済み CLI のワークフロー向けに同梱されたエージェントスキル
  • ブランチポリシー、フックのセットアップ、リリースワークフローに関するドキュメント

AI エージェントに rrt を実際に使わせる

rrt が設定されたリポジトリで Claude Code、Copilot、Cursor、Codex を使うと、エージェントは rrt がすでに行える処理を喜んで再実装します。たとえば、3 つのファイルにあるバージョン文字列を手作業で編集したり、pre-commit フックに拒否されるブランチ名を考案したり、間違ったセクションに変更履歴のエントリを書いたりします。ツールを使えないからではなく、この作業に使うべきツールが rrt だと伝えられていないためです。

これを解決する方法は 2 つあります。両方行ってください。

1. 指示ファイルで、エージェントに一度伝える

以下のエージェント指示スニペットのブロックを、リポジトリの CLAUDE.md、AGENTS.md、または .github/copilot-instructions.md に貼り付けます。これは圧倒的に効果の高い手順です。エージェントが計画を立てる前に毎回読み込まれ、実行時のコストもかかりません。

2. MCP サーバーに接続する(任意ですが、書き込みを行う場合は接続をおすすめします)
uv add "repo-release-tools[mcp]"

次に、リポジトリのルートに .mcp.json を追加します。Claude Code は次回の起動時にこれを読み込みます。

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

サーバーに接続すると、ほとんどのツールはエージェントに、解析が必要なターミナル出力ではなく、型付き JSON を返します(4 つのロックファイル読み取りツールと rrt_config は、代わりに生の dict を返します)。コミットの件名とブランチ名は、シェルで引用するのではなく、引数として渡されます。また、変更を伴う操作はデフォルトでドライランのプレビューになります。Claude Desktop、グローバルインストール、ベアラー認証を使った HTTP トランスポートについては、MCP サーバーガイドをご覧ください。

MCP サーバーですべての操作をカバーできるわけではありません。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、その他すべての --snapshot 書き込み操作、およびすべての rrt-hooks サブコマンドは CLI 専用です。CLI と MCP を併用するセッションは想定された使い方であり、代替手段ではありません。

効果的なプロンプトの例

次のプロンプトを使うと、手作業での編集ではなく、確実に rrt に処理が振り分けられます。

  • 「ブランチを作成する前に、ブランチ名がフックを通過するか rrt で確認してください。」
  • 「rrt でマイナーバージョンへの更新をプレビューしてください。ドライランで、変更されるファイルをすべて表示してください。」
  • 「エントリーを追加する前に、rrt で未リリースの変更履歴を読んで、重複しないようにしてください。」
  • 「rrt doctor を実行して、不足しているフックの統合を教えてください。」
  • 「コミットメッセージを書く前に、件名を rrt で検証してください。」
  • 「rrt によると、このリポジトリのバージョンはいくつですか?」。「バージョンはいくつですか?」だけだと、ランダムなファイルを読むよう促してしまいます。
  • 「PR を作成する前に、rrt release check を実行してください。」

ポイントは、rrt を明示し、「作成する前に」「PR を作成する前に」のように、実行するタイミングも指定することです。エージェントは機能ではなく、トリガーに基づいて処理を振り分けます。

エージェントへの指示文の例
## Use `rrt` for release policy

This repo uses `repo-release-tools` (`rrt`) to enforce branch naming, Conventional
Commits, 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.

タスクに合ったドキュメントから始める

ライセンス

repo-release-tools は MIT ライセンスのもとで公開されています。

ワークフローのアイデアの一部は、当初 joseluisq/gitnow に着想を得ていますが、rrt git の機能は意図的に範囲を絞り、Conventional Branches、 安全なコミット、リリースの自動化を中心に再構成しています。

コメント

MCP は初めてですか?

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。