creative-problem-solver

創造的問題解決

目的：戦略上の選択肢がまだ確定していないとき、現行の案を大きく異なる候補の道筋へと発展させ、実際に残った案を5段階のポートフォリオにまとめ、人間の選択を待ちます。

有効化の境界

暗黙の呼び出しは有効です。ホストによる読み込みは、ポートフォリオ作成の許可を意味しません。ポートフォリオのルートには、未解決の戦略上の選択肢と、相違のある案を求める依頼の両方が必要です。難しさ、不確実さ、創造性に関する表現、名前だけの言及、メタ的な言及だけでは不十分です。

有効化する場合

• ユーザーが選択肢、代替案、トレードオフ、新しい視点、捉え直し、戦略ポートフォリオ、または「ほかに試せることはありますか？」を求めている場合。
• 同じ方法での試みが繰り返し失敗し、大きく異なるアプローチを選ぶことが次のタスクである場合。
• 複数の制約を伴う意思決定について、決定前に複数の異なる概念的な枠組みを検討することが有益な場合。
• 主な成果物が、大きく異なる複数の道筋からなる選択肢であり、その後に人間が選択する場合。
• 方向性は選ばれているものの、大きく異なる展開、移行、封じ込め、または実証の戦略が未確定である場合。

有効化せず、別の担当へ振り分ける場合

• アプローチの選択後に、直接的な実装、デバッグ、レビュー、または実行を行う場合：担当ワークフローを使用します。
• 「今すぐ選んで実装する」ことが主で、選択肢の提示は副次的な混在リクエストの場合：実行担当は内部でこの推論を使ってもかまいませんが、このスキルがターンを奪い、依頼された実行を放棄してはいけません。
• 事実に関する回答、名前やコピーなどの通常の創作、またはポートフォリオを作ると形式張りすぎる少数の既知の選択肢の比較の場合：直接回答します。
• 根拠に基づくリポジトリや製品の機会探索、優先順位付けされた改善点の発見、または次に計画する内容の選択の場合：根拠に基づく直接的な機会分析を使用します。
• 選択済みの方向性を、詳細な実装計画、仕様、または実行タスクの分解に落とし込む場合：$planを使用します。
• 多様な道筋を求められていないコードベースのアーキテクチャや理解の場合：直接的なコードベース分析を使用します。
• このスキル自体の分析、説明、レビュー、調整、テスト、または編集の場合：適切に直接分析または$tuneを使用します。
• ユーザーがすでに段階や道筋を選び、その実行を求めている場合：実行担当に引き継ぎ、ポートフォリオを再生成しません。

スキル名に関するルール

• 戦略ポートフォリオを作成するために「use」「run」「apply $creative-problem-solver」と命令する依頼は、ポートフォリオのルートを明示的に許可します。
• 名前だけの言及やメタ的な言及は、ホストのポリシーに従ってパッケージを読み込む場合がありますが、タスクの担当先へ振り分けます。タスクがない場合は、直接確認します。ポートフォリオの生成は許可しません。

優先順位の決定

• 明示的なポートフォリオ作成の命令は、安全性、ドメイン固有の担当、メタタスクの担当、または矛盾する実行依頼により別のルートが必要な場合を除き、優先されます。
• 直接的な根拠に基づく機会分析は、リポジトリ探索と優先順位付けされた改善点の発見を担当します。
• 方向性が選択済みで、求められる出力が実行方針または詳細な計画の場合は、$planを優先します。
• 作業対象がスキルパッケージ自体の場合は、$tuneを優先します。
• 求められる成果が選択肢の提示であれば有効化します。成果が単一の回答、単一の計画、または単一の実装であれば有効化しません。

手法

1. 結び付ける：選択を左右する要素だけを結び付けます。

   Objective: <outcome or decision to improve>
   Hard constraints: <non-negotiable boundaries>
   Incumbent/default basin: <the approach or representation most likely to be repeated>
   Material unknowns: <unknowns that could change the choice>
   

2. 形式化する前に発散させる：複数の直交する操作軸に沿って、現行案を変形します。5つの段階をアイデアのきっかけとして使ってはいけません。
3. 商集合を作る：同じ支配メカニズムを共有し、コスト、範囲、実装規模、展開速度、期間、野心だけが異なる候補はまとめます。
4. 初期候補群ができたら アハーチェック を行います。重要な再表現によって候補群、検証範囲、順序、または判断基準が変わる場合は、その再表現に基づいて一度だけ候補を再生成し、再度まとめます。変わらない場合は、ペナルティなしで Aha: N/A と報告します。
5. 意味のある異なるコミットメントにつながる、互いに包含されない候補を 絞り込み ます。
6. 妥当な範囲で検証する：残った各候補に、適切な最小限の可逆的な検証、判断の分岐条件、中止基準、保持すべき資産、不可逆な実行に入る前の撤退手段を付けます。
7. 残った候補を、支配メカニズムをラベルに合わせて変えることなく、Quick Win から Moonshot までの段階に 位置付けます。すべての見出しを維持しますが、段階を埋めるために候補を捏造してはいけません。
8. 条件付きで推奨し、実行に移る前に人間の判断を仰ぎます。

