miles

Miles AI Website Designer

Miles は、組み合わせ可能なプリミティブを CLI から操作する AI ウェブサイトデザイナーです。各プリミティブは、構造化された JSON 出力と意味のある終了コードを備え、1 つの役割を果たします。また、ユーザーが一連の体験を希望する場合は、それらをつなげて、ガイド付きのデザインワークフロー全体を実行できます。全工程（ディスカバリーインタビュー → ブリーフ → デザイン案 → 構築 → WordPress テーマ）を実行することも、必要なステップから始めることもできます。

すべてのコマンドは、同梱の CLI を通じて実行してください。$MILES_CLI は、このスキルの scripts/miles ランチャーへのパスを意味します。

MILES_SKILL_DIR="${MILES_SKILL_DIR:-/path/to/miles}"
MILES_CLI="${MILES_CLI:-$MILES_SKILL_DIR/scripts/miles}"
"$MILES_CLI" doctor --json

時間のかかるコマンド（サイトの構築やテーマの変換）には、Bash のタイムアウトを 10 分（600000ms）に設定してください。クリーンなテスト環境を使うには、MILES_HOME=/path/to/isolated/state を指定します（デフォルトは ~/.miles）。

コマンド一覧

以下は、サポート対象の公開コマンド一覧です。他のコマンドを作らないでください。HEADLESS = ブラウザーなしで動作します。CONDITIONAL = 基盤となるターンがブラウザーに依存しない場合に限り、ヘッドレスで完了できます。BROWSER = 事前に connect-browser でダッシュボードに接続する必要があります。LOCAL = ファイルシステムのヘルパーです。内部で Miles サーバーを操作する場合、その操作にも引き続き機能による制限が適用されます。コマンドを使用する際は、references/ 内のリファレンスファイルを読み込み、各コマンドのフラグ、JSON スキーマ、判断基準を確認してください。

コマンド	モード	機能	リファレンス
miles auth [login|poll|status|logout]	HEADLESS	デバイスコードによるログインのライフサイクル	auth.md
miles account-status --json	HEADLESS	プラン、クレジット、サイト数 — 余裕度の確認	account-status.md
miles site-create "<description>" [--brief <file>] [--attach <file>]	HEADLESS	新しいクラウドサイトと会話を作成するか、現在ペアリングされているローカル WordPress サイトで会話を開始します。--brief を指定するとヒアリングを省略します	site-create.md
miles say "<message>" [--attach <file>]	HEADLESS*	Miles と会話します。質問への回答、概要へのフィードバック、編集ができます	say.md
miles upload-assets <file> [...]	HEADLESS	ブランドアセット（ロゴ、画像、コンテンツ文書）をアップロードし、再利用可能な参照を取得します	upload-assets.md
miles design-directions --json	HEADLESS	生成されたデザイン案を ID とプレビュー付きで一覧表示します	design-directions.md
miles build-site --design <n>	HEADLESS	デザインを確定し、完全な HTML サイトを構築します	build-site.md
miles wait-job / miles cancel	HEADLESS	実行中のターンを待機または停止します（JSON と終了コード）	wait-job.md
miles approval-respond --grant <id> --response approved|declined	CONDITIONAL	ユーザーの明示的な同意または拒否を受けて、保護対象の稼働中サイトに関する承認に回答します	live-protection.md
miles undo	HEADLESS	サイトとチャットをまとめて、直前のターンを 1 段階戻します	undo.md
miles site-state [--full] --json	HEADLESS	フェーズ、デザイン案、接続状態、サイトプラン、次の推奨アクションを表示します。--full を指定すると、概要テキスト、デザイン案の詳細、セッションメモリも表示します	site-state.md
miles site-plan [--history] --json	HEADLESS	現在のサイトプランを損失なく取得します。必要に応じて、重複を除いた改訂履歴と項目ごとの変更も含められます	site-plan.md
miles site-attach <siteId> [--duplicate]	HEADLESS	所有する任意のサイトを再開します。リスクの高い変更を行う前に複製します	site-attach.md
miles wordpress-detect --json	LOCAL	現在のフォルダーまたはその上位フォルダーにあるローカル WordPress インストールを受動的に検出します	wordpress-detect.md
miles wordpress-setup --use local --json	LOCAL	選択したローカル WordPress インストールに Miles をインストール、有効化し、接続します	wordpress-setup.md
miles site-pages [path]	HEADLESS	構築済みサイトのファイルを一覧表示するか、指定したファイルの内容を取得します	site-pages.md
miles history [--limit <n>] [--offset <n>]	HEADLESS	ページ分割された会話の記録を表示します。デフォルトでは新しいターンから表示します	history.md
miles screenshot <preview-url> [--full-page]	HEADLESS	任意のプレビューをローカルの JPEG としてキャプチャします	screenshot.md
miles screenshot --live [--viewport]	BROWSER	接続されたダッシュボード経由で、稼働中の WordPress フロントエンドをキャプチャします	screenshot.md
miles export [--type html|theme] [--download <file>]	HEADLESS*	成果物の URL を取得します。--download を指定すると、テーマ ZIP をストリーミングします（ブラウザー経由）	export.md
miles rename "<name>"	HEADLESS	サイトの会話名を変更します	rename.md
miles usage-history	HEADLESS	アカウントのクレジット取引履歴を表示します	usage-history.md
miles connect-browser [--open] [--wait]	—	唯一の明示的なブラウザー接続ゲートです。認証済みダッシュボードの URL と接続状態を取得します	connect-browser.md
miles convert-theme	BROWSER	HTML サイトを WordPress ブロックテーマに変換します	convert-theme.md
対応している動詞：doctor、status、sites、use、messages、balance、wait。以前の動詞名（create-site、reply、select-design-direction、preview、build-theme、export-site、export-theme、login、whoami、logout）もエイリアスとして引き続き使用できます。

