slipdock

Slipdock CLI

slipdock コマンドは、ユーザーのSlipdockアプリケーションと通信します。ホスト先は app.slipdock.us、またはユーザーがアクセスできる任意のアドレスでセルフホストされたものです。すべての書き込みはWeb UIにリアルタイムで表示されます。完全なリファレンスは slipdock --help を実行してください。

サーバーの指定。 $SLIPDOCK_URL、なければ ~/.config/slipdock/url（slipdock url <アドレス> またはサーバー自身の /install.sh によって書き込まれます）、さらになければこのマシンのTailnetアドレス（ポート4000）が使用されます。これらのいずれもユーザーの意図するボードでない場合は、アドレスをユーザーに確認してください。推測しないでください。

ボードから作業を開始しようとしている場合（次のタスクを取得する、エピックを進める、作業中にカードを更新し続けるなど）は、最初に slipdock guide を実行し（サーバー自身のエージェント向け指示：エピックとサブカード、次のカードの選択方法、何を書き戻すか）、それに従ってください。このファイルはコマンドリファレンスであり、ガイドはワークフローです。

SlipdockのMCPツールが接続されている場合

このセッションにすでにSlipdockツール（list_boards、get_card、create_card、complete_card…、サーバーの/mcpから）がある場合、それらは同じ作業のためのCLIの代替手段になります。どちらか存在する方を使用してください。どちらも規則は同じです。get_guide は slipdock guide が出力するガイドの短縮形を返し、最後に他のセクション名を表示します。section: "automations"（またはそれらの名前のいずれか、または"all"）でセクションを取得できます。archive_card はカードを片付け、restore: true で元に戻します。archive_board はボードに対して同じことを行います。これらを優先してください。delete_card（confirm: trueが必要）、delete_list、delete_board（confirm はボードのコード）は元に戻せません。create_list、create_tag、create_board は構造を追加します（タグは create_card/update_card でカードに付与する前に存在している必要があります）。list_cards を full: true で実行すると、各カードの全詳細（コメント、チェックリスト、ドキュメント）を一度の呼び出しで読み取ります（個別の get_card の代わりに）。update_card は依存関係の設定とチェックリストの操作も行います。list_pages はボードのWikiを一覧表示し（tree: true でツリー形式になります。page tree と同様）、read_page は単一のページを読み取ります。page_info は page links、page sections、page wanted、page resolve が何を行うかを回答します。write_page によるセクション編集の前に、見出しパスを推測する代わりに page_info で sections を問い合わせてください。page_history は page history と page diff（rev、または2つのバージョンを比較するための rev + against、または最新の保存との差分を示す diff: true）に対応し、revert_page は page revert です。これにはページの現在の content_hash を base_hash として指定する必要があります。update_page は page edit --title/--summary/--tag、page mv、page file、page rm/page restore（archived）、および page pin --card（pin_card/unpin_card）に対応します。upload_file は最大10MBのファイルを添付するための attach です（content_base64 または text を使用）。モデルが書き出したBase64は約1KBを超えると問題が発生するため（#1040）、ファイルが存在するシェルがある場合は送信しないでください。代わりに slipdock attach を使用するか、upload_file を card/page と link: true（#1147）で使用します。これにより、10分間有効でトークン不要の使い捨て upload_url が返され、curl -F file=@FILE -F sha256=<hex> <upload_url> で使用します（filename、replace、hide_on_card も指定可能）。これによりバイトデータがモデルを経由しなくなります。download_file を link: true で使用すると、逆向きに同じことができます。curl -fsSo FILE <download_url>。ユーザーの同期済みWikiにすでにあるファイルは、サーバーが wiki_file でコピーします（Wiki内のパス、またはIDを指定。コンテンツは不要）。content_base64 には sha256（Base64エンコード前のバイト列の16進数ハッシュ）を必ず含める必要があり、sha256_mismatch エラーが返された場合は再エンコードして再送信してください。応答の sha256 は保存時のバイト列のハッシュであり、get_card/read_page はすべてのファイルに対してこれを表示します。ファイルを検証するには、ダウンロードせずにソースのハッシュと比較してください。数KBを超えるデータは約4KBのチャンク（#1016）で送信されます。Base64が長くなるほど破損しやすいためです。最初のチャンクは append: true、card/page、filename、およびそのチャンクの sha256 と共に送信し、upload_id が返されます。後続の各チャンクは upload_id、append: true、offset（直前の応答の received の値）、および自身の sha256 を送信します。拒否されたチャンクは単独で再送信します。最後に upload_id、finish: true、およびファイル全体の sha256 を送信して完了します。完了するまでカードには何も表示されません。カードにすでにあるファイルを再構築する場合は replace: true を送信します（単一の呼び出し、最初のチャンクまたは finish 時）。新しいファイルが保存されると、同じファイル名の古いファイルは削除され、1つの最新コピーのみが残ります。delete_attachment（detach。attachment IDと confirm: true）は、誤ってアップロードしたファイルなどを完全に削除します。download_file はIDで添付ファイルを読み取ります（get_card と read_page がIDを一覧表示します）。list_automations は automations/automation（vocabulary: true で automation-help と automation-presets が提供する情報を追加）に対応し、manage_automation は new-automation（action: create）、set-automation（update）、delete-automation（delete、confirm: true が必要）に対応します。list_tools は tools/tools show（各ツールの種類と installed.board、つまりインストール先のボード。file を指定すると tools file。skill はその SKILL.md を読み取ります。link: true はファイル、スキルのzip、またはスキルのtarballの使い捨て download_url を返します。#1158。package: true で tools download）に対応し、install_tool は tools install-board に対応します。ツールがカバーしないもの（ルールの今すぐ実行、コールバックとアラート、スプリント、10MBを超えるファイル、フィールド）は、引き続きCLIまたはAPIを使用してください。

