はじめに

fx をインストールし、マニフェストを接続して開発を始めましょう。

fx をインストールし、チームのマニフェストを接続してリポジトリやツール、エージェントを利用します。

リリースごとの変更は変更履歴を参照してください。インストール済みの実行ファイルが対応する機能は、fx <command> --help と同梱の Skill で確認できます。

目的に合わせて読み始めてください：

新規ワークスペース：インストール、次にクイックスタート。
マニフェストがまだない場合：対応 CLI のセットアップ。
最新に保つ：ツールと Skill の更新。
リポジトリが多い場合：ダウンロード前に選択。
セットアップが中断した場合：結果の確認と復旧。
コーディング Agent：構造化結果と bundled Skill。

動作環境

Node.js ≥22。開発バージョンは package.json に固定されています。Bun もランタイムとして利用できます。
PATH 上の Git。グローバルインストールと fx self update には、Bun を使う場合も npm が必要です。
ワークスペースには、チームのマニフェスト、または自分で作成したマニフェスト。対応 CLI だけをセットアップする場合は不要です。

macOS と Linux をサポートします。Windows のネイティブアダプターは実装済みですが、実機実行とエージェントホストの有効化は未検証です。対象はローカル NTFS 上の PowerShell 5.1/7 と cmd です。Windows の検証範囲を参照してください。

Bitbucket の Git 認証

bitbucket-cli git --help が使える場合、fx は対応 CLI の既存のログインを利用し、HTTPS 経由で manifest の初期化、リポジトリのクローン、同期を行います。サーバーが HTTPS Git を許可していれば、リポジトリの読み取り権限を持つ Data Center PAT で利用でき、manifest が SSH URL でも SSH キーは不要です。URL の変換は呼び出しごとに適用され、保存済みの remote は変更されません。fx はトークンを読み取ったり保存したりしません。push には書き込み権限が別途必要です。

最初に manifest をクローンする前に、対応 CLI のサービス設定とログインを済ませてください。複数のアカウントでは BITBUCKET_CONTEXT で初期化に使う context を選びます。ワークスペースの操作では manifest の context 宣言が優先されます。bitbucket-cli git -- ls-remote <clone-url> で実際の Git 読み取りを確認できます。対応 CLI が未導入または旧版なら通常の Git 認証を継続するため、この機能には更新が必要です。拒否された認証情報のエラーはそのまま返します。単独の git fetch には個別の認証設定が必要です。代わりに bitbucket-cli git -- -C <dir> fetch upstream を利用できます。再帰的なサブモジュールは未対応です。

インストール

公開パッケージ

公開版は npmjs の @angelmsger/fx を使用します。チームのプライベート Registry は不要です。

npm install -g @angelmsger/fx --registry=https://registry.npmjs.org/ --@angelmsger:registry=https://registry.npmjs.org/
fx --version

現在はソースからも実行できます。

npm ci
npm run build
node bin/fx.js --help
node bin/fx.js --version

以下の例をソースから実行するときは、fx を node /absolute/path/to/fx-devkit/bin/fx.js に置き換えます。ランチャーが dist/ を読み込むため、事前のビルドが必要です。

PowerShell の実行ポリシーが .ps1 shim をブロックする場合は、npm.cmd と fx.cmd を使用します。ポリシーの変更は不要です。

更新

ソースからインストールした場合は Git で checkout を更新し、npm ci と npm run build を実行します。fx self info --format json でバージョンとパッケージ更新元を確認できます。更新ガイドを参照してください。

クイックスタート

必要なのは、チームから渡されたマニフェストの場所と、ワークスペースを作るディレクトリです。Agent に「fx を使い、このマニフェストからこのディレクトリにワークスペースを準備して」と依頼できます。自分で操作する場合は、まず計画を確認して実行します。

fx init ./work --from <manifest-repository> --dry-run
fx init ./work --from <manifest-repository>

fx はソースを検証し、承認済みのローカルツールと設定を準備して、選択したリポジトリと Agent 用のガイド・Skill を配置します。名前は既存の登録と重複しないよう自動で決まり、既存のファイルと完了済みの作業は保持されます。新しいコマンドを承認する前に、表示された引数を確認してください。

Ready to work と表示されたら作業を始められます。個人のログイン、権限、承認が必要な場合は、残る対応がまとめて表示されます。対応後は、返された再開コマンドを使います。

fx init --resume --workspace work

ターミナル出力には、個人のログインコマンドと再開コマンドが表示されます。自分のターミナルでログインを完了し、表示された前提条件を解決してから再開してください。

再開時は現在の状態を検証し、完了済みの準備を省略します。ディレクトリのソースを再取り込みしたり、既存の checkout を作り直したりしません。内部ステージや診断コマンドの組み合わせを覚える必要はありません。

新しいワークスペースでは共有リポジトリをすべて選択します。初回のダウンロードを絞る場合はリポジトリを選び、初回のプレビューと実行に --repos を加えます。既存ディレクトリも自動で採用されます。日常の更新は fx sync、リポジトリの状態確認は fx status を使います。

