AXF

AXF

リポジトリを一度整えれば、すべてのエージェントが同じ舗装路を進めます。

エージェントはコードを読めます。それでも、このリポジトリでのビルド、テスト、検索、診断、運用の方法を改めて見つける必要があります。手がかりはたいてい、スクリプト、パッケージタスク、説明文、CI、そして人の記憶に散在しています。

AXF（Agent eXoskeleton Framework）は、繰り返されるこうしたローカルな手順を、小さく自己記述型の機能に変えます。外骨格を一度意図的に装着すれば、後続のエージェントは適切な経路を見つけ、その契約を確認して、手順を一から作り直すことなく実行できます。

recurring repository ceremony
          ↓ fit once
inspectable AXF capabilities
          ↓ reuse
agent discovers → inspects → runs

AXF は交通整理役であり、既存の用語体系を置き換えるものではありません。デフォルトではプロバイダーの既存のコマンド体系を維持し、エージェント向けの契約をより明確にする必要がある部分だけを投影または正規化します。目標は判断を自動化することではありません。同じ経路を再構築するために必要な判断を減らすことです。

呼び出し側が使う5つの概念

整備されたリポジトリを使うために、フレームワークの用語を覚える必要はありません。

• Workspace — 必要な運用経路が含まれるリポジトリのコンテキストです。ルートに依存する契約では、AXF は検出に使うプロジェクトルートと、実行時の作業ディレクトリとして使う実行ルートを区別します。
• Module — 組み込みの echo モジュールや、リポジトリが管理する検証パックなど、再利用可能な機能のパックです。
• Capability — 引数、出力モード、副作用、ライフサイクル、ポリシー、実行先が宣言された、名前付きの操作です。
• Inspect — 実行前に完全な契約を読み取ります。
• Run — 影響と権限要件を確認したうえで、その契約を通じて実行します。

最小限の動作確認は次のとおりです。

npm install --global @smartergpt/axf
axf doctor
axf list --compact
axf inspect echo say
axf run echo say --message hello

AXF 2.1.5 は Apache-2.0 で公開されています。それ以前の npm リリースには、それぞれ公開時のライセンス条件が適用されます。整備済みのワークスペース外で、ルートの上書きがない場合、この例ではインストール済みパッケージに含まれるマニフェストが検出されます。doctor はプロジェクトルートを現在の実行ディレクトリとは別に報告します。明示的な AXF_PROJECT_ROOT がある場合は検出結果より優先されます。axf.workspace.json マーカーのない空のディレクトリには、機能がありません。整備済みのリポジトリには通常、独自の機能が追加されます。echo.say はレジストリ、リゾルバー、アダプター、実行機能が接続されていることを確認するためのものです。

整備前と整備後

AXF を使う前は、新しいエージェントが複数の指示ファイルを検索し、パッケージスクリプトをリバースエンジニアリングし、安全な検証の範囲を推測して、次のセッションでも同じ作業を繰り返します。

意図的に一度整備すれば、リポジトリは context、check、handoff などの安定したエントリーポイントを公開できます。呼び出し側は axf guide から始め、対象の機能を確認し、リポジトリが管理する経路を実行します。AXF は経路を見えるようにしますが、その経路を管理するのは引き続きリポジトリです。

このリポジトリは整備に向いていますか？

次のような場合、AXF が役立ちます。

• エージェントが、どのビルド、テスト、検証コマンドを使うべきか繰り返し推測している。
• 編集前に、同じリポジトリの情報を何度も調べ直す必要がある。
• ローカルの安全ルールが、散在する説明文、慣習、人の記憶に頼っている。
• リポジトリ固有の作業のために、壊れやすいシェルコマンドの連結を何度も作り直している。

明確なコマンドひとつで作業をカバーできる場合、同じ手順を繰り返す可能性が低い場合、またはチームが機能の契約を維持できないほどプロバイダーの仕様変更が速い場合、AXF はおそらく適していません。

導入を検討する際の問いは次のとおりです。