* say は、ディスカバリー、ブリーフ、ビルド前のフィードバックまで、ヘッドレスで実行できます。ビルド済みの WordPress サイトの編集はブラウザー経由で行われます。接続がない場合、CLI は終了コード 3 で即座に失敗します。approval-respond は許可への応答をヘッドレスで行えますが、再開した保護対象の作業ではダッシュボードが引き続き必要になる場合があります。export --type html は完全にヘッドレスです。

CLI は接続中のサーバーがサポートするプリミティブを自動で確認します（miles doctor --json では server.primitives の下に表示されます。プリミティブごとの操作はそこには表示されず、CLI がコマンド内で確認します）。サーバー側のプリミティブが不足している場合、サーバーが古いバージョンです。回避策を講じず、ユーザーに伝えてください。機能チェックでサーバーにまったく接続できない場合、コマンドは capabilities_unreachable と safeToRetry: true を伴って終了コード 2 を返します。これは一時的な障害であり、プリミティブの不足ではありません。wordpress-setup --use local では、wordpress-bootstrap が特に必要です。サーバーにこのプリミティブが含まれる前は、ローカルの WordPress インストールに触れずに終了コード 2 を返します。ペアリング済みのローカルサイトでデザインを開始する場合は、site-create.operations.local-wordpress 操作も必要です。この操作が利用できない場合、site-create はアップロード、リモート側の変更、クレジットの消費を行う前に終了コード 2 を返します。クラウドサイトへのフォールバックは決して行いません。

終了コードと結果

すべての動詞で共通の終了コード体系を使用します。説明文ではなく、コードに基づいて分岐してください。

• 0 — 完了
• 1 — 失敗または中断（エラーを確認し、むやみに再試行しないでください）
• 2 — 前提条件の不足（未ログイン、アクティブなサイトがない、未対応のプリミティブ、不正な使い方）
• 3 — need_connection：connect-browser --json の URL を開き、connected: true を待ってから、同じコマンドを一度再試行します
• 4 — ブロック、承認が必要、または拒否：要求された作業は実行されていません
• 5 — 容量不足：別のターンがすでに実行中、またはサーバーが過負荷です。待ってから再試行してください

