mcpField
F
fpf-problem-solving

fpf-problem-solving

github.com/codealive-ai生産性2169 回インストール26 週間前に更新
リポジトリ

fpf-problem-solving について

このスキルはアーカイブされ、CodeAlive-AI/ai-driven-development コレクションに統合されています。FPF は、問題の分解、証拠の評価、選択肢の比較、専門的な役割の連携を扱う、分野横断の推論フレームワークです。

主な機能

  1. 01複雑な問題を境界のある部分に分解
  2. 02確信度と証拠の質を評価
  3. 03選択肢を生成して比較
  4. 04分野間の用語を統一
  5. 05制約下でエージェントのツール利用を設計

活用シーン

  1. 01分野横断の問題を分解
  2. 02証拠が不十分な意思決定を評価
  3. 03多様なチームの用語を調整
  4. 04エージェントのツール選択と順序を計画

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/codealive-ai/fpf-problem-solving-skill --skill fpf-problem-solving

インストール後、Claude Code で/fpf-problem-solvingを入力して読み込まれたか確認します。

詳細

First Principles Framework (FPF)

「思考のオペレーティングシステム」――人間にも機械にも読み取れる擬似コードで記述された、学際的な推論アーキテクチャです。FPF は、生の知性(人間または機械)を、組織で活用できる推論へと変換します。明示的に範囲を定めたコンテキスト、監査可能な成果物、複数の視点からの記述、専門化したアクター間の規律ある引き継ぎを実現します。

ユースケース

状況に応じた通常の考え方よりも厳密に考える必要があるときは、いつでも FPF を使用してください。

  • 複雑で複数の領域にまたがる問題を、個別に推論できる要素に分解する
  • 不完全な証拠をもとに重要な意思決定を行い、まだ不足している証拠を把握する
  • 用語の衝突や隠れた前提を生じさせずに、異なる専門性を持つチームが協力して推論できるようにする
  • 結論が十分な根拠に基づいているのか、単にもっともらしいだけなのかを監査する
  • 精度を損なったり、カテゴリー錯誤を招いたりせずに、ある領域の洞察を別の領域へ移す
  • 複数の専門家の視点から検証される必要がある提案を構成する
  • 最初のアイデアに固執せず、代替案を体系的に生み出す
  • 選択肢を比較する前に、「より良い」とは何かを定義する
  • 解決策を探す前に、直面している問題がどのような種類のものかを分類する
  • 予算と信頼の制約のもとで、AI エージェントがどのようにツールを選択し、順序付けるべきかを計画する

ナビゲーション方法

上記のユースケースは、FPF を起動するかどうかを判断するのに役立ちます。起動後にどこへ進むかは、以下のルーターが判断します。

ステップ 1 — 思考上のニーズに合った出発点を選ぶ
必要な作業参照先
複雑な全体を、境界のある部分に分解する04 Kernel → A.1 Holons, A.1.1 Bounded Contexts, A.14 Mereology
役割と責任を割り当てる04 Kernel → A.2 Roles, A.15 Role-Method-Work Alignment
記述の意味に境界を設定する05 Signature Stack → 定義、ゲート、義務、証拠として分類する
カテゴリーエラー(役割と機能、方法と作業の混同)を防ぐ06 Constitutional Principles → A.7 Strict Distinction
主張や成果物への確信度を評価する07 Part B → B.3 Trust & Assurance; 08 Part C → C.2 F-G-R scoring
性質を保ちながら部分を全体にまとめる07 Part B → B.1 Gamma algebra; 08 Part C → C.13 Compose-CAL, C.20 Discipline-CAL
問題を体系的に考察する07 Part B → B.5 Reasoning Cycle, B.5.2 Abductive Loop
代替案を生み出す/解決策の可能性を探る08 Part C → C.18 NQD Open-Ended Search, C.19 Explore-Exploit
選択肢を厳密に測定し、比較する06 A.V → A.17-A.19 Characteristics, CSLC & SelectorMechanism; 08 Part C → C.16 MM-CHR
知識の質(形式性、範囲、信頼性)を評価する08 Part C → C.2 KD-CAL, C.2.2 Reliability, C.2.3 Formality
ステークホルダー間または価値観間の対立を解決する09 Part D → Ethics & Conflict
チーム間または分野間で語彙を統一する13 F.I Context of Meaning → 14-15 UTS tables → 20 Lexical Debt
複数の読者を対象に文書化する11 E-I Constitution → E.17 Multi-View Publication Kit
表現を明確にする — 曖昧な表現を修正し、曖昧さを明らかにする11 E-I → E.17.SD.SPR Surface Precision Restoration, E.17.SD.OOTD Object-of-Talk Discipline, E.17.EFP Explanation Faithfulness; 05 A.IV.A → A.6.H Wholeness Unpacking
分野を調査し、再利用可能なツールキットを構築する16 Part G → SoTA Packs, TraditionCards, OperatorCards; 08 Part C → C.21 Discipline-CHR (field health & maturity)
解決に取りかかる前に問題の種類を分類する08 Part C → C.22 Problem-CHR, C.3 Kind-CAL (typed reasoning)
品質属性(「-ilities」)を構造化されたまとまりとして定義する08 Part C → C.25 Q-Bundle; 06 A.V → A.17-A.19 Characteristics
予算と信頼ゲートのもとで、エージェントによるツール使用を調整する08 Part C → C.24 Agent-Tools-CAL
主張の来歴を追跡する06 A.V → A.10 Evidence Graph; 16 Part G → G.6 Provenance Ledger