このリポジトリには、安定して確認可能なエージェント機能として一度整備する価値のある、繰り返し発生するローカルな運用手順がありますか？

範囲を限定した、厳密な読み取り専用の評価を行うには、エージェントに次のプロンプトを渡してください。

Evaluate whether this repository is a fit for AXF by following
docs/agent-evaluation.md. Do not install AXF, edit files, scaffold or promote
capabilities, invoke MCP tools, or run repository code. Inspect only the
existing scripts, package tasks, documentation, agent instructions, CI and
platform/runtime constraints. Identify repeated mistakes and existing overlap,
then return exactly one verdict: adopt, pilot, defer, or not a fit. Include the
evidence, expected fitting cost, ongoing drift cost, authority boundaries, and
the smallest reversible pilot. Do not perform the pilot without separate
approval.

証拠のチェックリスト、判定の定義、回答テンプレートについては、エージェント適合性の評価を参照してください。

自分に合った進め方を選ぶ

対象者	ここから始める	担当する作業
呼び出し側またはコーディングエージェント	呼び出し側ガイド	誰かが組み込んだ機能を見つけ、調べ、実行します。
インテグレーションの作成者	インテグレーション作成者ガイド	既存のリポジトリやプロバイダーの手順を、安定した機能に組み込みます。
AXF フレームワークの作成者	フレームワーク作成者ガイド	ローダー、解決処理、アダプター、ポリシー、MCP、その他の AXF 内部を変更します。

プロバイダーの組み込みや AXF 自体の変更を担当していない場合は、呼び出し側ガイドまで確認してください。対象読者の全体像は ドキュメントの階層に記載されています。

ステータス：アルファ。基本的なループが整っています。単一のコントラクトを通じて、機能の調査、確認、実行、ひな形の作成、昇格を行えます。マニフェストバージョン axf/v0 が現在のアルファコントラクトです。

AXF が目指すものではないこと

AXF は、汎用的なコマンドカタログでも、認可の情報源でも、プロバイダーの ID の代替でも、レビューの代わりでも、MCP 専用の製品でもありません。MCP は、同じレジストリと実行経路を使用する、エージェント向けのインターフェースの 1 つです。

インストールと MCP

ライセンス

AXF は Apache License, Version 2.0 の下でライセンスされており、その条件に従って商用および組織内での利用も可能です。該当する通知を保持してください。以前のリリースには、それぞれ該当する条件が引き続き適用されます。

SmarterGPT は Joseph Gustavson（Guffawaffle）によって設立されました。運営方針、コントリビューション、プロジェクトのアイデンティティをご覧ください。コードのライセンスは、実行時の権限を付与するものではありません。

npm パッケージ名は @smartergpt/axf です。次の 2 つの実行ファイルがインストールされます。

• axf — stdio MCP 起動サブコマンド axf mcp を含む CLI のエントリーポイント
• axf-mcp — stdio MCP サーバーのエントリーポイント

MCP クライアントは axf-mcp を直接起動できます。レジストリ経由またはパッケージ経由で起動する場合は、パッケージが基本の axf コマンドのインターフェースを中心に保てるよう、axf mcp を推奨します。どちらのエントリーポイントも、同じ stdio MCP サーバーを起動します。このサーバーは axf という名前の MCP ツールを 1 つだけ公開し、そのツールはバインドされたワークスペースの AXF 既存の機能インターフェースに処理を振り分けます。

グローバルインストール

npm install --global @smartergpt/axf

次に、どちらかの実行ファイルを直接使います。

axf doctor
axf mcp
axf-mcp

設定されたサーバーがインストール済みの CLI と一致していると想定する前に、Codex MCP パッケージの指定を監査してください。

axf integrate codex --check
axf integrate codex --write
axf integrate codex --check --smoke

書き込みは Codex の config.toml にある AXF パッケージ指定のみが対象です。その後、Codex を再起動するか、開き直してください。明示的な off | shadow KnowledgeFrame プロバイダーのロールアウトを含む、AXF と Lex を一度の呼び出しでブートストラップする方法については、パッケージに含まれる templates/session-context ワークスペースレシピと docs/13-repo-onboarding.mdをご覧ください。