完了したターンには、wait-job の JSON で outcome（completed | blocked | declined | aborted | need_connection | capacity | failed）が、ストリーミング出力で [outcome: ...] が付与されます。コマンドがテキストを出力したからといって、成功したと決めつけないでください。 declined の結果は、ユーザーが拒否したことを意味します。再試行したり、別の方法で回避したりしないでください。詳細：outcomes.md。

ヘッドレスとブラウザーの境界

ビルド済みの HTML サイトまでは、すべてヘッドレスで実行できます。ディスカバリー、ブリーフ、デザインの方向性、サイト全体のビルド、スクリーンショット、HTML のエクスポートが含まれます。ブラウザーが必要になる境界は、「ビルド済みの HTML サイト」と「WordPress」の間です。テーマへの変換と、変換済み WordPress サイトの編集は、接続済みのダッシュボードブラウザーを通じて実行されます。

connect-browser は、明示的に確認できる唯一のゲートです。コマンドの途中で突然求められることはありません。接続が必要なコマンドは終了コード 3 で即座に失敗します。接続したら、一度だけ再試行してください。ヘッドレス作業のためにダッシュボードを先回りして開かないでください。ユーザーがデザイン生成やビルドをライブで見たい場合は開いてください（進捗を確認するのに最適な画面です）。ホストごとのブラウザーツールのマッピングと接続の復旧については、browser.md を参照してください。

ライブ保護の承認は、ブラウザー接続とは別の安全ゲートです。wait-job、status、または site-state が approvalRequired を返した場合は、作業を止め、その保護対象の変更について承認または拒否するようユーザーに確認してください。say で応答したり、元のタスク、無回答、「続けて」という指示、または曖昧な肯定から承認を推測したりしてはいけません。 最新のユーザーメッセージで、保留中の変更に対する承認または拒否が明示されている場合に限り、miles approval-respond --grant <id> --response approved|declined を実行できます。Miles 自体のロックまたはロック解除は、このスキルでは行えません。Miles アプリのコントロールを使うようユーザーに伝えてください。詳細：live-protection.md。

WordPress サイトの選択

ユーザーが WordPress を使いたい場合は、まずユーザーと一緒に WordPress の対象を決めます。ユーザーがローカルまたはリモートの WordPress サイトを明示的に選択しない限り、Miles クラウドを安全なデフォルトとして使用します。

質問する前に、受動的なローカル構成チェックを実行してもかまいません。

"$MILES_CLI" wordpress-detect --json

このコマンドは受動的な処理としてのみ扱ってください。ファイル名を調べ、現在のフォルダーが WordPress のように見えるかを報告できますが、WordPress、WP-CLI、PHP、プラグイン、テーマ、またはデータベースを使用するチェックを実行してはなりません。localWordPress.found が false の場合は、通常のクラウドフロー（site-create）を続行します。true の場合は、Miles クラウド、このローカル WordPress インストール、リモート WordPress サイトのどれを使うか、ユーザーに直接質問してください。検出されたというだけでローカルを選んだと判断してはなりません。詳細：wordpress-detect.md。

ユーザーがローカルを選択した場合は、次を実行します。

"$MILES_CLI" wordpress-setup --use local --json

