melech-distill-need について
ユーザーの文字どおりの依頼と実際の目的を切り分けるエージェント向けスキルです。背景や既存の選択肢を確認し、実装前に複数の方針を示して選択を促します。
主な機能
- 01依頼と本来の目的を区別
- 02少数の質問でニーズを明確化
- 03制約と既存の解決策を確認
- 04選択肢を比較して方針を提案
- 05実装前にユーザーの確認を待機
活用シーン
- 01新機能の開発が必要か判断
- 02既存の製品やプロセスから代替案を探す
- 03コーディング前に要件と成功基準を明確化
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/melech-distill-needを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
evals/evals.jsonevals/fixtures/support-product/product-signals.mdREADME.mdrouting.ts詳細
ニーズを見極める
ユーザーの要望は聖典ではありません。通常は解決策の提案です。
多くの場合、ユーザーは次のことを把握していません。
- 自分が具体的に何を求めているのか
- 実際に何が必要なのか
- 既存の解決策で、すでに要望が満たされること
単純な AI は言葉どおりに的を射ようとします。あなたの役割はニーズを見極めることです。そのうえで、目標を達成する方法を提示します。それは、ユーザーが名前を挙げた要望とはまったく異なるものかもしれません。
よくあるパターン：
- 要望：「もっと速い馬が必要です。」
- 見極めたニーズ：B地点にもっと早く着くこと。
- よりよい方法：車を使うこと。職場が3メートル先なら歩くこと。
達成しようとしていること
次の項目を切り分けます。
- 文字どおりの要望 — 名前が挙がった機能、ツール、実装
- 実際のニーズ／目標 — ユーザーが満足するために実現すべきこと
- コンテキスト — 問題を大幅に縮小したり、変えたりする制約
- よりよい方法 — 再利用、プロセスの変更、作らない選択肢を含む
そのうえで、ユーザーに決めてもらいます。見極めたニーズを示し、好みの解決策に黙って置き換えてはいけません。
ワークフロー
1. 提案された解決策を捉える
文字どおりの要望を一行で言い換えます。それを使命ではなく、解決策の提案として示します。
2. 目標を見極める
次の点を明らかにするため、必要最小限の質問をします。
- 完了時に何が実現していればよいか
- なぜ今それを望んでいるのか
- 何も変えなければどのような問題が起きるか
影響の大きい質問を1～3個に絞ります。分岐が明確なら、まとめて尋ねます。 長々と聞き取りを続けないでください。
3. 解決策を左右するコンテキストを確認する
解決策の種類を変える事実がないか確認します。
- 制約、距離、頻度、緊急性、規模
- 誰が問題を感じているか
- その人の環境では「完了」が何を意味するか
回答を変えるようなコンテキストが不足している場合は、尋ねてください。 リポジトリや製品から安全に推測できる場合は、前提を明示します。
4. 既存の解決策を確認する
新しいものを考案する前に、次を確認します。
- コードベース、製品、プロセスに、すでに使えるものがないか
- それを再発明しようとしていないか
- さらに悪いことに、四角形として再発明しようとしていないか
- 既知のライブラリ、ツール、サービスで実現できそうなら、ユーザーに伝える
ニーズを満たせるなら、ゼロから作るよりも統合、再利用、設定を優先します。
5. 解決策の種類を提示する
同じ目標を達成する、意味のある違いがある方法を1～3個提示します。少なくとも次の選択肢を検討します。
- 作らない／手作業／プロセス／既存ツール
- 既存のものへの最小限の変更
- 名前が挙がった要望（または整理した要望）。まだ採用する価値がある場合
各方法について、目標への適合度、コスト、妥協点、選ぶべき状況を説明します。 1つを推奨し、選択はユーザーに委ねます。
6. 引き継ぐ
- ニーズがなくなった場合、または「歩く」案が勝った場合 → そこで止めます。計画もコードも不要です。
- それでも何かを作る必要がある場合 → コンセプトのすり合わせと、最小限で役立つ方法の選定に進みます。
- ユーザーがすでに方針を決めていて、穴を指摘してほしいだけの場合 → その方針を検証します。
質問の絞り込み
次の点を変える質問だけをします。
- 目標の定義
- 解決策の種類
- 作ることが妥当かどうか
- 既存のものですでに解決できるかどうか
実装上の細かなことは尋ねないでください。要件をでっち上げて、検討を複雑にしてはいけません。
これが最初の見極めです。結論は作らないでもかまいません。
やること／やらないこと
やること：「もっと速い馬をご要望ですね。目標は、もっと早く職場に着くことのようです。職場まで3メートルなら、馬を育てるより歩くほうがよさそうです。本当の制約が天候、立場、荷物のどれかなら、教えてください。そこから改めて検討します。」
**やらないこと：**馬を速くするサービスの設計を始める。
やること：「新しい通知マイクロサービスをご要望ですね。ニーズは、ユーザーが請求の失敗に気づけるようにすることのようです。既存のメールとアプリ内バナーで対応できるかもしれません。選択肢は、（1）バナーを再利用する、（2）現在の通知機能を拡張する、（3）新しいサービスを作る、です。（1）をおすすめします。」
**やらないこと：**文中に出てきた名詞だからという理由で、マイクロサービスのひな形を作り始める。
やること：「文字どおりの要望は、カスタム RBAC エンジンです。見極めたニーズは、管理者以外に管理画面を表示しないことです。2つのルートにロールチェックを追加するだけで十分かもしれません。ポリシーフレームワークを考案する前に、目標を確認させてください。」
**やらないこと：**名前が挙がったアーキテクチャを神聖視する。
**やること：**推奨案を示してから、ユーザーが選ぶのを待つ。
**やらないこと：**ユーザーの要望をお気に入りの解決策に黙って置き換え、コーディングを始める。