xp-harness の公開済みリリースを要約して、チーム周知用の短いテキスト (利用者向けの変化 + 更新手順) を作る。「リリースをアナウンスしたい」「この期間のリリースをまとめて周知したい」「土日の分まとめて」と言われたときに発火。投稿はせずドラフト生成に留める。
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
リリースのたびに「何が変わったか」を短くチームへ伝える作業を、毎回その場のプロンプトで指示し直すと、要約の粒度・更新手順の書き方がぶれる。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 一覧を見せて依頼者と認識合わせしてから要約に入る。一方的に範囲を決めて要約しない。
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.
要件が固まった機能・変更について、アーキテクチャ・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.
E2E テストを実行する手順に沿って E2E を動かす際に発火させる。実行環境のセットアップ、実行コマンド、CI 統合、実行が失敗したときの対処など、E2E を「動かす」場面で使う。触る範囲に対応するプロジェクトの実行手順を探して従わせる入口。E2E spec を書く・レビューするのとは別の責務 (spec の書き方は扱わない)。
The English summary is being prepared. Showing the original description.