CLIがインストールされていない場合

以下はすべてJSON APIのラッパーであり、APIがフォールバックとなります。必要なのは curl だけです。CLIのインストールをユーザーに指示しないでください（EscriptでありErlangが必要です）。APIを使用し、CLIについては、ユーザーがよりタイピングしやすいものを要求した場合、またはCLIのみが行うWiki同期を要求した場合にのみ言及してください。Windowsの場合、ユーザー自身のサーバーからPowerShellで1行でインストールできます。irm "$B/cli/install.ps1" | iex、その後 slipdock auth を実行します。その他の環境では、リポジトリの cli/ からビルドします。

B="${SLIPDOCK_URL:-$(cat ~/.config/slipdock/url 2>/dev/null)}"
T="$(cat ~/.config/slipdock/token 2>/dev/null)"
H="Authorization: Bearer ${SLIPDOCK_TOKEN:-$T}"

curl -s "$B/api/guide"                 # トークン不要。API全体と各呼び出しのcurlコマンド
curl -s -H "$H" "$B/api/me"            # トークンの所有者を確認

GET /api/guide が完全なリファレンスです。すべてのエンドポイントがcurlコマンドと共に記載されており、トークンを渡せばユーザー自身のボードとリストも含まれます。このファイルからパスを推測するのではなく、それを読んでください。

サインインにもCLIは不要です。同じデバイスフローで、2回の呼び出しで完了します（ガイドに記載されています）。コードを要求し、ユーザーにURLとコードを表示し、承認されるまでポーリングし、トークンを ~/.config/slipdock/token にモード600で書き込みます。これにより次のセッションで使用できます。

curl -s -X POST "$B/api/auth/device" -H 'content-type: application/json' \
     -d '{"label":"claude on this machine","scope":"write"}'
# → user_code, verification_uri, device_code, interval
curl -s -X POST "$B/api/auth/device/token" -H 'content-type: application/json' \
     -d '{"device_code":"…"}'
# → 承認されるまでは 400 authorization_pending、承認されると {"token":"…"}

これらのスキルを何もインストールしていないマシンにインストールするには： curl -fsSL "$B/install.sh" | sh（必要なのは curl と tar のみ）。Windowsの場合、PowerShellで irm "$B/install.ps1" | iex（WSLのホームではなく %USERPROFILE%\.claude\skills にインストール）。CLIを実行できないChatGPTの場合は、slipdock skills chatgpt でスキルをアップロード用のzipとして保存します。各コマンドはMCPコネクタのツールにマッピングされます（$B/api/skills/<name>/chatgpt.zip）。

サインイン

APIはトークンを必要とします。コマンドが not signed in で失敗した場合は、slipdock auth を実行してください。短いコードとURLが表示され、ユーザーがすでにサインインしているブラウザで承認すると、数秒後にトークンが取得できます。コードとURLをユーザーに伝えてください。ユーザーが手動でトークンを作成することを希望しない限り、そのように依頼しないでください（slipdock auth <token> は依然としてトークンを受け付けますし、SLIPDOCK_TOKEN も引き続き機能します）。

slipdock whoami は現在のユーザーを表示します。アクセスできないボードは単に一覧に表示されません。forbidden エラーは、ユーザーが何かを見ることはできるが変更はできないことを意味します。2つの拒否はユーザーではなくトークンを名指しし、保持しているトークンが意図的に制限されていることを意味し、何かが壊れているわけではありません。再試行せずにその旨を伝えてください。

• this API token is read-only — 読み取り専用アクセスが許可されています。読み書き可能なものを要求してください。
• this API token's scope doesn't allow it — 特定のボードに制限されているか、管理者トークンではないのにサーバー管理を試みました。

さらに2つの拒否も最終的なものです。報告し、ユーザーが何をできるかを伝えてください。