マニフェストなしで対応 CLI をセットアップする

チームのマニフェストがない場合は、ディレクトリを指定せずに fx init を実行すると、fx が扱える対応 CLI をこのマシンにセットアップします。一覧を表示して必要なものを尋ね、Enter を押すとすべてを選びます。名前を指定すると質問を省略できます：

fx init
fx init --tools bitbucket-cli,jira-cli --dry-run
fx init --tools all

fx はまだ入っていないツールをインストールし、各ツールに自分の Skill を fx 自身の Skill と並べてコーディング Agent へインストールさせ、サインイン済みかどうかを確認します。まだセットアップされていないツールには、そのツール自身のセットアップを始めるかを尋ねます。たとえば bitbucket-cli config init は、サービスのアドレスと認証情報を尋ねます。断った場合、--yes を付けた場合、ターミナルなしで実行した場合は、代わりにそのコマンドを一覧で示します。実行した後に fx init --tools <names> をもう一度実行すると確認できます。すでにあるツールはそのまま残します。更新は別の手順です。

ワークスペースは登録せず、何も事前に設定しません。マニフェストがある場合は、fx init <dir> --from <manifest> がツールを決め、各サービスのアドレスも設定します。

ツールと Skill を最新に保つ

fx self update --yes   # fx と、インストール済みの fx の Skill のコピー
fx tool update --all   # インストール済みのすべての対応 CLI と、その Skill

fx tool update --all はすでにインストールされている対応 CLI を更新し、新しいものはインストールしません。それは fx tool install の役割です。fx がインストールまたは更新した各ツールは、続けてコーディング Agent 向けの Skill をもう一度インストールするので、Agent はいま入っている版の説明を読みます。fx self update は最後に、新しい fx に、それより古い自身の Skill のコピーを更新させます。fx skill update は同じことを単独で行います。ワークスペース内では、同じコマンドがワークスペースの使うツールを更新し、fx sync も Skill を更新します。

ワークスペースの確認と管理

fx workspace list は任意のディレクトリで使えます。デフォルトが未設定の場合や、登録先のルートまたはマニフェストが失われた場合も利用できます。fx workspace show <name> は、マニフェストが正常でなくても、識別情報、ソース、状態、選択の根拠を返します。明示的な選択は fx status --workspace <name> を使います。省略時は現在のディレクトリを含むワークスペースが default_workspace より優先されます。

fx workspace list
fx workspace show work
fx status --workspace work
fx config set default_workspace work

ディレクトリを移動済みの場合は workspace relocate <name> <new-dir> で登録先を更新します。この操作は checkout を移動したり再クローンしたりしません。マニフェストのソース変更には workspace rebind <name> --from <source> を使い、ワークスペースの識別情報と個人の選択を保持します。同じ実体のディレクトリを別名で登録する方法は移行になりません。

workspace unregister <name> は業務 checkout を残して管理を解除します。ライフサイクル操作は --dry-run でプレビューし、管理対象リソースの削除計画と競合を確認してください。外部で作成されたファイルは保持されます。

ダウンロード前のリポジトリ選択

初回ダウンロードを絞るには init に --repos を指定します。名前は検査済みマニフェストに存在する必要があります。--no-repos は空の選択です。既存ワークスペースに対する init で両方とも省略すると、現在の選択を保持します。

fx init ./work --from <manifest-repository> --repos example-api --dry-run
fx init ./work --from <manifest-repository> --repos example-api

既存ワークスペースでは select が選択集合を置き換え、pick が名前を追加し、unpick が除外します。選択の変更でファイルは削除されず、checkout のダウンロードも自動では行いません。取得や更新には続けて sync を実行します。

fx repo select example-api
fx repo pick example-web
fx sync --dry-run
fx sync
fx repo select --all
fx env select dev
fx env select --none
fx env select --all

明示的な Git URL を使い code-host を結び付けていない manifest では、リポジトリの同期にコードホストのユーザー名は不要です。

未取得のリポジトリも一覧に残ります。Agent にそのリポジトリの作業を依頼するか、fx repo show <name> を実行してください。返された next_steps で対象のワークスペースにリポジトリを追加選択して同期し、表示されたパスで元の作業を続けられます。

--all は将来追加される項目を含むチームの全体集合に追従します。現在存在する名前をすべて列挙しても、それは固定リストです。--none は何も選択しません。一覧と変更結果に現在のモードが表示されるため、空の選択と未設定を区別できます。

環境の選択を変更するのはこれらのコマンドだけです。fx login が尋ねることはありません。未設定の場合は宣言されたすべての環境を対象とし、絞り込み方を知らせます。--env はその実行だけを限定し、選択は変更しません。

リポジトリの選択は共有エントリーだけを対象とし、ローカルで登録したリポジトリと manifest checkout は別途管理されます。select は空白区切りの名前、init の --repos はカンマ区切りのリストを受け取ります。

リポジトリ状態の読み方