未知の情報が解決策候補を妨げるのは、その情報によって判断が逆転する可能性がある場合、比較が無意味になる場合、重大な安全、法務、または不可逆性の境界を越える場合、あるいは具体的な判断基準がなくなる場合に限ります。それ以外は、前提を明示するか、条件分岐を提示するか、検証によって解消します。対象領域、指標、しきい値、分母、母集団、反復回数、因果メカニズム、または事実的根拠を、暗黙のうちに選んではいけません。判断を左右する事実、裏付けのある推論、前提、仮説を区別し、選択に影響するものだけにラベルを付けます。

レーン

• Fast Spark：デフォルトです。少なくとも4つの操作軸に沿って、非表示の小規模な発散を行います。適切な場合は、削減の操作と境界または表現の変更を含めます。判断に役立つ候補だけを示します。
• Full Session：ユーザーが深掘りや網羅的な検討を明示的に求めた場合、または重大な影響、不可逆性、相互に関連する制約によって候補群そのものが判断に関わる場合に使用します。生の候補をおよそ10～30件生成し、支配メカニズムごとにまとめ、絞り込みに影響したクラスターまたは変換だけを示します。
• 難易度だけでは Full Session を正当化できません。表示上の簡潔さは、浅い探索を許可するものではありません。

発散カーネル

これらは、すべてを埋める見出しではなく、探索のための変換として扱います。

• 削減する — ニーズ、構成要素、調整、引き継ぎ、または継承された前提をなくします。
• 反転する — 支配的な前提、デフォルト、制御の方向、依存関係、または価値交換を逆転させます。
• 境界を動かす — 所有者、権限、インターフェース、信頼境界、または基盤を変更します。
• 再表現する — モデル、データ形状、抽象化、作業単位、または問題の記述を変更します。
• 時間を変える — 事前計算、延期、一括処理、ストリーミング、償却、先行処理、またはイベント駆動化を行います。
• アクターまたはインセンティブを変える — 誰が行動するか、誰が利益を得るか、誰が費用を負担するか、またはシステムがどのような行動に報いるかを変えます。
• 検証対象を変える — 別の観測可能なもの、契約、反証条件、または受け入れ境界を解決対象にします。
• 分割、構成、または転用する — 問題を分解し、別々の操作を組み合わせるか、構造的に類似した分野からメカニズムを取り入れます。

ユーザーが指定した創造的手法が使える場合は尊重しますが、目に見えるプロセスの演出としてではなく、現行案を変形するために使用します。

素材の多様性

• ある案ではなく別の案を残すことで、少なくとも次のいずれかが変わる必要があります。統治メカニズム、オーナー、表現形式、権限の境界、適用対象の領域、作業単位、立証責任、または反証条件。
• 減算型の候補と、境界または表現形式を変える候補が許容される場合は、それぞれ少なくとも1つ残します。
• より強い候補に包含される候補は、実質的に異なる可逆的な着手点を生み出さない限り、独立した候補ではありません。
• 誠実に差別化できる候補がない場合は、その旨を明記します。同じ領域に属する候補群や、候補がないティアのほうが、目新しさを捏造するより望ましいです。

Aha チェック

• Aha とは、再構成による洞察です。問題を別の形で捉え直すことで、異なる候補群が見えるようになります。
• Aha: <再構成による洞察> または Aha: N/A と出力します。
• 実質的な Aha の後には、Aha basis: <この転換が妥当である理由> [evidence: fact | supported inference] を付けます。
• 経験的な命題がある場合は、任意で別の行に記載します。Claim: <主張> [evidence: fact | supported inference | hypothesis]
• 実質的な Aha は、これまで見えていなかった候補を生み出すか、識別基準または立証の対象を変えるか、残った候補群の優先順位を変える必要があります。その視点で一度候補を再生成します。そうでなければ、それは Aha ではなくコメントです。
• 創造性の強さによって、根拠や主張の事実性が高まることはありません。仮説には、関連する調査で確認できる具体的な反証観察が必要です。

プローブ、エビデンス、蓄積

候補として記載するすべての案には、次の項目が必要です。

• プローブ — 判断を変え得る、最小限の可逆的な取り組みです。時間制限によって管理が大きく改善する場合は、その時間制限も含めます。
• 識別基準 — 現実的な代替案よりもこの案を支持する観察結果または比較結果です。
• 撤退基準 — この案、その統治上の主張、または適格性を覆す観察結果です。
• 保持する資産 — この案を採用しない場合も保持される、永続的なエビデンス、データ、インターフェース、プロトタイプ、テスト、モデル、仕様、または意思決定の記録です。
• 退避策 — 不可逆的な権限、データ、互換性、または組織上のコミットメントが境界を越える前に用意する、停止手段、フラグ、隔離境界、または事前コミットメントです。

