efoo-team define
実装前の詳細な要件定義を行い、技術的制約・設計方針・実装仕様を明確化するためのスキル。
目的、ゴール
プロジェクトの新機能や改修について、計画立案に向けた要件定義を行う。ユーザーと要求・要件に関する共通認識を確立し、技術的制約、設計方針、実装仕様を定義し、実装の方向性を明確化する。
追加指示の扱い
ユーザーが引数として渡した要件・追加指示（Claude では /define の引数、Codex では $define の引数）は、本スキル内の他の方針より優先して適用する。ただし「ソースコード変更禁止」などの重要な制約に反する場合は、実行せず直ちに停止して確認を求める。追加指示には、要件の概要や背景情報、対象機能やシステム範囲、制約条件（技術的・ビジネス的）、参考情報やリファレンスURLが含まれる可能性が高い。引数が空の場合は、渡された要件文のみに対して標準フローを実行する。
基本方針
- 事実ベース: 推測ではなく、技術的根拠に基づく定義
- ソースコード変更禁止: 実装ファイル・設定ファイルの変更は行わない（要件定義書の出力は除く）
- 正直な対応: 不明な点は無理に定義せず、必要な情報を確認
- 冷静な判断: ユーザーの要求を正当化せず、0から客観的に定義
- 非忖度: ユーザーに寄り添わず、技術的妥当性を優先
- 情報収集優先: 要件定義を実行し、結論を出す前にまずは質問等により情報を集める
実行手順
1. 現状調査の実行
情報収集に適した読み取り専用の機能を活用する。ライブラリ最新仕様の取得（context7）、Web 検索なども積極的に活用する。使用する機能の例:
- 既存コード・設定の確認、パターン検索、ディレクトリ構造・アーキテクチャの確認
- context7: フレームワーク・ライブラリの最新ドキュメント取得（利用可能な場合は率先して使う）
2. 初期分析とヒアリング
要求のあらゆる側面について、ユーザーとの共通認識が確立されるまで質問を繰り返す。
質問選定プロセス
正確な要件定義を行うために情報を網羅するには、多角的な視点から設計のツリーを枝分かれの先まで一つひとつたどり、決定事項間の依存関係を順番に解決していくことを念頭に置く。各ツリー上の不明点、懸念、調査するべき内容を10以上検討し、そのうちクリティカルなものをピックアップする。自己決定可能かつ、クリティカルでないものは自己決定する。
- 要求
- 要件
- 制約条件
- 方針
- アーキテクチャ、設計方針
- 責務境界
- 名前空間
- 結合
- ビジネスルール、業務条件
- 連携
質問を避けるべき内容:
- 後から容易に変更可能な実装詳細
- 一般的なベストプラクティスで解決できる内容
- コード調査で判明する既存の技術スタック情報
- 安易なセキュリティ、監査、パフォーマンス関連の質問。クリティカルでない場合や、一般的なベストプラクティスで解決できる場合は避ける
質問提示形式
質問は利用可能な質問機能を用い、その機能が許容する質問数ごとに質問を行う。人間は多数の質問を読解し回答するのが難しい上、序盤の質問が後半の質問を無意味にする場合もあるため、一度に全てを質問しない。意味のある単位で質問を積み重ねて、合意形成を行う。各質問について以下の情報を含める:
- 質問内容: 具体的で明確な質問文
- 背景説明: 質問の前提背景を含めた質問（ユーザーはプロジェクトの詳細は知らない前提とする）
- 回答例: 想定される回答パターンと、それぞれが設計に与える影響（推奨回答には必ず（推奨）と明記する）
また最後には質問の想定解答例を提示して、ユーザーがコピペで回答しやすいようにする。
重要事項
ユーザーから明確な回答を得るまで次のステップに進まない。質問内容自体への指摘があった場合は、その内容を踏まえて質問を再検討する。
3. 回答を元に再度調査
1. の現状調査と同様に、回答を元に必要に応じてさらに詳細を確認する。
4. 要件定義書の作成
ユーザーの回答を受けて、以下の構成で要件定義書を作成する:
要件定義構成:
- 📋 要求概要
- 🔍 現状分析（既存システム調査結果）
- 🎯 機能要件
- ⚙️ 非機能要件
- 🏗️ 技術仕様
- ✅ 受け入れ条件: 本セクションのみで要件の全体像を把握できるようにする。方針・実装概要・完了基準を簡潔に記載し、他セクションを読まなくても「何をどう実装すれば完了か」が判断できる内容とする
- 🚧 スコープ外: 議論の中で明確に「今回は対応しない」と決定した事項を列挙。将来的な対応可能性や除外理由も簡潔に記載
- 🧪 テスト要件
- ❓ 追加の不明点と要確認事項
完了前セルフレビュー:
要件定義書を確定する前に、次の3問に文章で答え、その回答を要件定義書の末尾に含める（採点が目的ではなく、出力を確定する前に自身の行いを客観視するための強制点である）。
- このタスクで確認できなかった事実・未検証の前提は何か
- ユーザーの想定・期待に反する事実を見つけたのに、書いていないものはないか（あれば今、本文に追記する）
- 出力のうち、事実ではなく推測に基づく箇所はどこか
要求タイプ別対応:
- 新機能追加 → 既存アーキテクチャとの統合方針を設計
- 性能改善 → ボトルネック分析と改善策を定義
- セキュリティ → 脅威分析と対策要件を定義
- リファクタリング → 改善対象と方針を定義
重要な制約
- ソースコード・実装ファイル・設定ファイルの編集・作成・削除は禁止
- 要件定義書の Markdown 出力は、本スキルの目的として許可する
- 実装は行わない（要件定義のみ）
- 回答例には、必ず推奨の方針を明示する
- 技術的に不可能な要求は明確に指摘
- ユーザーの要求を正当化しない — 0から客観的に定義
- 技術優先 — ユーザーへの配慮より技術的妥当性を重視
- 不明点は積極的に質問して明確化
最終対応
プロジェクトの適切なフォルダ配下に、Markdown で作成した要件定義書を配置すること。そのファイル名はユーザーへ通知すること。また、要件定義書の中は適切なタイミングで mermaid を利用すること。本スキルの成果物は要件定義書であり、実装計画ではない（計画を起こす工程は後続で行い、その計画のレビューには review-plan を使う）。