Clay CLI（Clayの主なコマンド実行環境。JSON形式の出力と型付きエラーに対応） JSON形式の出力や型付けされたエラー処理が必要な場合、または`clay`コマンドを実行・検索する場合に使用します。 Clayでできることやどのスキルを使うべきかについては、利用可能な場合は`clay`スキルのドキュメントを参照してください。スキルが利用できない場合は`clay --help`を実行してください。 コマンド名、オプションフラグ、JSON形式の構造、エラーコードの詳細については`clay --help`を使用してください。
Clay CLI — the primary scripting surface (JSON output, typed errors). Use when running or discovering `clay` commands. For what Clay can do and which skill to use, read the `clay` skill when it is available; otherwise run `clay --help`. Use `clay --help` for command names, flags, JSON shape, and error codes.
clay CLIclay CLI は Clay の主要なプログラミング用インターフェース（エージェント向けに最適化）で、JSON 形式の出力と型付きエラーコード（エラーの種類を明確にする仕組み）に対応しています。認証は clay login で行います（ブラウザを使った OAuth 認証；clay whoami に失敗した場合は setup スキルを一度実行してください）。ワークスペースは保存されたセッションから自動的に判定されるため、ワークスペース ID を渡す必要はありません。
CLI がどのワークスペースの認証情報かを把握すると、成功したコマンドの JSON には workspace: { id, name } というキーが含まれ、認証されたワークスペースの名前が示されます。複数のワークスペースに同時にログインできますが、ユーザーには CLI がどのワークスペースを向いているかが見えないので、以下のように伝えてください：会話内で clay コマンドを初めて実行する時に名前を示し、ワークスペースが切り替わった時にも再度示します。すべての結果ごとに繰り返す必要はなく、また確認を求める必要もありません。コマンドがワークスペースを判定する必要がなかった場合や、結果が最上位の JSON 配列で workspace キーを置く場所がない場合は、このキーは含まれません。
各ログイン時点で 1 つのワークスペースがカバーされます。複数のワークスペースで作業するには、ワークスペースごとに clay login を一度実行し（2 番目にログインしても最初のものは保持されます）、clay workspaces switch <id> で切り替えます。clay workspaces list で ID を確認できます。ログインすると、追加したワークスペースがアクティブになるため、別のワークスペースに戻る場合は明示的に切り替えが必要です。ペイロードにワークスペースキーがなく確認が必要な場合は、clay workspaces current で直接確認できます。Clay の管理下にあるセッション内では、これらは適用されません。セッションはそれが作成されたワークスペース内で実行され、clay login / clay logout / clay workspaces はそこでは使用できません。ユーザーにログインを促さないでください。ただしユーザーが別のワークスペースで作業したいと言った場合は、このセッションではワークスペース間の移動ができないため、Clay でワークスペースを切り替えて新しいチャットを開始するよう伝えてください。
ユーザーが Clay でできることを尋ねた場合は、clay スキルが利用可能な時にそれを使用します。これが製品機能の目次です。このスキルが CLI の呼び出し方です。
clay --help は最上位コマンドのリストです。ヘルプテキストは機械が読める仕様になっています。コマンド名、フラグ、JSON 出力の形式、エラーコードはここから確認してください。「Clay で何ができるか」という質問の答えとしては扱わないでください。
clay --help # 最上位のコマンド
clay <group> --help # そのグループのサブコマンド
clay <group> <cmd> --help # 詳細なフラグ、JSON 出力の形式、エラーコード
一度に 1 つのプレーン clay コマンドを実行することを優先します。リダイレクト・置換（&&、||、>、$(…)、バッククォート、$VAR など）は避けてください。本当に必要な場合を除き、これらの形式は手動承認プロンプトに進みますが、シンプルな clay <group> <cmd> の呼び出しは自動承認されます。
パイプ処理（|）は、他の段階が jq のような標準的な読み取り専用ツール（標準入力を変換するもので、ファイルは開かないもの）の場合は問題ありません。セミコロンでのコマンド連鎖（;）は制限が厳しく、各句は clay、またはリテラルな echo / printf（cat / jq などではないもの）である必要があります。その他はすべてプロンプトに進みます。
CLI はシェルでのスクリプト作成およびエージェント駆動のタスク実行に使用します。Clay と HTTP で通信するサービス・アプリケーション・統合を構築する場合は、公開 API（public-api スキル）を使用します。
完全な開発者ドキュメント（CLI リファレンス、公開 API リファレンス、概念、OpenAPI 仕様）は https://developers.clay.com/llms.txt にあります。
clay CLIThe clay CLI is Clay's primary programmatic surface, optimized for agents: JSON
output and typed error codes. It authenticates via clay login (browser OAuth;
run the setup skill once if clay whoami fails). The workspace is resolved from
the stored session — there is no workspace id to pass.
Once the CLI knows which workspace a credential is for, every successful command's JSON
carries a workspace: { id, name } key naming the workspace it authenticated as. More than
one workspace can be signed in at once and the user cannot see which one the CLI is pointed
at, so tell them: name it the first time you run a clay command in a conversation, and
again whenever it changes. Don't repeat it on every result, and don't ask for it — the key is
absent when a command never had to resolve the workspace, and when its result is a top-level
JSON array with nowhere to put it.
Each sign-in covers one workspace. To work across several, run clay login once per
workspace (signing into a second keeps the first) and switch with
clay workspaces switch <id>; clay workspaces list shows the ids. Signing in makes the
workspace just added the active one, so switch explicitly to go back to another. When a
payload carries no workspace key and you need to know, clay workspaces current answers
directly. Inside a managed Clay session none of this applies: the session runs in the one
workspace it was created in, and clay login / clay logout / clay workspaces are
unavailable there. Never ask the user to sign in — but if they ask to work in a different
workspace, tell them to switch workspaces in Clay and start a new chat there, since this
session cannot move.
When a user asks what they can do with Clay, use the clay skill when it is available — that is the table of
contents for product surfaces. This skill is how to invoke the CLI.
clay --help is the live list of top-level commands. The help text is a machine-readable
spec: use it for command names, flags, JSON output shape, and error codes. Do not treat
it as the answer to "what can I do with Clay?"
clay --help # top-level commands
clay <group> --help # a group's subcommands
clay <group> <cmd> --help # exact flags, JSON output shape, and error codes
Prefer running one plain clay command at a time. Avoid redirecting or
substituting (&&, ||, >, $(…), backticks, $VAR, etc.) unless it's genuinely
necessary — those forms fall through to a manual approval prompt, whereas a simple
clay <group> <cmd> call is auto-approved.
Piping (|) is fine when the other stages are common read-only helpers like jq that
transform stdin without opening files. Semicolon chaining (;) is narrower: each
clause must be clay, or a literal echo / printf (not cat / jq / …). Anything
else falls through to a prompt.
Use the CLI for scripting and agent-driven tasks in a shell. To build a service, app,
or integration that talks to Clay over HTTP, use the Public API (public-api skill).
Full developer documentation (CLI reference, Public API reference, concepts, OpenAPI spec) lives at: https://developers.clay.com/llms.txt
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。