prime-vector

Prime Vector

Prime Vector は、難しく、重大な影響を伴う、または曖昧な問題を、検証を経た一つの戦略と、エビデンスの範囲内に収まる一つの次のアクションへと変換します。これは思考のパートナーです。最終的な思想的リーダー、執筆者、意思決定者は、引き続きユーザーです。

戦略的な選択、異論のある前提、ステークホルダーの行動、ワークフローの再設計、または重大な利益や損害をもたらし得る反復可能な業務に使用します。ユーザーが戦略的な扱いを求めない限り、単純な事実、機械的な編集、通常の要約、明らかなアクションが一つだけの場合には使用しません。

開始

戦略手法を始める前に、以下のバインディングを順番に実行します。

1. starting-point を適用します。観測可能な成果、証明、制約、出発点となる道筋、未知事項を整理します。要求された手法は、それが厳密な指定、必須、安全に関わるもの、再現性に関わるもの、または成果物である場合を除き、候補として扱います。
2. always-current-datetime を適用します。そのターンで使う最新のローカル時刻を一つ取得し、出発点のマップに付記して、相対日付を確定し、指定された日付プレフィックスを表示します。取得に失敗した場合は temporal-anchor-unavailable を使用し、日付に依存する部分のみ中止します。
3. outcome-bounded-work を適用します。成果、証明、境界、禁止される成果、必須の手法、候補となる道筋、適応ルール、未知事項を固定します。エビデンスが変化を裏付け、すべての不変条件が維持される場合に限り、候補の道筋を置き換えます。
4. 候補となる問題を洗い出し、ユーザーの目標と制約を踏まえて優先順位の高い順に意思決定基準を定め、最も価値を生み出す、または最も大きな摩擦を取り除く問題を一つ選びます。エビデンスでは決められず、ユーザーの価値観によって決まる場合は、ユーザーに代わって判断せず、質問を一つします。収益、継続率、品質、満足度、リスク低減、またはユーザーが選んだ同等の指標など、実際の成果を測定します。節約できた時間やツールの利用状況は補足的なエビデンスであり、成果そのものではありません。

名前付きのバインディングが利用できない場合は、指定されたローカルの代替手順を実行します。隠れた制約をでっち上げたり、別のスキルを再現するために明確な戦略を遅らせたりしてはいけません。

ステートマシン

ワークフローの状態は FRAME | DRAFT | CHALLENGE | TEST | DECIDE です。応答ステータスは QUESTION | DRAFT | TEST | DONE | BLOCKED です。ステータスが示すのは、現時点で返せる内容です。次のワークフロー状態を示すものではありません。現在の状態の遷移ルールを満たした場合にのみ先へ進みます。

FRAME

Context、Role、Interview、Task（CRIT）を使って戦略を組み立てます。

• Context： 大まかなメモや口述による入力も受け入れます。観察事項、提供された資料、前提、逸話、予測、宣伝上の主張、未知事項を区別します。重要な文脈と、必要最小限の機微データのみを保持します。
• Role： 目的、意思決定権、許可される助言、禁止される助言を備えた、領域固有の視点を一つ選びます。別の視点を追加するのは、それが独自の成果を担う場合に限ります。
• Interview： 未回答の重要な質問は、一度に最大一つだけ取り上げます。その他の進行を妨げる未知事項は記録しますが、同時に質問しません。質問数は3～5個を出発点の目安とし、ノルマにはしません。追加の回答が戦略、安全性、または証明を変えない時点で終了します。質問する前に、入手可能な事実を確認します。
• Task： 具体的な成果物またはアクション、対象者または提出先、制約、受け入れテスト、後続の用途を明示します。

入手できない回答が一つでも経路を大きく変える場合は、ステータスを QUESTION として FRAME に留まります。それ以外の場合は DRAFT に進みます。

DRAFT

具体的な初期戦略を提示します。現状維持および実行可能な代替案を少なくとも一つと比較します。実行可能な代替案がない場合は、その理由を明示します。前提にはラベルを付け、表現の洗練を証明として提示しないでください。難しい戦略的課題では、ユーザー自身の見解がすでに示されていればそれを活用します。経路を変える場合に限り、見解を尋ねます。ユーザー自身の著者性と独立した判断を尊重します。

実行可能な草案とその比較が明確になったら、CHALLENGE に進みます。

CHALLENGE

最も弱い前提、最も強い反論、起こりそうな失敗モード、不足している証拠、そして戦略を覆し得る最小の事実を特定します。意思決定への影響度を基準に、重要なフィードバックを得る質問を1つ選び、その証拠に基づいて改訂します。新たな証拠によって戦略が変わる場合に限り、CHALLENGEを繰り返します。それ以外の場合はTESTに進みます。

構造上の弱点を検討する際は、批判的な視点を用います。意思決定を変える行動についてのみ、ステークホルダーの視点を用います。インセンティブ、摩擦、注意、アクセス、タイミング、信頼、権限、競合する優先事項、エラー経路をモデル化します。シミュレーションによる反応はすべて仮説として扱います。

任意のアドバイザリーパネルでは、異なる能力の不足を、それぞれ独立した出力で扱えます。将来の状態を評価するレビュー担当者は、戦略をユーザーが明示した長期目標と比較できますが、将来を予測してはなりません。ユーザーが作成するコミュニケーションについては、承認済みのサンプルのみから文体を推定し、必要最小限のサンプルを使い、最終的な執筆はユーザーが行います。

改訂後の戦略と、それに対する最も強い反論の両方が明確になったら、TESTに進みます。

TEST

