mcpField
F
flow-idea-to-proof

flow-idea-to-proof

github.com/jurgendn生産性1147 回インストール6 週間前に更新
リポジトリ

flow-idea-to-proof について

研究アイデアを明確な主張と証明計画へ進めるオーケストレーションスキルです。段階ごとの条件に沿って専門スキルへ処理を振り分け、仮定の抽出、形式化、証明設計、反例監査を進めます。

主な機能

  1. 01段階条件に沿った専門スキルの連携
  2. 02形式化前のアイデア検証
  3. 03必要な仮定の抽出
  4. 04主張の定式化と証明スケッチへの振り分け
  5. 05主張の反例チェック

活用シーン

  1. 01着想を形式的な定理へ発展
  2. 02証明を書く前の隠れた仮定の発見
  3. 03証明計画の反例監査

インストール

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

$npx skills add https://github.com/jurgendn/agent-skills --skill flow-idea-to-proof

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

詳細

アイデア → 仮説 → 証明設計(オーケストレーター)

生のアイデアを正式で擁護可能な主張と証明戦略へと導きます。仮説を明確にし、成立すべき条件を切り分け、主張を正確に述べ、証明の概要を示し、ユーザーが本格的な執筆に何週間も費やす前に監査します。このスキルは単体のスキル間をルーティングするものであり、ストレステスト、証明の概要、監査そのものは実行しません。

関連スキルとの違い:

  • flow-learn-new-topic / flow-deep-understanding — 既存の研究を理解します。ここで扱うのはユーザー自身のアイデアであり、まだ存在していません。
  • gap-finder — 既存論文の弱点から始めます。アイデアの着想を得るにはこちらを使い、すでにあるアイデアを発展させるにはこのスキルを使います。

始める前に:生のアイデアを把握する

推測できないことだけを尋ねてください。必要なのは次の情報です。

  • アイデアを一文で — 曖昧でも構いません。ステージ1で明確にします。
  • 設定 — どのような数学的・経験的対象に関するものか(そのアイデアが属する形式体系)。
  • 「真である」とは何を意味するか — ユーザーが求めているのは定理、上界、保証、不可能性の結果、それとも説明したい経験的規則性でしょうか。これにより、進むべき道が証明設計か実験設計か決まります。

ユーザーが証明ではなく経験的な検証を求めている場合は、代わりに research-idea-stress-test → experiment-design にルーティングし、その旨を伝えてください。

パイプライン

順番に実行します。アイデアがすでにある段階から始めてください — 明確な主張を示しているユーザーはステージ1をスキップできます。

Whiteboard the hunch → Stress-test → Extract premises → State the claim → Sketch → Audit
ステージ0 — ひらめきをホワイトボードで検討する → whiteboard-peer

アイデアがまだ未完成の直感である場合は、 正式な評価に進む前に、明確な意見を持つピアに検討を依頼してください。立場を一つに定めること、部分的な試みを一つ示すこと、そして実質的な異論を一つ述べることを求めてください。ピアは完成済みの解決策を提示するのではなく、 要となるステップを一つ、ユーザー自身に委ねなければなりません。 終了条件: 検討候補となる仕組み、異論のある前提、具体的な次のテストがあること。ユーザーがすでに明確な主張を提示している場合は、このステージをスキップします。

ステージ1 — アイデアをストレステストする → research-idea-stress-test

隠れた前提、見せかけの新規性、交絡要因を明らかにし、アイデアを形式化する価値があるかを判断する最も低コストのテストを見つけるため、引き継いでください。低コストの攻撃で崩れる主張の証明を設計してはいけません。 終了条件: アイデアが低コストの反証を乗り越え、ユーザーが仕組み・主張・貢献をそれぞれ別個に述べられること。

ステージ2 — 成立に必要な条件を抽出する → theory-assumption-extractor

主張に必要な前提を列挙し、論理的に必要な条件と便宜上の条件を分けるよう、引き継いでください。これらが定理の仮定になります。 終了条件: 仮定の集合が明示され、主張がどの前提なしには成立しないかをユーザーが把握していること。

ステージ3 — 形式的な主張を述べる → theorem-and-claim-audit

明確化したアイデアと仮定を、量化子が正確に明示された主張にまとめ、主張が過大でないか、循環論法でないか、既知の結果からすでに導かれるものではないかを確認するため、引き継いでください。 終了条件: 明示的な仮定と量化子を備え、実際に擁護可能な範囲に限定された形式的な主張があること。

ステージ4 — 証明の概要を作成する → theory-proof-sketcher

高レベルの論証、必要な補題、証明手法、最もリスクの高いステップを含む証明戦略を設計するため、引き継いでください。方針を固める前に、必要に応じて theory-to-toy-cases を使い、最小の具体例を基に戦略を組み立ててください。 終了条件: 名前付きの補題と、最も弱い箇所が特定された証明の骨格があること。

ステージ5 — 監査して攻撃する → theory-counterexample-hunter(+ theorem-and-claim-audit)

仮定の境界で反例を探し、具体的な導出ステップがあれば一行ずつ監査して、主張と証明の骨格を攻撃するため、引き継いでください。広すぎる主張を査読者に見つけられる前に捉える段階です。 終了条件: 述べられた主張への反例が残っておらず、リスクの高い導出ステップが検証されていること。そうでない場合は、どちらも満たすまで主張の範囲を狭めます。

ステージ 6 — 論文執筆への引き継ぎ

主張と概略が残れば、完全な証明の執筆と論文への統合に進めます。論文執筆スキル(method-section-writer、paper-argument-planner)に引き継ぎ、必要に応じて、貢献の位置づけを検討するためにgap-finderにも引き継ぎます。

ルーターのルール

  • 重複させず、委任する。 各ステージは単一のスキルに引き継ぎます。このファイルが担当するのは、順序とゲートの管理です。
  • アイデアの成熟度に応じて開始する。 明確な主張がある場合はステージ 1〜2をスキップし、漠然とした着想から始める場合はステージ 1から開始します。
  • 失敗したらループする。 ステージ 5で反例が見つかった場合は、主張を絞り込むためにステージ 2または3に戻します。主張を絞り込むことは失敗ではなく、成功です。
  • 実験ではなく証明を行う。 「真である」の意味が経験的なものなら、このオーケストレーターは適していません。実験設計パイプラインに引き継ぎます。
  • 見込みのないアイデアを形式化しない。 ステージ 1で却下または再構成と判断された場合は、ここで終了します。価値のないアイデアの証明を設計してはいけません。

コメント