メニュー
GitHub のリリースドラフトを充実化する。 ユーザーが「リリースノートを作って」「ドラフトリリースを充実させて」「release note を書いて」 などと言った時に使用する。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
タスクの説明からブランチ名を自動生成し、herdr の worktree + workspace を立ち上げ、必要なら作業担当エージェントに委任する。ユーザーが新しい作業を始めたい・worktree を切りたい・「/wt」と言った時に使う。
学習ループ用の教師モード — セッションの内容や設計判断を、段階的な説明・チェックリスト・ クイズでユーザーが深く理解するまで伴走する理解ゲート。 ユーザーが「/learn」「理解ゲート通して」「これ教えて」「クイズ出して」などと言った時に使う。 また、リポジトリの CLAUDE.md が理解ゲートを規定している場合(例: hexhive)、 設計判断を含む PR のマージ前にこちらから発火を提案してよい。
エージェントセッションの意思決定・洞察・成果物を Obsidian の ResearchNotes に昇格させる(蒸留パイプライン層1)。 ユーザーが「セッションをまとめて」「記録して」「/session-log」と言ったときに使う。 また、設計判断・アーキテクチャ決定・重要な学びが生まれたセッションの区切り(タスク完了時・終了間際)には、こちらから記録を提案してよい。 生ログの全転写ではなく、対話で生まれた判断・設計・学びの厳選記録。
Question Behind the Question — 実装プランを出す前に、要望の下にある設計判断を1段掘り、 「本当に問うべき問い」の候補を提示する。 ユーザーが「/qbq」「問いから掘って」「本当に問うべきことは何?」などと言った時に使う。 また、インフラ・ワークフロー・アーキテクチャ系の相談で、要望の背後に未言語化の 設計判断がありそうな時は、実装プランを提示する直前に自発的にこの手順を提案してよい。
マージ済み PR に対応する worktree / workspace / ローカルブランチを安全に掃除する。/wt で作った worktree のライフサイクルの後始末。ユーザーが「worktree を掃除して」「片付けたい」「/wtclean」と言った時に使う。
herdr を介して、ユーザー・Claude Code・Copilot CLI・copilot-quorum の四者が pane 越しに対話するためのプロトコル。相手 pane の見つけ方、宛先プレフィックス付き メッセージ形式、送信・応答待ちの手順、ループ防止の原則を定める。 ユーザーが「Copilot と相談して」「quorum に合議させて」「他のエージェントに聞いて」 「隣の pane と話して」などと言った時、または他エージェントからの宛先付きメッセージ (【from→to】形式)を pane 上で検知した時に使う。 司令塔↔作業者プロトコル(herdr スキルの `agent send` / 上り報告)とは別物 — あちらは 上下関係の報告経路、こちらは対等な対話。既存プロトコルは変更しない。
| name | release-note |
| description | GitHub のリリースドラフトを充実化する。 ユーザーが「リリースノートを作って」「ドラフトリリースを充実させて」「release note を書いて」 などと言った時に使用する。 |
GitHub のリリースドラフトを読み取り、PR の詳細を調査して充実したリリースノートを作成・更新します。
ユーザーがタグ名を指定している場合はそのリリースを使用。
指定がない場合は gh release list で最新の Draft を探す。
gh release list --limit 10
ドラフトが見つからない場合はユーザーに報告して終了。
gh release view <tag> --json tagName,name,body,isDraft
ドラフトでない場合はユーザーに確認してから続行。
gh release list から、対象ドラフトの 一つ前 の Latest / Published リリースのタグを特定する。
git log <prev-tag>...<target-tag> --oneline --no-merges
各コミットから関連する PR 番号を抽出する。
各 PR の詳細を gh pr view <number> --json title,body で取得する。
独立した PR は並列で調査 して効率化すること。
git diff --shortstat <prev-tag>...<target-tag>
以下の構造でリリースノートを作成する:
## 📦 <tag>
<1〜2行のリリース概要サマリー>
## 🎉 What's New
<主要な変更を 3〜5 個ピックアップ。絵文字 + 太字タイトル + 1行説明>
## 🚀 Features
### <機能カテゴリ>: <タイトル> (<PR番号>) @<author>
- <詳細項目（PR body から技術的な要点を抽出）>
## 🐛 Bug Fixes
### <カテゴリ>: <タイトル> (<PR番号>) @<author>
- <修正内容と影響範囲>
## 🔧 Refactoring
### <カテゴリ>: <タイトル> (<PR番号>) @<author>
- <リファクタリング内容>
## ⚠️ Breaking Changes（該当がある場合のみ）
- <破壊的変更の箇条書き>
---
**<N> files changed, <N> insertions(+), <N> deletions(-)**
**Full Changelog:** <compare URL>
作成したリリースノートの内容をプレビュー表示し、ユーザーに確認する。
承認後、gh release edit <tag> --notes "<content>" でドラフトを更新する。