リポジトリ内の開発用起動

ローカルクローンから、Node で実行ファイルを直接起動します。

node /path/to/axf/bin/axf.js doctor
node /path/to/axf/bin/axf.js mcp
node /path/to/axf/bin/axf-mcp.js

リポジトリ内の MCP 設定では、MCP の実行ファイルを直接呼び出す方法と、CLI サブコマンドを使う方法のどちらも選べます。クライアントがコマンド引数を適切にサポートしている場合は、CLI サブコマンドを推奨します。

{
  "mcpServers": {
    "axf": {
      "command": "node",
      "args": ["/path/to/axf/bin/axf.js", "mcp"],
      "cwd": "/path/to/project",
      "env": {
        "AXF_PROJECT_ROOT": "/path/to/project",
        "AXF_EXECUTION_ROOT": "/path/to/project"
      }
    }
  }
}

実行ファイルを直接呼び出す設定も引き続き有効です。

{
  "mcpServers": {
    "axf": {
      "command": "node",
      "args": ["/path/to/axf/bin/axf-mcp.js"],
      "cwd": "/path/to/project",
      "env": {
        "AXF_PROJECT_ROOT": "/path/to/project",
        "AXF_EXECUTION_ROOT": "/path/to/project"
      }
    }
  }
}

npm / npx による起動

公開済みパッケージのスモークテストは、AXF リポジトリのルートではなく、/tmp などのクリーンなディレクトリから実行する必要があります。リポジトリのルートから実行すると、npx または npm exec がパッケージからインストールされた axf バイナリではなく、リポジトリ内またはグローバルにインストールされた axf バイナリを使う可能性があります。

レジストリとの互換性が高い起動形式は axf mcp ですが、手動設定では MCP の実行ファイルを直接呼び出す方法も引き続き有効です。次の同等なパッケージ経由の形式では、公開済みの npm パッケージを使います。

npx -y --package @smartergpt/axf axf doctor
npx -y --package @smartergpt/axf axf mcp
npx -y --package @smartergpt/axf axf-mcp

npm exec --yes --package @smartergpt/axf -- axf doctor
npm exec --yes --package @smartergpt/axf -- axf mcp
npm exec --yes --package @smartergpt/axf -- axf-mcp

Windows ネイティブでの起動

レジストリ形式の Windows MCP 設定では、基本の axf.cmd ランチャーに引数として mcp を指定する方法を推奨します。

{
  "mcpServers": {
    "axf": {
      "command": "axf.cmd",
      "args": ["mcp"],
      "cwd": "C:\\src\\my-project",
      "env": {
        "AXF_PROJECT_ROOT": "C:\\src\\my-project",
        "AXF_EXECUTION_ROOT": "C:\\src\\my-project"
      }
    }
  }
}

実行ファイルを直接呼び出す .cmd 設定も引き続き有効です。

{
  "mcpServers": {
    "axf": {
      "command": "axf-mcp.cmd",
      "args": [],
      "cwd": "C:\\src\\my-project",
      "env": {
        "AXF_PROJECT_ROOT": "C:\\src\\my-project",
        "AXF_EXECUTION_ROOT": "C:\\src\\my-project"
      }
    }
  }
}

WSL / Linux での起動

レジストリ形式の WSL／Linux MCP 設定では、ベースの axf コマンドを使い、 最初の引数に mcp を指定してください。

{
  "mcpServers": {
    "axf": {
      "command": "axf",
      "args": ["mcp"],
      "cwd": "/home/user/src/my-project",
      "env": {
        "AXF_PROJECT_ROOT": "/home/user/src/my-project",
        "AXF_EXECUTION_ROOT": "/home/user/src/my-project"
      }
    }
  }
}

バイナリを直接指定する設定も引き続き有効です。

