Menú
xp-harness の公開済みリリースを要約して、チーム周知用の短いテキスト (利用者向けの変化 + 更新手順) を作る。「リリースをアナウンスしたい」「この期間のリリースをまとめて周知したい」「土日の分まとめて」と言われたときに発火。投稿はせずドラフト生成に留める。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
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 設計・テスト戦略のように選択肢が複数ある相談を受けたとき、要件定義 / 設計 / 実装の中で「複数アプローチがありそう」と感じたときに必ず使う。一案だけポンと出さない。
| name | announce-release |
| description | xp-harness の公開済みリリースを要約して、チーム周知用の短いテキスト (利用者向けの変化 + 更新手順) を作る。「リリースをアナウンスしたい」「この期間のリリースをまとめて周知したい」「土日の分まとめて」と言われたときに発火。投稿はせずドラフト生成に留める。 |
リリースのたびに「何が変わったか」を短くチームへ伝える作業を、毎回その場のプロンプトで指示し直すと、要約の粒度・更新手順の書き方がぶれる。skill 化して周知テキストの型を揃える。
責務は release skill と分ける (= 単一責任): release が「リリースを作る (version 上げ・tag・GitHub Release)」、本 skill が「作ったリリースをチームに伝える」。周知はリリース直後だけでなく後追いでも単独で呼びたい (= 「この期間の分まとめて」) ため、release に混ぜず独立させる。
skill が呼ばれたら以下の Step を順番に実行する。
依頼の範囲 (= 期間 / バージョン範囲 / 「前回の周知以降」) から対象の tag を割り出す。
git for-each-ref --sort=-creatordate --format '%(creatordate:short) %(refname:short)' refs/tagsgh release view <tag>release skill が既にユーザー向け / 開発者向けを分類済みなので、その分類を信頼して利用者向けだけ拾うrelease skill の「内容の書きっぷり」と同じ基準、内部の実装 how は載せない)apm.yml の依存を最新 tag に書き換えるapm install --target claudeContent hash mismatch が出たら apm install --update --target claudeチーム周知の目的は「使う人の作業で何が変わるか」を伝えること。開発者向け (= リポジトリ内部だけの変更) は既定で載せない。依頼者が「開発者向けも入れて」と言えば足す。
周知先チャンネルへの投稿は外向き操作で取り消しにくい。この skill はドラフト生成に留め、投稿は依頼者に委ねる。ドラフト生成はツール非依存で常に動く形を保つ (= 特定の周知ツール連携に依存させない)。
更新手順は思い出しで書かず、README の "Update" セクションを正とする。タグを跨ぐ更新は apm.yml の手編集が必要で、apm install --update だけでは #vX.Y.Z の pin を書き換えない (= APM 0.12.x 時点の仕様)。ここを省くと「--update で上がるはず」と試してハマる。README とずれたら README を正とする。
gh を使う (= git-workflow skill の override)リリースノート本文 (= 利用者向けセクション) は GitHub Release にしかない (tag のメッセージには入らない) ため、gh release view で取得する。git-workflow skill のデフォルト「gh 使わない」を、release skill と同様に意図的に override する。
「土日」「最近」など範囲が曖昧なときは、Step 1 で割り出した tag 一覧を見せて依頼者と認識合わせしてから要約に入る。一方的に範囲を決めて要約しない。