القائمة
新規・変更・削除・改善などの要望やレビュー指摘を受けたら、設計や実装に入る前にまず必ず発火させる「要件定義フェーズ」のスキル。依頼者のインテントを読み取り、Why / Done / スコープ / 影響範囲を引き出す。見える挙動が変わる依頼全般が対象で、やることが具体的でも md にまとめられていても発火させ、複数の要望が混ざる依頼ほど積極的に発火させる。発火しないのは、再現条件と期待動作が完全に明確なバグ修正、依存更新・タイポ修正などの定型作業、要件定義と基本設計の文書が両方揃った実装フェーズの続き（メモや TODO があるだけでは除外しない）だけ。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
xp-harness の skill / subagent が意図どおり振る舞えているか (発火するか・あるべき振る舞いができているか) を transcript で事実確認する手順。skill / subagent を改修した後に sandbox で動作検証したいとき、または本番の実運用セッションを「あるべき振る舞い」に照らして分析したいとき、「検証したい」「発火するか確かめたい」「このセッションを分析したい」と言われたときに発火させる。核は発火・振る舞いができたかの事実確認で、本番セッションでは自走の良し悪し (止まり方・判断の質など) も見る。
要件が固まった機能・変更について、アーキテクチャ・ER・シーケンス・論理設計までを対話で固める「基本設計フェーズ」のスキル。docs/working/<title>/要件定義.md が既にある状態で「設計を進めて」「basic-design」と言われたら必ず発火させる。要件定義が終わって設計フェーズに入りたい依頼、データモデルや API 設計や画面遷移の議論、コンポーネント分割や責務分離の相談、「どう作るか」の構造的な設計が必要な場面で使う。
依頼者と議論・対話を進める場面で必ず発火させる skill。共創を目指して、認識を小さく揃えながら、同じ抽象度・レイヤーで話すための対話の進め方を扱う。要件・設計フェーズの対話、実装中の設計判断の議論、レビュー結果の共有、複数の論点・選択肢を依頼者に渡す場面、依頼者からの指摘・反論に応答する場面、「確認したい」「議論したい」「相談したい」と問いかけたいとき、いずれも発火対象。「会話」ではなく「対話」を成立させたい全場面で効く。
Git 運用の規律 (branch / worktree 運用、commit / push / pull / rebase / conflict 解決、remote 同期、完了時の統合) を一元的に担う skill。コード変更を伴う依頼・セッション開始・Git 操作の話題のいずれかに該当したら、他より先に必ず最初に使う。ファイルを 1 行でも書き換える依頼なら Git に無関係に見えても発火し、セッション開始・作業再開 (「前回の続き」「何から始めよう」等) でも必ず発火する。発火しないのはコードを読むだけの質問、Git の概念学習質問、doc のサマリ依頼。project 固有ルールでの部分上書きに対応する。
設計判断・ライブラリ選定・アーキ判断・実装アプローチが 2 つ以上ありえる場面で必ず発火させる、「複数案＋メリデメ＋推奨」を提示する横断スキル。「どっちがいい？」「これでいい？」「方針を相談したい」と聞かれたとき、ライブラリ選定・ディレクトリ構成・API 設計・テスト戦略のように選択肢が複数ある相談を受けたとき、要件定義 / 設計 / 実装の中で「複数アプローチがありそう」と感じたときに必ず使う。一案だけポンと出さない。
エンジニアとして手を動かす作業全般で必ず発火させる: コードを書く / テストを書く / リファクタ / バグ修正 / E2E spec 追加 / 既存仕様への小さな修正など、コードに触る作業すべて。「実装して」「テスト書いて」「リファクタして」「バグ直して」のような依頼を受けたとき、または基本設計が済んで実装フェーズに入るときに発火。基本作業は TDD（テスト先書き → 最小実装 → リファクタ → コミット）で進め、要件が大きければ適切な小ささに分割しつつサイクルを回す。発火しないのは要件定義 / 基本設計の対話中（まだ手を動かしていない時）だけ。
| name | define-requirements |
| description | 新規・変更・削除・改善などの要望やレビュー指摘を受けたら、設計や実装に入る前にまず必ず発火させる「要件定義フェーズ」のスキル。依頼者のインテントを読み取り、Why / Done / スコープ / 影響範囲を引き出す。見える挙動が変わる依頼全般が対象で、やることが具体的でも md にまとめられていても発火させ、複数の要望が混ざる依頼ほど積極的に発火させる。発火しないのは、再現条件と期待動作が完全に明確なバグ修正、依存更新・タイポ修正などの定型作業、要件定義と基本設計の文書が両方揃った実装フェーズの続き（メモや TODO があるだけでは除外しない）だけ。 |
実装に入る前に「何を、誰のために、なぜ作るか」を固めないと、エンドユーザーに価値が届かない設計が通る。依頼者は依頼者であってエンドユーザーではない。プロのエンジニアとして、依頼者の言葉の裏にある真の課題を引き出すのがこのフェーズの責務。
依頼者の発言の表面（「○○を作って」「○○を消して」「○○を確認して」）の裏にあるインテントを読み取る。なぜそれが必要か、誰のためか、何が真の課題か。表面的な依頼に縛られず、Why から最善の一手を考える。
依頼が md ファイル（review / TODO / 改善要望リスト）にまとまっていても同じ。md に書かれているのは「依頼者の表面的な要望」であって、その裏のインテントを読み取り対話で引き出す。「やることが具体的だから skip」と判断しない — 具体的な解決策の裏に真の課題があり、別の解決策の方が良いかもしれない。
発火したら、いきなり Why 掘りや下の 5 セクションの要件定義に入らない。まず「今どのモードにいるか」を意識する。モードは 3 つ:
ゲートは 1 つだけ。設計・実装・変更という帰結ある行動（＝やり直しにコストがかかる動き）に入る手前で、どのモードで進めるかを依頼者と合意する。これ以外はゲートで止めない。特に次の非破壊な動きは、モード未確定でも止めない:
dialogue-principles skill を呼んでから議論に応じる帰結ある行動に入る手前で、AskUserQuestion で「対話モードで深掘る / 自走モードで進める」を出し、自分の見立てを推奨に置く。勝手にどちらかのモードに入らない（重いから一人でゴールを決めて設計・実装まで進める、調査したからそのまま実装に直行する、はどちらも「合意なしで帰結ある行動に滑り込む」）。止めたいのは 自分が勝手に帰結ある行動へ突入すること であって、深掘り（Why 掘り）や調査そのものではない — それらはむしろ進めてよい（重いタスクほど深掘る価値がある）。見立ての目安:
見立ては当てにいくものではなく外すことがある（機械的に見分けるのは難しい）。だから独断で決めず、見立てを述べて依頼者に確認する — この確認が見立てのブレを受け止める安全網。依頼者は自分の意図（探ってほしいのか、任せて進めてほしいのか）を分かっているので選べる。迷ったら対話モード側を推奨に置く（「簡単そうで難しい／指定された手段が最善でない」を取りこぼさないため）。
basic-design skill を挟まず slice-tdd skill での実装にそのまま渡す（最小合意を口頭で持って渡す）。要件定義.md は作らない。この時点で終わり — 下の「やること」以降のセクションは実行しないdialogue-principles skill を呼んでから、下の通常フローに進む（Why を掘り要件を固める）。対話モードで進めると決めた時点が、対話の規律を効かせ始める地点モード合意は一度きりではなく 再来しうる。例えば調査を挟んで前提が変わったり、進める中で「ここは一度立ち止まって対話したい」となれば、その時点でモードを合意し直す。固定ではなく、その時々で合意し直せる。
「誰が・何のために・何をしたいのか」を 1 文で書ける状態にする。形式は問わないが、最低限この 3 要素が揃うまで質問する:
例: 「運用管理者が、不正注文を早期に発見するために、注文レビュー画面で要確認の注文をまとめて見たい」
「なぜその機能が必要か」を 2-3 段階掘る。表面的な依頼の裏にある本当の課題を引き出す。
例:
→ ここまで掘ると、本当の課題が「月末の差し戻し負荷」だと分かる。レビュー画面が解決策の一つだが、他の解決策（自動承認の閾値調整、当日中の通知）もありえる。Why を掘らずに作ると、依頼者が思いついた表面的な解決策に縛られる。
「どうなったら完成と言えるか」を観測可能な形で書く。
E2E テストで検証可能なレベルにする。後で slice-tdd skill が E2E spec を書くとき、この Done を直接スペック文に変換できる粒度を目指す。
「今回はやらない」を明示することで、設計と実装の発散を防ぐ。例:
Done（達成したいこと）・スコープ外（今回やらないこと）に加えて、守るべき制約を洗い出す。制約は「絶対に踏み外せない条件」で、スコープ外とは性格が違う（スコープ外＝交渉可能な除外、制約＝非交渉のルール）。制約は他の決定（Done の粒度、解決策の選び方）を縛るので、先に効く前提として早めに拾う。この手順 5 という番号は文書上の並びであって洗い出す順番ではない — Why を掘る中で制約が見えたら、その場で拾って確認してよい（テンプレートの「5. 制約」セクションも文書レイアウト上の位置にすぎない）。
制約は技術に閉じない。次のような広い範囲から、該当するものだけ拾う（全項目を機械的に聞かない）:
引き出し方は制約の種類で変える:
依頼者が示す解決策（「○○の機能を作って」）と、Why を掘って出てきた真の課題が整合していないと感じたら、代案を提案する。一人前の開発者として「依頼通りに作る」だけが仕事ではない。Why から最善の一手を考えて、依頼者の指定した解決策が最適でないなら別案を出す。
例:
押し付けではなく選択肢として提示する。Why と整合してれば代案は不要、整合してない時だけ提案する。
代案を出すときは propose-options skill のフォーマット（複数案＋メリデメ＋推奨）に乗せる。
エンドユーザー価値を守るために、依頼者の発言を無批判に受け入れない。
依頼者の指摘や反論に「あ、確かに、そうですね」と即引き下がるのは迎合の一種。同意する前に:
賛成するなら自分の根拠を述べ、反対するなら根拠を示す。本当に依頼者の指摘が正しければ修正する。両立するなら追加質問する。
要件定義は対話駆動。インテント・Why・Done を引き出すには、以下を厳守する。
深い議論は 1 つずつ。複数を 1 メッセージに混ぜると依頼者が回答しづらい。軽い確認 (Yes/No 程度) なら複数 OK。
質問はクローズな選択肢で出すのを基本に。依頼者の負担が小さい。「3 案あります、どれが近いですか?」のような形。AskUserQuestion ツールが使える場面では使う。
議論の節目で「ここまでの理解はこうです、合ってますか?」を 依頼者が確認サインを出す前に こちら側から出す。節目の例:
「サマリ → 確認」を pattern 化する。依頼者が違和感を感じたタイミングで戻れる。
要件定義 md は 5 セクション (背景と動機 / ユーザーストーリー / Done / スコープ外 / 制約)。各セクションを埋め終わるごとに「このセクションで合っているか」を明示的に確認してから次へ。一気に全部書いてからレビューを求めない。
「たぶんこういう意図だろう」で進めない。不明点が出たらその場で質問。依頼者の沈黙を「OK」と解釈しない。
proactive な対話の型に加えて、依頼者が以下のサインを出した時は必ず「私の理解はこうです、合ってますか」と確認する:
認識合わせの形式: 「私の理解は次のとおりです: [箇条書きでサマリ]。合ってますか？ずれている点はありますか？」
要件の解釈や Done の定義に複数案がありえると感じたら、必ず propose-options skill を呼んで「複数案＋メリデメ＋推奨」のフォーマットで整理する。一案だけポンと出すのは禁止。
例:
要件が固まる前に「じゃあ画面はこういう構造で...」「DB に column 追加して...」と踏み込まない。それらは basic-design skill / slice-tdd skill の仕事。
ただし、制約（技術に限らず、コスト・期限・組織ルール等）は要件に影響するので、上の「制約（守るべき条件）を洗い出す」の通り引き出して要件に反映する。これは設計・実装の詳細に踏み込むこととは別（守るべき前提の確認であって、どう作るかの決定ではない）。
要件が固まったら docs/working/<title>/要件定義.md を新規作成する。<title> は機能を表すケバブケース（日本語可）。例:
docs/working/注文レビュー画面/要件定義.mddocs/working/顧客単位サマリ/要件定義.mdディレクトリ構成（基本設計フェーズで 基本設計.md が同ディレクトリに追加される）:
docs/working/<title>/
├── 要件定義.md ← この skill が作る
└── 基本設計.md ← basic-design skill が作る
要件定義.md の構成:
# <機能名> — 要件定義
> このドキュメントは進行中の設計メモ。実装後もそのまま残す（振り返り・PR レビューで参照される）。
> 削除のタイミング・要否は依頼者または外側の仕組みで別途判断する（あなたは削除しない）。
## 1. 背景と動機
[Why の掘り下げ結果]
## 2. ユーザーストーリー
- [誰が] が [何のために] [何をしたい]
## 3. Done（完了基準）
- [観測可能な完了条件 1]
- [観測可能な完了条件 2]
- ...
## 4. スコープ外
- [今回やらないこと 1]
- [今回やらないこと 2]
- ...
## 5. 制約（Constraints）
- [守るべき条件 1（種類: 技術 / 非機能 / セキュリティ / 資源・時間 / 組織）]
- [守るべき条件 2]
- ...
（該当する制約がなければ「特になし」と書く。空欄で飛ばさない — 後で再発見する事故を防ぐため）
- **D5**: skill-reviewer が違反パターンを検出する機能を持つ- **skill-reviewer が違反パターンを検出する機能を持つ** (= 内容で書く)### skill-reviewer の機能 の下に内容を書く)handoff-docs skill を呼んで、自己完結性の規律を効かせる。要件の議論が完全に固まってから書き起こす。途中段階で md にしない。理由: ドキュメントの構造が議論を縛り、未決論点の存在が見えにくくなる。
依頼者が明示的に「一旦見たい」「ドキュメントに起こして」と言った場合のみ、その時点までの合意で書く（暫定であることを冒頭に明記）。暗黙に「これで合意できたから書こう」と判断しない。
要件定義が固まったタイミングで、規模や複雑度を判断して「第三者レビューを入れる価値あり」と感じたら、依頼者に pre-implementation-reviewer subagent を呼ぶことを提案する。自動では呼ばない（毎回呼ぶと Opus コストが嵩む）、提案に留める。
判断基準:
提案の形式:
要件が固まりました → docs/working/<title>/要件定義.md
この要件は <理由> なので、pre-implementation-reviewer の第三者レビューを入れる価値ありそうです。呼びますか？
依頼者が「呼んで」と言ったら、Task ツールで pre-implementation-reviewer subagent を起動する。レビュー結果は依頼者と一緒に議論する材料として扱う（main session が機械的に対応/非対応を決めない）。
要件定義.md は別セッションのエージェントが読んで設計・実装に進む成果物。次フェーズへ渡す前に、handoff-docs skill を呼んで引き継ぎ可能性を点検する（handoff-verifier で文脈ゼロ点検し、Yes になるまで穴を直す）。
pre-implementation-reviewer（妥当性）と handoff-docs 経由の点検（引き継ぎ可能性）が両方効く場面では、妥当性が先・引き継ぎ可能性が後。中身の妥当性がまだ固まっていないのに引き継ぎ可能性を点検しても、中身が変われば書き直しになるため。
要件が固まり md に書き起こしたら、次のフェーズ（基本設計）に進む案内を出す:
要件定義が固まりました → docs/working/<title>/要件定義.md
このセッションのコンテキストはもう使わないので、節約したい場合は:
1. /clear でこのセッションをリセット
2. 新しい入力で次のメッセージを送ってください:
@docs/working/<title>/要件定義.md basic-design で設計を進めて
そのまま続けても問題ありません。
強制ではなく任意のガイド。設計 md があれば context 再現できるので、依頼者が選べばよい。