set-theory-for-projects

プロジェクトの集合論

より大きな山ではなく、価値の核心を見つけます。

1 つのアンカープロジェクトを対象に、範囲を限定した読み取り専用の探索を行います。プロジェクトが持つ既存の価値を、より多くの現実的な状況で活用できるようにする、安定したユニバーサルコア、範囲を限定したアダプターの機会、または信頼できるプラットフォームの機会を探します。拡張なしという結果も成功として扱います。

拡張の目標と、その後のスコープ変更はすべてユーザーが決定します。探索はエージェントが担当します。ユーザーが提供したプロジェクトは有用な起点ですが、探索の前提条件でも制限でもありません。会話形式の探索レポートと探索チェックポイントを作成した時点で終了します。実装、プロトタイピング、統合、および他のプロジェクトへの変更は、ユーザーが候補の 1 つを新規または改訂されたユーザーの課題として明示的に指定した後にのみ開始します。

英語での出力

英語の文章を作成または改訂する前に、インストール済みの simple-english スキルを使用してください。名前を指定して読み込むか、その SKILL.md と該当する参考資料を読んでください。 このコンテキストですでに読み込まれている指示は再利用してください。 この規約を読んだ後、英語で進捗を報告したり、草稿または最終回答を送ったりする前に、依存関係を読み込んでください。

スタイル規則と矛盾する場合は、意味、不確実性、要件の強さ、専門用語、およびタスクで指定された形式を維持してください。指定された言語を使用してください。 コード、識別子、コマンド、原文からの引用、および歴史的な根拠は保持してください。

必要な指示を利用できない場合は、その不足を一度だけ報告し、独立して進められる作業は続行してください。依存関係が利用可能になるか、ユーザーが例外を明示的に許可するまでは、影響を受ける英語の出力を草稿として扱ってください。依存関係を自動的にインストールしたり、確認していない草稿がこの要件を満たすと主張したりしないでください。

1. アンカーを確立する

ユーザーの依頼またはアクティブなワークスペースから、アンカープロジェクトを特定します。拡張の目標を定めます。これは、既存の価値のうち、どの価値をより具体的な状況で活用できるようにするのかを示す 1 文です。その価値の選択が欠けている、または実際に曖昧な場合は、焦点を絞った質問を 1 つ尋ねます。事実に関する不足は直接調査します。

現在の根拠に基づいて、簡潔なアンカープロファイルを作成します。

• 現在のユーザーと、すでに解決している課題；
• その価値を生み出す仕組みとインターフェース；
• フレームワーク、プラットフォーム、ドメイン、ワークフロー、およびエクスペリエンス上の制約；
• 現在の統合、検証対象、リリースモデル、およびメンテナー。

重要な制約をそれぞれ次のいずれかに分類します。

• 必要な境界 — 取り除くと、維持する価値のある価値またはアイデンティティが変わるもの；
• 偶発的な制約 — 中核的な価値を生み出すことなく、対象となる状況を狭めている、歴史的または技術的な結び付き。

事実に関する分類は根拠に基づいて判断します。曖昧な価値のトレードオフだけをユーザーに尋ねます。

完了条件： アンカープロジェクトと拡張の目標が具体化され、探索の結果を左右し得る重要な制約がすべて分類され、ユーザーが決定する境界に曖昧さがあれば解消されていること。

2. 範囲を限定して調査する

拡張の目的と必要な境界が明確になったら、2つ以上の検索経路でそれぞれ独立して進展できる場合は、調査の割り当てを利用します。主担当者は候補の同一性、最終判断、全体で共通の予算を管理します。目的が未解決のまま並列化したり、このスキルの上限を作業者ごとに増やしたりしないでください。

最も関連性の高い利用可能な一次情報を積極的に調査します。プロジェクトファイル、公式ドキュメント、ソースリポジトリ、課題トラッカー、リリースノート、メンテナーの発言などが対象です。重要な主張はそれぞれ、ファイル、URL、またはユーザーから提供された事実にたどれるようにします。

このアンカーの証拠が得られる可能性が高い順に、次の4つの経路を調査します。

1. 技術的な隣接性 — 共通のプロトコル、形式、エンジン、拡張ポイント、または重複するインフラストラクチャ。
2. 共通するユーザーの課題 — 異なるプロジェクトのユーザーが、同じ根本的な作業や問題に直面していること。
3. 補完的な機能 — 別のプロジェクトが、アンカーで利用する、またはアダプターを通じて公開する、範囲の明確な機能を提供すること。
4. 異なるエコシステムにおける類例 — 別のフレームワーク、プラットフォーム、または分野が、同等の問題を同様の接点を通じて解決していること。

候補の証拠が双方に存在する場合に限り、未検証のアイデアは適格となります。つまり、アンカーと、少なくとも1つの実在する隣接プロジェクトの両方について、共通または補完的な課題と、安定した実現手段または統合の接点が見込めることを示す証拠が必要です。概念上の類似、共通する技術、または技術的に接続できるというだけでは適格になりません。

次のいずれかの上限に達した時点で終了します。

• 未検証の候補を15件調査した
• 適格な最終候補を5件残した
• 異なる2つの検索経路から、新たな適格候補が見つからなかった

未確認の経路と入手できなかった証拠は、調査を際限なく延長するのではなく、証拠の境界に記録します。

**完了条件：**残した最終候補のすべてに、双方からたどれる候補の証拠があり、どの検索経路と終了条件によって結果の範囲を定めたかを報告書で正確に説明できます。

3. 接点を分類する