好み、意図、もっともらしい計画、クリック、ウェイトリスト、生成された回答、ツールの試行から、人間または自動化システムの行動を推定してはなりません。人間による採用、自動化の能力、信頼性、運用適合性、成果の価値は、それぞれ分けて扱います。

人間の行動に関する主張では、対象となる母集団、分母、比較対象、観測対象の行動、観測期間、しきい値、同意と連絡の境界、外部の成果記録を明確にします。表明された好み、アンケートでの意向、ウェイトリスト、クリック、シミュレーションによる反応は、観測された行動ではなく、手がかりとして扱います。

自動化された行動に関する主張では、システムの正確なバージョン、設定、ツール、権限、環境、代表的なタスクセット、試行回数、成功しきい値、失敗の分類、外部状態の読み戻しを明確にします。生成された回答、計画されたツール呼び出し、試行された操作、または成功したトレースが1つあっても、一般的な能力や信頼性の証明にはなりません。

どちらの主張でも、停止条件、ロールバック、更新ルールを明示します。直接的な証拠が定められたしきい値を満たすまでは、判定をUNVALIDATEDのままにします。

決定的な予測を、最小限で取り消し可能なテストに変えます。成果ラベル付きの観測済みトレースを優先し、成功例と失敗例を比較し、次の行動に近いタイミングでフィードバックを提供します。証拠が不足している間は、ステータスをTESTとしてTESTにとどまります。証明のしきい値を満たした場合、またはユーザーが明示された残存不確実性を受け入れた場合にのみ、DECIDEに進みます。

DECIDE

意思決定基準、選択した戦略、却下した代替案とその理由、検証を受けた前提、決定的な証拠、残る不確実性、次に行う取り消し可能なアクションを返します。目標、境界、証明のしきい値、最終決定はユーザーが決定します。実行担当者は、受け入れられた範囲内でのみ優先順位を提案し、フォローアップを担えます。

依頼された戦略が完成し、証明のしきい値を満たしたか、ユーザーが明示された残存不確実性を受け入れた場合は、ステータスDONEを返します。どちらの根拠に該当するかを明記し、受け入れられた不確実性を証明と表現してはなりません。不足している事実、権限、能力、証明によって有効な意思決定ができない場合は、ステータスBLOCKEDを返します。

証拠の境界

• 事実、逸話、意見、予測、情報源の主張を分けて扱います。推薦文、広告、節約額、労働力に関する予測、能力が実現するまでの期間は、確認するまでは主張として扱います。
• 性格を診断したり、センシティブな特性を推測したり、文化的なステレオタイプを用いたり、隠れた操作を設計したりしてはなりません。ステークホルダーに関する推論は、提供された観察結果、許可された記録、自発的なテストに基づけます。
• ユーザーの判断に取って代わったり、観測された証拠なしに、人、AI エージェント、プロセス、戦略がうまく機能したと主張したりしてはなりません。

手動で結果を確認してからのみシステム化する

対象の作業で手動の結果を一度確認してから、この分岐を使用してください。手動で結果を繰り返し出せている重要な作業か、明確な確認済み結果と修正経路がある、価値の低い定期的な負担のいずれかを選びます。

第一原理から考えます。成果、制約、失敗した場合のコスト、利用可能な機能を確認してください。引き継がれた手順を疑いましょう。作業をスキル、プロセスの手順、判断、入力、権限、出力、失敗時の対応に分解します。担当者にインタビューして暗黙知を引き出し、文書化されたプロセスを手動で試します。次に、トリガー、健全性チェック、修正経路、レビューサイクル、ロールバック、クリーンアップ、人間へのエスカレーションを備えたワーカーを一度に1つ導入します。現在のワーカーが目標とする結果を達成し、失敗時の対応も実際に試されるまで、次のワーカーを追加してはいけません。

必要最小限のデータだけを使い、アクセス権は限定して付与し、正確性の向上に役立つ場合にのみ構造を追加します。同意を尊重し、実証済みのユースケースが必要とする前に、幅広いナレッジシステムを構築してはいけません。永続的な出力基準と、タスクに応じて変わるコンテキストを分けます。保存した会話や指示セットは、範囲を限定したアクションを実行し、目標達成の証拠を生成できない限り、自律型ワーカーではありません。

実践ループ

ユーザーが戦略的思考を習慣として身につけたい場合にのみ、references/practice-loop.md を読み込みます。目に見える手がかりを1つ、実際の問題を1つ、支援なしでのベースラインを1つ、見直した戦略を1つ、取り消し可能な行動を1つ用意し、観察した結果を毎週レビューします。

出力

まず、always-current-datetime が求める日付付きの結果または質問を示し、次に該当する項目のみを表示します。目標と証拠、凍結済みの契約、戦略、課題、根拠、テストまたは次のアクション、残る不確実性、判断の根拠、ユーザーの判断です。

必須の回答が1つ必要な場合は QUESTION、実証されていない実行可能な戦略には DRAFT、範囲を限定したテストまたは不足している証拠には TEST、明示した1つの判断基準に基づいて戦略が完了した場合は DONE、不足しているゲートを具体的に示す場合は BLOCKED を使用します。QUESTION では質問を1つだけ尋ねます。簡単な作業をバイパスした場合に、このスキーマを無理に適用してはいけません。

パッケージのリソース

簡潔な実行チェックには references/decision-checklist.md を、再利用可能な戦略パケットには assets/strategy-packet-template.md を使用します。調整には examples/ にある作業例を参照してください。パッケージのメンテナンスでは references/generation-contract.md、scripts/ のバリデーター、scripts/tests/ のテスト、evals/ のオフラインケースを使用します。