القائمة
GitHub のリリースドラフトを充実化する。 ユーザーが「リリースノートを作って」「ドラフトリリースを充実させて」「release note を書いて」 などと言った時に使用する。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| 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>" でドラフトを更新する。
タスクの説明からブランチ名を自動生成し、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` / 上り報告)とは別物 — あちらは 上下関係の報告経路、こちらは対等な対話。既存プロトコルは変更しない。