fx status は対象ワークスペースと未追跡ファイル数を表示します。fx status --dirty は追跡済みファイルの変更と新規の未追跡ファイルの両方を検索します。JSON の dirty は従来どおり追跡済みファイルまたはインデックスの変更を表し、追加された uncommitted はどちらの未コミット作業も表します。無視されたファイルは未追跡作業に含みません。空の結果では、リポジトリ未選択か、フィルターに一致する変更がないかを説明します。

ワークスペースのルートは Git リポジトリではないため、fx status は stray_entries も返します。これはルートにあるファイルやディレクトリのうち、checkout、派生ガイド、fx が保つ Go ワークスペース、エージェントやサービスの設定、ワークベンチのいずれでもないものです。fx doctor は root グループで 1 件ずつ警告として表示し、準備状態の判定には影響しません。

sync は作業ファイルとブランチを保持します。計画された動作を確認してください。追跡済みファイルの変更は skip_dirty となる場合があり、別ブランチの checkout では追跡対象ブランチの参照だけを更新できます。空の upstream は fast-forward する対象がないためスキップされます。追跡対象ブランチがない upstream もスキップされますが、確認が必要なものとして報告されます。更新によって、ブランチが追跡していないローカルファイル (.env のような無視されたファイルを含む) が置き換えられる場合、sync はその checkout を変更せずに残し、outcome local_files_in_the_way を報告して、対象ファイルを files_in_the_way に示します。それらを別の場所に移してから、もう一度 sync を実行します。status は通常 fetch しません。リモートとの比較を更新する場合は --fetch を明示します。

ターミナルでは、sync と init は確認が必要なリポジトリや Skill の行だけを表示し、成功したものはステータス行で数えます。どちらも最後にステージごとに 1 行の結果を示し、続いて解決方法ごとにまとめた阻害要因を示します: サインイン、サービスに拒否されたアクセス、またはこのマシンから届かないサーバーです。届かないサーバーには再確認するコマンドが示されます。--verbose ではすべての行を表示し、パイプや --format json には従来どおりすべての行が届きます。

基本概念

ワークスペースとマニフェスト

ワークスペースは、独立した checkout と管理対象のエージェントリソースを含む登録済みの通常ディレクトリです。マニフェストのソースは ~/.fx/workspaces/<name>/source にあります。fx は管理対象のルートで Git を実行しません。同期は checkout、reset、stash によって未コミットの変更や分岐した履歴、別ブランチでの作業を上書きしません。

どのリポジトリにも属さない成果物は、ワークスペースルートの .workbench/ に置きます。タスクごとに日付付きのディレクトリを 1 つ作ってレポート、計画、証拠を入れ、worktrees/ は git worktree add の作成先、tmp/ はいつでも破棄できるものに使います。派生ガイドがエージェントに同じ規則を伝えます。fx はこのディレクトリに書き込みません。

ルートの AGENTS.md は fx が派生する唯一のガイドで、各エージェントが自分で読み込みます。Claude Code も 2.1.277 以降は同様ですが、ワークスペースルートとその上位ディレクトリに CLAUDE.md や CLAUDE.local.md がない場合に限ります。存在する場合はガイドの代わりにそのファイルが読み込まれるため、先頭に @AGENTS.md を書いてください。

workspace、environments、tools、members の文書に共有情報を記述します。任意の harness 文書では MCP とルールを宣言します。

fx manifest explain 'repos[].upstream'
fx manifest schema --kind tools

個人設定

グローバル設定はワークスペースと設定値を登録します。エージェント選択は同一 FX_HOME のワークスペース間で共有され、リポジトリと環境の選択はワークスペース単位です。repo add はローカル参照を登録し、repo remove は参照だけを削除してファイルを残します。設定のエクスポートには資格情報、信頼記録、マニフェスト checkout は含まれません。

ケイパビリティ、プロバイダー、連携ツール

capability はコードホスト、CI、ログ、エラー追跡などの目的を表し、provider は連携 CLI を通じて実装します。マニフェストが能力、プロバイダー、環境の座標を結び付けます。can は準備状態、where は座標、release check は宣言されたリリースチェックを返します。

ワークスペース単位で結び付ける能力は code-host、issue-tracker、knowledge-base、im、channel、calendar、meeting、task、worklog です。環境単位で platform ごとに結び付ける能力は error-tracker、log-store、metrics、ci、cluster です。対象を指定しない fx can は、これらの能力と、このワークスペースでそれぞれを提供するものを一覧します。fx manifest providers は結び付けの内容と、各能力が受け付ける provider を一覧します。calendar は予定と空き時間の所在です。meeting はオンライン会議とその録画・議事録を保持する会議システムで、予定の管理と会議の開催を別の製品で行うチームは両方を結び付けます。WeCom では、wecom-calendar は WeCom CLI を通じてボットから見える予定を一覧し、wecom-calendar-cli は各メンバー自身のカレンダーのローカルミラーを履歴ごと検索します。サインインと wecom-calendar-cli sync によるミラーの更新は、各メンバーが自分で行います。

