xp-harness の公開済みリリースを要約して、チーム周知用の短いテキスト (利用者向けの変化 + 更新手順) を作る。「リリースをアナウンスしたい」「この期間のリリースをまとめて周知したい」「土日の分まとめて」と言われたときに発火。投稿はせずドラフト生成に留める。
sei-newbear/xp-harness92026年9月17日 更新
無料GitHub で公開
review-recording
xp-harness 本体 (skill / agent / instruction / kanban 等) のレビューを進めているときに必ず発火させる skill。依頼者がレビュー中の気づきを次々と伝えてくるので、それを改修バックログ（かんばん）に記録していく作業に特化した振る舞いを規定する。
「レビューしている」「気づきを記録」「かんばんに追加」「TODO に追加」「あとは…」「次は…」のような連続入力を受けたときに発火。1 つの気づきへの返答が終わってから次の気づきを受けるリズム。発火しないのは、レビューではなく実際に手を動かして実装 / 修正している場面、依頼者から明示的に「議論したい」「相談したい」と言われた場面。
含まれるファイル（1）
- SKILL.md4.5 KB
SKILL.md（原文）
インストールする前に、エージェントに与えられる指示の中身を確認できます。
review-recording — レビュー中の気づきを記録するモード
なぜこの skill があるか
xp-harness の本体 (skill / agent / instruction / かんばん) を依頼者がレビューするとき、気づきを次々と伝えてくる場面がある。その場で議論したり、優先度を勝手に付けたり、複数気づきを合体させたりすると、後から個別に着手 / 削除 / 整理しにくくなる。
このモードでは「気づきを記録に徹する」振る舞いをルール化する。
中核ルール
1. 議論や提案は基本しない
依頼者が「やる際に検討する」と判断したものは、記録段階では議論しない。
- ✗ 「周辺の範囲はどこまでですか？」
- ✗ 「この方針 / あの方針、どちらが良いと思いますか？」
- ○ 「カードとして記録しました」
例外: 依頼者から明示的に「相談したい」「議論したい」と言われた場面のみ議論モードに切り替わる。
2. 「ペイン」「痛み」「優先度」を勝手に付与しない
これはレビューでの気づきの記録であって、運用痛から駆動された TODO ではない。
- 新規の気づきはデフォルト優先度で記録する（優先度の判断は別途）。具体の優先度値は
kanbanskill の規約に従う（現状のデフォルトはbacklog） - 依頼者が優先度を明示したものだけ、それに従って上げる
3. 複数の気づきはカードごとに分割する
同じ対象ファイル / 同じ agent への複数指摘でも、合体させずに別カードとして記録する。理由: 後から個別に着手 / 削除 / 優先度変更しにくくなる（1 項目 1 カードはかんばんの基本）。
合体が許される場面: 既存カードが同じ概念をカバーしている、かつ依頼者が「他のカードに書いてあるなら統合してよい」と明示した場合のみ。
4. 意図が不明な箇所だけ確認する
意図そのものが分からないときに限り、確認質問をする。
- ✗ 「これは <候補 a> / <候補 b> どちらの意味ですか？」(中身が分かっている上での選択肢確認)
- ○ 「<曖昧な指示>。これはどのファイルの話ですか？」(意図が読み取れない)
5. 記録はかんばんのカードを作る
気づき 1 件につき 1 カードを新規作成する。記録先はかんばんなので、カードの置き場所・ファイル名規約・本文テンプレ・優先度の扱いはかんばんの規約に乗る（具体は振る舞いの流れで kanban skill を呼ぶ）。本文には背景 / Why・状況・再開時の起点を含める。
振る舞いの流れ
- 依頼者から気づきが届く
- 必要なら対象ファイルを軽く確認 (記録の正確性のため。議論のためではない)
- 気づきをかんばんのカードとして作成する（
kanbanskill を呼び、その規約に従ってカードを作る） - 短く完了報告 (「カードを作成しました」+ 必要な補足のみ)
- 「次の気づきをどうぞ」で次の入力を待つ
何をしないか
- レビュー対象を読み込んで自分の見解を述べる (議論しない)
- 既存カードと新規カードの重複を勝手に判定 / マージする (依頼者が「統合」と言わない限り別カード)
- 優先度を運用想定から推測して付与する (
backlog既定に留める) - 関連 skill / agent / instruction の修正に手を出す (記録のみ、修正は別タイミング)
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
要件が固まった機能・変更について、アーキテクチャ・ER・シーケンス・論理設計までを対話で固める「基本設計フェーズ」のスキル。docs/working/<title>/要件定義.md が既にある状態で「設計を進めて」「basic-design」と言われたら必ず発火させる。要件定義が終わって設計フェーズに入りたい依頼、データモデルや API 設計や画面遷移の議論、コンポーネント分割や責務分離の相談、「どう作るか」の構造的な設計が必要な場面で使う。
sei-newbear/xp-harness92026年9月17日 更新
新規・変更・削除・改善などの要望やレビュー指摘を受けたら、設計や実装に入る前にまず必ず発火させる「要件定義フェーズ」のスキル。依頼者のインテントを読み取り、Why / Done / スコープ / 影響範囲を引き出す。見える挙動が変わる依頼全般が対象で、やることが具体的でも md にまとめられていても発火させ、複数の要望が混ざる依頼ほど積極的に発火させる。発火しないのは、再現条件と期待動作が完全に明確なバグ修正、依存更新・タイポ修正などの定型作業、要件定義と基本設計の文書が両方揃った実装フェーズの続き（メモや TODO があるだけでは除外しない）だけ。
sei-newbear/xp-harness92026年9月17日 更新
依頼者と議論・対話を進める場面で必ず発火させる skill。共創を目指して、認識を小さく揃えながら、同じ抽象度・レイヤーで話すための対話の進め方を扱う。要件・設計フェーズの対話、実装中の設計判断の議論、レビュー結果の共有、複数の論点・選択肢を依頼者に渡す場面、依頼者からの指摘・反論に応答する場面、「確認したい」「議論したい」「相談したい」と問いかけたいとき、いずれも発火対象。「会話」ではなく「対話」を成立させたい全場面で効く。質問がスルーされる・訂正が続く・話題を変えられる・「そうじゃなくて」と返されるなど、噛み合っていない兆候を観測したときは軌道修正のために再度発火させる。
sei-newbear/xp-harness92026年9月17日 更新
内部由来の知見（ふりかえりの反映・実プロジェクトの検証記録など）を公開リポジトリに出す前に、組織固有の固有名詞（会社名・内部リポ名・顧客名・人物名・プロジェクト名・ID・パス等）の混入を独立点検して防ぐ。公開 git 履歴は遡れて消せないため、コミット / push の前に必ず通す。機密・認証情報の検査は扱わない。
sei-newbear/xp-harness92026年9月17日 更新
E2E テストの spec を書く・編集する・レビューする際に必ず発火させる。新しいシナリオの追加、既存 E2E テストの修正・デバッグ、E2E テストの書き方の相談、slice-tdd skill から E2E spec が必要と判断された場面で使う。触る範囲に対応するプロジェクトの E2E の流儀 (spec の書き方・構造・命名) を探して従わせる入口。E2E を実行する手順は扱わない (別スキルの責務)。
sei-newbear/xp-harness92026年9月17日 更新