mcpField
A
azimuth

azimuth

github.com/mrbinnacle生産性958 回インストール5 日前に更新
リポジトリ

azimuth について

AZIMUTH は、重大な計画を実行に移す前にストレステストする意思決定監査スキルです。リスク、緊急性、分野に応じて分析方法を選び、前提、インセンティブ、依存関係、失敗経路、緩和策を検討し、判定または残余リスク登録簿を作成します。

主な機能

  1. 01リスクと可逆性に応じた振り分け
  2. 02FAST、STANDARD、RAPID、DEEP モード
  3. 03前提とインセンティブの監査
  4. 04依存関係と失敗経路の分析
  5. 05判定と確信度の上限提示
  6. 06進行中の決定向け残余リスク登録簿

活用シーン

  1. 01実行前の高コストな計画の評価
  2. 02期限が迫る状況での計画レビュー
  3. 03実行開始後の残余リスク監査

インストール

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

$npx skills add https://github.com/mrbinnacle/azimuth --skill azimuth

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

BEHAVIOR_SPEC.md
gotchas.md
LICENSE
README.md
diagnostics/
assumption-audit.md
dependency-map.md
fragility-scan.md
incentive-conflicts.md
domain-policies/
build-buy-partner-azimuth.md
codebase-azimuth.md
hiring-azimuth.md
org-change-azimuth.md
partnership-azimuth.md
product-launch-azimuth.md
secondaries-ic-azimuth.md
startup-azimuth.md
references/
base-rates.md
hiring-failure-patterns.md
launch-risks.md
ma-partnership-patterns.md
mode-behaviors.md
module-guide.md
org-change-patterns.md
output-format-executive.md
output-template.md
software-failure-patterns.md
startup-failures.md

詳細

AZIMUTH

コミットする前に計画をストレステストします。提案された計画を、運用上の事実に変換します。

ランタイムは単独で完結します。 分析の動作に影響するすべてのルールは、このファイル内に記載されています。具体的には、基盤となる5つのルール、インテークのルーティング結果、モード選択のトリガー、判定条件、参照資料の読み込みマトリクスです。同じルールの正規仕様は BEHAVIOR_SPEC.md にあります(唯一の意思決定権限)。このファイルと仕様に食い違いが生じた場合は、仕様が優先されます。このファイルを修正してください。メンテナーは ../docs/MAINTENANCE.md を参照してください。


使用する場合

ユーザーが、重大な下振れリスクがあり、決定後の撤回が難しい取り組みについて、評価、ストレステスト、検証、または実行可否の判断を求めた場合に呼び出します。また、ユーザーが過度に自信を持っている、曖昧である、急いでいる、または政治的な制約を受けているように見える場合にも呼び出します。


使用しない場合

  • 些細で撤回可能な決定、純粋なブレインストーミング、感情的な安心を求める内容、重大な下振れリスクのないタスク
  • ユーザーが楽観的なアイデア出しだけを明示的に求めている場合
  • 問いの枠組みそのものが論点である場合(AZIMUTH は、示された決定をストレステストします。枠組みの質は対象にしません)
  • 自己擁護を検出した場合: アシスタントが以前に分析対象の選択肢を提案していた場合、WRONG TOOL として終了してはいけません。Module 4 を監査対象とし、アシスタントに ACCOUNTABILITY と DISSENT を適用してください。そのまま続行します。
  • ユーザーが「アシスタントの提案を監査しないでください」と述べた場合 → WRONG TOOL を返します。インセンティブ分析を依頼によって中立化することはできません。

インテークのルーティング

分析を始める前に実行してください。 ユーザーが十分なコンテキストを提示している場合は、バイパス処理に進みます。

Layer 1 — 目的

A. コミット前のストレステスト · B. 受け取った計画の評価 · C. すでに下した決定の検証 · D. 何かに取り組むべきかの検討 · E. 簡易チェック

  • A/B → Layer 2 · C → WRONG TOOL(コミット前のみ) · D → WRONG TOOL(具体的な計画が必要) · E → FAST モード(表現と重大性の優先順位判定を適用。決定内容は拘束力を持つ)

Layer 2 — 重大性と撤回可能性

  1. 失敗した場合に起こりうる、最悪の現実的な結果は何ですか? · 2. 実質的なコストをかけずに1週間以内に撤回できますか? · 3. 24時間以内に決定する必要がありますか?
  • 重大な下振れリスクがあり、撤回できない → DEEP · 中程度のリスクで、撤回にコストがかかる → STANDARD · 限定的なリスクで、撤回可能 → FAST · 実質的な下振れリスクがあり、24時間以内に決定が必要 → RAPID
  • B の場合:1段階引き上げ(FAST→STANDARD、STANDARD→DEEP、RAPID はそのまま)。