ワークスペースの channel を wecom-channel-cli に割り当てると、CLI と Skill をインストールできます。準備状態はエージェントのソケット経由で doctor を実行して確認します。チャネルの監視では、同じ Bot ID を使う別クライアントからの送信も含め、その Bot が作成したメッセージを除外します。CLI とブローカーを一緒に更新し、既存の監視チェックポイントやリレーキューはコンパニオンの移行ガイドに従って照合してください。

スマートボットとの会話には、隔離されたワーカーのワークスペース内でのみ im を wecom-chat-cli に割り当てます。fx can im は現在のタスクへのアクセスを確認し、会話内容を出力せずに読み取りコマンドを返します。CLI は fx tool install wecom-chat-cli でインストールできますが、同梱 Skill は隔離ホストで手動設定します。ワーカー設定を参照してください。

metrics は prometheus-cli が提供します。座標はサービスの scrape job です。where は up{job="..."} クエリを出力し、そのサービスのターゲットのラベル集合を返すので、以降のセレクターを書く出発点になります。何にも一致しないセレクターでもクエリは成功するため、メトリクスには存在確認の probe がなく、where --probe は推測せず unknown を報告します。

tool list/show は要件を表示し、tool install/update は宣言されたインストーラーを使い、login は設定を案内します。認証は各ツールの責任で、保存済みの認証情報をどのサービスへ送れるかの判断も含みます。fx が同梱ツール向けに定義するコマンドは確認なしで実行されます。チームの tools.yaml が追加または上書きした実行ベクトルには一度の信頼が必要で、変更後は再確認します。手動手順の完了を申告するだけでは検証成功の代わりになりません。

ツール定義は内蔵の目録と選択したワークスペースの tools.yaml を統合します。ワークスペースのツールチェーンはそのうち実際に使う部分、つまり結び付けた provider が動かすツールと tools.yaml が宣言したツールです。fx tool list は各ツールがなぜそこにあるかを示し、--catalog は fx が知っていて選ばれていないツールも表示します。選択順は --workspace、FX_WORKSPACE、現在のディレクトリを含む登録済みルート、default_workspace です。解決できない場合は読み取る結び付けがないため、内蔵の目録を表示します。インストール先はパッケージ管理ツールが決め、複数のワークスペースで共有します。

tool install と tool update は名前か --all のいずれか一方を必須とします。install の --all は有効で PATH にないツールを補い、update の --all は選択したツールチェーンの有効なツールのうち PATH にあるものを対象にします。ワークスペース内では、対象外にしたツールを TOOLS_NOT_INSTALLED 通知で示します。明示した名前では無効なツールも選べます。引数なしの呼び出しはパッケージ操作前にエラーになります。パッケージ操作の後、インストールまたは更新した各ツールが選択した Agent 向けに Skill をインストールし、行の skill が結果を示します。

doctor はワークスペースが宣言したツールと、選択された環境で有効な provider の依存ツールを既定で確認します。未使用の組み込みツールは tool list --catalog または明示的な doctor --tool <name> で確認できます。不在でも無関係なワークスペースの異常にはしません。インストールはマシン単位なので、ツールチェーン自体は manifest が宣言する全環境にまたがり、doctor の検査だけが対象環境に絞られます。有効な provider の依存ツールが無効化されている場合は、検査を未完了として報告します。

init/sync も同じ関連ツールを対象とします。任意ツールの不在は表示しますが、準備を妨げません。有効な install_on_init ツールは検証が必要です。無効な任意ツールは、このインストール指定だけで必須にはなりません。

組み込みの Sentry ツールは npm の sentry パッケージからインストールできます。manifest で指定すれば init 中も対象になります。

共有サービス設定と個人の認証情報

manifest の service は URL、context、組織、認証方式などの公開接続設定を宣言します。init、明示的な sync、login が対応 CLI 自身のコマンドで準備し、バックグラウンド hook は確認だけを行います。宣言した認証方式は、fx が context を新しく作るときの既定値にすぎません。自分の context が宣言されたサービスにすでに到達できるなら、どの方式でサインインしていても準備完了として扱われます。fx sync --only services --dry-run でプレビューします。

設定と認証は別です。各メンバーが対応 CLI で自分の認証情報を取得・保存します。競合する既存設定は保持して報告し、sync は個人のログインを行いません。ただし実行のたびに、同じサービスに対する既存のログインをワークスペースの context に関連付けるため、別の場所でサインインした後に覚えておくことはありません。Sentry はワークスペースの .sentryclirc に公開デフォルトのみを書き、外部所有のファイルは保持します。

sync の stages.services と stage_details.services.items が結果を示します。init はこれらを sync 配下に返します。要約にはブロック・失敗項目が残り、--details では成功項目も確認できます。サービス設定と復旧リファレンスを参照してください。

ツールのインストール履歴

fx tool history --format json
fx tool history bitbucket-cli --format json
fx tool inventory --format json

init、tool install、tool update は $FX_HOME/tool-history.json に試行を記録します。installed はパッケージ管理器の成功を示しますが、その後の版確認は失敗する場合があります。started だけでは成功を証明できません。dry-run と init が既存ツールをスキップした場合は記録しません。

