Menü
xp-harness の version を上げて GitHub Release を作る開発者向け skill。現バージョン確認 → 次バージョン判定 (semver) → 変更内容のユーザー向け / 開発者向け分類 → tag + push → gh release create までの流れを定義。「リリースする」「タグを打つ」「v0.x.x をリリース」と明示されたときに発火。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| 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 設計・テスト戦略のように選択肢が複数ある相談を受けたとき、要件定義 / 設計 / 実装の中で「複数アプローチがありそう」と感じたときに必ず使う。一案だけポンと出さない。