{
  "mcpServers": {
    "axf": {
      "command": "axf-mcp",
      "args": [],
      "cwd": "/home/user/src/my-project",
      "env": {
        "AXF_PROJECT_ROOT": "/home/user/src/my-project",
        "AXF_EXECUTION_ROOT": "/home/user/src/my-project"
      }
    }
  }
}

WSL ユーザーは、Windows の npm shim や npm の _npx キャッシュではなく、 PATH 上にある WSL ネイティブの AXF インストールを使用してください。 ネイティブ CLI を起動するオプションの共有パックにも同じルールを適用してください。 PATH の上位では Linux ネイティブのツールを優先し、WSL から Windows の shim を 呼び出さないようにしてください。

ルートのバインド

axf、axf mcp、axf-mcp は、次の順序でアクティブなプロジェクトルートと 実行ルートを解決します。

1. 明示的に指定された --project-root と --execution-root
2. AXF_PROJECT_ROOT と AXF_EXECUTION_ROOT
3. 従来の CLI エイリアス：--workspace、--registry-workspace、--execution-workspace
4. 従来の環境変数エイリアス：AXF_WORKSPACE、AXF_REGISTRY_WORKSPACE、AXF_EXECUTION_WORKSPACE
5. cwd から最も近い axf.workspace.json
6. インストール済みスクリプトの場所から最も近い axf.workspace.json
7. フォールバックとしての cwd

axf run では、プレフィックスのないルートフラグはサブコマンドより前にある場合のみ グローバルとして扱われます。run の後では、これらはケイパビリティが所有します。 run 以外のコマンドには後続の引数の所有者がいないため、従来の配置を維持します。 --axf-project-root、--axf-execution-root、--axf-workspace の表記は、 コマンドの AXF 管理下の部分で後から指定できます。 axf run ... -- の境界より後では、ルートに関する名前はケイパビリティに属します。

実行引数の所有権

AXF は --axf-* 名前空間をフレームワーク制御用に予約し、自然な公開引数名は ケイパビリティに委ねます。コマンド自体で所有権を明示したい場合は、明示的な境界を 使用してください。

axf --project-root /repo run global.logs.query \
  --axf-json --axf-any-lifecycle -- \
  --json --limit 20 --workspace downstream-name

-- より前のオプションは AXF の実行制御です。-- より後のオプションは公開 ケイパビリティ引数です。AXF は引き続きこれらを解析し、argsSchema で検証と型変換を 行い、argMap でマッピングし、宣言されたアダプターを通じて実行します。この境界は、 生の argv やスキーマ検証を迂回する argv を有効にするものではありません。同じ名前を 両側に異なる所有権で指定できますが、明示的に区切られた各セクション内で重複すると 拒否されます。

axf run echo say --message hello のような、境界を使わない既存の呼び出しも 引き続きサポートされます。この互換形式では、ケイパビリティが同じ引数を明示的に 宣言していない限り、従来の --json、--any-lifecycle、--allow-draft は 引き続き AXF の制御として扱われます。AXF の所有権を曖昧にしたくない場合は、 --axf-json と --axf-any-lifecycle を使用してください。

エージェント優先の探索

すべての完全なマニフェストを要求するのではなく、範囲を限定したワークスペースガイドから 始めてください。

axf guide
axf guide context --json
axf list --compact --search lex --limit 20 --json
axf explain global.lex
axf inspect global.lex.status --json

MCP ルーターは、同じ guide、簡潔な一覧／検索の list、explain、inspect の 結果を公開します。guide は、実行せずにワークスペースまたはファミリーで宣言された コンテキスト、検証、引き継ぎのエントリーポイントを返します。簡潔な一覧項目には ライフサイクル、副作用、ソースの来歴が保持され、完全なスキーマと実行ターゲットは inspect するまで省略されます。

