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 } というキーが含まれ、認証されたワークスペースが示されます。このような情報は内部で活用してください。
ユーザーから明確に尋ねられた場合、または実際のアカウント・ワークスペースの問題がある場合以外は、認証情報やユーザー、ワークスペースについて言及しないでください。初回コマンドの実行、結果から ID を受け取る、またはこのスキルを後から読み込むだけでは、わざわざユーザーに通知する必要はありません。このルールはマネージド型・スタンドアロン型のどちらの CLI セッションにも適用されます。
ワークスペース情報キーがない場合も、ユーザーに対してワークスペース情報の入力を求めないでください。キーが含まれていないのは、コマンドがワークスペースを解決する必要がなかった場合や、結果が最上位のJSON配列で情報を入れる場所がない場合です。
ブラウザでのサインインは、ユーザーが同意画面で選んだすべてのワークスペースをカバーし、最初に選ばれたものをアクティブにします。clay login --device を使う場合は、実行ごとに 1 つのワークスペースをカバーします。どちらの場合でも既にサインイン済みのワークスペースは保持されるため、clay login を再度実行するとワークスペースが置き換わるのではなく追加されます。
clay workspaces list でワークスペース ID の一覧を表示し、clay workspaces switch <id> で切り替えることができます。サインイン時にアクティブにならなかったワークスペースを使う場合は、明示的に切り替えてください。ペイロードにワークスペースキーがなく、確認が必要な場合は clay workspaces current で直接確認できます。
マネージド Clay セッション内では、これらのルールは適用されません。セッションはそれが作成されたワークスペース内で実行され、clay login / clay logout / clay workspaces は使用できません。ユーザーにサインインを強要しないでください。ただし、別のワークスペースで作業したいという要望があれば、Clay でワークスペースを切り替えて新しいチャットを開始するよう案内してください。このセッションではワークスペースを移動できないためです。
ユーザーが Clay でできることを尋ねてきた場合は、利用可能な clay スキルを使用してください。これは Clay の機能の目次です。
clay --help は最上位コマンドの最新リストです。ヘルプテキストは機械可読仕様となっており、コマンド名、フラグ、JSON 出力形式、エラーコードを確認できます。これを「Clay でできることは何か」という質問への直接的な答えとして扱わないでください。
clay --help # 最上位コマンド
clay <group> --help # グループのサブコマンド
clay <group> <cmd> --help # フラグ、JSON 出力形式、エラーコード
毎回、シンプルな clay コマンドを 1 つだけ実行してください。リダイレクトや値の置換（&&、||、>、$(…)、バッククォート、$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. Use this
information internally. Only mention authentication, the user, or the workspace when the
user asks or an actual account/workspace issue needs their attention. Running the first
command, receiving identity in a result, or loading this skill later in a conversation
does not call for an identity announcement. This applies to managed and standalone CLI
sessions. Don't ask the user for workspace information merely because the key is absent — it 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.
A browser sign-in covers every workspace the user selects on the consent screen, and leaves
the first one selected active; clay login --device covers one workspace per run. Either way
the workspaces already signed in are kept, so clay login again adds more rather than
replacing them. clay workspaces list shows the ids and clay workspaces switch <id> moves
between them, so switch explicitly to work in one the sign-in did not leave active. 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 による自動翻訳です。