各最終候補を、信頼性のある最小限のアーキテクチャ変更に基づいて分類します。

• 汎用コア — 偶発的な制約を取り除くか、少なくとも2つの具体的な状況ですでに裏付けられている安定した仕組みを抽出します。その間、個別製品はそれぞれの体験レイヤーを維持します。
• アダプターの機会 — アンカー固有のコアを維持し、別の具体的なプロジェクトや状況に対応する、範囲の明確な統合の接点を1つ追加します。
• プラットフォームの機会 — 具体的なプロジェクト群がそれぞれ独自の統合を維持しながら参加できる、安定したインターフェースまたはプロトコルを公開します。

恣意的な機能の寄せ集めは退けます。共通の課題と安定した接点の証拠がないまま、機能、対象ユーザー、またはブランドを組み合わせても、プロジェクトの規模が大きくなるだけで、汎用性は高まりません。

最終候補ごとに、次の問いに答えます。より深い再利用可能な仕組みが明らかになりますか。それとも、単に機能が1つ増えるだけですか。

**完了条件：**すべての最終候補に分類が1つだけ割り当てられ、必要な境界が明示されたままであり、規模が大きくなるだけで汎用性が高まらない組み合わせは退けられています。

4. 証拠調整後の価値を評価する

最終候補を定性的に比較します。数値スコアは算出しないでください。次の点を考慮します。

• 双方向の証拠の強さと独立性；
• 同じ価値が役立つ、具体的な追加コンテキスト；
• 必要な境界の維持；
• 提案する接合部の安定性と検証可能性；
• 結合度、可逆性、アイデンティティの希薄化；
• 保守の責任者、検証マトリクス、互換性に関するコミットメント、撤退経路。

候補の判定を1つ割り当てます。

• 推奨 — 証拠と接合部に信頼性があり、保守モデル全体にも実現可能性があります；
• 証拠が必要 — 特定され、解消可能な証拠の不足により、推奨できません；
• 却下 — 必要な境界、共有する課題の弱さ、不安定な接合部、または保守コストが候補の価値を損ないます。

責任者、検証範囲、互換性ポリシー、撤退経路が現実的でない興味深い候補は、「証拠が必要」または「却下」のままです。リーチの広さや抽象化の洗練度を理由に、評価を引き上げてはいけません。

完了条件： すべての最終候補に、根拠のある判定が付いており、「推奨」の候補はすべて保守ゲートを通過していること。

5. 実験ラダーを設計する

「推奨」または「証拠が必要」の候補ごとに、段階的で反証可能な実験ラダーを作成します。

1. 隣接するコンテキストと、そこで示された課題が実在することを確認します。
2. 提案する接合部を、アンカーと隣接ケースに照らして、契約または設計として検証します。
3. より低コストの2つの検証が両方とも通過した場合に限り、使い捨てのプロトタイプを推奨します。

各段階について、求める証拠、信頼できる最も低コストな方法、合格とみなす観察結果、候補を打ち切るか見直すべきシグナルを明示します。ラダーを計画し、実行は別途承認されたタスクに委ねます。

完了条件： 残った候補ごとに、プロトタイプ作成前のより低コストな検証と、明示的な反証シグナルがあること。

探索レポート

結果を冒頭に示し、次の項目を含めます。

1. アンカーのプロファイル — アンカープロジェクト、拡張の狙い、維持する価値、必要な境界、偶発的な制約。
2. 検索範囲 — 確認した経路、調査した候補の総数、終了条件、証拠の境界。
3. 候補カード — スコアを付けず、証拠調整後の価値の順に最大5件。それぞれのカードには次を記載します。
   • 判定と種類；
   • 隣接するプロジェクトまたはコンテキスト；
   • 出典を添えた双方向の候補証拠；
   • 共有または補完する課題；
   • 維持する必要な境界；
   • 提案する接合部と、それが単なる機能拡張ではない理由；
   • 保守モデル；
   • 重大なリスク；
   • 実験ラダー。
4. 却下記録 — 判断に関係する却下候補を最大3件挙げ、それぞれを退けた証拠、境界、またはコストを示します。
5. 探索の確認ポイント — 1つの候補を選択する、明示した証拠の境界1つについて対象を絞った調査を承認する、または拡張なしの結果を受け入れるようユーザーに促します。

証拠ゲートと保守ゲートを通過する最終候補がない場合は、拡張なしの結果を明示し、利用可能な選択肢と比べて現行スコープの維持がより妥当な理由を説明します。ユーザーから明示的に保存を求められない限り、レポートは会話内に留めます。

探索の確認ポイントでは、次のとおりにします。

• 候補が選択されたら探索を終了し、実装には新しいユーザー課題、または改訂されたユーザー課題が必要だと伝えます。
• 対象を絞った調査は、開始前に、1つの証拠に関する問い、範囲を限定した1組の情報源、1つの終了条件を設定します。
• 拡張なしの結果が受け入れられた場合は、別の方向性を無理に作らずに作業を完了します。

レンズの由来

この独立したスキルは、Anthony Fu の「The Set Theory」に着想を得ています。対象ユーザーの共通部分を不必要に狭める制約を取り除き、価値ある具体性を保ち、実際のニーズから和集合が見えてきた場合は共通の下位レイヤーを抽出します。ここでいう「和集合」は、恣意的なプロジェクトの統合ではありません。Antfu の React Summit の発表スライドと公式の録画および文字起こしをご覧ください。これは独立した非公式のスキルです。リンクはこの視点の出典を示すものであり、著作者を示唆するものではありません。