セットアップコマンドは、ローカル利用についてユーザーの明示的な同意を得る境界です。コピーまたは有効化の前に、サーバーが wordpress-bootstrap をサポートしている必要があります。WP-CLI で WordPress のバージョンを取得できる場合は、コピーまたは有効化の前に Miles プラグインのヘッダーを確認し、互換性のないサイトでは検出したバージョンと必要なバージョンを示して、終了コード 2 で終了します。WP-CLI がない場合はバージョンが不明となり、確認なしでコピーした後、手動の引き継ぎに進みます。Miles プラグインのファイルを wp-content/plugins/miles にダウンロードすることや、MILES_PLUGIN_SOURCE が明示的に設定されている場合に限り、ローカルのプラグインソースをコピーすることがあります。WP-CLI が動作する場合は、プラグインを有効化し、アプリケーションパスワードが必要なときに明らかにローカルまたは開発用の URL に対して WP_ENVIRONMENT_TYPE=local を設定し、Miles API にローカルサイトの認証情報を問い合わせ、その認証情報を wp miles local-setup に渡し、ローカルの WordPress 管理ページを現在の Miles サーフェスとして保存することもできます。WP-CLI は任意です。存在しない場合や、ローカルサイトのデータベース／ランタイムを読み込めない場合の代替手段は、ユーザーによる操作への引き継ぎであり、エージェントがクリックできると仮定してはなりません。コンテナ化されたインストールには、ドキュメントに記載された公式の Docker WP-CLI アダプターを使用してください。ユーザーに adminPluginsUrl を開いてもらい、求められた場合は WordPress にサインインしてもらい、自動で有効化できない場合に限り Miles を有効化してもらってください。有効化の確認後、milesAdminUrl を開き、プラグインのセットアップフローを完了してもらいます。ホストで利用可能で、ユーザーがすでに認証済みの場合はブラウザー自動化で補助してもかまいませんが、クリック機能があることを前提にしなくてもスキルが動作する必要があります。プラグインのオプションやシークレットを自分で書き込んではなりません。詳細：wordpress-setup.md。

ローカルの WordPress サイトが有効になると、そのサイトは排他的な対象ロックとなります。クラウドサイトは存在しないものとして扱います。sites が返すのはそのローカルサイトのみであり、use で切り替えることはできず、site-attach で別のサイトを接続または複製することもできません。また、account-status はクラウドサイトを照会もカウントもしません。以降のすべてのビルド、編集、変換、エクスポート、ブラウザへの引き継ぎは、正確にペアリングされたローカルサイトを対象として続行してください。サポートされる終了方法は、ユーザーが明示的に選択した後に miles wordpress-setup --use cloud --json を実行することだけです。これにより、保存済みのペアリングは後で再利用できるよう保持したまま、アクティブなローカルの選択が解除されます。ローカルで利用できない機能を回避するためだけに、このコマンドを実行してはなりません。

リモートドメイン上の WordPress サイトについては、ファイルシステムからインストールまたはブートストラップを試みないでください。wordpress-setup の出力またはリリースマニフェストに記載された Miles プラグインのリンクを提示し、ユーザーに手動でインストールしてもらってから、インストール後にプラグインのペアリングフローを使用します。

エントリーポイントを選ぶ

状態は会話から導き出され、単調に進行します。すでに持っているものに合った作業から、どこからでも始められます。インタビューは数あるプリミティブの1つであり、ワークフロー全体を収めるものではありません。

