slipdock/work - Slipdock ボードから作業する

Slipdock からの作業について

ボードは計画の正式記録です。次に何をするか、そして何が起こったかの記録が置かれます。サーバーは独自の規約を文書化しています。何かを選択または更新する前に、セッションごとに一度、最初にこれを読んでください:

slipdock guide                    # markdown、GET /api/guide から

このマシンに CLI がない場合（通常はこちらです。CLI には Elixir が必要です）:

B="${SLIPDOCK_URL:-$(cat ~/.config/slipdock/url 2>/dev/null)}"   # どちらも設定されていない場合はユーザーに尋ねる
curl -s -H "Authorization: Bearer $SLIPDOCK_TOKEN" "$B/api/guide"

サーバーのアドレスは $SLIPDOCK_URL、なければ ~/.config/slipdock/url（slipdock url またはサーバーの /install.sh によって書き込まれます）から取得します。どちらもない場合は、ユーザーに Slipdock のアドレスを尋ねてください。推測しないでください。ホスト型ボードは https://app.slipdock.us のようなもので、セルフホスト型の場合はユーザーが到達する名前になります。

トークンがある場合は渡します（$SLIPDOCK_TOKEN、なければ ~/.config/slipdock/token）。ガイドにはトークンは不要ですが、トークンがある場合、ガイドの最後にユーザーの実際のボード、各リスト、そしてどのリストが準備完了リスト、バックログ、進行中リスト、完了リストであるかが表示されます。これはまさに、何かをピックアップするために必要な情報です。

ガイドはこのファイルよりも優先されます。 ガイドは実行中のサーバーから提供されるため、最新です。ガイド内のエンドポイント、語彙、ボードレイアウトはリクエスト時に生成されます。このファイルは、ガイドを取得する方法と、まだガイドを持っていない場合の対処法を示すだけです。

名前がわからないものを見つける

slipdock cards <board> --search Q は、1つのボードを部分文字列でフィルタリングします。他のフィルターは単語ではなく状態を問うもので、「何を選ぶべきか」に答えるものです。--deps ready は未完了のカードに依存しているものを除外し、--no-assignee は他の人の作業を除外し、--due overdue は期限切れのものです。したがって、対象となるリストは1回の呼び出しで取得できます:

slipdock cards <board> --column "To Do" --open --deps ready --no-assignee

slipdock search <words...> は異なります。意味でマッチングし、ユーザーが見ることができるすべてのボードにまたがり、カードだけでなくコメントやステータス更新もカバーします。ユーザーが名前ではなく何かを説明している場合（「払い戻しの丸め問題に関するカード」）、探しているものがタイトルではなくコメントで述べられている可能性が高い場合、またはどのボードを見ればよいかわからない場合に使用します。それが出力したマッチしたチャンクを読み、それから操作する前に slipdock card <id> でカード全体を確認します。

詳細が展開される短いバージョン