AI エージェントは MCP の結果を主に利用するため、AXF は responseDetail: "compact" をデフォルトとしています。これは、ケイパビリティデータ、 対応可能なエラー、警告、必須の安全状態を含む、決定論的な最小限の安全な エンベロープです。拡張された正規の結果を得るには responseDetail: "standard" を、 来歴、ワークスペースのバインド、起動動作を調査する場合は明示的に responseDetail: "diagnostic" を指定してください。呼び出しトレースは、通常の成功時 および失敗時の結果には含まれません。診断用のフレームワークメタデータでは、機密性の 高いフィールド名と値が秘匿されます。レスポンスの詳細度によって、ケイパビリティが所有する data が切り詰められたり、秘匿されたり、その他の方法で変換されたりすることはありません。 すべての応答プロファイルで、projectRoot と executionRoot はバインドされた状態を維持します。両方のルートが同じチェックアウトを指している場合も同様です。MCP の機能エントリーには、互換性のある scope フィールドに加えて registryScope が公開されます。global は AXF レジストリの名前空間を示すものであり、プロバイダーの保存先を示すものではありません。CLI の inspect 結果には、詳細度がコンパクトな場合も、コマンド／引数／作業ディレクトリを要約した、機密情報を伏せた起動サマリーが含まれます。ルートと起動メタデータが示すのはルーティングであり、プロバイダーの認可ではありません。プロバイダーの保存先に関する事前チェックと書き込みレシートはプロバイダーが所有する data のまま維持され、変更されずに引き渡されます。

{
  "operation": "run",
  "responseDetail": "compact",
  "target": { "id": "global.lex.status" },
  "args": {}
}

compact リストオプションと responseDetail は、意図的に別々に設定します。compact は要約された機能エントリーを選択し、responseDetail はエージェント向け応答エンベロープ全体の詳細度を制御します。デフォルトのコンパクトな MCP list 応答は、limit が省略された場合、個別に最大 25 件に制限されます。これはリスト項目の compact オプションを有効にするものではありません。この上限を変更するには limit を明示的に指定してください。または、デフォルトの上限を適用しない場合は、limit を指定せずに standard または diagnostic を明示的にリクエストしてください。

AXF 2.0 では、MCP の暗黙の応答が 2.0 より前のリッチなエンベロープから compact に変更されます。プロベナンスや起動メタデータを利用する呼び出し元は diagnostic をリクエストする必要があります。呼び出しトレースなしで展開された結果が必要な呼び出し元は standard をリクエストできます。

AXF のプロジェクトルートと実行ルートは、ファイルシステムの検出／実行に使うバインディングであり、テナント、リポジトリ、ワークスペース、許可、認可の根拠ではありません。環境に存在するルート環境変数は、引き続き互換性／設定用の入力としてのみ扱われます。AXF がそれらを権限として扱うことはありません。セキュリティ上重要なホストでは、ルートを明示的に渡し、AXF を呼び出す前に操作を認可してください。プロバイダーが所有する ID と認可はプロバイダー側に留まり、AXF は Lex を必須とせず、Lex の権限を再構築することもありません。

推奨宣言、不足している機能の診断、CLI／MCP の例については、エージェントの検出とワークフローガイドを参照してください。

機能は、即時の結果では特定の外部操作が進行中のままとなる場合、検証済みの型付き継続を返すこともできます。最初の継続の種類は global.wait.external を経由してルーティングされます。この種類に対応する、プロセスにバインドされた GitHub プロバイダーは、特定のコミット SHA に対する明示的な必須チェック、または特定のレビュアー ID によるプルリクエストレビューを監視します。ディスクリプター、権限、キャンセル、結果の境界については、待機可能な完了を参照してください。

検出と実行で同じリポジトリを使う場合は、AXF_PROJECT_ROOT と AXF_EXECUTION_ROOT の両方に同じパスを設定します。異なるリポジトリを使う場合は、それぞれ独立して設定します。従来の AXF_WORKSPACE は互換性のためのエイリアスとして、両方のルートを 1 つのパスにバインドします。

MCP クライアントでは、cwd に呼び出し元が実行する対象のディレクトリを設定し、可能であれば AXF_PROJECT_ROOT／AXF_EXECUTION_ROOT を明示的に設定してください。これにより、マニフェストの検出と呼び出し元向けの実行が決定論的になります。

