define

define

実装前の詳細な要件定義を行い、技術的制約・設計方針・実装仕様を明確化するためのスキル。

目的、ゴール

プロジェクトの新機能や改修について、計画立案に向けた要件定義を行う。ユーザーと要求・要件に関する共通認識を確立し、技術的制約、設計方針、実装仕様を定義し、実装の方向性を明確化する。

起動時の判断

ユーザーから機能の要望（新機能の追加・既存機能の改修・振る舞いの変更）を受けたら、実装に着手する前に本スキルを使う。明示起動（Claude では /define、Codex では $define）を待たない。

開始時に、実装前に要件定義を行うことと、その理由を1行でユーザーへ伝える。ユーザーが不要と答えた場合は本スキルを終了し、ユーザーの指示に従う。

次の場合は本スキルを使わない:

• 依頼文と既存コードから仕様が確定しており、未決の判断が残らない局所的な変更
• 原因が分かっていない不具合の調査が主題の依頼
• ユーザーが要件定義を経ずに実装することを明示している依頼

追加指示の扱い

ユーザーが引数として渡した要件・追加指示（Claude では /define の引数、Codex では $define の引数）は、本スキル内の他の方針より優先して適用する。ただし「ソースコード変更禁止」などの重要な制約に反する場合は、実行せず直ちに停止して確認を求める。追加指示には、要件の概要や背景情報、対象機能やシステム範囲、制約条件（技術的・ビジネス的）、参考情報やリファレンスURLが含まれる可能性が高い。引数が空の場合や明示起動されていない場合は、会話中のユーザーの要望とその経緯を入力として標準フローを実行する。

基本方針

• 事実ベース: 推測ではなく、技術的根拠に基づく定義
• ソースコード変更禁止: 実装ファイル・設定ファイルの変更は行わない（要件定義書の出力は除く）
• 正直な対応: 不明な点は無理に定義せず、必要な情報を確認
• 冷静な判断: ユーザーの要求を正当化せず、0から客観的に定義
• 非忖度: ユーザーに寄り添わず、技術的妥当性を優先（実装やテストの都合は技術的妥当性に含めない）
• 情報収集優先: 要件定義を実行し、結論を出す前にまずは質問等により情報を集める

実行手順

1. 現状調査の実行

情報収集に適した読み取り専用の機能を活用する。ライブラリ最新仕様の取得（context7）、Web 検索なども積極的に活用する。使用する機能の例:

• 既存コード・設定の確認、パターン検索、ディレクトリ構造・アーキテクチャの確認
• context7: フレームワーク・ライブラリの最新ドキュメント取得（利用可能な場合は率先して使う）

2. 初期分析とヒアリング

要求のあらゆる側面について、ユーザーとの共通認識が確立されるまで質問を繰り返す。

質問選定プロセス

正確な要件定義を行うために情報を網羅するには、多角的な視点から設計のツリーを枝分かれの先まで一つひとつたどり、決定事項間の依存関係を順番に解決していくことを念頭に置く。各ツリー上の不明点、懸念、調査するべき内容を10以上検討し、そのうちクリティカルなものをピックアップする。自己決定可能かつ、クリティカルでないものは自己決定する。

• 要求
• 要件
• 制約条件
• 方針
• アーキテクチャ、設計方針
• 責務境界
• 名前空間
• 結合
• ビジネスルール、業務条件
• 連携

質問を避けるべき内容:

• 後から容易に変更可能な実装詳細
• 一般的なベストプラクティスで解決できる内容
• コード調査で判明する既存の技術スタック情報
• 安易なセキュリティ、監査、パフォーマンス関連の質問。クリティカルでない場合や、一般的なベストプラクティスで解決できる場合は避ける

質問提示形式