• エピックとサブカード。 トップレベルのカードはエピックです。つまり、優先順位、日付、議論を保持する成果物です。作業はそのサブカードにあり、各サブカードが1つの作業です。チェックリスト項目はタスク内のステップです。発見した新しい作業は、新しいトップレベルカードとしてではなく、それが属するエピックの下にサブカードとして追加します。
• 選択。 すでに進行中のものを完了します。次に準備完了リスト（To Do）を、そこに対象となるものがない場合のみバックログを確認します。優先順位の高いものから、リスト内の位置で同順位を解決します。完了済み、アーカイブ済み、ブロック済み、待機中、スヌーズ済み、または他の人に割り当てられたものはスキップします。--open --deps ready --no-assignee はその大部分を自動でスキップします（スヌーズされたカードは slipdock cards からすでに除外されています）。また、代理カード（↪stand-in-for:#N）もスキップします。これはカードがスプリントに入った場所を示すだけです。ボードが PAUSED（JSON では paused）と応答した場合、誰かがそのボードでのランナーの作業を停止しています。何も取得せずに停止します。選択したカードにサブカードがある場合、そのカードに入り、サブカードを全て完了してから、次のトップレベルカードに戻ります。
• 進行に応じた更新。 開始時にカードを進行中に移動し、自分自身に割り当てます。すべての決定、驚き、行き詰まりに対してコメントを残します。フラグを立てます（blocked、review）、何を待っているかをコメントに付けます。必要なものを人間だけが提供できる場合、待機を開始して停止します(slipdock wait <id> "必要なもの" [--on EMAIL] [--choice X]...、または update_card wait; 複数の質問は --question Q --question Q / questions で、それぞれ個別に、決して1ブロックにまとめません): カードに waiting のフラグが立ち、それに答えると（slipdock answer）作業が再開されます。待機しているものに日付がある場合は、代わりにスヌーズします（slipdock snooze <id> <date> --note "…"）: リストから外れ、指定日にリストの先頭に戻ります。完了時は completed: true を設定し、かつ完了リストに移動します。エピックは、そのロールアップですべてのサブカードが完了している場合にのみ完了します。
• 検証作業、それが有効なボードの場合（ガイド内のそのボードの行に verified work: … とあります）。作業を開始する前にカードの基準を書き込みます（slipdock edit <id> --bar "…"）。作業が開始されたら決して変更しようとしないでください。確認した内容と共に完了します（slipdock done <id> --evidence-commit <sha> --tests a,b --suite passed:38:0 --evidence "…"）。別のエージェントが検証するボードでは、done はカードを送信し、保留状態のままにします。自分で Done に移動しないでください。拒否されたカードは、コメントに理由が、ジョブのプロンプトと get_card の rejection とともに戻ってきます（ハンドオフは Rework: … と表示されます）。それが次の指示なので、まずその理由を読んでください。他の人のカード（自分のものは不可）を検証するには、証拠のコミットをクリーンなツリーでチェックアウトし、スイートを実行し（プルリクエストボードの場合は、そのコミットで CI が合格したことを確認します）、基準と照らし合わせて判断し、それから slipdock accept <id> または slipdock reject <id> --reason "…" を実行します。プルリクエストで出荷するボード（ボードの行にそう記載されており、要求されたジョブのプロンプトと slipdock card も同様）では、デフォルトブランチにプッシュしないでください。card-<id> でコミットし、プッシュし、プルリクエストを一度開きます（gh pr create --head card-<id> --title "<title> (#<id>)" --fill; 拒否されたカードの次の試行は同じブランチをプッシュします）。そのチェックを監視します（完全なテスト実行：プッシュ前に、追加または変更したテストのみを実行します）。slipdock done <id> --pr <url> で完了します。カードを受け入れるとマージされます。自分でマージしないでください。マージが失敗すると、カードは理由とともに拒否されて戻ってきます。ブランチをリベースして再送信します。
• レーン、それが有効な場合（ボードのガイド内の行に lanes: on とあります）。カードを開始する前に、作業が触れるパスを書き込みます: slipdock edit <id> --paths "lib/foo/**,docs/manual.md"、指示が許す限り狭くします。進行中のカードと重複するために移動が拒否された場合、そのカードが指定されます。パスを狭めるか、そのカードによってブロックされたままにします。レーンを上書きできるのは人間だけです。プッシュボードでは、検証待ちのカードはレーンとその依存関係を解放します。プルリクエストボードでは、マージまで両方を保持します。ボードにレーンがあるかどうかにかかわらず、パスを持つカードでは、名前でその下のファイルのみをステージングし、同じリポジトリで別のセッションがアクティブな場合は、独自の git ワークツリーで作業します（git worktree add ../<repo>-lanes/card-<id> -b card-<id>）。ただし、ランナーがすでにワークツリーに入れている場合（$SLIPDOCK_WORKTREE）は除きます。
• 最初にハンドオフを読み、途中で止める場合はハンドオフを残す。 カードのハンドオフ（slipdock card <id> の先頭にある Left off:、JSON の handoff）は、最後に持っていた人が残した場所です。次の1ステップと短いメモです。カードをピックアップするときは、コメントの前にそれを読んでください。カードを未完了のまま停止する場合（セッション終了、返却、ブロック、時間切れ）は、必ずハンドオフを残してください: slipdock handoff <id> --next "<次の1ステップ>" --body "状態: … 注意点: … 未解決: … 参照: …"（MCP 経由では leave_handoff）。これは最後のハンドオフを置き換えます。履歴は保持されます。コメントは実行ログであり、ハンドオフは「今」の状態です。完了したカードの場合、ハンドオフは人間向けです。彼らがしなければならないこと、確認すべきこと、知っておくべきこと（デプロイ、再インストール、質問、注意点）を --next として、状況を箇条書きで数行記述します。彼らに残すものがない場合は、空白のままにし、以前に残したハンドオフは slipdock handoff <id> --clear でクリアします。
• プッシュする前にカードを再読し、その後コメントも読む。 作業がチェックされたら、もう一度 slipdock card <id> を実行します。あなたのクレームより新しい、変更された説明やコメントは、まだこのカードのものです。コミットする前に行ってください。ビルドが開始されたら、コメントをもう一度読み、その間に追加されたものがないか確認します。
• インシデントとデプロイ。 ボードがデプロイを記録している場合（slipdock dora <board> が、デリバリーメトリクスがオフであると言う代わりに回答する）、障害や壊れたリリースは incident タグが付けられた通常のカードです。原因となったデプロイがわかっている場合は、slipdock incident-of <card> <deploy-id> を使用します。修正のコミットには、他のカードと同様に、カード番号を記載します（#57）。これにより、そのデプロイが修正としてカウントされ、カードに Shipped 行が表示されます。デプロイは手動で記録または完了しないでください。それは CI の仕事であり、CI 専用のトークンがあります。
• 整理整頓の提案は人間が決定します。 slipdock garden <board>（MCP 経由では garden）は、ボードのガードナーが見つけたものを一覧表示します。完了しているが未クローズのエピック、進行中で詰まっているカード、重複、孤立したページなどです。整理を求められたらそれらを表示し、人間が承認したもののみを適用します（slipdock garden apply <id>、garden_decide）。無人で作業する場合は、適用も却下も決して行わないでください。却下は記憶されます。
• 長時間の作業は中間アップデートを行います。 タスクが短時間の作業以上にかかる場合は、まだ実行中の各マイルストーンでコメントを残します。何が完了したか、何が残っているか、計画を変更したものがあれば、それらを記録し、percent_complete も更新します。最後に1回まとめて書き上げるのでは遅すぎて役に立ちません。進行中のカードで、移動以降に新しいコメントがないものは、放棄されたと見なされます。複数回の作業にわたるエピックも同様に、各サブカードがクローズされるたびに1行コメントを残します。
• コメントは Markdown であり、ざっと読まれます。 それが何であるかを示す太字の行で始め（**ピックアップしました。**、**ビルド完了。**、**決定:** …）、その後、短い箇条書きで、各項目1つの事実を、パス、コマンド、コミットIDはバックスラッシュで囲んで記述します。節が連なる1つの密集した段落は避けてください。1行を超えるものは slipdock comment <id> --body - <<'EOF' … EOF で送信します（引用符で囲まれているため、バッククォートは保持されます）。コマンドラインの単語は改行を失います。
• コミットし、リンクする。 プロジェクトが git リポジトリの場合、カードの作業が完了したら、カードを閉じる前に、コミットメッセージにカードID（#42）を含めてコミットします。クローズコメントはコミットへのリンク、またはプルリクエストが開かれた場合は PR へのリンクを含めます（コミット: https://github.com/…/commit/abc1234）。リンクするリモートがない場合は、短いハッシュとブランチを代わりに示します。
• 書き込み時のトークンコスト。 カードのクローズコメントは、作業が使用したトークンを示す行で終了します。例: トークンコスト: ~135k トークン (コンテキスト予算 15.00M → 14.86M、クレームからクローズまで)。カードをクレームした時とクローズした時に、残りトークンカウンター（システムメッセージの total_tokens left）を読み取り、その差を示します。複数のカードを一連の作業で処理した場合は、各カードをそれぞれのクレームから測定します。カウンターが表示されない場合は、「トークンコスト: 未測定」と表示し、推定しないでください。エピックの進捗コメントにも同じ数値を追加します。
• まずお気に入りを読む。 slipdock favourites は、この人がマークしたボード、リスト、カード、保存済みビューを一覧表示します。つまり、彼らが実際に作業している場所です。これはボードのリストだけではわかりません。「次に何をすべきか？」とボードを指定せずに尋ねられた場合、お気に入りが最も強力なヒントです。これらは個人用です。頼まれない限り、追加も削除もしないでください。
• アーカイブされたボードは、保留された作業です。 slipdock boards は意図的にこれらを除外します。--all は archived 状態で表示します。アーカイブされたボード上のものは読み取りも書き込みも可能ですが、断りなくアーカイブされたボードから作業を選択したり、新しい作業をそこに置いたりしないでください。
• カードに収まらないものを書き留める。 ボードは何が行われているかを示します。仕組み、決定事項とその理由、物事の形状などを保存するのには適していません。これらはボードのwikiに保存します。slipdock page ls <board>、slipdock page read <page>、slipdock page new <board> <title...>。判断基準は、このカードがクローズされた後も再び読まれるかどうかです。決定事項、runbook、仕様、調査結果は再び読まれるものであり、ページ（カードのクローズコメントからコード W-31 でリンク）に属します。進捗状況、ブロッカー、そして「今」起こったことはカードのコメントに属します。両方に書かないでください。コメントを繰り返すページは、誰も信頼しないページになります。 書く前に検索してください（slipdock page ls <board> --q <件名>）。既存のページを拡張することは、デプロイに関する4番目のページを作成するよりも優れています。編集のたびに --message を渡し、自分で書いたばかりでないページの編集には --base-hash を渡して、保存が他の人の作業を静かに上書きしないようにします。
• タイトルは短く保つ。 カードのタイトルは最大約60文字、シリーズの場合は <シリーズ> <n>: <内容> とします（Agent supervision 5: Parked jobs）。詳細は説明に書きます。カードのタイトルはフォルダ名になり、タイトなリストに表示されます。最初の40文字を共有する一連のカードは、そこで区別できません。
• してはいけないこと: カードを削除する（代わりにアーカイブする）、タイトルを実際に行ったことに合わせて書き換える、他の人のカードを整理する、移動以降に新しいコメントがない状態でカードを進行中のままにしておく。ボード全体のアーカイブや並べ替えは、さらにあなたの業務範囲外です。明示的に依頼され、そのボードを指定された場合のみ行ってください。

これが適用される場合

• 「次に何をすべきか？」、「計画を続行する」、「バックログを処理する」、「次のタスク」→ ガイドを取得し、そのルールに従って選択し、どのカードを選んだか、なぜかを伝えてください。
• 「この計画をボードに載せる」、「これをタスクに分解する」→ ガイドの形式に従い、サブカードを持つエピックとして作成します。
• ボードから取得した何かの中間タスクをすでに実行中の場合 → カードは、進捗状況、決定、ブロッカーを、最後に一度にダンプするのではなく、発生したときに書き込む場所です。
• ボードから取得した何かを完了した場合 → 完了を報告する前に、ボード上でそれをクローズアウトします。