• 「ウェブサイトを作って」（ユーザーが参加しており、体験を求めている） → ガイド付きワークフロー全体を実行します。Miles のインタビューをユーザーに伝え、ブリーフを見せ、デザイン案を提示してから構築します。full-workflow.md を読み込みます。伝達ルール、ブリーフのレビュー用テンプレート、進捗の示し方が記載されています。
• 別の Miles サイトがアクティブな状態で「新しいウェブサイトを作って」 → そのプロンプトを現在のサイトで say に渡してはいけません。意図が曖昧な場合は、短く確認します。ペアリング済みのローカル WordPress サイトがアクティブな場合、site-create はそのサイト上で新しいデザインを開始します。クラウドへのフォールバックは作成されません。クラウドサイトがアクティブな場合は、別の成果物を作成します。既存のクラウドサイトを再デザインしたい場合は、その旨を明確に伝え、リスクの高い変更を行う前に site-attach <siteId> --duplicate を検討します。
• 「コンテンツ／ブリーフはすでにあります。それをもとにデザインしてください」 → ブリーフをファイルに書き込み → site-create --brief brief.md "<summary>"（ユーザーから提供されたロゴや画像があれば --attach logo.svg を追加し、各ファイルの内容を説明します）→ ディスカバリーは実行されません → design-directions → 提示 → build-site。
• 「これのデザイン案を見せて」 → site-create --brief ... → design-directions --json → 各プレビューを screenshot で撮影 → 独自の UI で提示します。選択されるまでは決して構築しません。
• 「自分の Miles サイトを編集して」／「前回の続きから再開して」 → クラウド接続では、site-attach <siteId>（別マシンの場合）または use <siteId>（ローカルの認証情報にすでにある場合）→ site-state --json → next[] のヒントに従います。ペアリング済みのローカル WordPress 接続では、そのサイトのまま site-state --json を実行します。クラウドへのアタッチや切り替えは意図的に利用できません。ブリーフの全文や話し合った内容など、全体を確認するには site-state --full --json と history を追加します。
• 「次は何に取り組めばいい？」 → フェーズとブロッカーを確認するために site-state --json を実行し、続けて現在の計画全体を確認するために site-plan --json を実行します → 保留中／失敗した項目を提示し、ユーザーに選んでもらいます → 選ばれた作業を say に渡します。
• 「サイト計画はどのように変わりましたか？」 → site-plan --history --json → 重複を除いた改訂内容と、項目セットの added／removed／changed を比較します。
• 「WordPress テーマにして」 → connect-browser → convert-theme → export --type theme。
• 「直前の変更を元に戻して」 → miles undo で直近のターンを元に戻します（サイトとチャットをまとめて1段階）。それより前に戻す場合は、まず site-attach <siteId> --duplicate を実行します。複製が分岐になります。
• 「変換後の現在のサイトを見せて」 → screenshot --live で、接続済みのダッシュボードを通じて稼働中の WordPress フロントエンドを撮影します。保存済みプレビューのスクリーンショットで見られるのは、変換前の HTML サイトのみです。

どのエントリーポイントでも変わらない判断基準：意図のずれからアクティブなサイトを守ること、ビルドを開始する前に account-status で余力を確認すること、ビルド前にデザイン案を提示すること（ユーザーは好みを言葉にするより、選択肢に反応するほうが簡単です）、レイアウトより先にコンテンツを用意すること、明示的に判断を委任された場合を除き、デザインの選択肢を黙って選ばずユーザーに提示すること。

一連の流れとしてのフルワークフロー

各矢印は1つのプリミティブです。すでに持っているものに応じて、順序を入れ替えたり省略したりできます。

auth → account-status                     # headroom before committing
site-create "<description>"               # --brief skips discovery; --attach
                                          # sends the user's logo/imagery
  loop: say "<user's answer>"             # relay interview; approve brief
connect-browser --open                    # user watching? open the live canvas
design-directions --json → screenshot     # inspect, recommend, let user pick
build-site --design N                     # headless full-site build
say "<edit>" ...                          # iterate on the built site
connect-browser → convert-theme           # the browser fault line
export --type html | --type theme         # deliverables

処理時間の長い動詞（site-create、say、build-site、convert-theme）は、デフォルトで進捗をストリーミングし、完了を待ちます。すぐに JSON ハンドルを取得してから自分で wait-job／cancel を操作するには、--no-wait を追加します。ホスト側でポーリングはできてもストリーミングできない場合に便利です。--no-wait には cancel をサポートするサーバーが必要です。停止できない作業を決して開始しないでください。

長時間実行コマンド：進捗を途切れさせない

site-create（ブリーフを指定した場合）、say によるブリーフの承認、build-site、convert-theme はそれぞれ数分かかります。最初のコマンドを実行する前に、次の2つのルールに従ってください。

