xp-harness: Skill for Claude Code

要件定義フェーズ

なぜこの skill があるか

実装に入る前に「何を、誰のために、なぜ作るか」を固めないと、エンドユーザーに価値が届かない設計が通る。依頼者は依頼者であってエンドユーザーではない。プロのエンジニアとして、依頼者の言葉の裏にある真の課題を引き出すのがこのフェーズの責務。

依頼者のインテント（真の意図）を読み取る

依頼者の発言の表面（「○○を作って」「○○を消して」「○○を確認して」）の裏にあるインテントを読み取る。なぜそれが必要か、誰のためか、何が真の課題か。表面的な依頼に縛られず、Why から最善の一手を考える。

依頼が md ファイル（review / TODO / 改善要望リスト）にまとまっていても同じ。md に書かれているのは「依頼者の表面的な要望」であって、その裏のインテントを読み取り対話で引き出す。「やることが具体的だから skip」と判断しない — 具体的な解決策の裏に真の課題があり、別の解決策の方が良いかもしれない。

モードを合意してから帰結ある行動に入る ★最初に通す

発火したら、いきなり Why 掘りや下の 5 セクションの要件定義に入らない。まず「今どのモードにいるか」を意識する。モードは 3 つ:

• モード未確定: 依頼を受けた直後 / 調査中。まだどちらのモードか決まっていない
• 対話モード: 決めに行かず、確認しながら認識を揃える（このスキルの通常フロー）
• 自走モード: ゴールが明確で「任せる」とき。決めて進め、終わってから共有する

守りたいのは「合意なしで帰結ある行動に滑り込むこと」の一点

ゲートは 1 つだけ。設計・実装・変更という帰結ある行動（＝やり直しにコストがかかる動き）に入る手前で、どのモードで進めるかを依頼者と合意する。これ以外はゲートで止めない。特に次の非破壊な動きは、モード未確定でも止めない:

• 調査（読む・探る・理解を作る、戻せる動き）: そのまま進めてよい。調査は「どちらのモードでいくか」を決めるための情報集めだから。ただし調査が終わって帰結ある行動に入る手前で、必ずモード合意に戻る（調査は実装への抜け道ではない）
• 議論・要件対話（依頼者と認識を揃える動き）: 依頼者がいきなり議論を始めたら、それは既に対話モードそのもの。止める対象ではない（むしろ望ましい）。その場で dialogue-principles skill を呼んでから議論に応じる

モード合意 ← ここがゲート

帰結ある行動に入る手前で、AskUserQuestion で「対話モードで深掘る / 自走モードで進める」を出し、自分の見立てを推奨に置く。勝手にどちらかのモードに入らない（重いから一人でゴールを決めて設計・実装まで進める、調査したからそのまま実装に直行する、はどちらも「合意なしで帰結ある行動に滑り込む」）。止めたいのは 自分が勝手に帰結ある行動へ突入すること であって、深掘り（Why 掘り）や調査そのものではない — それらはむしろ進めてよい（重いタスクほど深掘る価値がある）。見立ての目安:

• 対話モードを推奨: 依頼が特定の手段・解決策を指していて、その裏の Why 次第では別のやり方の方が良いかもしれないとき。「○○を表示して」「○○を追加して」のような解決策の指定は、それ自体が深掘る理由になりうる（手段が明確なだけで、真の課題への最善とは限らない — 下の代案提案の例を参照）
• 自走モードを推奨: 純粋作業（タブ削除・typo 的な文言修正・整形）／ゴールが明確で手段はお任せ（「任せる」「やり方は問わない」）／掘っても手段が変わらなそう、のとき

見立ては当てにいくものではなく外すことがある（機械的に見分けるのは難しい）。だから独断で決めず、見立てを述べて依頼者に確認する — この確認が見立てのブレを受け止める安全網。依頼者は自分の意図（探ってほしいのか、任せて進めてほしいのか）を分かっているので選べる。迷ったら対話モード側を推奨に置く（「簡単そうで難しい／指定された手段が最善でない」を取りこぼさないため）。

モードが決まったら

• 自走モードで合意 → 「何をするか」「どうなったら完了か」の最小限だけ口頭で揃え、basic-design skill を挟まず slice-tdd skill での実装にそのまま渡す（最小合意を口頭で持って渡す）。要件定義.md は作らない。この時点で終わり — 下の「やること」以降のセクションは実行しない
• 対話モードで合意 → dialogue-principles skill を呼んでから、下の通常フローに進む（Why を掘り要件を固める）。対話モードで進めると決めた時点が、対話の規律を効かせ始める地点