tool inventory のインストール元と tool list/show の定義元は別の事実です：

installation_origin	証拠
`fx`	fx がそれまで存在しなかった実行ファイルを正常にインストールし、現在のパスも記録と一致しています。
`external`	fx のインストール記録なしに既知の実行ファイルが存在していました。fx で更新や再インストールをしても、この出所を維持します。
`unknown`	旧履歴、未完了の操作、変更または欠落したパスのため、現在の出所を確認できません。

依存関係の確認は同じ FX_HOME に登録された全ワークスペースを対象とし、有効な任意ツールと内蔵デフォルトを含みます。fx によるインストールが確認でき、残る要求がない場合だけ unused になります。他の FX_HOME や未登録プロジェクトは対象外です。削除の提案は参考情報で、sync/doctor はアンインストールしません。読めない manifest や不十分な証拠から削除可能とは判断しません。

照会は PATH ツールを管理下に移したり過去の履歴を再構築したりしません。一覧のフィールドとローカルデータを参照してください。

fx 同梱 Skill とチーム Skill

fx 同梱 Skill は Agent に CLI の使い方を説明します。インストールやワークスペース登録なしでも読めます：

fx self info --format json
fx skill show
fx skill status

ホストにコピーを検出させるには fx skill install --agent codex を使います。--project は現在のディレクトリ、--dir ./custom-skills は独立ディレクトリを対象とし、後者は --agent、--project と併用できません。単独の Skill コマンドはワークスペースの Agent 選択とは独立しています。検出・置換・削除は Skill リファレンスを参照してください。

明示的な install は認識済みコピーを呼び出した CLI の版に揃え、同版の修復や新しい版の置換も行います。skill update は呼び出した CLI より古い認識済みコピーだけを、すべての Agent のディレクトリで更新し、新しくはインストールしません。self update は新しくインストールした fx からこれを実行します。init/sync は同版を再利用し、新しい版を下げません。外部所有の内容の置換には確認とバックアップが必要です。削除しても Agent 選択は変わらず、後の sync で再インストールされる場合があります。

skill status はインストール版と activation: unverified を返します。ファイルの存在だけではホストによる読み込みを証明できません。必要なときに同梱ガイドを読んでください。

チーム Skill は manifest の skills/ にあり、init/sync が選択ホストへリンクし、ルート AGENTS.md に一覧を生成します。ワークスペースルートから起動してください。子リポジトリでの検出は保証されません。fx sync --only docs,skills で更新します。共有リンク経由で fx 同梱 Skill をインストールせず、ユーザー用コピーか独立ディレクトリを使います。

共有情報への貢献

source push は選択したソースファイルの変更をプレビューまたは提出し、ソース checkout の HEAD、インデックス、作業ファイルを保護します。個人フォークと上流の関係を示す根拠と、Bitbucket または GitHub にある manifest ソースが必要です。実行前に fx source push --help と貢献の契約を確認してください。

主なコマンド

fx <topic> --help で正規コマンドと互換名を確認できます。集合引数は繰り返しとカンマ区切りに対応します。

目的	コマンド
作成、同期、状態確認	`init`、`sync`、`status`
アクセス設定と準備状態	`login`、`doctor`、`can`
座標とリリースの根拠	`where`、`release check`、`repo version`
リポジトリ管理	`repo list/show/pick/unpick/add/remove/fork/open`
環境とエージェント	`env list/show/pick/unpick`、`agent list/pick/unpick`
ツールと Skill	`tool list/show/install/update/history/inventory`、`agent skills`
共有ソース管理	`manifest validate/lint/explain/schema/providers/repo-set/record-probe/render/import`、`source push`
メンバーと設定	`member list/show`、`config list/get/set/unset/export/import`
ホストのリソース	`hook list/enable/disable`、`mcp list/show`
CLI 自体の管理	`self info/update`、`completion`

正確な構文は --help と生成された CLI リファレンスが基準です。

コーディング Agent 向け

fx self info --format json から始めます。初期化では返された initialization_guide を読み、同じ実行ファイルを使い続けます。完全な Skill はその他のタスクを説明します。

