jpskill.com
📦 その他 コミュニティ

release

プロジェクトの新しいバージョンを公開するために、バージョン番号の更新や変更履歴の作成、タグ付けなど、一連の作業をスムーズに進めるための手順を案内するSkill。

📜 元の英語説明(参考)

Guide for releasing a new version of the project, including version bumping, changelog updates, and tagging.

🇯🇵 日本人クリエイター向け解説

一言でいうと

プロジェクトの新しいバージョンを公開するために、バージョン番号の更新や変更履歴の作成、タグ付けなど、一連の作業をスムーズに進めるための手順を案内するSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux 
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o release.zip https://jpskill.com/download/10385.zip && unzip -o release.zip && rm release.zip
🪟 Windows (PowerShell) 
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/10385.zip -OutFile "$d\release.zip"; Expand-Archive "$d\release.zip" -DestinationPath $d -Force; ri "$d\release.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して release.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → release フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動
⬇ .zip でダウンロード(推奨) ⬇ .skill 形式(上級者用) 元のソース ↗

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

リリースワークフロー

このスキルは、プロジェクトの新しいバージョンをリリースするプロセスをガイドします。

ワークフロー

  1. 準備

    • gitのワーキングディレクトリがクリーンであることを確認します: git status。
    • 最新の変更をプルします: git pull origin main。

  2. バージョン選択

    • どのバージョンのbumpを適用するかを常にユーザーに尋ねます: major、minor、またはpatch。
    • ユーザーがこれらのオプションのいずれかを確認するまで、バージョンを更新しないでください。

  3. バージョンBump

    • ルートのCargo.tomlのversionフィールドを更新します。
    • Cargo.lockが更新されていることを確認します（例：cargo checkを実行して更新をトリガーします）。

  4. 検証

    • テストを実行します: cargo test -q。

  5. ドキュメントレビュー

    • 前回のリリース以降に、エージェントモデル、キーバインディング、またはセッション状態が変更されたかどうかを確認します: git diff <previous_tag>..HEAD -- crates/agentty/src/domain/agent.rs crates/agentty/src/domain/session.rs crates/agentty/src/ui/state/help_action.rs
    • これらのファイルのいずれかが変更された場合は、対応するドキュメントページが最新であることを確認します:
      • docs/site/content/docs/agents/backends.md — エージェントのバックエンドとモデル。
      • docs/site/content/docs/usage/workflow.md — セッションのライフサイクルとワークフロー。
      • docs/site/content/docs/usage/keybindings.md — キーバインディング。
    • zola check --root docs/siteを実行して、壊れた内部リンクがないことを確認します。

  6. 変更履歴

    • CHANGELOG.mdを更新します。
    • 現在の日付で新しいバージョンのエントリがあることを確認します: ## [vX.Y.Z] - YYYY-MM-DD。
    • コンテンツがKeep a Changelogに準拠していることを確認します。
    • 新しいリリースエントリの下に### Contributorsセクションを追加し、GitHubのユーザー名の箇条書きリストを追加します（例：- @minev-dev）。
    • 前回のタグ以降のコミットからコントリビューターリストを作成し、名前を重複排除します。

  7. コントリビューター

    • タグ間のコミットメールからコントリビューターのユーザー名リストを生成します: git log <previous_tag>..HEAD --format='%ae' | sed -nE 's/.*\\+([^@]+)@users\\.noreply\\.github\\.com/\\1/p' | sort -u | sed 's/^/- @/'
    • コントリビューターがGitHubのnoreplyメールを使用していない場合は、手動でGitHubのユーザー名にマッピングします。

  8. コミット

    • 変更をステージングします: git add Cargo.toml Cargo.lock CHANGELOG.md。
    • メッセージ付きでコミットします: git commit -m "Release vX.Y.Z"。

  9. タグ付け

    • 'v'プレフィックス付きでgitタグを作成します: git tag vX.Y.Z。
    • 重要: リリースワークフローはvプレフィックスに依存しています（例：v0.1.4）。

  10. プッシュ

    • コミットをプッシュします: git push origin main。
    • タグをプッシュします: git push origin vX.Y.Z。

  11. 完了

    • GitHub Actionsワークフローは、自動的にリリースを作成し、アーティファクトを公開します。
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Release Workflow

This skill guides you through the process of releasing a new version of the project.

Workflow

  1. Preparation

    • Ensure the git working directory is clean: git status.
    • Pull the latest changes: git pull origin main.

  2. Version Selection

    • Always ask the user which version bump to apply: major, minor, or patch.
    • Do not update versions until the user confirms one of these options.

  3. Version Bump

    • Update the version field in the root Cargo.toml.
    • Verify Cargo.lock is updated (e.g., run cargo check to trigger update).

  4. Verification

    • Run tests: cargo test -q.

  5. Documentation Review

    • Check if agent models, keybindings, or session states changed since the last release: git diff <previous_tag>..HEAD -- crates/agentty/src/domain/agent.rs crates/agentty/src/domain/session.rs crates/agentty/src/ui/state/help_action.rs
    • If any of those files changed, verify the corresponding doc pages are up to date:
      • docs/site/content/docs/agents/backends.md — agent backends and models.
      • docs/site/content/docs/usage/workflow.md — session lifecycle and workflow.
      • docs/site/content/docs/usage/keybindings.md — keybindings.
    • Run zola check --root docs/site to verify no broken internal links.

  6. Changelog

    • Update CHANGELOG.md.
    • Ensure there is an entry for the new version with the current date: ## [vX.Y.Z] - YYYY-MM-DD.
    • Ensure content adheres to Keep a Changelog.
    • Add a ### Contributors section under the new release entry with a bullet list of GitHub usernames (example: - @minev-dev).
    • Build the contributor list from commits since the previous tag and deduplicate names.

  7. Contributors

    • Generate the contributor username list from commit emails between tags: git log <previous_tag>..HEAD --format='%ae' | sed -nE 's/.*\\+([^@]+)@users\\.noreply\\.github\\.com/\\1/p' | sort -u | sed 's/^/- @/'
    • If a contributor does not use a GitHub noreply email, map them manually to their GitHub username.

  8. Commit

    • Stage changes: git add Cargo.toml Cargo.lock CHANGELOG.md.
    • Commit with message: git commit -m "Release vX.Y.Z".

  9. Tagging

    • Create a git tag with the 'v' prefix: git tag vX.Y.Z.
    • Important: The release workflow depends on the v prefix (e.g., v0.1.4).

  10. Push

    • Push the commit: git push origin main.
    • Push the tag: git push origin vX.Y.Z.

  11. Completion

    • The GitHub Actions workflow will automatically create the release and publish artifacts.