プロジェクト間で共有するオプションのパックを、ユーザーまたはマシン単位の AXF ルートから利用する場合は、AXF_MACHINE_ROOT を設定します。同じファミリー名の場合、プロジェクトルートのファミリーがマシンレベルのファミリーより優先されます。

インストール後は、どのディレクトリからでも次を実行できます。

axf doctor
axf list
axf inspect echo say
axf run echo say --message hello
axf scout --check
axf run toy echo say --message hello
axf init capability global.acme.status

axf doctor は選択したワークスペースのソースを報告します。また WSL では、axf、lex、node、npm が /mnt/c/... 配下の Windows PATH エントリー経由で解決される場合に警告します。

MCP のルーティングとガバナンス

MCP サーバーは、axf というツールを 1 つ公開します。サポートされている操作は次のとおりです。

• help
• guide
• list
• explain
• inspect
• run
• doctor
• scout_check

これらの操作は、AXF のマニフェストに基づく検出、リゾルバー、ライフサイクル、ポリシー、アダプター、実行パスにルーティングされます。MCP が第 2 のガバナンスモデルを追加したり、AXF を迂回する生のシェル実行を提供したりすることはありません。

AXF MCP は、現時点では CLI との完全な機能同等性を意図的に備えていません。init、promote、demote、scout --write、その他のレジストリやマテリアライゼーションのフローなどのコマンドについては、引き続き CLI が正式な変更・制御プレーンです。

global.echo.say のような機能は、独立した MCP ツールではありません。ルーターの契約を確認するには operation=help を、機能を検出するには operation=list を使用し、operation=run の前に operation=inspect を実行してください。機能の lifecycleState、sideEffects、policies、ワークスペースのバインディングは、実行契約の一部として扱ってください。

scout_check は、AXF 固有の読み取り専用の構造化された scout 診断機能です。axf scout --check と文字どおりの機能同等性を保証するものではありません。

レジストリとマニフェストの更新は、引き続き通常の AXF CLI およびファイルシステム／制御プレーンのフローで行われます。MCP サーバーはリクエストごとにレジストリの状態を再読み込みするため、外部で行われた AXF の更新は、サーバーを再起動せずに後続の MCP 呼び出しで反映されます。

CLI との完全な機能同等性は、明示的なポリシーと承認ゲートを設けたうえで、将来的に検討される可能性があります。

共有パックは、バインドされた AXF プロジェクトルートまたはマシンレイヤーで機能が検出またはマウントされた場合にのみ、AXF 経由で利用できます。

実装済みの機能

組み込みアダプター

AXF には、次の 2 種類の公開組み込みアダプターが含まれています。

• internal — ハンドラーをプロセス内で実行します（adapters/internal/）
• cli — stdout の JSON 解析に対応した汎用サブプロセスディスパッチャーです（adapters/cli/）

共有コマンドファミリーは、プロジェクト所有の機能と同じアダプター契約を使用します。共有パックでは、汎用の cli アダプター、プロバイダーアダプター、または内部ハンドラーを使用できますが、AXF コアはそのパックを実行時依存関係として要求しません。

組み込み機能

機能	プロバイダー	ライフサイクル	備考
global.echo.say	internal	active	最小のプロセス内機能の例
global.wait.timed	wait	active	プロセスに紐づいた 1 秒から 30 分までの中断。経過時間を外部処理の完了とはみなしません
global.wait.external	wait	active	型付きの外部完了をプロセスに紐づけて監視します。GitHub の厳密な head チェックとプルリクエストレビューは、組み込みプロバイダーです
global.await.external	await	active	公開済みの 2.0.0 契約における global.wait.external の非推奨の互換エイリアス

Lex パックを含むオプションの共有パックは、マシンまたはプロジェクトのスコープに追加できます。フレームワーク自体を定義することなく、同じリゾルバー、ライフサイクル、ポリシー、アダプター、実行パスを通じてルーティングされます。

ツールスペース

• toy — 最小のマウント例です。ローカルのデフォルト設定で echo.say を再マウントします

リポジトリの導入

推奨されるリポジトリの手順は次のとおりです。

