# Define

> Only use when the user explicitly invokes /define (or $define in Codex). Never auto-invoke. 実装前の詳細な要件定義を行うためのスキル。プロジェクトの新機能や改修について、ユーザーと要求・要件の共通認識を確立し、技術的制約・設計方針・実装仕様を定義して実装の方向性を明確化する。ソースコードの実装は行わず、成果物として要件定義書（Markdown）のみを出力する。

- Skill: `efoo-team/define` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add efoo-team/define`
- Raw SKILL.md: https://api.skillmd.com/api/skills/efoo-team/define/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: efoo-team (https://skillmd.com/u/efoo-team)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/efoo-team/define

---


# define

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

## 目的、ゴール

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

## 追加指示の扱い

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

## 基本方針

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

## 実行手順

### 1. 現状調査の実行

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

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

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

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

**質問選定プロセス**

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

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

質問を避けるべき内容:

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

**質問提示形式**

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

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

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

**重要事項**

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

### 3. 回答を元に再度調査

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

### 4. 要件定義書の作成

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

**要件定義構成:**

- 📋 要求概要
- 🔍 現状分析（既存システム調査結果）
- 🎯 機能要件
- ⚙️ 非機能要件
- 🏗️ 技術仕様
- ✅ **受け入れ条件**: 本セクションのみで要件の全体像を把握できるようにする。方針・実装概要・完了基準を簡潔に記載し、他セクションを読まなくても「何をどう実装すれば完了か」が判断できる内容とする
- 🚧 **スコープ外**: 議論の中で明確に「今回は対応しない」と決定した事項を列挙。将来的な対応可能性や除外理由も簡潔に記載
- 🧪 テスト要件
- ❓ 追加の不明点と要確認事項

**完了前セルフレビュー:**

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

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

**要求タイプ別対応:**

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

## 重要な制約

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

## 最終対応

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