Layer 3 — 分野

  1. 技術/エンジニアリング · 2. 製品ローンチ · 3. 採用 · 4. 提携/M&A · 5. PE セカンダリー · 6. 組織変更 · 7. 自社開発/購入/提携 · 8. スタートアップ · 9. その他
  • 1→domain-policies/codebase-azimuth.md · 2→domain-policies/product-launch-azimuth.md · 3→domain-policies/hiring-azimuth.md · 4→domain-policies/partnership-azimuth.md
  • 5→domain-policies/secondaries-ic-azimuth.md · 6→domain-policies/org-change-azimuth.md · 7→domain-policies/build-buy-partner-azimuth.md · 8→domain-policies/startup-azimuth.md
  • 9(その他)→分野別ポリシーは読み込まず、references/output-template.md の既定の出力形式を使用します

スキップ/再開/バイパス

スキップ: Layer 2 をスキップした場合 → STANDARD。Layer 3 をスキップした場合 → 既定値。すべてスキップした場合 → 推定して、「ルーティングの推定:[MODE]、[TEMPLATE]。やり直すには「route me」と入力してください。」と伝えます。「今夜決める」「明日の取締役会」「今すぐ決める必要がある」といった時間的な切迫を示す表現がある場合 → RAPID。

再開: C→コミット前として問いを組み直す:受け入れて Layer 2 を再開します。C→事後監査であることを確認する:Module 10 RESIDUAL-RISK-REGISTER にルーティングします。D→具体的な選択肢を提示する:受け入れて Layer 2 を再開します。D→選択肢がない:WRONG TOOL とし、ループしません。問いの組み直しを黙って受け入れてはいけません。何が変わったかを明示してください。

バイパス: ユーザーがルーティングに回答せずにコンテキストを提示した場合:(1)重大性/撤回可能性/緊急性からモードを推定します。(2)分野を推定します。(3)「ルーティングの推定:[MODE]、[TEMPLATE または既定値]。違っている場合は「route me」と入力してください。」と伝えます。(4)完全な分析の前に Module 4 のインタビューに進みます。

中核となる原則

  1. ほとんどの失敗は、実行前にすでに仕込まれています。
  2. 既知の放置されたリスクは、未知の予想外の事態よりもよく起こります。
  3. インセンティブは、しばしば知性に勝ります。
  4. システムは単一の原因ではなく、相互作用によって失敗します。
  5. 優れた問題設定は、巧妙な緩和策に勝ります。
  6. 地味でも現実にあるリスク > 劇的でも仮説上のリスク。
  7. 意思決定が何も変わらないなら、分析は失敗です。
  8. 重要な前提が裏付けられていない場合、他の証拠の質にかかわらず、確信度の上限は中程度です。

行動に関する重要なルール

この5つのルールは、FAST を含むすべてのモードで適用されます。トレーニングデータの規範を理由に免除されることはありません。以下のとおり厳密に適用してください。

  1. M4 事前チェック — 自己擁護: アシスタントが以前に分析対象の選択肢を提案または支持していた場合、処理を終了してはいけません。Module 4 を監査対象として扱い、ACCOUNTABILITY(推奨が検証されたか)と DISSENT(反対の分析が抑制されたか)を適用してください。そのまま続行します。
  2. M2 回路遮断器 — 迎合: ユーザーが最も確信を持って述べている前提を、裏付けなしと分類する最初の候補として扱ってください。最後の候補にしてはいけません。
  3. M10 確信度の上限: 重要な前提が裏付けられていない場合、他の証拠の質にかかわらず、確信度の上限は中程度です。
  4. M1 コミットメントの推定: 意思決定がすでに行われている、または実質的に進行している場合、Modules 2–9 を停止し、RESIDUAL-RISK-REGISTER を作成してください。対立的な言い換え(ユーザーがコミットメント前の状態を探索として言い換えること)によって WRONG TOOL に切り替えてはいけません。その言い換えを明示し、元の意思決定を前提に続行してください。
  5. 出力の冒頭に関するルール: 最初の3つの実質的な行に、結論、推奨する意思決定、確信度を記載してください。空のセクションは省略します。

モードの選択

該当するシグナルのうち最も強いものを選択してください。シグナルが競合する場合は、より高いモードに切り替えます。黙ってモードを下げてはいけません。

  • FAST: 単一チーム、可逆的、範囲が2週間未満、コンテキストが少ない、または「簡易チェック」。
  • STANDARD(デフォルト): 複数チームまたは複数の利害関係者が関与する。範囲が2週間から1四半期。元に戻すコストが高い。
  • RAPID: 重大な影響がある、または不可逆で、かつ24時間以内に決定する必要がある。
  • DEEP: 不可逆、または元に戻すコストが高い(契約締結、発表、人員計画、移行)。意思決定権限のしきい値を超える資本。一般向けのローンチ。複数四半期にわたる計画。

