# Pre Define

> Only use when the user explicitly invokes /pre-define (or $pre-define in Codex). Never auto-invoke. ユーザーの曖昧な要望を、詳細な要件定義（/define）に渡せる具体的な入力へ洗練させるためのスキル。仕様決定や要件定義そのものは行わず、関連する既存仕様を調査したうえで平易な質問を重ね、コミュニケーションの齟齬をなくすことを目的とする。

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

---


# pre-define

ユーザーの曖昧な要望を、`/define` に渡せる具体的な入力へ洗練させるためのスキル。

## 目的

ユーザーの曖昧な要望を、`/define` に渡せる具体的な入力に洗練させる。具体的な仕様決定や要件定義そのものは行わず、要望とその背景を明確化し、ユーザーとの間のコミュニケーションの齟齬をなくすことを目的とする。

## 追加指示の扱い

ユーザーが引数として渡した要望・追加指示（Claude では `/pre-define` の引数、Codex では `$pre-define` の引数）は、本スキル内の他の方針より優先して適用する。ただし「仕様を決めない」「実装しない」などの重要な制約に反する場合は、実行せず直ちに停止して確認を求める。追加指示には、曖昧な要望・リクエスト、実現したい機能の概要、目的や背景の断片的な情報が含まれる可能性が高い。引数が空の場合は、渡された要望文のみに対して標準フローを実行する。

## 基本方針

- **まず調査**: 勝手に推論せず、関連する既存仕様を調査してから質問する
- **仕様決定はしない**: 具体的な設計や実装方法は `/define` に委ねる
- **ユーザー視点**: 技術用語や専門知識を前提とせず、平易な言葉で質問する
- **具体化の支援**: ユーザーが自分の要望を言語化できるよう導く

## 実行手順

### 1. 関連仕様の調査

ユーザーの要望からキーワードを抽出し、関連しそうな既存仕様を調査する。調査は読み取り専用で行う。

**調査に用いる機能の例:**

- 既存コード・設定の確認、パターン検索、ディレクトリ構造・アーキテクチャの確認

**調査対象:**

- 要望に含まれるキーワードに関連するファイル
- 類似する既存機能
- 関連するデータモデル・スキーマ
- 対象となりそうな画面・コンポーネント

### 2. 仕様の概要提示と確認

調査結果を元に、関連しそうな仕様の概要を**端的に**提示し、ユーザーにどの仕様のことを指しているのかを確認する。

**提示形式:**

```markdown
## 🔍 関連しそうな仕様の調査結果

要望「[要望の要約]」に関連する既存仕様を確認しました：

| No | 仕様・機能 | 概要 | 関連ファイル |
|----|----------|------|-------------|
| 1 | [名称] | [1行での説明] | [ファイルパス] |
| 2 | [名称] | [1行での説明] | [ファイルパス] |
| 3 | [名称] | [1行での説明] | [ファイルパス] |

---

この中で、あなたが指している仕様はどれですか？あるいは、これらすべてとは別の新しい仕様ですか？

回答例:
- No.1の「〇〇機能」のことです
- No.2とNo.3の両方に関連します
- これらとは別の新しい仕様です
```

**重要:**

- 概要は1行で簡潔に
- 技術詳細は省き、「何をしているものか」だけを説明
- 最大5件までに絞り込み

**重要事項**

ユーザーが対象を特定するまで、次のステップに進んではならない。対象が既存仕様なのか、新しい仕様なのかを明確にする。

### 3. 要望の分析

対象が特定できたら、改めて要望を分析し、曖昧な点を特定する:

- **何を作りたいのか**: 目的・ゴールが明確か
- **何をしたいのか**: 機能・操作の具体性
- **制約や条件**: あるべき条件、避けるべきこと
- **前提情報**: 対象仕様との関係、変更範囲など

### 4. 質問による明確化

曖昧な点について、利用可能な質問機能を用いて最大4つの質問を行う。

**質問の設計方針**

- 技術用語を避け、ユーザーの言葉で回答できるようにする
- 回答例を提示し、選びやすくする
- 手順2で特定した仕様を踏まえた質問にする

**質問すべき典型項目**

| カテゴリ | 質問例 |
|---------|--------|
| 目的 | 何のためにこの変更が必要ですか？（例：業務効率化、UX改善） |
| 対象 | どの画面・機能・データに関連しますか？ |
| 操作 | ユーザーは具体的に何をしたいですか？（例：ボタン押下、データ入力） |
| 条件 | どのような条件の時に動作すべきですか？ |
| 優先順位 | どの機能が最も重要ですか？ |

避けるべき質問:

- 技術的な実装方法（例：どのライブラリを使うか）
- 細かい仕様詳細（例：エラーメッセージの文言）
- `/define` で決定すべき事項（例：アーキテクチャ方針）

**質問提示形式**

各質問について以下の情報を含める:

- **質問内容**: 具体的で明確な質問文
- **背景説明**: なぜこの情報が必要なのか
- **回答例**: 想定される回答パターン。推奨には（推奨）と明記

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

**重要事項**

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

### 5. ブラッシュアップ結果の出力

質問の回答を元に、以下の形式で要望を具体化して提示する。

```markdown
## 📝 ブラッシュアップされた要望

### 対象仕様
[特定した既存仕様 または 新規仕様]

### 目的
[明確化された目的]

### 機能概要
[何をする機能かの簡潔な説明]

### 想定されるユースケース
[ユーザーが何をしようとしているかの具体例]

### 関連範囲
[対象となる画面・機能・データなど]

### 既知の制約・条件
[判明している条件や制約]

---

この要望を `/define` に渡して、詳細な要件定義を進めることができます。
```

## 重要な制約

- **推測で埋めない**: 不明な点は「不明」と明記する
- **仕様を決めない**: 実装方法や詳細仕様は決定しない
- **実装しない**: あくまで入力の具体化のみ行い、ファイルの編集・作成・削除は行わない
- **技術用語に頼らない**: ユーザーが理解できない言葉は使わない
- **まず調査から**: 質問前に必ず関連仕様の調査を行う