decision-helper

decision-helper スキルの概要

decision-helper スキルは、意思決定支援のための軽量な構造化プロンプトです。AI に漠然とおすすめを聞くのではなく、pros/cons、decision matrix、cost-benefit analysis、SWOT、ICE といった明示的なフレームワークで選択肢を比較するよう促します。単なる素早い意見ではなく、根拠のある判断がほしい場面で decision-helper は特に役立ちます。

decision-helper が最も得意なこと

decision-helper が向いているのは、次のようなケースです。

• すでに有力な選択肢が 2〜5 個ある
• アイデア出しよりもトレードオフ比較が重要
• AI に「どう考えたか」の構造を見せてほしい
• チームやステークホルダーのレビューに回せる再利用可能な形式が必要

特に、プロダクト判断、採用、ツール選定、優先順位付け、「どの進路を取るべきか」といった問いに相性が良いです。

decision-helper スキルを入れるべき人

decision-helper が最もフィットするのは、散らかった選択肢を構造化された提案に落とし込む機会が多い人です。

• ツールや計画を比較する創業者・オペレーション担当者
• 施策の優先順位を決める PM
• 実装方針を評価するエンジニア
• 提案メモを作るアナリスト
• 決めきれずに止まっている個人ユーザー

一方で、ゼロから選択肢を生み出すこと自体が主な課題なら、これ単体ではやや不十分です。

解決してくれる job-to-be-done

本当に解決したい仕事は「代わりに決めてほしい」ではありません。むしろ次の 4 点です。

1. 何を決めるのかを明確にする
2. 重要な基準で選択肢を比較する
3. トレードオフとリスクを表に出す
4. 説明可能な推奨案を作る

ここが、単なる「何を選ぶべき？」という汎用プロンプトとの大きな違いです。

普通のプロンプトと違う decision-helper の特徴

普通のプロンプトは、好みベースの答えを返しがちです。decision-helper skill は、次のような再現性のある構造を促します。

• decision statement
• option ごとの pros and cons
• risk と effort
• weighted matrix
• recommendation と reasoning

この構造自体はシンプルですが、一貫性をかなり高められますし、弱い前提や雑な判断にも気づきやすくなります。

decision-helper スキルの使い方

decision-helper のインストール情報

skills 対応ワークフローを使っているなら、decision-helper はソースリポジトリからインストールできます。

npx skills add Shubhamsaboo/awesome-llm-apps --skill decision-helper

インストール後にまず確認すべきファイルは次です。

• awesome_agent_skills/decision-helper/SKILL.md

このスキルはドキュメントのみで構成されています。スキルフォルダ内に helper script、resource file、reference data はありません。つまり、価値の大半は「どれだけ良い形で意思決定の条件を渡せるか」にかかっています。

使う前に最初に読むべきファイル

まずは SKILL.md を開き、特に次の項目を見てください。

• When to Apply: 自分のケースに合うか確認する
• Decision Frameworks: どの分析モードを使うべきか選ぶ
• Output Format: 期待される出力構造を把握する

リポジトリ側のサポート範囲はかなり小さいため、長い repo ツアーは不要です。まず試してみるまでのハードルは低めです。

decision-helper をうまく機能させるために必要な入力

decision-helper usage の質は、入力次第で大きく変わります。最低限、次の情報を入れてください。

• 何を決めるのか
• 比較する選択肢
• 判断基準
• 重み付けや優先順位
• 大きな制約条件
• スケジュール、予算、リスク許容度
• 何をもって成功とするか

弱い入力:
“Should I use tool A or tool B?”

強い入力:
“Help me decide between Postgres, DynamoDB, and MongoDB for a SaaS app expecting 50k MAU, small ops team, heavy read traffic, moderate write volume, budget sensitivity, and a preference for low operational overhead. Weight reliability 35%, developer speed 25%, cost 20%, analytics flexibility 20%.”

曖昧な目的を強いプロンプトに変える

decision-helper skill の実用的なプロンプトテンプレートは次のとおりです。

1. 何を決めるのかを書く。
2. 選択肢を列挙する。
3. 基準と重みを示す。
4. 制約条件と背景を加える。
5. フレームワークに基づく recommendation を求める。

例:

“Use the decision-helper skill to evaluate whether our team should build in-house, buy a SaaS product, or outsource implementation for customer support analytics. Use a decision matrix plus pros/cons. Criteria: time-to-value 30%, long-term cost 25%, customization 20%, maintenance burden 15%, security/compliance 10%. Budget is capped, team size is 4 engineers, and we need an MVP in 6 weeks. End with a recommendation, key risks, and what would change the decision.”

decision-helper で適切なフレームワークを選ぶ

このスキルには複数のフレームワークがありますが、向いている状況はそれぞれ異なります。

• Pros/Cons Analysis: トレードオフが少ないシンプルな意思決定向け
• Decision Matrix: 基準に重みを付けて比較したいとき向け
• Cost-Benefit Analysis: コストと価値をある程度見積もれる場合向け
• SWOT Analysis: 戦略判断や市場に関わる選択向け
• ICE Framework: 優先順位付け、特に施策や実験の比較向け

指定しないと、モデルは汎用的な比較に流れがちです。より良い decision-helper usage にしたいなら、使うフレームワークを明示するのが有効です。

当てずっぽうを減らす実践的な進め方

おすすめの進行順は次のとおりです。

1. まずモデルに、意思決定内容と前提を言い換えさせる
2. 足りない判断基準を洗い出させる
3. 重みを追加・修正する
4. 構造化比較を実行する
5. 最終 recommendation を求める
6. どんな新しい証拠があれば recommendation が覆るか聞く