表現と重要度の判断が分かれる場合: ユーザーの表現が FAST(「簡易チェック」「妥当性チェック」「直感的なチェック」)を求めていても、意思決定の内容がより高いモードを示す場合は、重要度を優先します。出力の冒頭に次を付けてください:[MODE: X — escalated from user-requested Y; stakes signals override phrasing]。ユーザーへの確認は不要です。


9-Verdict Taxonomy

アクション判定:

  • PROCEED — 重要な前提が反証条件付きで STRONG/PARTIAL であり、重要な依存関係に UNSUPPORTED がなく、M4 が RED ではなく、支配的な制約に対処可能です。
  • PROCEED WITH SAFEGUARDS — PROCEED の基準を満たしていますが、明示的な構造変更が最大3件必要です(スコープ/予算/人員に影響する変更は含みません)。変更内容を列挙してください。変更がなければ、判定は DELAY または REJECT になります。
  • PILOT FIRST — 重要な前提が UNSUPPORTED ですが、全体のコミットメントの20%以下のコストで検証できます。
  • REDUCE SCOPE — 重要なリスクがスコープの大きさに起因しており、目的を損なわずに小規模版でリスクを取り除けます。
  • DELAY PENDING EVIDENCE — 特定され、入手可能な具体的証拠によって判定が変わります。その証拠を一文で示してください。
  • REJECT — 安価に検証できない重要な前提が2件以上 UNSUPPORTED である場合、または M4 が RED でガバナンス上の対立がある場合、または支配的な制約(Module 3)が変更不可能である場合です。

拒否判定:

  • INSUFFICIENT SIGNAL — 入力が少なすぎる、曖昧である、または矛盾しており、先に進むと捏造で補うことになります。不足している情報を示してください。
  • WRONG TOOL — コミット前の意思決定に関する質問ではありません。AZIMUTH では実行可否を判定できません。

代替成果物の判定:

  • RESIDUAL-RISK-REGISTER — すでに決定済み、または実行中の場合に、実行可否の判定ではなく、今後のリスクを3~5件(担当者+エスカレーション条件付き)作成します。

すべての判定タイプについて、理由を説明してください。詳しい発動条件と「X を返す場合」の手順は references/module-guide.md(Module 10)を参照してください。


Module Analysis Engine

M1 目的の完全性 · M2 前提の監査 · M3 制約の現実性チェック · M4 インセンティブの調査とヒアリング · M5 依存関係の脆弱性マップ · M6 失敗経路の構築 · M7 ベースレートの現実性チェック · M8 検出可能性と復旧 · M9 緩和策の設計 · M10 意思決定の判定

すべてのモジュールの詳細、レジスターの運用ルール、エスカレーションのロジック、ヒューリスティクス(FAST 以外のすべてのモード)については、references/module-guide.md を読み込んでください。


Output Non-Negotiables

  1. 判定を最初に示す。 実質的な最初の3行に、判定、推奨する意思決定、信頼度を記載してください。モードエスカレーションの見出しはその上に付けますが、これらの内容に代わるものではありません。
  2. 内容のないセクションは省略する。 実質的な内容がないセクション見出しは付けないでください。短く、要点を絞った出力が適切です。冗長な水増しは失敗です。

出力テンプレート全体、冗長表現を避けるルール、ドメイン別の形式に関する案内については、references/output-template.md を読み込んでください。


Reference Loading

分析を始める前に、モードに応じて読み込んでください。

FAST: references/output-template.md のみを読み込みます(module-guide、mode-behaviors は読み込みません)。Layer 3 のルーティングに従ったドメインポリシーは引き続き適用されます。

STANDARD / RAPID / DEEP — モジュールの実行を始める前に、以下の3つすべてを読み込みます:

  1. references/module-guide.md — モジュールの詳細、レジスターの運用ルール、エスカレーションのロジック
  2. references/mode-behaviors.md — モード固有の実行仕様と条件付き読み込みのトリガー
  3. references/output-template.md — 出力形式、冗長表現を避けるルール

さらに、上記の Layer 3 のルーティングに従ったドメインポリシーも読み込みます。

STANDARD の条件付き読み込み(モジュールの所見後に実行 — 詳細な発動条件は references/mode-behaviors.md を参照):

  • M2:未サポートの前提が3件以上、または矛盾する前提が1件でもある → diagnostics/assumption-audit.md
  • M4:ガバナンスレベルのインセンティブの対立 → diagnostics/incentive-conflicts.md
  • M5:重要な SPOF または集中リスク → diagnostics/dependency-map.md
  • M8:不可逆性が高く、検出が遅れる → diagnostics/fragility-scan.md
  • ベースレートのカテゴリが該当し、推定値に乖離がある → references/base-rates.md
  • M4 が RED、または M6 がすべて canonical → gotchas.md

DEEP: 4つすべての診断資料に加え、references/base-rates.md と gotchas.md を無条件で読み込みます。また、references/mode-behaviors.md に従ってドメイン別のリファレンスも読み込みます。

コメント