pre-define

pre-define

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

目的

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

追加指示の扱い

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

基本方針

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

実行手順

1. 関連仕様の調査

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

調査に用いる機能の例:

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

調査対象:

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

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

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

提示形式:

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

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

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

---

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

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

重要:

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

重要事項

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

3. 要望の分析

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

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

4. 質問による明確化

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

質問の設計方針

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

質問すべき典型項目

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

避けるべき質問:

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

質問提示形式

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

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

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

重要事項

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

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

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

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

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

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

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

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

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

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

---

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

重要な制約

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