--format json を使い、stdout の結果と stderr の進捗・通知・エラーを分けて保存します。既定の結果は準備の判定とすべての障害を保持し、--details で各段階の証拠を展開します。human ではタスクの結果と次の操作を先に表示します。release check の human 出力は、各リポジトリの最初にリリースされる内容を示します。対象ブランチが宣言しているバージョン、両ブランチの先頭コミット、まだ対象ブランチにマージされていないソースブランチのコミット数です。冒頭で失敗、警告、未完了、成功、対象外のチェックを別々に集計します。確認済みの問題はリポジトリごとに表示し、同じ原因の取得不能または部分的な結果は、対象のチェック、リポジトリ、復旧手順とともにまとめます。確認済みの失敗が未完了でもある場合があります。問題なくチェックを完了したリポジトリだけが完了欄に入り、明示的な対象外は成功と区別します。--details は各リポジトリの全チェックを展開します。確認済みの失敗がなくても未完了なら RELEASE_INCOMPLETE を通知します。JSON は従来の ok/complete の意味と構造化されたクエリエラーを保持します。エラー追跡のプロジェクトが未指定なら未完了とし、組織全体を検索しません。端末では色と記号を加え、表を幅に合わせ、エラーをテキストで表示します。パイプやファイルにはプレーンテキストと JSON のエラーエンベロープを出力し、NO_COLOR で色を消せます。コマンドの実行中は、端末に経過時間、数えられる作業の進み具合、待っている対象を示すステータス行を 1 行表示します。この行はコマンドの終了とともに消え、パイプ、ファイル、JSON 出力、--quiet には出力しません。git やインストーラーの実行中は、同じ端末でホスト鍵やパスフレーズを尋ねられることがあるため、ステータス行は描き直さず、5 秒ごとに 1 行として出力します。明示的な --fields は完全な結果から抽出し、ドットパスは平坦なキーになります。例：fx sync --format json --fields operation,preparation.state,items,summary。

リリースバージョンは、ソースブランチのルートに VERSION があれば優先し、両ブランチの先頭コミットで同じパスを読み取ります。前後の空白を除去し、空の宣言は不明のままにします。VERSION がなければ、従来どおり package.json などの依存関係ファイルからバージョンを取得します。依存関係チェックは引き続き依存関係の宣言を読み取ります。

リリースのエラー期間には、相対時間かタイムゾーンを含む開始・終了時刻の組を指定できます。絶対期間は開始を含み、終了を含みません。1 日全体を含めるには、その地域の翌日 0 時を終了に指定します。例:

fx release check fx-example-api --from 2026-04-01T00:00:00+08:00 --to 2026-04-15T00:00:00+08:00 --format json --details
fx repo version fx-example-api --ref main --baseline v1.2.0 --format json
fx repo version fx-example-sdk --path packages/client/package.json --format json

バージョンの証拠は参照をコミットに固定し、実際の宣言フィールドを示し、第一親の履歴でその値が最後に変わったコミットを探します。依存関係だけの編集はバージョン変更になりません。過去の基準との比較は、その参照以降のすべての変更を対象とし、リリースブランチにまだマージされていないコミットとは別です。ソースのバージョンや変更時刻は公開済みである証拠になりません。履歴の欠落や取得上限への到達は、理由付きの部分的な証拠として返します。CLI リファレンスに、複数リポジトリのリリースチェックでこれらの証拠を取得する方法と、パッケージのパスを選ぶ方法を示します。

バージョンの証拠を自動検出するときは、requirements.txt など依存関係だけを記述するファイルを除外します。対応するバージョンソースが存在しても読み取れない場合、別のパッケージへ暗黙に切り替えず、証拠を未完了とします。Gradle は隣接する gradle.properties を使用できます。Maven ではリテラル値、またはプロジェクトの properties 内でリテラル値に解決できる単一の ${property} に対応します。複合式、入れ子の式、未解決の式は VERSION_DECLARATION_UNREADABLE を返し、証拠は未完了になります。

Sentry の証拠は、未解決のクエリに一致し期間内に活動があった取得済み候補を、古い問題も含めて保持します。後から resolved または ignored と確認された状態は監査証拠に残しますが、新規問題の判定から除外します。存続期間全体の初回発生時刻と一覧/期間内の時刻は区別します。ページ取得やメタデータの失敗は明示され、部分的な証拠から問題が存在しないとは判断できません。状態と担当者は各応答を読んだ時点の情報であり、過去の期間内の状態ではありません。イベント数の集計範囲は不明で、今回新たに発生した回数とは扱えません。エラー判定は存続期間全体の初回発生を数えます。古い問題の再発は別途評価します。

repo show は ownership_evidence も返します。リポジトリに結び付く業務範囲、人、チーム、集団としての責任を示します。日付指定は現在のメンバー文書に宣言された有効期間を評価するだけで、過去のスナップショットを復元したり担当者を選んだりしません。

結果	完了の判定
`init/sync/doctor`	`preparation.state` は `planned`、`ready`、`incomplete`。対象は `preparation.scope` の範囲です。
`release check`	`ok`、`complete`、`evidence_complete`、確認項目と `repos` を読みます。公開やデプロイは行いません。
`can`	対象能力の `status` と引き継ぎを読みます。

準備完了の終了コードは 0、未完了は 12 です。プレビューは計画だけです。設定や実行のエラーは元の分類コードを保持し、部分的な stdout を返す場合もあります。doctor.coverage は診断の確認範囲を別に示します。任意のホスト機能の有効化が未検証でも必須作業は阻害しません。ファイルの存在だけでは有効化を証明できません。

リリースレポートを生成できた場合の終了コードは引き続き 0 です。ok は失敗したチェックがないこと、complete はチェック範囲を確認できたことを示します。evidence_complete は取得を依頼したリポジトリの事実も含むため、false の場合は facet_coverage と失敗理由を確認します。observed_at はコマンドの開始時刻です。各リポジトリに正規化された期間を記録し、ポリシーによって期間が異なる場合、最上位の期間は null になります。