質問は利用可能な質問機能を用い、その機能が許容する質問数ごとに質問を行う。人間は多数の質問を読解し回答するのが難しい上、序盤の質問が後半の質問を無意味にする場合もあるため、一度に全てを質問しない。意味のある単位で質問を積み重ねて、合意形成を行う。各質問について以下の情報を含める:

• 質問内容: 具体的で明確な質問文
• 背景説明: 質問の前提背景を含めた質問（ユーザーはプロジェクトの詳細は知らない前提とする）
• 回答例: 想定される回答パターンと、それぞれが設計に与える影響（推奨回答には必ず（推奨）と明記する）

また最後には質問の想定解答例を提示して、ユーザーがコピペで回答しやすいようにする。

重要事項

ユーザーから明確な回答を得るまで次のステップに進まない。質問内容自体への指摘があった場合は、その内容を踏まえて質問を再検討する。

3. 回答を元に再度調査

1. の現状調査と同様に、回答を元に必要に応じてさらに詳細を確認する。

4. 要件定義書の作成

ユーザーの回答を受けて、以下の構成で要件定義書を作成する:

要件定義構成:

• 📋 要求概要
• 🔍 現状分析（既存システム調査結果）
• 🎯 機能要件
• ⚙️ 非機能要件: 利用者ができることを狭める制約（上限・禁止・必須の手順・情報の省略）には、根拠（要求・外部仕様・確かめた技術的限界。安全や認可なら誰から何を守るか）を添える
• 🏗️ 技術仕様
• ⚖️ 判断の配置（LLM を組み込む機能の場合）: 判断ごとに（検証での判定を含む）、LLM とコードのどちらが担うかと、コードが担う場合はその理由（安全・認可・不可逆な副作用の保証、または閉じた集合の検査）を表で示す。閉じた集合とは、ID・enum・schema・DB の行・権限・状態遷移のように列挙で閉じる対象を指す。理由を書けない判断は LLM に任せる
• ✅ 受け入れ条件: 本セクションのみで要件の全体像を把握できるようにする。方針・実装概要・完了基準を簡潔に記載し、他セクションを読まなくても「何をどう実装すれば完了か」が判断できる内容とする
• 🚧 スコープ外: 議論の中で明確に「今回は対応しない」と決定した事項を列挙。将来的な対応可能性や除外理由も簡潔に記載
• 🧪 テスト要件
• ❓ 追加の不明点と要確認事項

完了前セルフレビュー:

要件定義書を確定する前に、次の3問に文章で答え、その回答を要件定義書の末尾に含める（採点が目的ではなく、出力を確定する前に自身の行いを客観視するための強制点である）。

1. このタスクで確認できなかった事実・未検証の前提は何か
2. ユーザーの想定・期待に反する事実を見つけたのに、書いていないものはないか（あれば今、本文に追記する）
3. 出力のうち、事実ではなく推測に基づく箇所はどこか

要求タイプ別対応:

• 新機能追加 → 既存アーキテクチャとの統合方針を設計
• 性能改善 → ボトルネック分析と改善策を定義
• セキュリティ → 脅威分析と対策要件を定義
• リファクタリング → 改善対象と方針を定義

重要な制約

• ソースコード・実装ファイル・設定ファイルの編集・作成・削除は禁止
• 要件定義書の Markdown 出力は、本スキルの目的として許可する
• 実装は行わない（要件定義のみ）
• 回答例には、必ず推奨の方針を明示する
• 技術的に不可能な要求は明確に指摘
• ユーザーの要求を正当化しない — 0から客観的に定義
• 技術優先 — ユーザーへの配慮より技術的妥当性を重視
• 不明点は積極的に質問して明確化

最終対応

プロジェクトの適切なフォルダ配下に、Markdown で作成した要件定義書を配置すること。そのファイル名はユーザーへ通知すること。また、要件定義書の中は適切なタイミングで mermaid を利用すること。本スキルの成果物は要件定義書であり、実装計画ではない（計画を起こす工程は後続で行い、その計画のレビューには review-plan を使う）。