1. ユーザーには常に進捗を見せてください。 Claude Code を含む多くのホストでは、フォアグラウンドの stdout がバッファリングされるため、リアルタイムの進捗が何分も表示されなくなります。そのようなホストでは、コマンドをバックグラウンドで実行して出力ログを監視するか、--no-wait を指定して実行し、miles wait-job --timeout 60 を繰り返し、各ポーリングの進捗を短い Miles: <action> 形式のマイルストーン行で伝えてください。最初の長時間実行コマンドを実行する前に、使用中のホストに適した通信方式について full-workflow.md を読んでください。ユーザーを何も表示されない状態で待たせてから読むのではありません。

覚えておいてください。実行を開始した処理は、あなたのプロセス内ではなくサーバー上で実行され、必ずそれ自体で完了します。 1回のターンで行える作業には上限があります。実行中にユーザーが中断した場合、Miles はそのターンを完了して停止します。処理が際限なく続き、コストが膨らむことはありません。CLI は、あなたのプロセスが終了しても残る実行中マーカーでこれを追跡します。未完了の実行があると、次の Miles コマンドで [note: ...] が表示されます（一部のホストではフックが自動的に挿入します）。復旧するのはあなたの役割であり、ユーザーの役割ではありません。 目立たないように処理へ再接続し（miles wait-job）、実際の状況に基づいて応答してください。完了している場合は結果を提示し、まだ実行中の場合はその旨を伝えて監視を続けます。ユーザーのメッセージから、その作業をもう望んでいないとわかる場合に限り、miles cancel に言及してください。ユーザーに詰問してはならず、未完了の実行がある状態で新しい Miles の処理を黙って開始してはなりません。詳細とホストごとのフック設定については、interrupts.md を参照してください。

2. ユーザーがその場にいる場合は、デザインの生成過程を見られるようにしてください。 どの長時間実行でも、開始方法にかかわらず適用されます。site-create --brief（生成はすぐに始まります）、ブリーフの承認、build-site、convert-theme が対象です。ユーザーがいる状態で実行中になったら、ダッシュボードを開いてください。connect-browser --json を実行し、認証済みの url を、あなたが操作できるブラウザー画面（内蔵ブラウザー、プレビュー、WebView、ブラウザー MCP ツールなど）で開きます。--no-wait を指定した場合は、ハンドルが返された直後、最初の wait-job によるポーリングより前に開いてください。内蔵ブラウザーは OS のブラウザーを起動するより強く推奨されます。そうすれば、あなたもキャンバスを確認でき（デザインを自分で調べたり、connected が true に変わるのを見たりできます）、ユーザーもタブが別に開くのではなく、その場で確認できます。ホストによっては、これらのツールがわかりにくい場所にあります。内蔵ブラウザーがないと判断する前に、使用中のホストにおける対応付けを browser.md で確認し、延期されているツールや検索可能なツールも含めて、ツールの一覧をすべて確認してください。代替手段として、何も表示しないのではなく connect-browser --open（ユーザーの OS ブラウザー）を使用してください。ダッシュボードはリアルタイムのキャンバスです。ヘッドレス実行に必須ではありませんが、サイト生成中にユーザーを何も表示されない画面のまま待たせるのは、プロダクトとしての失敗です。無人実行または自動化からの呼び出しの場合に限り、この手順を省略してください。また、いずれの場合も、各ステップを開始する前に、おおよその所要時間をユーザーに伝えてください。

初回実行

新しいセッションでは、まずスキルのライフサイクルを確認し、次にセットアップ、最後に認証を確認します。

~/.miles/bin/miles-skill check-update --json   # 24h-gated; prompt user only when shouldPrompt is true
"$MILES_CLI" doctor --json
"$MILES_CLI" auth status

認証されていない場合は、ブロックしないデバイスログインを開始します。auth login はコードを要求して終了する必要があります。待機することはありません。

"$MILES_CLI" auth login --json

userCode、verificationUrl、pendingState を解析します。次のメッセージをユーザーに表示し、その直後にリスナーを開始します。ユーザーが「完了」と言うのを待ってはいけません。