こうしておくと、悪い前提のまま作られた matrix による「もっともらしい精密さ」を避けやすくなります。

出力はどんな形になるべきか

元のスキルでは、次のような markdown 構造が推奨されています。

• decision statement
• options
• option ごとの pros and cons
• risk と effort のラベル
• weighted scoring を含む decision matrix
• recommendation

この出力形式が便利なのは、説明的な分析と最終判断を分けて見られる点です。もし model が matrix や criteria を省いたら、スキルの形式で再生成するよう求めてください。

criteria と重みを自分で足すべきタイミング

まだ課題の輪郭出しをしている段階でない限り、criteria をすべて model 任せにしないほうがよいです。実務の意思決定では、たいてい「ユーザー側で重み付けを入れること」が一番効きます。

答えを変えやすい criteria の例:

• implementation time
• reversibility
• operating cost
• team expertise
• compliance risk
• long-term flexibility
• stakeholder buy-in

影響の大きい意思決定なら、ざっくりした重みでもゼロよりずっとましです。

decision-helper の出力品質を大きく上げるコツ

より良い decision-helper guide の結果を得るには、次を意識してください。

• 選択肢は現実的な候補に絞る
• 採点前に「何が good なのか」を定義する
• 絶対条件と好みを分ける
• スコアだけでなく不確実性メモも求める
• 既知の事実ではなく推定に頼っている箇所を示させる

このスキルは、比較対象が明確で、範囲がきちんと区切られた意思決定で最も力を発揮します。

decision-helper スキル FAQ

自分でプロンプトを書けるなら、decision-helper を入れる価値はある？

あります。特に、同種の意思決定を何度も行い、一貫性がほしいなら有効です。主な価値は、隠れたロジックや特別なツールではなく、criteria・trade-off・recommendation の形式を明示しやすい「出来合いの型」があることです。すでに社内で強い意思決定テンプレートを使っているなら、上乗せ効果は小さくなります。

decision-helper は初心者にも向いている？

はい。decision-helper for Decision Support は、使うフレームワークが馴染みやすく、出力形式も確認しやすいため、初心者にも扱いやすいです。初心者がハマりやすいのは、文脈をほとんど渡さないことと、出てきた recommendation を信じすぎることです。

decision-helper が向かない場面は？

次のようなケースでは decision-helper は見送ったほうがよいです。

• 評価よりも、まず選択肢の新規発想が必要
• 実質的に選択肢が 1 つしかない
• 判断が model の持たない proprietary data に依存する
• criteria をまったく見積もれず、scoring が完全に形だけになる
• 法務・医療・金融など、専門領域の固有判断が必要

こうした場合は、decision engine としてではなく、論点整理の補助として使うのが現実的です。

汎用的な analysis prompt と比べてどう違う？

汎用 prompt でも、一度きりならそこそこ良い答えが返ることはあります。ですが、decision-helper skill が強いのは次のような場面です。

• 形式を毎回そろえたい
• 意思決定ごとに比較可能な出力がほしい
• criteria と weights を見える形にしたい
• チームレビューしやすくしたい

その代わり、探索寄りの課題に対しては、少し硬く感じることがあります。

decision-helper は自動で決めてくれる？

いいえ。意思決定を整理し、最終的に recommendation まで出すことはありますが、その質は criteria、inputs、constraints に強く依存します。最終判断の責任はあくまでユーザー側にあります。

decision-helper スキルを改善する方法

decision-helper に渡す材料を良くする

最も速く効く改善は、prompt を長くすることではなく、入力の質を上げることです。次を足してください。

• 明確な option 名
• 測定可能な criteria
• 既知の制約条件
• 絶対に避けたい deal-breaker
• おおよその weights
• なぜ今この意思決定が重要なのかという背景

これらがないと、model は空白を汎用的な前提で埋めてしまいます。

最もよくある失敗パターンを避ける

decision-helper usage で最大の失敗パターンは、「見た目は整っているのに中身の基準や重みが弱い matrix」による偽の客観性です。これを防ぐには、次のように聞いてください。

• “Which criteria are missing?”
• “Which scores are low-confidence?”
• “What assumption most affects the ranking?”

こうすることで、出力が“整った当て推量”ではなく、意思決定支援として使えるものに変わります。

初回比較のあとに sensitivity analysis を求める

強い follow-up prompt の例:

“Re-run the decision matrix and show how the ranking changes if cost matters more, if speed matters more, and if long-term flexibility matters more.”

これは decision-helper の結果を改善するうえで非常に有効です。実際の意思決定は、1〜2 個の不安定な前提で結論がひっくり返ることが少なくないためです。

recommendation と不確実性を分けて出させる

最初の回答が自信満々すぎると感じたら、次の 4 点を分けて出すよう求めてください。

• recommendation
• 未解決の不確実性の上位項目
• どんな証拠があれば結論が変わるか
• 不確実性を減らす軽量な test は何か

こうすると、段階的に進める意思決定、pilot、experiment の場面でも使いやすくなります。

一発採点ではなく反復で使う

質の高い decision-helper install の成果は、たいてい 2 ラウンドで生まれます。

1. まず意思決定の構造を作る
2. その後、より良い入力で scoring を磨く

最初の matrix を最終版だと思わないでください。まずは不足情報をあぶり出し、そのうえで再度 analysis を回す。この反復こそが、このスキルの価値が最も出る使い方です。