xp-harness の version を上げて GitHub Release を作る開発者向け skill。現バージョン確認 → 次バージョン判定 (semver) → 変更内容のユーザー向け / 開発者向け分類 → tag + push → gh release create までの流れを定義。
「リリースする」「タグを打つ」「v0.x.x をリリース」と明示されたときに発火。
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
xp-harness のリリース (= 新 version tag + GitHub Release 作成) は手動運用。 手順を skill 化することで、 改修者間でリリースの流儀 / リリースノートのスタイルを揃える。 「GitHub Actions で release notes 自動化」 (kanban backlog の項目) が完了するまでは手動運用が続く想定。
skill が呼ばれたら以下の Step を順番に実行する。
git fetch --tags origin && git tag -l | sort -Vgit fetch origin && git log --oneline origin/main -5変更内容に応じて semver で判定:
判定は変更内容 (= 前回 tag → 現在の commit 一覧) を main session が判断し、 依頼者と認識合わせしてから確定する。
git log --oneline <prev-tag>..origin/maingh release view <prev-tag> で前回の body を確認参考にするのは書式 (= section 構成・分類の仕方) であって、項目の粒度ではない。前回が新 skill 追加で厚く書いた回でも、今回が既存 skill への追記なら必要な量は変わる。完成形は判断基準より強く効くので、見た後は必ず Step 4 の書きっぷり・長さの規律を通してから書く。
リリースノートは ユーザー向け / 開発者向けを明確に分ける:
<簡潔な 1 行サマリ>
## ユーザー向け (= xp-harness を使う人)
### Added
- ...
### Changed
- ...
## 開発者向け (= xp-harness を改修する人)
### Added
- ...
### Changed
- ...
## Install (新規 consumer 向け)
(apm install コマンド)
## Update (既存 consumer 向け、 <前 version> → <新 version>)
`apm.yml` の依存指定を新バージョンに書き換える:
```diff
dependencies:
apm:
- - sei-newbear/xp-harness#<前 version>
+ - sei-newbear/xp-harness#<新 version>
```
そのあと:
```bash
apm install --target claude
# Content hash mismatch が出たら (= APM のサプライチェーン検出機構、想定挙動)
apm install --update --target claude
```
詳細は README "Update" セクション参照。
## Note
(後方互換性 / 状態 note)
リリースノートは一時ファイル (例: /tmp/release-notes-vX.X.X.md) に書く。
## Update セクションが必要な理由APM 0.12.x はタグを跨いだ更新コマンド (npm でいう npm install pkg@latest) を持たない。 既存 consumer は apm.yml を手で書き換える必要があり、 リリースノートに手順がないと「apm install --update で上がるはず」と試してハマる (= v0.2.0 アップデート時に別 consumer プロジェクトで実際に発生)。
.apm/skills/ / .apm/agents/ / .apm/instructions/)、 README の install / 使い方scripts/ / kanban/ / .claude/skills/<開発者向け>/)迷ったら判断基準: 「この変更は APM 経由で consumer に届くか?」 → 届けばユーザー向け、 届かなければ開発者向け。
分類 (= どこに置くか) とは別に、各項目の書き方を間違えない。ユーザー向けの項目は、consumer が実際に観測する挙動の変化で書く (= その skill / 機構が今後どう振る舞うようになったか)。内部の実装 how (どう書き直したか・リファクタ詳細・行数・用語統一など) はユーザー向けに書かない (= consumer の挙動に直接効かないため)。書きたければ開発者向けへ。
slice-tdd skill をゼロベースで書き直し、用語を統一、重複を single-source 化 (365→227 行)」 (= 内部の how)slice-tdd: outside-in が実装の各層に届くようになった。実装エージェントが各層でも "その層が外に見せる契約" を先に決めて内側を surface する方向に進む」 (= consumer が観測する挙動)判断軸: 「この項目を読んだ consumer が、自分の作業で何が変わるか を掴めるか?」 掴めなければ内部の how に寄っているサイン。
「内容の書きっぷり」(= 観測可能な挙動の変化で書く) と対になる量の規律。長いリリースノートは読まれず、読まれなければ書いた意味がない。
判断軸: 「ユーザー向け section を、consumer が上から下まで一息で読み切れるか?」項目ごとに読み返しが要る長さなら削る。あわせて「今回の変更の重さに対して、前回のリリースノートより厚くなっていないか」も見る。
git checkout main
git pull --ff-only origin main
リリース対象は origin/main の最新。 別 branch にいる場合は main を checkout する。
README には install / migrate / Update セクションの例に sei-newbear/xp-harness#vX.Y.Z 形式のバージョン参照が複数箇所ある。 tag を打つ前に これらを新バージョンに揃える (= 新規 consumer が README をコピペしたら新バージョンが入る状態にする、 既存 consumer 向けの Update 例も最新の migration を示す)。
# 1. 全箇所を grep して把握
grep -n "sei-newbear/xp-harness#v" README.md
# 2. 該当箇所を新バージョンに編集
# - Install セクション (install コマンド)
# - 初回 install 前の migrate 手順内の install コマンド
# - Update セクションの diff 例 (= 直前リリース → 今回リリース に揃える)
# 3. commit + push to main
git add README.md
git commit -m "README: install / migrate / update 例のバージョン参照を vX.Y.Z に更新"
git push origin main
tag を打つ前に README を更新しておくことで、 tag が指す commit に正しいバージョン参照が含まれ、 consumer が tag で取得した README にも新バージョンが反映される。
APM (0.12.x 時点) は タグ pin を推奨しており、 sei-newbear/xp-harness のようにバージョン無指定で書くと「default branch (main) の HEAD」 を取得する (= unreleased な作業中 commit も pull される)、 加えて APM 自体が [!] 1 dependency unpinned: ... add #tag or #sha to prevent drift の warning を出す。 また semver range syntax (^v1, ~v1.0 等) も公式 docs にサポート記載がない。 そのため xp-harness の README は具体 tag で pin し、 release ごとに手動同期する運用を取る (= kanban backlog の「GitHub Actions で release notes 自動化」 と合わせて将来自動化対象)。
git tag -a vX.X.X -m "<簡潔な概要 (= リリースタイトル相当)>"
git push origin vX.X.X
annotated tag を使う (= -a 付き)。 軽量 tag は使わない (= 後から release notes / 履歴を辿りにくくなるため)。
gh release create vX.X.X --title "vX.X.X — <概要>" --notes-file /tmp/release-notes-vX.X.X.md
完了したら一時ファイルを削除: rm /tmp/release-notes-vX.X.X.md
リリースは「shipped した」の曖昧さのない節目。作業に没頭するとバックログの現実同期が抜け落ちる (= 完了・リリースまで行ってカードを動かさない失敗が実際に起きた)。リリースの締めで必ず kanban skill を呼び、リリースに含む改修をバックログに反映する。何をどうカード化 / DONE 化するか (= 独立項目か付随か・ファイル名規約・DONE カードの中身・完了済みの直接記録) は kanban skill の流儀に従う (= この Step の責務は「リリースの節目で必ず同期する」の規律化で、カード化の判断と操作は kanban skill が single source として持つ)。
gh コマンドを使う (= git-workflow skill の override)この release skill では gh コマンドを使う。 git-workflow skill のデフォルト「gh 使わない」を意図的に override する。 理由: GitHub Release 作成は Web UI でも可能だが、 リリースノートの一貫性 / 自動化のため CLI で実行する。
semver の判定 (= patch / minor / major) は影響度の解釈に依存する。 main session の判断を依頼者と認識合わせしてから tag を打つ。 一方的に決めない。
ユーザー向け / 開発者向けの分類は曖昧にしない。 各項目を分類した根拠 (= 配布先) を意識する。 分類が曖昧な項目は依頼者と認識合わせ。
テンプレ内の <前 version> / <新 version> placeholder は 実リリースノートでは具体 version (例: v0.1.0 / v0.2.0) に置き換える。 placeholder のまま公開しない。 リリース時点で前バージョン (= 直前の tag) と新バージョン (= これから打つ tag) は両方確定しているので、 具体 version を書いた方が consumer は「自分のバージョンから上げる diff」 を直接読めて親切。
tag を打つ対象は origin/main の最新 (= マージ済のすべての変更が含まれる commit)。 未マージの branch には tag を打たない。
v0.2.0)、 origin に push 済 (= README 更新済 commit を指す)kanban バックログに反映済No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
xp-harness の公開済みリリースを要約して、チーム周知用の短いテキスト (利用者向けの変化 + 更新手順) を作る。「リリースをアナウンスしたい」「この期間のリリースをまとめて周知したい」「土日の分まとめて」と言われたときに発火。投稿はせずドラフト生成に留める。
The English summary is being prepared. Showing the original description.
要件が固まった機能・変更について、アーキテクチャ・ER・シーケンス・論理設計までを対話で固める「基本設計フェーズ」のスキル。docs/working/<title>/要件定義.md が既にある状態で「設計を進めて」「basic-design」と言われたら必ず発火させる。要件定義が終わって設計フェーズに入りたい依頼、データモデルや API 設計や画面遷移の議論、コンポーネント分割や責務分離の相談、「どう作るか」の構造的な設計が必要な場面で使う。
The English summary is being prepared. Showing the original description.
新規・変更・削除・改善などの要望やレビュー指摘を受けたら、設計や実装に入る前にまず必ず発火させる「要件定義フェーズ」のスキル。依頼者のインテントを読み取り、Why / Done / スコープ / 影響範囲を引き出す。見える挙動が変わる依頼全般が対象で、やることが具体的でも md にまとめられていても発火させ、複数の要望が混ざる依頼ほど積極的に発火させる。発火しないのは、再現条件と期待動作が完全に明確なバグ修正、依存更新・タイポ修正などの定型作業、要件定義と基本設計の文書が両方揃った実装フェーズの続き（メモや TODO があるだけでは除外しない）だけ。
The English summary is being prepared. Showing the original description.
依頼者と議論・対話を進める場面で必ず発火させる skill。共創を目指して、認識を小さく揃えながら、同じ抽象度・レイヤーで話すための対話の進め方を扱う。要件・設計フェーズの対話、実装中の設計判断の議論、レビュー結果の共有、複数の論点・選択肢を依頼者に渡す場面、依頼者からの指摘・反論に応答する場面、「確認したい」「議論したい」「相談したい」と問いかけたいとき、いずれも発火対象。「会話」ではなく「対話」を成立させたい全場面で効く。質問がスルーされる・訂正が続く・話題を変えられる・「そうじゃなくて」と返されるなど、噛み合っていない兆候を観測したときは軌道修正のために再度発火させる。
The English summary is being prepared. Showing the original description.
内部由来の知見（ふりかえりの反映・実プロジェクトの検証記録など）を公開リポジトリに出す前に、組織固有の固有名詞（会社名・内部リポ名・顧客名・人物名・プロジェクト名・ID・パス等）の混入を独立点検して防ぐ。公開 git 履歴は遡れて消せないため、コミット / push の前に必ず通す。機密・認証情報の検査は扱わない。
The English summary is being prepared. Showing the original description.
E2E テストの spec を書く・編集する・レビューする際に必ず発火させる。新しいシナリオの追加、既存 E2E テストの修正・デバッグ、E2E テストの書き方の相談、slice-tdd skill から E2E spec が必要と判断された場面で使う。触る範囲に対応するプロジェクトの E2E の流儀 (spec の書き方・構造・命名) を探して従わせる入口。E2E を実行する手順は扱わない (別スキルの責務)。
The English summary is being prepared. Showing the original description.