SKILL.md
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` に渡して、詳細な要件定義を進めることができます。重要な制約
- 推測で埋めない: 不明な点は「不明」と明記する
- 仕様を決めない: 実装方法や詳細仕様は決定しない
- 実装しない: あくまで入力の具体化のみ行い、ファイルの編集・作成・削除は行わない
- 技術用語に頼らない: ユーザーが理解できない言葉は使わない
- まず調査から: 質問前に必ず関連仕様の調査を行う