xp-harness の skill / agent を新規作成・改修するとき、または xp-harness そのものの設計判断 (取り込む / 取り込まない / 翻訳する) を考えるときに必ず発火させる skill。
xp-harness の中核思想 (最終形の理想像 = エージェント群と利用者で XP の開発チームを成す、価値で導きつつ規律装置最小注入、エンジニアとして振る舞う、ペアプロ哲学、中央集権より decentralized、outside-in 例外なし、対話と自走の境界、INVEST の取捨、共創を目指す対話) を context に inject し、新規 skill / agent の設計判断や既存 skill / agent の改修判断を、xp-harness 思想と整合させるためのもの。
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
xp-harness の中核思想と判断軸を集約した skill。新規 skill / agent を作るとき、既存 skill / agent を改修するとき、または harness そのものの設計判断 (新しいアイデアを取り込むか / 取り込まないか / 翻訳して取り込むか) を考えるときに、ここに書かれた思想と判断軸に立ち返る。
xp-harness は「XP の進め方の規律」に閉じる。名前がそのままスコープ宣言。
判断の型: 新しい要素を harness に「足す / 残す」か迷ったら、4 象限の前にまず 「それは XP の進め方の規律か、中身の流儀か」を名前に照らして問う。中身の流儀なら配布既定から外し、プロジェクト側に委ねる (= 探索型スキルが探し当てる先にする)。
失敗パターン (= 実際に起きた): 個別判断を「一般的な良し悪し」(充実させる方が価値が高い / 知見は残す方が良い) で組み立てると、harness に足す・残す方向へ流れて責務境界を超える。名前 (xp-harness) と各 skill の責務から演繹すれば「XP でない中身」は外せる。名前をラベルでなく 責務宣言 として読む。
xp-harness の最終形は、エージェント群と利用者で XP の開発チームを成すこと。
議論の経緯とマトリックスの象限別の既定値は references/最終形の議論経緯.md を参照。
実例:
slice-tdd の done-verifier 連携セクション (Iron Law + 言い訳対応表 + Red Flags) → 規律注入define-requirements / basic-design の対話の型 → そこまで強い規律にしていない未来の判断で「これは worker 化を進める変更か / engineer 性を保つ変更か」を必ず問う。
AgentTeam 等の検討ではこの軸を見る。lead 固定 = 中央集権感が強い → 思想と微妙にズレる。ペアプロ的に弱める方向で使う。
詳細は slice-tdd の「実装方針: outside-in TDD」セクション。
slice-tdd skill 本文に集約 (レイヤー → 手戻りの 2 段ゲート、元に戻せない操作は無条件停止)。デフォルトは自走、即停止は手戻りする例外。止まる条件を固定列挙にしない (= 規模が大きいだけなら再分割で自走、感覚語でなく観測可能な問いで判定する)xp-harness はこの境界を 対話モード / 自走モード として扱う:
モードの切り替えは、要件定義フェーズの「帰結ある行動 (設計・実装・変更) の手前でモードを合意する」ゲートが経路になる — この合意地点は一度きりでなく、要件定義フェーズの中で再来しうる (まず調査してから帰結行動の手前で合意する等)。だから対話 / 自走は「実装とその前」で固定分割されるのでなく、合意し直せる。実装フェーズの途中から対話に戻すような、より広い切り替えの機構はまだ通っていない (段階的でよい)。出発点は「固定分割が既定」ではなく「合意し直せる経路がある」。
「対話駆動で固めた前提を持って自走する」が xp-harness のモード。フル自走 (数時間 autonomous) には倒さない。
自走とは「認識を揃えてから実行する」こと (= 依頼者の意図を汲み、認識を揃え、どう実現するかを定めた上で動く)。「止まらず手を動かすこと」ではない。揃える前にそれっぽい成果物を作るのは自走ではなく自己満足で、認識がズレていれば必ず手戻りが出る (= 揃える手間を惜しむほうが結局は遅い)。揃っていないと気づいたら、作るのを止めて揃えに戻る。
この境界の最終形は「最終形 (= 理想像、北極星)」section の通り — ストーリーが共同と自律の境界線になり、関与の深さはタスクの性質が決めるのではなく、境界で利用者が選ぶ (= マトリックスは既定値の提案材料)。
xp-harness は I / V / S / T を採用、N を落とし、E は暗黙 とする:
Small は 「ユーザー価値を保ったまま分割可能な最小単位」 として価値ベースで判定 (技術的サイクル数ではない)。
依頼者との対話は「会話 (conversation)」ではなく「対話 (dialogue)」を成立させる:
迎合を 2 種類意識する。両方とも「自分の本当の判断を出していない」が共通:
「自分の本当の判断を根拠と共に出す」が核。具体動線は dialogue-principles skill に集約。
望ましい振る舞いは skill / プロジェクト規約に宿らせ、その場のプロンプトで都度指示する形に頼らない。プロンプト依存は再現せず・consumer に届かず・検証もできない (指示の効果か skill の効果か切り分けられない)。harness が skill ベースなのはこのため。
この軸は harness-verification の「ノーヒント」原則の裏返しでもある: 検証で確認したい挙動をプロンプトに書くと自己成就して因果が測れない = 振る舞いは本来 skill / 規約に宿るべき、の証拠。だから検証は挙動を skill / 規約側に置き、プロンプトはヒントなしの普通の依頼にする。
新 skill / agent / 判断装置を harness に取り込むか考えるとき、以下の 4 象限で見る:
| 象限 | 説明 | 該当例 |
|---|---|---|
| 直接採用 OK (哲学衝突なし) | 失敗モードが大きい規律にだけ装置を注入 | Iron Law / Red Flags / Rationalization Table パターン、verification 系、systematic-debugging 系 |
| xp-harness のフローに翻訳して採用 | 既存の thought に合わせて取り込む | subagent prompt template の supporting file 化、bite-sized task 粒度の slice-tdd 連携 |
| 哲学衝突、採用 NG | 思想と相反するので採用しない | エージェントを矯正・強制する hook (動作をブロック/矯正して価値誘導を奪う)、subagent throwaway 模式 (ペアプロ哲学と衝突)、全 skill への HARD-GATE 装着 |
| 痛みが明確化していない / スコープ外 | 必要性が立証されていない | parallel agent dispatch、AgentTeam の本格導入 (= 「最終形」section の具体化に伴い、保留を解く議論の対象になりつつある。経緯は references/最終形の議論経緯.md) |
新アイデアは必ずこの象限分けで判断する。象限 3 (哲学衝突) のものは「採用したい」と感じても踏みとどまる。象限 4 は痛みが見えてから検討する。痛みが明確化して象限 4 から採用に移った実例: 自動 worktree (並行作業の痛みが明確化し、git-workflow の worktree 化として採用。経緯は docs/working/git-workflow-worktree/要件定義.md)。もう一つの実例: git 最新化支援 hook (自走で「開始時に fetch」の規律が発火せず落ちる痛みが顕在化し、支援 hook として採用。経緯は docs/working/自走時のgit最新化支援/)。
象限 3 の NG は「hook そのもの」ではなく「エージェントを矯正・強制する hook」。気づきを注入するだけの支援 hook は、価値で導く・エージェントの能力を最大化するという思想と整合するので象限 3 ではない。時間計算や fetch のような機械が得意な作業を機械にやらせ、判断はエージェントに委ねる (ブロックしない = 常に成功終了) のが支援 hook。人間がタイマーで気づくのと同じ位置づけ。
例外: 安全・コストのハードストップ (元に戻せない課金・破壊の防止) は、矯正 hook でも正当な例外 (= 判断軸 5「元に戻せない操作は無条件停止」の hook 側の現れ)。実例は改修者ローカルの block-claude-headless (ヘッドレス=従量課金の誤発火をブロックする)。ここは「価値で導く」より「取り返しのつかない事故を止める」が優先される領域。
ただし「支援なら何でも採用」ではない。支援 hook も、判断軸 1 と同じ 失敗モードが大きい節目に限る・痛みが顕在化してから の spirit で律する (hook 乱立の白紙委任を防ぐ)。
ただし 4 象限の前に、まず「責務境界」section の問い (= それは XP の進め方の規律か、中身の流儀か) を通す。中身の流儀なら、4 象限に入る前に「配らない」(= プロジェクト側に委ねる) で決まる。
xp-harness の XP エンジニアは「価値を共有した自律」で動く。失敗モードが大きい部分にだけ規律装置を注入し、それ以外は価値で導く。subagent はワーカーではなくペアプロ相手。
判断に迷ったら、この文に立ち返る。
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.
xp-harness の公開済みリリースを要約して、チーム周知用の短いテキスト (利用者向けの変化 + 更新手順) を作る。「リリースをアナウンスしたい」「この期間のリリースをまとめて周知したい」「土日の分まとめて」と言われたときに発火。投稿はせずドラフト生成に留める。
The English summary is being prepared. Showing the original description.
要件が固まった機能・変更について、アーキテクチャ・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.