• card_limit_reached（HTTP 402）— ボード所有者のアカウントが許可するアイテムを使い切りました。アイテムはカード、Wikiページ、アップロードされたファイルのいずれかです。これら3つはすべて同じ数にカウントされるため、代わりにページとして書き込んでも回避できません。タイトルを変えても解決しません。同じように失敗し続けます。完了したものをアーカイブすることを提案してください。slipdock whoami --json と slipdock guide はどちらも残りの許容量を表示するため、バッチ処理を開始する前に確認し、途中で壁にぶつかるのを防ぐことができます。
• board_limit_reached（HTTP 402）— このサーバーが一人に許可する数のボードを所有しています。サブボード（サブカード）はこの数にカウントされません。ボードのアーカイブ、または管理者への問い合わせを提案してください。
• storage_limit_reached（HTTP 402）— アップロードされたファイルが許容スペースを埋め尽くしました。添付ファイルを削除することでのみ空き容量が確保されます。ファイルが添付されているカードをアーカイブしても空き容量は増えません。
• trial_expired（HTTP 402）— 無料トライアルが期限切れです。どのボードにも新しいものは一切追加できません。すでにあるものはすべて読み取りと編集が可能です。あなたにできることはありません。ユーザーにサブスクリプションが必要であることを伝え、停止してください。 これら4つは作成だけでなく、アーカイブからの復元、他のユーザーのボードへの move --board（カードとその配下すべてが相手の許容量にカウントされます）、インポート、および welcome でも発生します。
• No account here uses that address… — このサーバーは、共有相手のアカウントを作成しません。管理者が招待する必要があります。

他のユーザーと何かを共有した場合のみ相手が表示されるサーバーでは、見つからないはずの相手が見つからない場合、おそらく何も共有されていません。削除されたわけではなく、何かが共有されるまで相手にカードを割り当てることはできません。

カードはそれを開くことができるユーザーにのみ割り当てられます。割り当て先に user … not found が表示された場合は、まさにその状態です。アカウントの有無にかかわらず、最初にボードを共有する必要があります（ブラウザでボードの共有設定から）、またはユーザーにそのように依頼してください。

ワークフロー

1. 最初にボードとその構造を見つける: slipdock boards、次に slipdock board <board> または slipdock columns <board> と slipdock tags <board> を実行します。ボードとカラムはIDまたは大文字小文字を区別しない名前を受け入れるため、slipdock board "product launch" のように動作します。 すべてのボードにはコードもあります。これは短い名前で、一意でURLセーフ、最大10文字、ボードの名前から生成され編集可能です（例：「QVM V1 Remediation」は qvm-v1-rem）。slipdock boards のCODEカラムと --json の code フィールドに表示され、<board> はどこでもこれを受け入れます：slipdock board qvm-v1-rem、slipdock add qvm-v1-rem "..."。名前よりもコードを優先してください。コードは一意であり、名前が変更されても有効です。また、ユーザーにボードを伝えるときもコードを使用してください。slipdock new-board <name> [--code C] で明示的に設定できます。省略した場合は名前から生成されます。 ボードにはショートカットキーもあります。これはWebアプリでそのボードにジャンプするための1〜2文字です（b を押してからキーを押します）。slipdock boards のKEYカラムと --json の shortcut フィールドに表示され、new-board または set-board の --shortcut K で設定されます。これはコマンドラインでボードを指定する方法ではありません。コードを使用してください。
2. 書き込む前に読む。 slipdock card <id> ですべてを表示：説明、フラグ、タグ、チェックリスト項目のID、コメント。
3. 出力を解析する必要がある場合は --json を使用する（ID、フィルタリング、カウントなど）。プレーンな出力はユーザーに表示するためのものです。
4. delete よりも archive を優先する。 削除は永続的です。ユーザーが明示的に削除を要求したものでない限り、削除前に確認してください。 ボード全体もアーカイブできます（slipdock archive-board <board>）。これはカードのアーカイブとは異なり、あなたの業務からはるかに遠いものです。ユーザーのインデックス、ボードスイッチャー、クイック追加からボードを削除します。ユーザーがそのボードを名前で指定した場合を除き、ボードをアーカイブしたり並べ替えたりしないでください。
5. 実行中に何が起こっているかを伝える。 短時間で終わらない作業は、各マイルストーンで slipdock comment <id> ... を実行し（そして slipdock edit <id> --percent N で進捗を合わせる）、最後に一度にまとめて書き込まないようにしてください。進行中のカードに、最後の移動よりも新しいコメントがない場合、見ている人には放棄されたと見なされます。
6. IDをユーザーに報告する（#42）。これによりユーザーはUIでカードを見つけられます。コメントや説明内の @handle（メールアドレスの「@」より前の部分）はその人にメールを送信します。