Init は承認済みのローカル準備を実行し、完了した手順も結果に保持します。認証が未完了でも、準備を繰り返さないでください。

出力を保存して解析する場合は、タスクで許可されたディレクトリを使ってください。読み取り専用設定はシェルのリダイレクトを制御しません。

まず preparation.next を読み、プレビューの確認、準備完了後の元タスクの続行、Agent の操作、または前提条件の引き継ぎを選びます。next_actions は Agent の操作のみです。個人の操作はブロッカー内の actor: user に残り、条件が変わってから resume を実行します。

preparation.blockers をまとめて確認します。next_actions には正確な argv、cwd、任意の env 座標、承認条件があり、再開時にこれらを保持します。resume は登録済みワークスペースを再開します。既存の承認は維持され、新しい引数列は確認が必要です。登録や clone だけで成功と判断したり、詳細を得るため書き込みを繰り返したり、個人の認証情報をマニフェストへコピーしたりしないでください。

ファイル競合の結果は stage_details.docs.files（init では sync 配下）に残ります。外部ファイルの置換は承認を必要とし、同じ階層にバックアップを保持します。応答契約も参照してください。

設定

~/.fx には登録、個人レイヤー、所有権状態、信頼記録、キャッシュがあります。FX_HOME は fx の個人ディレクトリのみを変更し、連携ツールの資格情報の場所は変えません。

config list はキー、既定値、環境変数名、実効値の出所を示し、config get <key> --explain は各レイヤーを説明します。優先順位は明示的フラグ、環境変数、ファイル、組み込み既定値です。config export/import で個人設定を移行します。

インポートはワークスペース登録を名前ごとにマージし、profile に含まれない既存登録を保持します。指定された個人レイヤーは置き換えますが、既存ワークスペースのルートやソースは変更しません。先に workspace relocate または workspace rebind を使ってください。登録解除には workspace unregister を明示します。計画は登録と残りの準備作業を示し、失われた manifest checkout は表示された init コマンドで復元できます。エクスポートには manifest checkout、信頼情報、認証情報を含みません。

format は出力形式です。command_shell は生成されるコマンド文字列だけを変更し、実行方法は変更しません。auto は Windows で PowerShell、それ以外で POSIX を選択します。--command-shell、FX_COMMAND_SHELL、cmd 設定で変更できます。マニフェストの shell テンプレートはそのままです。

bash、zsh、fish、PowerShell の補完は fx completion <shell> で生成し、必要に応じて自分の環境に読み込みます。

Agent 選択

fx config set agents codex は指定ホストを選び、fx config set agents '' または空の FX_AGENTS は何も選びません。設定と環境変数の上書きを両方解除すると自動検出に戻ります。同じ FX_HOME の全ワークスペースに適用されます。FX_HOME はグローバル Skill や対応 CLI の認証情報を移動しません。

連携

マニフェストでワークスペースの provider と連携 CLI を選びます。fx manifest providers はこのワークスペースで各能力に結び付けられているものを表示し、fx tool list --catalog は、ここで何からも選ばれていないものを含め、fx が知っている連携ツールをすべて表示します。コミュニケーションと知識の入口は連携ツールに引き継ぎ、すべての API を fx が仲介するわけではありません。

Agent の検出には Claude Code、Codex CLI、Cursor などの登録済みホストを含みます。Skill、hook、MCP、ルールの対応はホストによって異なります。同等の機能があると決めつけず、agent list、hook list、mcp list で確認してください。

初期化と復旧結果の読み方

結果に含まれる再開操作に従います。新しいソースが未受理なら完全な再試行コマンドを使い、受理済みなら管理済みソースと既存の選択で再開します。登録やファイルの書き込みは実行済みの効果であり、完了は preparation.state と障害項目で判断します。

ローカルのプレビューはディレクトリ、stdin、Git のコミット済み内容を調べます。新しいリモートソースは取得まで source_inspected: false です。既知のガイド競合と予定コマンドを先に表示し、プレビューだけでは信頼を付与しません。通常のソースガイドから生成先へ不足領域を補い、共有本文は保持します。曖昧なマーカーは管理者が修正します。

部分失敗でも、完了済みのリポジトリ、ローカル準備、利用者のファイルは保持されます。前提条件へ対応してから返された操作で続けます。既存のインストールと検証済みの手順は省略します。相対ファイルはワークスペースのルートを基準とします。空白や Unicode を含むディレクトリにも名前を自動生成するため、返された識別子を使ってください。

SKILL_WRITE_DENIED では対象パスを確認します。FX_HOME を変えても共通ロックは移動しません。fx sync --only repos,docs --no-refresh-manifest で可能な作業を続けられますが、Skill の修復完了とは別です。外部ファイルの置換には承認とバックアップが必要です。Git ソースの更新はローカル変更を保護し、通常の再試行はリポジトリの可読性を再確認します。サポートも参照してください。

