Menu
xp-harness の version を上げて GitHub Release を作る開発者向け skill。現バージョン確認 → 次バージョン判定 (semver) → 変更内容のユーザー向け / 開発者向け分類 → tag + push → gh release create までの流れを定義。「リリースする」「タグを打つ」「v0.x.x をリリース」と明示されたときに発火。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | release |
| description | xp-harness の version を上げて GitHub Release を作る開発者向け skill。現バージョン確認 → 次バージョン判定 (semver) → 変更内容のユーザー向け / 開発者向け分類 → tag + push → gh release create までの流れを定義。「リリースする」「タグを打つ」「v0.x.x をリリース」と明示されたときに発火。 |
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 を確認リリースノートは ユーザー向け / 開発者向けを明確に分ける:
<簡潔な 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)
## 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 に寄っているサイン。
リリースノートは一時ファイル (例: /tmp/release-notes-vX.X.X.md) に書く。
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 バックログに反映済xp-harness の skill / subagent が意図どおり振る舞えているか (発火するか・あるべき振る舞いができているか) を transcript で事実確認する手順。skill / subagent を改修した後に sandbox で動作検証したいとき、または本番の実運用セッションを「あるべき振る舞い」に照らして分析したいとき、「検証したい」「発火するか確かめたい」「このセッションを分析したい」と言われたときに発火させる。核は発火・振る舞いができたかの事実確認で、本番セッションでは自走の良し悪し (止まり方・判断の質など) も見る。
要件が固まった機能・変更について、アーキテクチャ・ER・シーケンス・論理設計までを対話で固める「基本設計フェーズ」のスキル。docs/working/<title>/要件定義.md が既にある状態で「設計を進めて」「basic-design」と言われたら必ず発火させる。要件定義が終わって設計フェーズに入りたい依頼、データモデルや API 設計や画面遷移の議論、コンポーネント分割や責務分離の相談、「どう作るか」の構造的な設計が必要な場面で使う。
新規・変更・削除・改善などの要望やレビュー指摘を受けたら、設計や実装に入る前にまず必ず発火させる「要件定義フェーズ」のスキル。依頼者のインテントを読み取り、Why / Done / スコープ / 影響範囲を引き出す。見える挙動が変わる依頼全般が対象で、やることが具体的でも md にまとめられていても発火させ、複数の要望が混ざる依頼ほど積極的に発火させる。発火しないのは、再現条件と期待動作が完全に明確なバグ修正、依存更新・タイポ修正などの定型作業、要件定義と基本設計の文書が両方揃った実装フェーズの続き（メモや TODO があるだけでは除外しない）だけ。
依頼者と議論・対話を進める場面で必ず発火させる skill。共創を目指して、認識を小さく揃えながら、同じ抽象度・レイヤーで話すための対話の進め方を扱う。要件・設計フェーズの対話、実装中の設計判断の議論、レビュー結果の共有、複数の論点・選択肢を依頼者に渡す場面、依頼者からの指摘・反論に応答する場面、「確認したい」「議論したい」「相談したい」と問いかけたいとき、いずれも発火対象。「会話」ではなく「対話」を成立させたい全場面で効く。
Git 運用の規律 (branch / worktree 運用、commit / push / pull / rebase / conflict 解決、remote 同期、完了時の統合) を一元的に担う skill。コード変更を伴う依頼・セッション開始・Git 操作の話題のいずれかに該当したら、他より先に必ず最初に使う。ファイルを 1 行でも書き換える依頼なら Git に無関係に見えても発火し、セッション開始・作業再開 (「前回の続き」「何から始めよう」等) でも必ず発火する。発火しないのはコードを読むだけの質問、Git の概念学習質問、doc のサマリ依頼。project 固有ルールでの部分上書きに対応する。
設計判断・ライブラリ選定・アーキ判断・実装アプローチが 2 つ以上ありえる場面で必ず発火させる、「複数案＋メリデメ＋推奨」を提示する横断スキル。「どっちがいい？」「これでいい？」「方針を相談したい」と聞かれたとき、ライブラリ選定・ディレクトリ構成・API 設計・テスト戦略のように選択肢が複数ある相談を受けたとき、要件定義 / 設計 / 実装の中で「複数アプローチがありそう」と感じたときに必ず使う。一案だけポンと出さない。