1. リポジトリのルートに axf.workspace.json を追加し、ワークスペースのバインディングを明示します。
2. リポジトリで共有パックが必要な場合は、マシンまたはプロジェクトのスコープに意図的に追加します。
3. リポジトリ固有の機能は、manifests/capabilities/ または manifests/families/ に別途追加します。
4. MCP は任意の機能として扱います。MCP がなくても、AXF は通常の CLI 機能ルーターとして動作します。
5. 変更を伴う機能には sideEffects: "write" を設定します。AXF にはまだ第一級の approvalRequired フィールドがないため、現時点では承認ゲートはリポジトリのポリシーまたはレビューの慣例に委ねます。

具体的な導入パターンとプラットフォームに関する注記は、docs/13-repo-onboarding.md を参照してください。

新しいプロバイダーの追加方法

この契約はオープンです。まず、そのプロバイダーに必要なのがコマンドファミリー、選択的なマテリアライズドオーバーライド、プロバイダーアダプターのどれかを判断してください。その判断の手順は Integration author guideに記載されています。プロバイダーアダプターが必要なのは、汎用 CLI ルートではプロバイダーの引数、エンベロープ、失敗、出力の契約を表現できない場合に限られます。

プロバイダーアダプターが妥当と判断された場合、スキャフォールドはdraftから始めます。

# 1. Scaffold a draft provider adapter (only if the provider has an
#    envelope or quirks the generic cli adapter shouldn't carry):
axf init adapter --kind provider acme --composes cli

# 2. Scaffold each capability:
axf init capability global.acme.status

# 3. Edit the drafts, then:
axf doctor
axf inspect global.acme.status --json

prompts/にある4つの標準プロンプトは、実際のファイル契約に沿って、エージェントによる調査 → 計画 → スキャフォールディング → レビューを案内します。JSON を優先するプロバイダーは、通常、汎用のcliアダプターをそのまま使用できます。プロバイダーアダプターは、汎用ルートでは対応できないエンベロープ、エラー、引数の正規化が必要なラッパー向けです。

非アクティブな機能を実行するには、ライフサイクルの明示的なオプトインが必要です。また、実際にプロバイダー側の処理が実行されることもあります。実行するのは、確認を行い、リポジトリの通常の承認プロセスを経た後に限ってください。ライフサイクルの変更ではマニフェストを検証しますが、レビューは実施しません。

構成

axf.workspace.json               # workspace marker
bin/axf.js                      # CLI entrypoint
src/cli/                        # CLI parsing + main dispatch
src/core/                       # registry, resolver, executor, adapters, doctor, policy
adapters/<type>/                # type adapters (internal, cli, ...)
adapters/<provider>/            # optional provider adapters for wrapped CLIs
manifests/capabilities/         # capability manifests
manifests/toolspaces/           # toolspace mount manifests
prompts/                        # canonical prompts for agent-authored adapters
docs/                           # architecture, contract, lifecycle, prompts
test/                           # node:test suite

ドキュメント

現在の作業に該当するガイドから始めてください。

• Caller guide — 機能を検出、確認し、適合済みの機能を実行します。
• Integration author guide — プロバイダーの語彙を維持しながら、繰り返し発生するリポジトリやプロバイダーの定型作業に適合させます。
• Framework author guide — AXF の内部構造と、サーフェス間の契約を変更します。
• Awaitable completions — 型付きの継続を返し、スケジュールを行わずに外部処理の完了を正確に確認します。

Documentation pathsでは、各利用者に関連するリファレンスドキュメントを案内しています。リポジトリのオンボーディングを行うかどうかを判断しかねる場合は、事前に read-only agent fit evaluationを使用してください。

テスト

npm test

Node 組み込みのnode:testを使用します。外部のテストランナーは不要です。

意図的に含めていないもの

• 広範なコマンドエイリアスレイヤー
• 特権を必要とする統合経路
• プラグインマーケットプレイス
• リモート実行や MCP サポートの必須化
• 自動的に昇格する、エージェント生成の機能