doctor --tool <name> は指定したツールのインストールと準備だけを診断・修復し、無関係なリポジトリ、ガイド、ホスト資源を更新しません。ワークスペース全体の検査では --tool を省略します。実行ファイルの起動・バージョン検査に失敗した場合、依存するコマンド検査はその前提条件を待ちます。再ログインが必要だという意味ではありません。

can と検査ありの where は、検査したツールの execution.binary_path、version、cwd を返します。後続の呼び出しにもこのパスと作業ディレクトリを使い、新しい shell の PATH が別のインストールを選ぶことを防ぎます。Provider コマンドと直接の handoff コマンドはこのパスに固定されますが、manifest の shell テンプレートは原文のままです。tool install/update は version_after と binary_path を返します。更新後は準備状態を再確認し、対応する Skill を読み直します。

準備完了はすべての API 操作の権限を保証しません。追加認可の前に必要な操作を試してください。検索できなくても、既知の文書は読める場合があります。デバイス OAuth 非対応の Sentry は service.auth_scheme: token を宣言でき、個人 Token の手動設定を案内します。有効な CLI ログインは引き続き利用できます。Token を manifest やチャットに書かないでください。

login が人の入力を必要とする場合は、許可された handoff を完了して同じコマンドを再実行します。fx は操作の前に現在の状態を確認します。その後、元の can または doctor を再実行し、元のタスクを続けてください。init や sync と同じく、login は既存のログインを再利用する組み込みの手順を、--no-input のときも確認なしで実行します。確認するのはサインインの前だけです。

機械から呼び出す場合、非ゼロ終了でも部分的な stdout と stderr のエラーを両方確認します。完了済みのステップは保持され、handoff、blocked、failed、not_started が残る作業を区別します。集計、計画上の問題、復旧フィールドはログイン応答契約を参照してください。

人に引き継がれたステップは、そのチェックが何と答えたかを示します。ステップの check にはツール自身のメッセージが入り、fx が失敗を読み取れる場合は原因も示します。認証が確立されなかった、サービスが権限を拒否した、接続を確立できなかった、のいずれかです。そのときステップの手順は原因に応じた対処を説明するので、サインインし直す前に読んでください。多くのチェックは原因を示しません。その場合はツールのメッセージとステップの手順に従ってください。

答えが得られなかったチェック（ツールが起動しなかった、または時間切れになった）は、人には引き継がれません。can と where はそれを unfinished に挙げ、ほかに失敗がなければ unknown を返します。login はそのエラーで停止し、部分的な結果を stdout に残します。doctor は確認範囲が不完全な項目として報告します。以前の fx にはこれらのフィールドがありません。fx doctor --tool <tool> --env <env> で、1 つのツールが返したメッセージを確認できます。

Skill の所有権とホストの有効化

ユーザー用 fx Skill はワークスペース間で共有し、ユーザー単位のロックで保護します。チームリンクは各ワークスペースに属し、対応インストーラーは自らの版を管理します。正しいファイルだけではホストの有効化を証明できません。

hook list で対応状況と検証状態を確認します。検証した Grok 1.0.25 は Git ルートでのみプロジェクト hook を検出し、通常のディレクトリ信頼では制限を解消できません。明示的な fx sync --only docs,skills を使い、ワークスペースルートは通常のディレクトリのままにします。ホストの実行承認は別途必要です。

既存のログインを再利用する

初期化ではチーム共通の context 名を維持します。対応する CLI は同じサービスの既存ログインを照合し、個人の認証情報を再利用してから、再ログインが必要かを判断します。トークンは元の CLI の認証ストアに残り、現在の context と既存の ID は変更されません。複数の候補がある場合は、元の CLI の auth reuse --from-context で選択できます。ネットワークやキーチェーンの問題は、認証情報の不足とは別に報告されます。環境どうしが保存済みのログインを共有することがあります。fx login がそのうち 1 つでサインインすると、そのツールで先に完了できなかった環境をもう一度確認し、使えるようになったものを verified として報告します。

メンバーの所属と協力関係

fx member selectors でフィルター値を確認できます。--kind area、scenario、team、function で種類を絞れます。各行は種類、ID、名称、親 area を返し、人物は列挙しません。シナリオを area として指定した場合は、正しい親を指定した完全なクエリを返します。欠けているアカウント情報は不明のままです。責務の情報は担当案の根拠であり、既存の作業項目の担当者を変更する権限ではありません。

著者を調べるには fx member show <account> --system <system> --area <id> --format json を実行し、アカウントが一人だけに完全一致することを確認します。組織上の所属、業務を所管するチーム、本人がその業務で協力するチームと役割を区別します。複数のチームが確認済みの場合もあります。候補は要確認で、記録のない所属は不明です。領域を省略すると有効な関係をすべて返します。

fx member list --team <id> --function <id> --area <id> は全条件を同じ業務上の関係で満たす人を検索します。業務範囲を省略すると組織上の所属も検索対象になります。--as-of YYYY-MM-DD は指定日の宣言済み有効期間を評価します。