複雑な問題では、複数のセクションをまたぐパスをたどってください。ルーターが示すのは出発点であり、終着点ではありません。

ステップ 2 — _index.md を読み、次にサブセクションを読む
  1. 対象セクションのフォルダーにある _index.md を開きます。行数と説明を含むすべてのサブセクションが一覧表示されています。
  2. 必要なサブセクションのファイルだけを読みます。
  3. セクション全体を読み込まないでください。ユーザーの質問に応える、最も範囲の狭いファイルを選びます。
ステップ 3 — 平易な言葉で適用する

ユーザーには平易な言葉で説明してください。FPF 内部の名前(U.Holon、Gamma、F-G-R)は、ユーザーに必要な精度を高める場合にのみ使います。

ステップ 4 — セクションをまたいで知見をまとめる

問題が複数のセクションを参照する場合:

  1. 各パターンがどのように役立つかを一行で述べます(例:「Bounded Contexts は部分を示し、Trust Calculus は各部分への確信度を評価します」)。
  2. 異なるセクションのパターンが矛盾しているように見える場合は、A.7 Strict Distinction を使ってカテゴリーエラーがないか確認します。たいていは実際の矛盾ではなく、レベルの混同(役割と機能、方法と作業の混同)が原因です。
  3. 自然な順序で統合します。まず分解(部分は何か)、次に評価(どの程度確信できるか)、最後に解決(不足にどう対処するか)です。
  4. FPF パターンをただ列挙するのではなく、ユーザーが実際に尋ねていることに答える、一貫した説明にまとめてください。

スタータープロンプト(例 — ユーザーの実際の役割とニーズに合わせて調整してください)

FPF の仕様を読み込んでいます。 プロジェクト/課題/プログラムの構成を手伝ってください。 エンジニアリングマネージャー向けに、平易な言葉で説明してください。 次の項目を提案してください:(1)境界づけられたコンテキスト/専門分野、(2)意思決定基準、(3)主な代替案、 (4)引き継ぎ、(5)決定前に不足しているエビデンスやテスト。 内部向けの FPF 用語は、精度を高める場合にのみ導入してください。

セクション索引

構造上の参照です。各項目はフォルダーです。まず _index.md を読み、次にサブセクションを選んでください。

#セクションサブ使用する場面
01タイトルページ0著者情報、バージョンの日付、最上位のアイデンティティ。
02目次0仕様書のナビゲーション、パターンの特定、セクション間の依存関係の追跡。
03序文17導入:役割別の読解パス、FPF の理念、目的と対象外事項。
04パート A — カーネル19分解と割り当て:ホロン、境界づけられたコンテキスト、役割、変換器、メソッドと作業の分離。
05A.IV.A — 署名20境界の設定:記述を定義、ゲート、義務、証拠に分類します。
06A.V — 原則29混同の防止:カテゴリー錯誤、測定、比較、証拠グラフ、メカニズムスイート、フロー制約、ゲートプロファイル。
07パート B — 推論24構成と評価:集約(Gamma)、信頼スコア、創発、推論サイクル。
08パート C — 拡張30スコアリングと検索:認識論的品質(F-G-R)、種類、測定、オープンエンドな検索、問題の型付け、分野の構成、エージェントによるツール使用、品質バンドル。
09パート D — 倫理1対立の解決:倫理的なトレードオフ、バイアス監査、安全性によるオーバーライド。
10パート E — 憲章0パート E のサブセクションへの入口。
11E-I — 憲章33統治と公開:11 の柱、ガードレール、マルチビュー公開(MVPK)、サーフェス規律、比較読解、変換グラフ、パターン品質ゲート。
12パート F — 統合0パート F のサブセクションへの入口。
13F.I — 意味19語彙の調整:意味のずれ、同音異義語の衝突、アラインメントブリッジ。
14UTS レイアウト A0標準(BPMN、PROV-O、ITIL)間の概念の対応付け。
15UTS レイアウト B1分野(オペレーション、物理学、数学)間の概念の対応付け。
16パート G — SoTA キット15分野の知見を収集:SoTA Pack、TraditionCards、OperatorCards、ベンチマーク。
17パート H — 用語集0用語の参照:標準定義、4 種のレジスターによる命名、相互参照。
18パート I — 付録0チュートリアル、変更履歴、外部標準との対応付け。
19パート J — 索引0概念からパターン、パターンから例、原則の追跡に関する索引。
20パート K — 用語上の負債2用語の修正:必須の置き換えと移行に伴う負債。

コメント