主張に必要な分だけ、根拠を強化します。定量比較には、結果を解釈可能にするために必要なベースライン、分母、比較ルール、しきい値、反復を含めます。定性的な調査には、エビデンスソース、解釈ルール、反証となるエビデンスが必要です。因果仮説には反証条件が必要です。不可逆的なコミットメントには、中止境界と影響の封じ込めが必要です。定性的または戦略的な判断に、ベンチマークの形式を無理に当てはめないでください。

エビデンス・スパインには、候補の構築方法を指定せずに比較するための、中立的な事実、ベースライン、事例、基準、評価ハーネスをまとめられます。表現形式、インターフェース、オーナー、または立証の対象が異なる場合、各候補はそれぞれ独自のオプション成果物を保持してもかまいません。アーティファクトを共有するためだけに、変革的な案がクイックウィンの構築方法を引き継ぐことを強制しないでください。完了したこと自体は便益の証明ではなく、事後の隔離は可逆性ではありません。

ティアへの振り分け

• クイックウィン — 今すぐ判断または成果を改善する、最も低コストで可逆的な一手です。
• 戦略的施策 — 現在の運用モデルの範囲内で、最も強力な道筋です。
• 優位性を築く施策 — 再利用可能な能力、蓄積する資産、または非対称な選択肢を生み出します。
• 変革的な施策 — インターフェース、運用モデル、統治上の制約、権限の境界、またはユーザーの慣習を変えます。
• ムーンショット — 立証可能な、最小限に範囲を限定したプローブを通じて、非連続な上振れを検証します。

候補を絞り込んだ後で振り分けます。同じメカニズムを5段階の規模に拡大して使わないでください。あるティアに誠実に当てはまる候補がない場合は、No honest <tier> survived divergence と記載し、その区別に必要な要素が欠けている理由を1文で説明します。

オプションカード

<Tier> — <path> [shift: <mechanism, boundary, representation, or proof surface>]
- Probe: <smallest reversible test; timebox when meaningful>
- Decide by: <discriminator>; kill if <disconfirming observation>
- Retain: <durable option artifact>; escape before <irreversible boundary>

オプションの解釈に影響する場合に限り、前提またはエビデンスのラベルを追加します。

選定と出力

• 各有力な方針が優位となる条件を示し、条件付きの推奨を1つ提示してください。
• 見せかけの精密さよりも、定性的なトレードオフの優位性を優先してください。数値評価やパレートに関する表現は、ユーザーが基準、尺度の基準点、値を意味あるものにする根拠を提示した場合に限って使用してください。
• Fast Spark では、簡潔な制約条件、Aha または正直な N/A、簡潔なカードまたは正直な不足点を含む5つの段階見出し、推奨を1つ、そして Human Input Required: choose a path or update the constraints. を提示してください。
• Full Session では、検討した仕組み、統合した同等クラス、絞り込みを変えた変換をまとめた簡潔な候補フィールドの要約を追加してください。
• ユーザーから求められない限り、オペレーターのチェックリスト全体や破棄したアイデアの一覧を公開しないでください。
• 推奨は実行の許可ではありません。選択後、詳細な計画は $plan に引き継ぎ、許可された実装は担当ワークフローに引き継いでください。このスキルはリポジトリを変更しません。

ルーティング例

起動すべき場合

• 「どの案を選ぶか決める前に、オンボーディングの離脱を減らす、実質的に異なる方法をいくつか提示してください。」
• 「クエリの調整を2回試しましたが、まだ行き詰まっています。他に試せることはありますか？」
• 「この移行の問題を別の視点から捉え直し、異なる方針間のトレードオフを示してください。」
• 「問題が曖昧です。構築計画ではなく、学習につながる取り組みを提示してください。」
• 「イベントソーシングを選びました。実行前に、実質的に異なる段階的導入と封じ込めの戦略を示してください。」

起動すべきでない場合

• "$creative-problem-solver" → 直接確認してください。ポートフォリオオブジェクトは許可されていません。
• 「$creative-problem-solverを使ってください。」→ ポートフォリオオブジェクトが提示されるまで、直接確認してください。
• 「自分の$creative-problem-solverスキルを詳細に分析してください。」→ 直接分析／$tune
• 「過剰に起動しないよう、$creative-problem-solverにパッチを適用してください。」→ $tune
• 「コンパイラーエラーで行き詰まっています。他に試せることはありますか？」→ デバッグ担当
• 「このコマンドの名前を20個ブレインストーミングしてください。」→ 直接的な創造的生成
• 「選択肢を提示し、最善のものを選んで、今すぐ実装してください。」→ 実行担当。ポートフォリオは内部で扱ってもかまいません。
• 「このリポジトリから、根拠に基づいた製品およびDXの機会を見つけてください。」→ 直接的な根拠に基づく機会分析
• 「選んだイベントソーシングの方針を、詳細な実装計画にしてください。」→ $plan
• 「このリポジトリのアーキテクチャとデータフローを説明してください。」→ 直接的なコードベース分析
• 「このプルリクエストに不具合がないかレビューしてください。」→ レビュー担当
• 「Quick Winを選びました。今すぐ構築してください。」→ 実行担当