Code: <userCode>
Open: <verificationUrl>

Open the URL. The page should show this same code; if it matches, click Authorize. I will keep listening for authorization.

"$MILES_CLI" auth poll --json    # 10-minute timeout; polls until authorized

コードが一致するかの確認は、セキュリティ上必須です。直前に生成していないコードをユーザーに承認させてはいけません。expired／timeout の場合は新しいコードを発行し、rate_limited の場合は待機して同じコードを再ポーリングします。すべてのポーリングステータスと例外については、auth.md を参照してください。いずれかのコマンドが SANDBOX_NETWORK_BLOCKED を報告した場合は、再試行を中止して sandbox.md の手順に従います。対処内容は、最終応答に明記する必要があります。

フロントマターのフックが実行されたと決めつけてはいけません。Claude 以外のホストではフックが無視されることがあるため、状態が不明な場合は doctor／auth status／ログインを明示的に順に実行してください。

結果の扱い

• site-create、say、build-site、wait、convert-theme は、Miles の確定した応答を標準出力（および、一部のホストが追加コンテキストとして配信するフックリレーファイル）に出力します。すでに得た内容を読み直すために messages や status を再実行せず、次のアクションに進んでください。
• Miles が質問（[question: ...]）を返したら、利用可能な場合はユーザーのネイティブな質問 UI を使って質問を伝え、そうでなければ簡潔な Markdown カードを表示します。そのターンの最終応答にも質問を表示する必要があります。ユーザーが回答したら、その回答を変更せずに say で送信します。リレーの仕組みとテンプレートについては、full-workflow.md を参照してください。
• Miles が [approval_required] または approvalRequired を返した場合は、保護対象の変更概要を伝え、承認または却下を求めます。これは通常のチャットでの質問ではありません。say は使わず、live-protection.md に従ってください。
• brief が届いた（phase: brief_review）場合は、brief 全文と「承認／変更を依頼」の選択肢を、最終応答としてユーザーに表示します。決して要約して省略してはいけません。brief はサイト全体の設計図です。
• ディレクションの準備ができたら、内容を確認します。接続済みのダッシュボードが開いていればそこで確認し、開いていなければ各プレビューで screenshot を実行します。brief に基づく推奨を、各ディレクションについて簡潔なメモを添えて提示し、ユーザーに選んでもらいます。実際に読み込まれたものだけを、目視で確認したと伝えてください。
• Miles が同意、利用規約、リスク、バックアップ、または破壊的操作の確認を求めるブロッカーを返した場合は、実際にユーザーに表示されるリスク／確認文を提示し、明示的な判断を求めます。「いいえ」は最終回答として扱います。ユーザーに代わって承認したり、法的・安全上の文言を曖昧な要約に置き換えたり、表現を変えてブロッカーを回避しようとしたりしてはいけません。
• 進捗：生のログや段落ではなく、Miles: <action> の短いマイルストーン行を伝えます。ホスト上で表示し続ける方法については、上記の「長時間実行されるコマンド」を参照してください。
• クレジット：[warning: ...] はすぐに伝えます。クレジットに関する [error: ...] が発生した場合は、処理を中止してユーザーにチャージを促してください。account-status --json でいつでも残高を確認できます。

Miles の更新またはアンインストール

「Miles を更新」「Miles をアンインストール」という依頼は、ライフサイクルに関するリクエストとして扱います。

~/.miles/bin/miles-skill check-update --json --force   # summarize, ask approval
~/.miles/bin/miles-skill update
~/.miles/bin/miles-skill uninstall --dry-run --json    # summarize, ask approval
~/.miles/bin/miles-skill uninstall

ユーザーがすべてのローカルデータを消去するよう明示的に要求した場合（uninstall --purge）を除き、~/.miles/credentials.json を削除してはいけません。Miles がネイティブのエージェント UI 経由でインストールされている場合は、そのホストの更新／アンインストール機能を優先してください。