mcpField
S
shipyard

shipyard

github.com/yahyabedirhan開発198 回インストール1 週間前に更新
リポジトリ

shipyard について

shipyard は、macOS 向けプロジェクト通知アプリを設定・操作するスキルです。Agent がプロジェクトの一覧や通知ルールを管理し、クリック可能な ping の送信、Notion のメモ管理、アプリ操作を行えます。

主な機能

  1. 01TOML でプロジェクトと通知ルールを設定
  2. 02クリック可能な Agent ping と通知の送信
  3. 03アプリの操作とスクリーンショット撮影
  4. 04Notion のプロジェクトメモ管理
  5. 05パネルテーマの設定

活用シーン

  1. 01複数プロジェクトのプルリクエストを絞り込む
  2. 02リンク付きの Agent 更新通知を受け取る
  3. 03プロジェクトメモの整理やパネル外観の変更

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/yahyabedirhan/shipyard --skill shipyard

インストール後、Claude Code で/shipyardを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

presets.md
references/
demo-items.md
notes.md
notices.md
themes.md

詳細

shipyard の設定

Shipyard は、1 つの TOML ファイルに記述されたプロジェクトのプルリクエスト(有効にした場合は、イシューやワークフロー実行も)を一覧表示し、通知ルールで選択したイベントを macOS の通知で知らせます。このファイルが設定のインターフェースのすべてです。設定ウィンドウはなく、設定を変更するコマンドもありません。保存するたびに、アプリに即座に反映されます。

エージェントは shipyard ping コマンドで、shipyard を通じてユーザーにピンを送ることもできます。クリックすると、エージェントの意図した場所にユーザーを移動させる短いメッセージです。設定の後にある「ピンまたは通知の送信」を参照してください。ユーザーの対応が不要な状況報告には、代わりに shipyard notice send でお知らせを投稿します。これは保存されない通知です。「ピンまたはお知らせ?」を参照してください。

Mac では、エージェントは shipyard app と panel を使って、ユーザーのデータまたはデモのデータで実行中のアプリを開き、操作し、スクリーンショットを撮ることもできます。一度に操作できるエージェントは 1 つです。末尾の「アプリの操作」を参照してください。

ユーザー自身のメモは Notion にあり、プロジェクトごとに 1 つの番号付きリストにまとめられています。メニューには未完了のリストが表示されます。ユーザーが口述したメモを記録する前や、番号でメモを探す場合、またはメモの一覧表示、整理、アーカイブを行う場合は、references/notes.mdを読んでください。メモの保存場所、すべてのエージェントが従うルール、Notion コネクターまたは ntn を通じた各操作、アプリがメモを読み取れるかどうかを表示する shipyard notes check が記載されています。

パネルの外観はテーマで決まります。トップレベルの theme キーで、組み込みテーマまたはユーザーのテーマファイルを選びます。 テーマを選ぶ前、テーマファイルを作成または修正する前、あるいはパネルに Shipyard がどう描画されるかについて回答する前に、references/themes.mdを読んでください。組み込みテーマ、すべてのトークン、状態色、ノブを含むテーマファイルの形式、コントラストチェック、および shipyard config check によるテーマファイルの報告方法が記載されています。

ユーザーの shipyard を変更する依頼は、このファイルを変更する依頼です。以下のキーで対応できない場合は、shipyard にその設定はないと伝えてください。

このスキルは npx -y skills add yahyabedirhan/shipyard -g -y でインストールします。アプリの設定メニュー(歯車アイコン)では、インストール後に Set up /shipyard skill にチェックが付き、この画面の Update を実行すると、同じコマンドで最新版に更新されます。ユーザーがスキルの最新版を求めた場合は、そこを案内するか、コマンドを実行してください。

ファイル

  • パス:XDG_CONFIG_HOME が絶対パスに設定されている場合は $XDG_CONFIG_HOME/shipyard/config.toml、それ以外の場合は ~/.config/shipyard/config.toml です。
  • すべてのキーは省略可能です。ファイルがない場合や空の場合は、プロジェクトなしのデフォルト設定になります(その場合、アプリにはプロジェクト選択画面が表示されます)。
  • アプリがファイルに書き込む方法は、次の 3 通りだけです。オンボーディングではファイル全体にプリセットを書き込みます(ただし、ファイルが存在しない場合、または version 以外に有効な内容がない場合に限ります)。プロジェクト選択画面では [[projects]] ブロックを追加します。メニューのヘッダーにあるレイアウトボタンでは、他のすべての行を維持したまま、[menu] の下にある layout を次のレイアウトに切り替えます(リスト、次にタブ、再びリストの順)。そのため、編集する前に必ずファイルを読み直してください。
  • キーは kebab-case です。スキーマは https://raw.githubusercontent.com/yahyabedirhan/shipyard/main/schema/config.schema.json で、ファイルの 1 行目に #:schema <url> として指定されています。

プリセットから始める

Shipyard には、主な用途に合わせたすぐに使えるファイルであるプリセットが3つあります。アプリのセットアップ時に提示され、presets.mdにはそれぞれのファイル全体が記載されています。

  • my-agents:ユーザーとそのエージェントが作成したプルリクエストとイシュー。リポジトリごとに1つのプロジェクトです。
  • incoming-contributions:ユーザーのリポジトリで他の人が作成したもの。ボットは非表示で、どこにあるものでもレビュー待ちのプルリクエストが含まれます。
  • review-queue:どのリポジトリにあるかを問わず、ユーザーのレビュー待ちのプルリクエストのみです。

ユーザーがプリセットを指定した場合、またはこれらの用途のいずれかに合わせて shipyard をセットアップ(または最初からやり直す)よう求めていて、ファイルが存在しないか、version以外に有効な設定がない場合は、presets.mdの説明に従い、ユーザーのリポジトリを使ってプリセットのファイルを作成してください。ファイルにすでに設定やプロジェクトがある場合は置き換えず、以下のキーを使って、依頼に必要な変更を行ってください。

編集方法

  1. ファイル全体を読みます。ユーザーはコメントを書き込み、手作業で編集しています。コメント、空行、既存の順序をすべて維持し、依頼に必要な行だけを変更または追加してください。

  2. 追加する内容は、TOMLが正しく解釈できる場所に配置してください。

    • トップレベルキー(refresh-interval、launch-at-loginなど)は、最初の[table]ヘッダーより前に置きます。その下に置くと、TOMLではそのテーブルのキーとして解釈されます。
    • version = 1は先頭に維持してください。これがなくてもキーを設定したファイルは読み込まれますが、警告が表示されます。今後のバージョンでは拒否されます。
    • テーブル([menu]、[menu-bar]、[rate-limit]、[attention]、[defaults.issues]など)は、最初の[[projects]]ブロックより前に1回だけ置きます。テーブルがすでにある場合は、その中にキーを追加してください。テーブルヘッダーを重複して書くと、TOMLとして無効になります。
    • 新しいプロジェクトは、ファイルの末尾に追加する[[projects]]ブロックです。
    • プロジェクトのオーバーライド(pull-requests、issues、workflow-runs、pings、notes、notifications)は、各ブロック内にインラインテーブルとして記述し、ブロックごとに内容を完結させます。
    • インラインテーブル{ … }は1行に収めます。配列[ … ]は複数行にまたがってもかまいません。
    • アプリが作成したファイルの先頭には、共通設定をデフォルト値のコメントアウトされたTOMLとして示すヘッダーがあります。対象は、theme、[defaults.pull-requests] authors、[menu] layout、[menu-bar] count、[defaults] group-by、sort-by、show-first、[defaults.issues]のshowとstates、[defaults.workflow-runs]のshow、[defaults.pings]のshowとseen-window、refresh-interval、5つのデフォルト[[defaults.notifications]]ルール(pr.opened、ping.sent、agent.notice、control.started、control.ended)、および[rate-limit] max-share-percentです。いずれかを設定するには、その行(キーを含むテーブル行)をコメント解除し、同じ設定を追加するのではなく値を変更してください。ヘッダーではトップレベルキーがテーブルより前に置かれるため、どれでもコメント解除できます。以降に編集されたファイルでは、コメント解除するテーブル行より下にトップレベルキーがないことを確認してください。ある場合、そのキーはテーブル内のものとして解釈されます。
  3. アプリは起動時、またはRefreshボタンをクリックしたときに、ヘッダーのないファイルをこのヘッダー付きで作成します。ファイルがまだ存在しない場合は、ディレクトリも作成して、以下の内容から始めてください。

    #:schema https://raw.githubusercontent.com/yahyabedirhan/shipyard/main/schema/config.schema.json
    version = 1
    
  4. 編集のたびにshipyard config checkを実行し、その後、残りの項目も確認してください(「編集内容の確認」を参照)。shipyard config checkが終了コード0で終了し、taplo checkも終了コード0で終了し、アプリの記録に保存内容の"accepted": trueが示されれば完了です。

キーとデフォルト値

トップレベル:

キーデフォルト許可される値
version11 のみ
theme"System"大文字と小文字を区別せず、名前で指定するパネルのテーマ:System(macOS の外観とアクセントカラーに従います)、Shipyard Light、Shipyard Dark、Paper Light、Paper Dark、Harbor、Heather、Brass、Ocean、Sunset、または config.toml と同じ場所にある themes/*.toml のテーマファイルの name。不明な名前を指定すると、すべてのテーマを列挙したエラーになります。ギアメニューの Theme サブメニューからも設定できます。テーマファイルについては、references/themes.md を参照してください
refresh-interval"2m"以下の期間。少なくとも "30s":アプリの更新頻度です。レート制限の割り当て内に収まるよう、必要に応じて間隔を延ばします
launch-at-logintrueブール値

テーブル:

キーデフォルト許可される値
[menu-bar] count"total""total"、"per-kind"(PR、イシュー、実行、ping を個別に表示)、"none"
[menu] layout"list""list"(すべてのプロジェクトを、項目ごとに1行のスクロールリストに表示)、"tabs"(一度に1つのプロジェクトを表示)
[menu] header-counts5種類すべて"pull-requests"、"issues"、"workflow-runs"、"pings"、"notes" のリスト。各項目は1回ずつ指定します。リストレイアウトで各プロジェクトのヘッダーに件数を表示する種類です。プロジェクトのヘッダーには、そのプロジェクトに項目がある種類の件数が、リストの順序にかかわらず常にこの順番で表示されます。グローバル設定のみ:プロジェクトごとの設定はできません
[rate-limit] show"always""always"、"when-low"(25% 未満)、"never"
[rate-limit] max-share-percent101~50:各時間単位の GitHub 制限のうち、shipyard が使用できる割合です(ユーザーのエージェントと共有されます)
[attention] unseentrueまだクリックされていない項目に注意が必要になります
[attention] changedtrueクリック後に変更された項目に注意が必要になります
[attention] review-requestedtrueユーザー(またはユーザーが所属するチーム)にレビューを依頼している PR に注意が必要になります
[attention] checks-failedtrueチェックに失敗した PR(または実行)に注意が必要になり、PR のチェックに合格するまで、既読になった後も signal.attention-failed の注意ドットは赤のままです
[herdr] terminal未設定Herdr を実行するターミナルアプリ。名前("Ghostty")またはバンドル ID("com.mitchellh.ghostty")で指定します。--herdr で送信した ping をクリックすると、その Herdr タブにフォーカスしてから、このアプリを前面に表示します。未設定の場合、送信元のターミナルが判明していればそれを前面に表示します。判明していなければ、タブにフォーカスするだけです
[remote] machines[]保存済みのマシンとして Herdr が認識しているラベルで指定する、その他のマシン(["beta-vps"])。ホスト名やアドレスは指定しないでください。shipyard は各マシンに Herdr 経由でエージェントの ping を問い合わせ、プロジェクトの後に、そのマシン名を付けたセクションに一覧表示します。ラベルは空にできません。また、- で始めること、制御文字を含めること、重複させること、プロジェクトのスラッグまたはタイトルと同じにすることはできません
[notices] listenfalseアプリが tailnet 経由で、その他のマシンのエージェントからの通知(shipyard notice send)を直接受け取るかどうかを指定します。true でない限り、何も待ち受けません。true にすると、アプリは 127.0.0.1 のみで待ち受け、この Mac 自身の Tailscale ログインから送信された通知のみを受け取ります。設定方法については、references/notices.md を参照してください
[notices] port474201~65535:127.0.0.1 で待ち受けるポート。tailscale serve によって tailnet に公開されます
[banners] snooze-duration"1h"以下の期間。0 より大きい値:✕ をクリックした後、プロジェクト上部のバナーを非表示にする時間です。期間が過ぎても条件が続いていれば、バナーが再表示されます。条件がいったん終了してから再び成立した場合は、バナーがすぐに表示されます。"10s" などの短い値を使うと、バナーが再表示されることをすばやく確認できます

各プロジェクトに表示する内容は、[defaults.pull-requests]、[defaults.issues]、[defaults.workflow-runs]、[defaults.pings]、[defaults.notes](および [[defaults.notifications]])で設定します。また、プロジェクトごとのブロックで上書きできます:

キーデフォルト許可される値
pull-requests.showtrueブール値
pull-requests.states["open", "merged", "closed"]一覧に表示するPR:"open"(ドラフトも含む)、"merged"、"closed"(マージせずにクローズ)のいずれか
pull-requests.closed-window"7d"期間(下記):クローズ済みおよびマージ済みのPRを一覧に表示する期間。"0"にすると非表示になります
pull-requests.draftstrueブール値。ドラフトPRを一覧に表示します
pull-requests.authors{ show = [], hide = [] }一覧に表示するPRの作成者:authors.showからauthors.hideを除いたもの。どちらも作成者セレクターのリストです(「対象アイテム」を参照)
pull-requests.review-requestedfalseブール値。trueにすると、ユーザー本人または所属するチームがレビューを依頼された、レビュー待ちのオープンPRのみを一覧に表示します
issues.showfalseブール値
issues.states["open", "closed"]一覧に表示するIssue:"open"、"closed"のいずれか
issues.closed-window"7d"期間:クローズ済みのIssueを一覧に表示する期間
issues.authors{ show = [], hide = [] }一覧に表示するIssueの作成者。プルリクエストと同様です
workflow-runs.showfalseブール値
workflow-runs.states["in-progress", "failed", "succeeded"]一覧に表示する実行:"in-progress"(キュー待ちまたは実行中)、"failed"(タイムアウトおよび起動失敗も含む)、"succeeded"のいずれか
workflow-runs.finished-window"3h"期間:完了した実行を一覧に表示する期間(実行中のものは常に表示されます)
workflow-runs.branches"default-and-pull-requests"または"all"
workflow-runs.authors{ show = [], hide = [] }一覧に表示する実行の作成者(実行の作成者は、それを開始したアカウントです)
pings.showtrueブール値。エージェントがshipyard pingで送信したPingを、リポジトリを監視する各プロジェクトの下、またはPingで指定された1つのプロジェクトの下に一覧表示します。Pingにはstates、authors、drafts、review-requestedを設定できません。いずれかを設定するとエラーになります
pings.seen-window"24h"期間:確認済みのPingを一覧に表示する期間。確認された時点から数えます。未確認のPingは確認されるまで表示されます。確認済みのPingは、期間が過ぎた後の最初の更新時に一覧から消え、削除されます
notes.showtrueNotionにあるユーザーのオープンなノートを、新しい順に「Notes」グループ内に一覧表示します。対象となるのは、プロジェクトのデータベース内、「Shipyard Notes」ページの「Projects」ページの下にあるノートのうち、プロジェクトのタイトルと完全に一致するものです。各行には、接頭辞付きの番号(SHOP-7)、タイトル(または本文の最初の行)、ラベルが表示されます。クリックするとNotionで開き、ヘッダーのノート数をクリックするとプロジェクトのデータベースが開きます。プロジェクトのヘッダーには新規ノートアイコンがあり、クリックするとデータベースに空のノートを作成してNotionで開きます(データベースがない場合は、データベースとProjectsページを先に作成します)。ノートは対応が必要なアイテムではないため、どのカウントにも加算されません。データベースがないプロジェクトには何も表示されません。アプリはNotionのCLIであるntnを通じて、ntn独自のログインを使用してノートの読み取りと書き込みを行います。これは毎分、およびメニューを開いたときに実行されます。アプリが独自のNotionトークンを保持することはありません。設定メニューのSet up NotionビューでユーザーがConnect with ntnを押すまで、ノートは一覧表示されず、ntnも実行されません。接続後、ntnがインストールされていないかログインしていない場合、またはntnのデフォルトのワークスペースにShipyard Notesページがない場合は、ノートは一覧表示されず、何をすべきかを示すバナーが表示されます。また、ntnがインストールされてログインするまで、新規ノートアイコンは非表示になります(ノートのリファレンスにある「ntnのセットアップ」を参照)。ノートに設定できるのはshowのみです。states、authors、drafts、review-requested、seen-windowを設定するとエラーになります
notifications5つのルール:pr.opened、ping.sent、agent.notice、control.started、control.ended。それぞれのauthors = []ルールのリスト(下記)
window は文字列です。整数と単位 s、m、h、d を1つずつ組み合わせます。たとえば "45s"、"30m"、"12h"、"7d" です。"0" にすると、クローズ済み(または完了済み)の項目がすぐに非表示になります。小数、負の数、空白、複数の単位は使えません。"1.5h" や "1h30m" ではなく、"90m" と記述してください。不正な値は該当する行と最も近い表記を示して拒否されます。例:"closed-window must be a whole number and one unit, s, m, h or d, such as "30m" (got "30min"; did you mean "30m"?)"。項目は、クリックしなくても、指定した期間が過ぎてから1回の更新以内に表示されなくなります。

メニュー内で各プロジェクトの項目をどのようにグループ化して並べ替えるかは、[defaults] の直下(サブテーブル内ではありません)で設定します。各プロジェクトのブロックでは個別に上書きできます。

KeyDefaultAllowed
[defaults] group-by"kind""kind"(プルリクエスト、ピン、イシュー、実行、メモの順)、"repository"(AからZ)、"date"(今日、昨日、今週、今月、それ以前)、"author"(AからZ。ピンは送信者ごとに並び、送信者の記載がないものは「ピン」としてまとめられます)、"none"(1つのリスト)。階層は1つのみです
[defaults] subsectionsunsetブール値:true の場合は各グループをサブ見出し(グループ名と件数)で表示し、false の場合は区切り線の後に表示します。未設定の場合は各レイアウト独自の表示になります(リストでは区切り線、タブではサブ見出し)
[defaults] sort-by"updated""updated"(新しい順)、"created"(新しい順)、"title"(AからZ)。オープン中または実行中の項目は常に先頭に表示されます。"date" はこの日付でグループ化します(タイトル順で並べ替える場合は "updated")
[defaults] show-first00以上の整数:各グループの先頭N行を表示し、「Show N more」行を追加します。この行を選ぶと残りが表示され、その後は「Show less」と表示されます。0 の場合はすべての行を表示します。group-by = "none" の場合はプロジェクト全体を対象にします。グループの件数には非表示の行も含まれます。また、メニューを閉じるたびに、すべての上限が元に戻ります

タブレイアウトの「All」タブは、常に種別ごとにグループ化し、新しい順に並べます。

「Which repositories」を参照してください。リポジトリのグループと owner/* に含める対象は、[defaults] とプロジェクトのブロックで設定します。

KeyDefaultAllowed
[defaults] archivedfalseブール値:true の場合、アーカイブ済みのリポジトリも含めます
[defaults] forkstrueブール値:false の場合、フォークを除外します

プロジェクトは、[[projects]] ブロックを1つずつ記述し、ファイル内の順序でセクションとして表示します。

KeyRequiredAllowed
slugyesプロジェクトのIDです。プロジェクト間で一意にする必要があります。小文字と数字を単一のハイフンでつなげて指定します(例:"e-commerce")。--project、panel fold、panel show-tab で指定します
titlenoメニュー、セクション、タブのタイトルとして表示するテキストです(例:"E-commerce")。未設定の場合はスラッグが使われます
repositoriesyesリポジトリセレクターを1つ以上指定します:owner/name、owner/*、owned、organizations、collaborator、anywhere(「Which repositories」を参照)。URLは指定できません
pull-requests、issues、workflow-runs、pings、notesno上記のキーを含むインラインテーブル
group-by、subsections、sort-by、show-firstno上記の [defaults] と同様です
archived、forksnoブール値です。このプロジェクトでは [defaults] を上書きします
notificationsnoルールのリスト

オーバーライド

  • プロジェクトの pull-requests、issues、workflow-runs、pings、notes テーブルは、[defaults.*] に対してキーごとにマージされます。issues = { show = true } とすると、イシューが表示され、デフォルトの closed-window はそのまま維持されます。states のようなリストは1つのキーとして扱われ、プロジェクトのリストがデフォルトのリストに置き換わります。authors もキーごとにマージされます。プロジェクトで authors = { hide = [...] } とすると、デフォルトの hide は置き換わり、デフォルトの show は維持されます。
  • プロジェクトの notifications は、そのプロジェクトのデフォルトリストを置き換えます。追加されるわけではありません。プロジェクトでも維持するデフォルトのルールは、繰り返し記述してください。notifications = [] は、そのプロジェクトでは通知を受け取らないことを意味します。
  • [[defaults.notifications]] ブロックも、組み込みのデフォルト(全員からの pr.opened、ping.sent、agent.notice、control.started、control.ended)を置き換えます。ファイルにこのブロックがある場合、維持するルールも記述してください。独自のルールを列挙して ping.sent がないファイルでは、ping の通知は届きません。通知を受け取るには { event = "ping.sent" } を追加してください。ルールに agent.notice がないプロジェクトは、エージェントからの通知を拒否するため、そこで shipyard notice send を実行すると終了コード 1 になります。通知を表示するには { event = "agent.notice" } を追加してください。同様に、control.started と control.ended がない場合は、エージェントがアプリの使用を開始または終了しても通知されません。

対象のリポジトリ:リポジトリセレクター

プロジェクトの repositories には、任意の組み合わせでリポジトリセレクターを列挙します。構文は作成者セレクター(以下を参照)と同じです。単独の単語はグループを表し、/ はリポジトリを表します。

セレクター監視対象
owner/name1つのリポジトリ:オーナー名には英字、数字、- を使用でき、リポジトリ名にはさらに _ と . を使用できます
owner/*ユーザーまたは組織が所有するすべてのリポジトリ。例:my-org/*
ownedサインイン中のアカウントが所有するすべてのリポジトリ
organizationsアカウントがメンバーになっている組織を通じて、直接またはチーム経由でアクセスできるすべてのリポジトリ
collaboratorアカウントをコラボレーターとして追加した、他の人のリポジトリ
anywhereユーザーがレビューを待っている、ユーザーが一度もコミットしたことのないリポジトリも含む、あらゆるリポジトリのオープンなプルリクエスト
  • owned、organizations、collaborator は GitHub 独自の所属区分であり、重複しません。この3つを合わせると、アカウントがアクセスできるすべてのリポジトリになります。me/* はありません。owned と記述してください。
  • グループとワイルドカードは、アプリの起動時、編集のたび、⌘R を押したとき、およびそれ以外ではおよそ1時間ごとに検索されます。そのため、ファイルを編集しなくても、後から作成されたリポジトリが表示されます。既存の項目は通知なしで一覧表示され、通知されるのはその後に起きたことだけです。
  • archived = true または forks = false を指定しない限り、アーカイブ済みリポジトリは除外され、フォークは含まれます。owner/name として指定したリポジトリは、アーカイブ済みかどうかにかかわらず常に一覧表示されます。
  • 2つのセレクターが同じリポジトリを含めても、一覧には1回だけ表示されます。
  • オーナーが存在しない、またはアカウントから見えない owner/* は、プロジェクトにエラー行として表示されます。リポジトリがないグループには「オープンな項目はありません」と表示されます。
  • repositories に指定した作成者グループ(me、others、bots)または @login は、ヒントとともに拒否されます。誰かのリポジトリを監視するには、owner/* と記述してください。
  • anywhere はリポジトリではなく、GitHub の検索1回から取得されるため、review-requested = true のプルリクエストを一覧表示し、イシューも実行履歴も表示しないプロジェクトでのみ機能します(そのブロックまたはデフォルトで指定します)。これ以外の設定は拒否され、「anywhere には pull-requests = { review-requested = true } が必要です。また、イシューや実行履歴を一覧表示できません」と表示されます。プロジェクトの他のフィルター(authors、states、drafts)は通常どおり適用されます。検索で取得されるプルリクエストは最大100件です。それ以上のレビュー待ちがある場合は、その旨がプロジェクトに表示されます。

対象項目:状態

各種類の states は、項目の状態に基づいて対象を選びます。対象外の項目は表示も集計も通知もされません。クローズ済みウィンドウの設定は引き続き適用されます。states はどの項目を対象にするかを指定し、closed-window(または finished-window)はクローズ、マージ、完了した項目をどれくらいの期間表示するかを指定します。そのため、pull-requests = { states = ["open"] } では、マージ済みやクローズ済みの PR は一切表示されません。また、states = ["merged"] では、closed-window の期間内にマージされた PR が表示されます。その種類で使用できない状態を指定すると、最も近い有効な状態を示して拒否されます:「unknown pull request state merge (did you mean merged?)」。states = [] にすると、その種類の項目は何も表示されません。種類を非表示にするには、show = false を指定するほうが明確です。

投稿者の項目:投稿者セレクター

各種類の authors = { show = [...], hide = [...] } は、プロジェクトに表示する項目の投稿者を決定します。投稿者が show に一致し(show が空の場合は全員が対象)、かつ hide に一致しない項目が表示されます。両方に一致する場合は hide が優先されます。すべてのプロジェクトに適用するには [defaults.pull-requests]、[defaults.issues]、または [defaults.workflow-runs] に設定するか、個別のプロジェクトブロック内で設定してください。プルリクエスト、issue、ワークフロー実行にはそれぞれ個別の設定があります。すべての場所で誰かを非表示にするには、プロジェクトで表示する各種類でその人を非表示にする必要があります。

プロジェクトのフィルターで対象外になった項目は shipyard から除外されます。表示されず、メニューバー、プロジェクトのヘッダー、タブでも集計されず、通知もされません。取得済みの項目はすべて記憶されるため、後から設定を変更して項目が表示対象になっても、新着として通知されることはありません。

show と hide の値、および通知ルールの authors の値は、投稿者セレクターです。構文はシンプルです。単独の単語はグループ、@ はユーザー、/ はリポジトリを示します。

セレクター対象
meサインイン中のユーザー。本人として動作するエージェントも含みます
othersユーザー本人とボットを除くすべてのユーザー
botsGitHub Bot アカウント、またはログイン名が [bot] で終わるアカウント
@login1 つのアカウント。例:@octocat、@dependabot[bot]([bot] の接尾辞は残してください)。大文字と小文字を区別せず照合します

me、others、bots を組み合わせると、すべての投稿者を漏れなく分類できます。ログイン名には必ず @ を付けてください。グループ名ではない単独の単語を指定すると、ヒントとともに拒否されます:「unknown author bots2 (did you mean bots or @bots2?)」。リポジトリ(owner/name)やリポジトリグループも authors では拒否されます。リポジトリはプロジェクトの repositories に指定してください。

通知ルール

notifications リストの各要素であるルールは { event = "…", authors = [...] } です。authors は作成者セレクターのリストで、デフォルトは [](全員)です。プロジェクトのリストにイベントを指定するルールがあり、その authors のいずれかがアイテムの作成者に一致すると、そのイベントが通知されます。ルールで絞り込めるのは、プロジェクトのリストに含まれるアイテムだけです。プロジェクトのフィルター(states、authors、drafts、または 0 のクローズ済みウィンドウ)から除外されたアイテムは、ルールの指定にかかわらず通知されません。そのため、pr.merged には states で merged を指定し、closed-window を "0" より大きくする必要があります。また、run.failed には states で failed を指定し、finished-window を "0" より大きくする必要があります。各イベントは一度だけ通知され、プロジェクトに追加した時点ですでに存在するアイテムは通知されません。

イベントタイミング
pr.opened新しいプルリクエストがオープン状態でリストに追加されたとき(ドラフトも含む)
pr.mergedオープン中のプルリクエストがマージされたとき
pr.closedオープン中のプルリクエストがマージされずにクローズされたとき
pr.reopenedクローズ済みのプルリクエストが再オープンされたとき
pr.review_requestedオープン中のプルリクエストで、ユーザー本人またはユーザーが所属するチームに新たにレビューが依頼されたとき
pr.checks_failedオープン中のプルリクエストのチェックが新たに失敗したとき
pr.commentedプルリクエストにコメントまたはレビューが追加されたとき
issue.opened新しいイシューがオープン状態でリストに追加されたとき
issue.closedオープン中のイシューがクローズされたとき
issue.commentedイシューにコメントが追加されたとき
run.failedワークフローの実行が失敗して終了したとき(タイムアウトまたは開始失敗も含む)
run.succeededワークフローの実行が成功して終了したとき
control.startedエージェントが shipyard アプリ(shipyard app、panel、または lease)の使用を開始したとき:「Claude Code is using shipyard」。アプリの実行場所を示します。判定には [[defaults.notifications]](または組み込みのデフォルト設定)のみが使われます。プロジェクト独自のリストやルールの authors は適用されず、アプリはその旨を警告します。クリックするとパネルが開き、バナーにエージェント名が表示されます
control.endedエージェントがアプリの使用を終了したとき:「Claude Code is done with shipyard」。終了理由(解放された、リースが期限切れになった、ユーザーが停止した)を示します。判定方法は control.started と同じです
ping.sentエージェントが新しい ping を送信したとき。タイトルにはプロジェクト名と ping のタイトルが表示され、本文と送信者を示します。ping は一度だけ通知されます。通知をクリックすると、ping をクリックしたときと同じ動作が行われます。アクション(リンクまたはアプリを開く、あるいは Herdr タブにフォーカスする)が実行され、ping は確認済みとしてマークされます。ping には作成者がいないため、authors を指定したルールでは選択されません
agent.noticeエージェントが shipyard notice send で通知を投稿したとき。タイトルにはプロジェクト名と通知のタイトルが表示され、本文と送信者を示します。--id で置き換えられない限り、通知ごとに個別の通知が送信され、リストには追加も保存もされません。プロジェクトのルールで除外される通知は拒否され、その旨がエージェントに伝えられます。通知には作成者がいないため、authors を指定したルールでは選択されません

イシューイベントを通知するには、プロジェクトでイシューを表示する必要があります。また、実行イベントを通知するには、ワークフローの実行を表示する必要があります。

編集内容の確認

コマンド。 編集のたびに shipyard config check を実行します。アプリを起動せずに、アプリがファイルを読み込むのと同じ方法で読み込み、コマンド独自の cli.toml がある場合はそれも読み込みます。

shipyard config check; echo "config check exit status: $?"
/Users/me/.config/shipyard/config.toml: rejected
  problem: config.toml line 14: unknown event `pr.openned` (did you mean `pr.opened`?)
/Users/me/.config/shipyard/cli.toml: accepted (no file: the defaults)

themes フォルダー内の各テーマファイルには、config.toml と cli.toml の間に個別の判定が表示され、問題は themes/<file> line N: … の形式で示されます。

終了ステータスが 0 の場合、すべてのファイルが受け入れられています。それでも各 warning 行を修正してください。通常はキーのスペルミスです。終了ステータスが 1 の場合、ファイルに problem があります。それぞれの行で修正し、コマンドを再実行してください。shipyard config check --json は、各ファイルの結果をファイル名(config.toml、themes/<file>、cli.toml)の下に、以下のアプリの記録と同じフィールドで出力するため、比較できます。これはディスク上のファイルを確認するもので、アプリが実際に使用している内容を確認するものではありません。アプリの記録で、保存内容が反映されたかどうかを確認できます。

スキーマ。 ファイルに対して Taplo を実行し、終了ステータスを出力します。スキーマは #:schema 行から取得されます。

taplo check ~/.config/shipyard/config.toml; echo "taplo exit status: $?"

終了ステータスが 0 なら成功です。それ以外は失敗で、その理由は上の行に表示されます。出力を tail、grep、head にパイプしないでください。成功時に Taplo が出力するのは INFO 行だけであり、パイプを使うと終了ステータスが分からなくなります。Taplo がインストールされていない場合は、同じ方法で npx -y @taplo/cli check <file> を実行するか、brew install taplo を実行してください。ファイルに #:schema 行がない場合、またはスキーマ URL を取得できない場合は、上記のスキーマ URL を指定して --schema <url> を渡してください(file://<absolute path> としてローカルコピーを指定することもできます)。スキーマは未知のキーについてアプリより厳格です。アプリなら警告して無視する内容も拒否するため、それらも修正してください。

スキーマでは次の 3 つのルールを確認できません。shipyard config check とアプリの記録で確認するか、ファイルを読んで確認してください。

  • 各プロジェクトの slug は 1 回だけ使用されています。
  • 各プロジェクトで、リポジトリ、ワイルドカード、グループがそれぞれ 1 回だけ列挙されています。大文字と小文字は区別されません(owner/name と Owner/Name は同じリポジトリです)。
  • トップレベルのキーは、最初の [table] ヘッダーより前にあります。

アプリ。 Shipyard は保存のたびにすぐにファイルを再読み込みし、判定結果を ~/Library/Application Support/Shipyard/config-status.json に書き込みます。保存後に 1 秒待ち、記録と編集したファイルの更新日時($XDG_CONFIG_HOME が設定されている場合はその下のファイル)を読み取ります。

cat ~/Library/Application\ Support/Shipyard/config-status.json
date -u -r ~/.config/shipyard/config.toml +%Y-%m-%dT%H:%M:%SZ
{
  "accepted" : false,
  "checked" : "2026-09-25T12:05:01Z",
  "config" : "/Users/me/.config/shipyard/config.toml",
  "configModified" : "2026-09-25T12:05:00Z",
  "problems" : [
    {
      "banner" : "config.toml line 14: unknown event `pr.openned` (did you mean `pr.opened`?)",
      "line" : 14,
      "message" : "unknown event `pr.openned` (did you mean `pr.opened`?)"
    }
  ],
  "version" : 1,
  "warnings" : []
}
  • 保存内容に対する記録ですか? configModified が date の出力と一致し(どちらも UTC、秒単位)、かつ config が編集したファイルを示している場合に限ります。記録がそれより古い場合、アプリはまだ再読み込みしていません。少し待ってからもう一度読み取ってください。いつまでも更新されない場合は、shipyard が実行されていません。アプリが編集内容を反映したと主張せず、そのことを伝えてください。
  • "accepted": true:アプリは編集内容を反映しました。warnings には無視された設定が、それぞれ line とともに一覧表示されます。通常はキーのスペルミスなので、修正してください。
  • "accepted": false:アプリはファイルを拒否し、最後に有効だった設定で実行を続けています。problems の各項目を該当する line で修正してください(該当行を特定できない場合は null)。保存してから記録をもう一度読み取ります。banner はパネルのバナーにユーザー向けに表示されるのと同じ行で、末尾は「Using the last valid configuration.」です。

この記録では、上記の 3 つのルールを含め、アプリでしか確認できない内容も検出できます。

依頼例

「このリポジトリを shipyard で監視して。」 リポジトリの origin リモートから owner/name のスラッグを取得します。プロジェクトにすでに登録されている場合は、そのことを伝えて終了します。登録されていない場合は、ブロックを追加します。slug はリポジトリ名、つまり / より後ろの部分から作成します。小文字に変換し、その他の文字が連続する箇所はハイフン 1 つに置き換えます(My_Shop → my-shop)。すでに別のプロジェクトでそのスラッグが使われている場合は、owner/name 全体を同じ方法で変換して作成します(yahyabedirhan-shipyard)。ユーザーがプロジェクトに独自の名前を付けた場合は、その名前からスラッグを作成し、すでにスラッグと同じ名前でない限り、名前を title として追加します("My Shop" → slug = "my-shop"、title = "My Shop")。

[[projects]]
slug = "shipyard"
repositories = ["yahyabedirhan/shipyard"]

「これらのリポジトリを1つのプロジェクトにまとめてください。」 すべてのリポジトリを1つのブロックに記述します。一部がすでにプロジェクトになっている場合は、それらのリポジトリ(およびグループに適用するオーバーライド)を1つのブロックに移し、空になったブロックを削除します。引き続き適用されるコメントは残してください。

[[projects]]
slug = "e-commerce"
repositories = ["yahyabedirhan/e-commerce-frontend", "yahyabedirhan/e-commerce-backend"]

「自分のすべてのリポジトリを監視してください。」 owned グループを含むプロジェクトを1つ作成します。ユーザーが所属する組織のリポジトリも対象にする場合は、organizations を追加します。

[[projects]]
slug = "mine"
repositories = ["owned"]

「my-org のすべてと、自分の shipyard を監視してください。」 ワイルドカードを単一のリポジトリの隣に置きます。archived = true を設定すると、組織のアーカイブ済みリポジトリも含まれます。

[[projects]]
slug = "my-org"
repositories = ["my-org/*", "yahyabedirhan/shipyard"]

「他の人がここで PR を作成したときに通知してください。」 このプロジェクト専用のリストを設定します(デフォルトが置き換えられます。「オーバーライド」を参照)。

[[projects]]
slug = "shipyard"
repositories = ["yahyabedirhan/shipyard"]
notifications = [
  { event = "pr.opened", authors = ["others"] },
]

すべてのプロジェクトに適用する場合は、[[defaults.notifications]] ブロックを記述します。

「dependabot を非表示にしてください。」 プルリクエストのデフォルトに hide を設定します(リストがすでにある場合は追加します。プロジェクトでイシューも表示する場合は、[defaults.issues] にも同じ設定を追加します)。GitHub の表示どおり、@ を付けたログイン名を指定し、[bot] の接尾辞も含めます。すべてのボットを非表示にするには、代わりに bots を指定します。

[defaults.pull-requests]
authors = { hide = ["@dependabot[bot]"] }

「マージ済みおよびクローズ済みの項目を30分間表示してください。」 各種別のデフォルトに closed-window を設定します(実行の場合は finished-window)。特定のプロジェクトだけに適用する場合は、そのプロジェクトのブロック内に設定します。

[defaults.pull-requests]
closed-window = "30m"

[defaults.issues]
closed-window = "30m"

「このプロジェクトでは、他の人が作成した項目だけを表示してください。」 プロジェクトが表示する各種別について、プロジェクトのブロック内で me と bots を非表示にします。

[[projects]]
slug = "shipyard"
repositories = ["yahyabedirhan/shipyard"]
pull-requests = { authors = { hide = ["me", "bots"] } }
issues = { show = true, authors = { hide = ["me", "bots"] } }

1つのアカウントの項目だけを表示する場合(たとえば依存関係の更新用プロジェクト)は、代わりに show を使用します。pull-requests = { authors = { show = ["@dependabot[bot]"] } } のように設定します。

「このプロジェクトでは、自分のレビュー待ちの PR だけを表示してください。」 プロジェクトのプルリクエストに review-requested を設定します。ユーザーが所属するチームへの依頼も対象になります。プロジェクトのイシューと実行には影響しません。レビュー待ち専用のキューにするには、それらも無効にします。

[[projects]]
slug = "shipyard-reviews"
title = "shipyard reviews"
repositories = ["yahyabedirhan/shipyard"]
pull-requests = { review-requested = true }

「場所を問わず、自分のレビュー待ちの PR をすべて表示してください。」 anywhere グループを含むプロジェクトを作成します。この場合、ユーザーのレビュー待ちの PR だけをリストに指定する必要があります。リポジトリごとにグループ化すると、多数のリポジトリを見やすく整理できます。また、pr.review_requested を設定すると、新しいレビュー依頼があるたびに通知されます。

[[projects]]
slug = "review-queue"
title = "Review queue"
repositories = ["anywhere"]
pull-requests = { review-requested = true }
group-by = "repository"
subsections = true
notifications = [
  { event = "pr.review_requested" },
]

「このプロジェクトをリポジトリごとにグループ化し、それぞれにヘッダーを表示してください。」 プロジェクトのブロック内で group-by と subsections を設定します(すべてのプロジェクトに適用する場合は [defaults] に設定します)。

[[projects]]
slug = "contributions"
repositories = ["yahyabedirhan/shipyard", "yahyabedirhan/skills"]
group-by = "repository"
subsections = true

新しく作成されたものを先に表示するには sort-by = "created" を追加します。本日の変更を先頭に表示するには group-by = "date" を設定します。

「このプロジェクトを簡潔にして、各項目を少しだけ表示し、残りは展開できるようにしてください。」 プロジェクトのブロック内で show-first を設定します(すべてのプロジェクトに適用する場合は [defaults] に設定します)。各グループに指定した件数の行が表示され、残りを表示する「さらに N 件を表示」行が追加されます。メニューを閉じるまで、そこから残りを表示できます。

[[projects]]
slug = "contributions"
repositories = ["yahyabedirhan/shipyard", "yahyabedirhan/skills"]
show-first = 5

「ここではオープン中の PR とイシューだけを表示してください。」 プロジェクトのブロック内で、各種別に states を設定します。

[[projects]]
slug = "shipyard"
repositories = ["yahyabedirhan/shipyard"]
pull-requests = { states = ["open"] }
issues = { show = true, states = ["open"] }

実行も同様に設定できます。workflow-runs = { show = true, states = ["failed", "in-progress"] } とすると、成功した実行は表示されません。すべてのプロジェクトに適用するには、代わりに [defaults.pull-requests](または [defaults.issues]、[defaults.workflow-runs])で states を設定します。

「メニューをタブ表示に切り替えてください。」 [menu] テーブルにキーを1つ設定します。配置ルールで許可されている場合は、ヘッダーにある # [menu] の行のコメントを解除します。メニューのヘッダーにあるレイアウトボタンを使えば、同じ変更をワンクリックで行えます。

[menu]
layout = "tabs"

「Ocean テーマを使ってください。」 最初のテーブルより前に、トップレベルのキーを1つ設定します。ヘッダーに # theme の行がある場合は、そのコメントを解除します。メニューの歯車アイコンにある「テーマ」サブメニューを使えば、同じ変更をワンクリックで行えます。 ユーザー独自のテーマ(たとえば「オレンジ色にする」)を使う場合は、references/themes.md の説明に従って、まずテーマファイルを作成し、ここにその name を指定します。

theme = "Ocean"

「このプロジェクトのイシューを表示してください。」 プロジェクトのブロック内に issues オーバーライドを追加します。

[[projects]]
slug = "e-commerce"
repositories = ["yahyabedirhan/e-commerce-frontend", "yahyabedirhan/e-commerce-backend"]
issues = { show = true }

すべてのプロジェクトでイシューを表示するには、代わりにデフォルトで一度だけ設定します。

[defaults.issues]
show = true

「このプロジェクトの CI 実行を表示して、失敗したときに知らせてください。」 workflow-runs のオーバーライドと、デフォルトの pr.opened、ping.sent、agent.notice に run.failed を加えた通知リストを設定します:

[[projects]]
slug = "shipyard"
repositories = ["yahyabedirhan/shipyard"]
workflow-runs = { show = true }
notifications = [
  { event = "pr.opened" },
  { event = "ping.sent" },
  { event = "agent.notice" },
  { event = "run.failed" },
]

「Shipyard から ping の通知が届きません。」 このファイルでは、ping.sent を含めずに独自のルールを列挙しています(「オーバーライド」を参照)。既存のルールの隣に、[[defaults.notifications]] または独自のルールを列挙している各プロジェクトの notifications にルールを追加してください:

[[defaults.notifications]]
event = "pr.opened"
authors = ["others"]

[[defaults.notifications]]
event = "ping.sent"

プロジェクトの ping をメニューに表示しないようにするには、そのブロックで pings = { show = false } と設定します。既読の ping を 1 週間保持するには、[defaults.pings] で seen-window = "7d" と設定します。ノートも同様です。プロジェクトのブロックで notes = { show = false } と設定すると、そのノートはメニューに表示されません。また、[defaults.notes] で show = false と設定すると、各プロジェクトのブロックで notes = { show = true } と指定しない限り、すべてのプロジェクトのノートが表示されなくなります。

「VPS から ping を表示してください。」 Shipyard が別のマシンにアクセスできるのは Herdr 経由のみです。そのため、対象のマシンはすでにユーザーの Herdr 保存済みマシンに登録されている必要があります。ラベルがわからない場合は尋ねてください。ホスト名やアドレスは決して記述しないでください。[remote] の machines にラベルを追加します(リストがすでにある場合は、そのリストに追加します):

[remote]
machines = ["alpha-vps"]

次に、そのマシンでユーザーが(または、そのマシン上で実行する場合はあなたが)herdr-shipyard プラグインを一度インストールします。このプラグインによって、そのマシンで shipyard コマンドが使えるようになり、ブロックされているエージェントの ping を確認できます(「ping の送信」を参照):

herdr plugin install yahyabedirhan/herdr-shipyard

プラグインのページは https://github.com/yahyabedirhan/herdr-shipyard です。Shipyard は約 30 秒ごとに各マシンから ping を取得します。アクセスできないマシンはメニューに静かな行として表示され、再び応答するまで最後に取得した ping が保持されます。

Herdr 0.9.3 の既知の制限をユーザーに伝えてください。マシンの ping をクリックすると、そのマシンのペインにフォーカスが移りますが、Mac の Herdr ウィンドウがそのマシンに切り替わるのは、すでにそのマシンを表示している場合だけです。Mac または別のマシンを表示しているときにクリックしても、何も起きなかったように見えます(ping は既読になります)。ペインを表示するには、ユーザー自身が Herdr をそのマシンに切り替える必要があります。Herdr には、開いているウィンドウを保存済みマシンに切り替えるコマンドがまだないため、この動作を変える設定はありません。

「VPS の通知を受け取れるようにしてください。」 別のマシンからの通知はユーザーの tailnet 経由で届くため、Mac とそのマシンの両方が tailnet に接続され、ユーザーとしてログインしている必要があります。config.toml でリスナーを有効にします:

[notices]
listen = true

それ以外の設定は config.toml の外で行います。Mac では tailscale serve を実行し、そのマシンの cli.toml では app-machine を設定します。references/notices.md の「別のマシンから通知を受け取る」に、各手順とテスト通知が記載されています。

ping と通知のどちらを使う?

Shipyard は、あなたからユーザーへ 2 種類のメッセージを送れます。ユーザーが何をする必要があるかに応じて選んでください:

ping(shipyard ping)通知(shipyard notice send)
用途ユーザーが対応する必要がある、または今すぐ知りたいこと:レビュー可能になったプルリクエスト、あなたの作業が止まっている質問、長時間のタスクの完了や失敗ユーザー側で何もする必要がない状況報告:「オーケストレーションを開始しました」「テストを実行中です」「ステージング環境にデプロイしました」
ユーザーに表示されるものクリックするまで注意を促すメニューの行と、通知(ping.sent)通知のみ(agent.notice)。一覧表示、カウント、保存はされません
あなたが確認できることID。ユーザーの応答を待ちますアプリに表示された場合、または Mac のポーリング用にキューに追加された場合(queued と表示)の終了コード 0。表示されなかった場合は、その理由とともに終了コード 1

迷ったら通知を使ってください。無視してもユーザーに負担はかかりません。同じ事柄について ping と通知の両方を送ってはいけません。通知はユーザーの通知ルールに従い、あなたが直接投稿した通知とは異なり、表示されたかどうかを確認できます。Mac と Herdr を実行しているユーザーのほかのマシンで動作し、設定後はそれらのマシンからユーザーの tailnet 経由で直接送信できます。references/notices.md にコマンド、フラグ、経路、終了コード、実例が記載されています。

ping の送信

ping は、shipyard を通じてユーザーに送る短いメッセージです。タイトル、任意の本文と送信者、およびクリックすると実行されるアクション(URL を開く、アプリを前面に表示する、または Herdr のタブにフォーカスする)のうち最大 1 つで構成されます。作業中のリポジトリを監視しているプロジェクトの下に表示され、ユーザーがクリックするまで対応が必要な状態になり、通知(ping.sent イベント)が投稿されます。GitHub には何も送信されません。

同じコマンドは、ユーザーの Mac と、herdr-shipyard プラグインを使って Herdr を実行しているほかのマシンの両方で使えます。実行する場所によって、ping がユーザーに届く方法が変わります。

Mac 上別のマシン(VPS)上
メニューに届く方法アプリが Mac から読み取ります[remote] machines にマシン名がある場合、Mac が Herdr を通じて約 30 秒ごとにマシンへ問い合わせます(「リクエストの処理例」を参照)
分類される場所送信時に確認され、リポジトリを監視しているプロジェクトの下に分類されます。該当するプロジェクトがない場合は拒否されます(「コマンド」を参照)Mac 上で、リポジトリを監視しているプロジェクトの下に分類されます。該当するプロジェクトがない場合は、マシン独自のセクションに表示されます(「別のマシン上」を参照)
アクションなしでクリックした場合既読になりますそのマシン上のペインにフォーカスします
表示されなくなるタイミング既読になり、seen-window が経過した後既読かどうかにかかわらず、送信時または最後に置き換えた時点から 24 時間後
ユーザーの対応を待っている場合自分で ping を送りますプラグインが代わりに ping を送ります

ユーザーが対応すべきとき、または今すぐ知りたいと思うようなときに ping を送ります。プルリクエストのレビュー準備が整ったとき、ユーザーの回答を待っていて作業が止まっているとき、ユーザーが依頼したものが公開されたとき、時間のかかるタスクが完了または失敗したときなどです。進捗を逐一知らせるためや、ユーザーが今まさにあなたと話しているときには ping を送らないでください。ping を何度も送るより、1 つの ping を置き換えて使う(同じ --id を指定する)ことを優先し、内容が事実でなくなったら ping を取り下げてください。

プラグインを使って別のマシンで作業している場合、入力待ちは自動で ping されます。 herdr-shipyard プラグインがインストールされた Linux マシン(herdr plugin list に yahyabedirhan.herdr-shipyard と表示されます)では、Herdr があなたの作業をブロック中としてマークすると(「Claude is waiting in 」)、プラグインがすぐに自動でユーザーに ping を送ります。作業を再開するか、ペイン、タブ、またはワークスペースが閉じると、その ping は取り下げられます。同じ内容の ping を二重に送ることになるため、入力待ちを伝えるだけの ping は送らないでください。それ以外の場合は通常どおり ping を送ります。Mac 上ではプラグインは何もしないため、プラグインのないマシンと同様、入力待ちのときは自分で ping を送ってください。

コマンド

アプリはコマンドを ~/.local/bin/shipyard にリンクします(オンボーディング、またはパネルの設定メニュー(歯車アイコン)にある Set up shipyard command)。shipyard が見つからない場合は ~/.local/bin/shipyard を実行してください。それも存在しない場合は、Set up shipyard command からリンクするようユーザーに依頼してください。リンクできない場合は、何が妨げになっているかも表示されます。アプリを起動しておく必要はありません。送信した ping は、アプリの起動時に表示されます。

shipyard ping send "<title>" [--body <text>] [--from <label>] [--id <id>]
                             [--open <url> | --app <bundle id or name> | --herdr [<tab or pane id>]]
                             [--repo <owner/name> | --project <name>]
shipyard ping withdraw <id>
shipyard ping list [--json]

すべてのコマンドは shipyard <group> <command> の形式です。shipyard --help ですべてのコマンドを確認できます。

フラグ機能
"<title>"メニューと通知に表示される1行です。1つの引数なので、引用符で囲みます
--body <text>タイトルに収まらない内容を、その下と通知に表示します
--from <label>送信者を示します。名前とタスク("claude · checkout")などを指定します。group-by = "author" を設定すると、通知が送信者ごとにまとめられます。エージェントの名前で始め、その後に大文字・小文字を問わず任意の単語を続けると、その行にロゴが表示されます。使用できる名前は claude、codex、opencode、cursor、pi、gemini、copilot、amp、または Claude Code、Codex CLI、OpenAI Codex、Cursor Agent、Cursor CLI、Pi Agent、Pi Coding Agent、Gemini CLI、Copilot CLI、GitHub Copilot、Ampcode、Factory Droid です
--id <id>通知に名前を付け、置き換えたり取り消したりできるようにします。1〜64文字の小文字、数字、-、_ を使い、先頭は英字または数字にします。指定しない場合は自動生成されます
--open <url>クリックするとURLを開きます。ページ、プルリクエスト、アーティファクト、アプリのディープリンクなどを指定できます。URLにはスキーム(https://…)が必要です
--app <bundle id or name>クリックすると、アプリが前面に表示されます。名前("Claude")またはバンドルID(com.anthropic.claudefordesktop)で指定します
--herdr [<id>]クリックするとHerdrのタブにフォーカスします。単独で指定すると、自分のペインのタブにフォーカスします(HERDR_PANE_ID を使用するため、Herdr内でのみ有効です)。または、Herdrが出力するタブIDやペインID(w1:t2 や w1:p3 など)を指定します。--herdr の後の引数は、この形式の場合にのみIDとして扱われます
--repo <owner/name>作業フォルダーではなく、このリポジトリに通知を記録します
--project <name>config.toml の slug、または slug がない場合は title で指定したプロジェクトに記録します
--フラグの終わりを示します。後に続くすべての内容は、-- で始まる単語も含めてタイトルとして扱われます
  • アクションは最大1つです。 アクションがない場合、クリックすると ping が既読になるだけです。アクションが失敗した場合(ペインが閉じている、該当するアプリがないなど)、ping は未読のままになり、その行に理由が表示されます。
  • 登録先。 --repo も --project も指定しない場合、リポジトリには作業フォルダーの git リモート origin が owner/name の形式で使われ、ping はそれを監視するすべてのプロジェクトに登録されます。対象は、repositories にそのリポジトリを指定しているプロジェクト、またはグループや owner/* 経由で対象に含めているプロジェクトです(アプリが最後に参照した設定が使われるため、追加したばかりのプロジェクトを反映するには、アプリを一度更新する必要があります)。--repo と --project は併用できません。
  • 出力。 成功すると ping の ID(例:k7qm2x)が出力され、終了コード 0 で終了します。この ID は --id と withdraw に指定します。Mac では、ping が登録された各プロジェクト内で番号が付けられます(行に #3 のように表示)。番号は ping が届いた順で、置き換えても変わりません。それ以外の場合は標準エラー出力に1行表示されます。終了コード 1 は拒否された場合(どのプロジェクトもリポジトリまたはその名前を監視していない、登録先となるすべてのプロジェクトで pings.show = false に設定されている、または config.toml を読み込めない場合。この確認を行うのは Mac のみです。取り下げる ID が不明な場合も含みます)、終了コード 2 は引数を読み取れない場合(タイトルがない、アクションが2つある、不正な ID、Herdr 外で --herdr だけを指定した場合)です。拒否された場合はユーザーのプロジェクトが表示されます。--project でいずれかを選ぶか、リポジトリを独自に監視するべき場合は、ファイルを無断で編集せず、ユーザーに監視を提案してください(「リクエストの例」を参照)。プロジェクトで ping の表示が無効になっているため拒否された場合は、そのプロジェクトと、ping を表示するプロジェクトが示されます。表示するプロジェクトのいずれかを --project で指定して送るか、ユーザーに届かなかったことを伝えてください。ユーザーが意図的にそこで ping を非表示にしているため、無断で show を有効に戻さないでください。
  • 置き換え。 すでに存在する ID を指定して送信すると、その ping が置き換えられます。タイトル、本文、送信者、アクション、プロジェクトが新しい内容になり、経過時間は置き換え時点から再開します。再び未読になり、通知は追加で送信されません。
  • 取り下げ。 shipyard ping withdraw <id> は ping を取り下げます。ping はメニューから消え、通知も通知センターから削除されます。存在しない ping の ID を指定すると、終了コード 1 で終了します。ユーザーがすでに通知を消したか、既読後に ping が消えた可能性があるため、追加の操作は不要です。
  • 一覧表示。 shipyard ping list は、そのコンピューター上で現在有効な ping を新しい順に1行ずつ出力します。各行には ID、経過時間、タイトル、登録先が表示され、ping がない場合は no pings と表示されます。--json を指定すると、ユーザーの Mac 上で shipyard が読み取るための JSON 形式で出力されます。ping を送るだけなら不要です。
  • Herdr のターミナル。 --herdr を指定したクリックでは Herdr のタブにフォーカスが移ります。また、クリックすると ping の送信元となったターミナルアプリも前面に表示されます。CLI はこれを自動で認識します。ユーザーが [herdr] terminal で別のアプリを指定している場合(「キーとデフォルト」を参照)、そちらが優先されます。
別のマシンの場合

herdr-shipyard プラグインがインストールされた Linux マシン(VPS など)では、shipyard は ~/.local/bin/shipyard にあり、同じフラグを使えます。[remote] machines にそのマシンが指定されている場合(「リクエストの例」を参照)、ユーザーの Mac は Herdr 経由でそのマシンに ping を問い合わせます。異なる点は次のとおりです。

  • 登録は Mac で行われます。 マシンにはプロジェクトがないため、どのプロジェクトも監視していないリポジトリでも shipyard ping は拒否されません。リポジトリ(origin または --repo から取得)か --project 名を保持し、Mac がそれを監視するプロジェクトに登録します。作業フォルダーに origin がない場合は、--repo <owner/name> または --project <name> を指定してください。どちらも指定しない場合、またはどのプロジェクトも対象にしない場合、ping はメニュー内のそのマシン専用セクションに表示されます。
  • ペインも引き継がれます。 アクションを指定せず、Herdr のペインから送信した場合、ping をクリックすると、そのマシン上の自分のペインにフォーカスが移ります。そのため、再び見つけるために --herdr を指定する必要はありません。
  • --open と --app は Mac 上で実行されます。 URL は Mac のブラウザーで開き、アプリも Mac のアプリが使われます。マシン上の localhost の URL はそこで開けません。
  • ping は1日後に消えます。 既読かどうかにかかわらず、送信または最後に置き換えてから24時間後に、ping はそのマシンから消えます。同じ --id で置き換えると保持できます。内容が事実でなくなったら取り下げてください。
作業例の ping

「PR の準備ができたら知らせてください。」 プルリクエストが作成され、チェックに合格したら、そのプルリクエストを開く ping を送ります。

shipyard ping send "PR #57 is ready for review" --body "Adds the order export" --from "claude · orders" \
  --open https://github.com/my-org/shop/pull/57

「必要になったら、このペインに戻してください。」 herdr-shipyard プラグインを使っている別のマシンでは、作業が止まったときにプラグインがすでにこれを行います。そのプラグインから確認できないこと、たとえば自分が作業を続けている間に決めてほしいことだけを ping してください。Mac の Herdr 内から --herdr だけを指定すると、自分のペインが対象になります。あとで更新または取り消しできるように、ID を指定してください。

shipyard ping send "Waiting for your input" --body "Postgres or SQLite for the cache?" --from "claude · cache" \
  --herdr --id cache-question

しばらく待っても返事がない場合は、同じ ID をもう一度送信してください。ping が更新され、2 回目の通知を送らずに、再び注意を促します。

shipyard ping send "Still waiting for your input (10 min)" --body "Postgres or SQLite for the cache?" --from "claude · cache" \
  --herdr --id cache-question

「回答したら取り消してください。」 ユーザーがペイン内または別の場所で回答したら、古い ping が残らないように取り消します。

shipyard ping withdraw cache-question

「Claude に私が必要になったら知らせてください。」 作業フォルダーがユーザーのリポジトリにない場合に、名前を付けたプロジェクトに記録しつつ、アプリを前面に表示するアクションです。

shipyard ping send "Claude is asking for permission" --app Claude --project shop

アプリを操作する

ユーザーの Mac では、さらに 2 つのコマンドグループを使って、実行中のアプリを開いたり、操作したり、スクリーンショットを撮ったりできます。shipyard に表示されている内容の確認、変更のチェック、スクリーンショットの添付などができます。shipyard app(スクリーンショットには app capture を使用)と shipyard panel があります。これらはアプリと直接通信するため、アクセシビリティや画面収録の権限は不要で、config.toml を変更することもありません。一度に保持できるのは 1 つのエージェントだけです。また、shipyard lease を実行すると、実行中は shipyard を保持します。「順番に使う」を参照してください。コマンドの場所は「ping を送信する」と同じです(~/.local/bin/shipyard)。

shipyard app open [--demo <folder>]
shipyard app quit
shipyard app status [--json]
shipyard app capture <file.png> [--appearance light|dark] [--menu-bar-icon] [--with-indicator]
shipyard panel open
shipyard panel close
shipyard panel fold <project>
shipyard panel unfold <project>
shipyard panel show-more <project> <kind>
shipyard panel show-tab <name>
shipyard panel show-view <name>
shipyard lease take [--wait <seconds>] [--for <purpose>] [--key <k>]
shipyard lease release [--key <k>]
コマンド内容成功時の出力
app openshipyard が実行中でなければバックグラウンドで起動し、応答するまで待機します(最長で約10秒)app status と同じステータス
app open --demo <folder>shipyard を終了し、デモデータで実行します(「デモ実行」を参照)demo: 行を含むステータス
app quitshipyard を終了し、終了するまで待機しますshipyard quit
app statusshipyard が実行中かどうかと、そのパネルの表示内容ステータス(以下)
app status --json同じ内容を1行のJSONオブジェクトで出力しますJSON形式のステータス
panel open、panel closeメニューバーアイコンのパネルを開く、または閉じ、完了するまで待機します。ユーザーがパネルを閉じてから30秒間(別の場所をクリックして閉じた場合も含む)は、panel open が再度開ける時刻を示して拒否されます。その時刻まで待ち、それより前に再試行しないでくださいpanel open、panel closed
panel fold <project>、panel unfold <project>config.toml の slug、またはそれがない場合は title を使って、プロジェクトのセクションを折りたたむ、または展開しますfolded <project>、unfolded <project>
panel show-more <project> <kind>パネルを閉じるまで、プロジェクトの指定した種類のグループで show-first の上限を超えるすべての行を表示します。<kind> は pull-requests、issues、workflow-runs、pings、notes のいずれかです<project> のすべての <kind> を表示しています
panel show-tab <name>タブレイアウトのタブを選択します。プロジェクトの slug または title、あるいは All を指定しますshowing <title>
panel show-view <name>設定メニューの項目と同様に、プロジェクトの代わりにステータスビューを表示します。指定できるのは github、notion、skill、cli です。github はサインイン中のアカウント(@login)と接続方法(GitHub CLI の gh または GitHub でサインイン)を表示します。サインアウト中の場合はサインイン手順を表示するため、スクリーンショットにユーザーのログイン名が写ることがあります。projects を指定すると、‹ 戻る と同様にプロジェクトを再表示します。パネルを閉じた場合もプロジェクトが再表示されますshowing <title>(Shipyard CLI)、または showing projects
app capture <file.png>パネルの表示状態を保存します。パネルが閉じている場合は、開かずに画面外で描画されます(標準エラーに表示されます)。画面上に描画された状態のパネルを保存するには、先に panel open を実行してください。相対パスは実行したフォルダーからのパスとして扱われますファイルの絶対パス
--appearance light または darkスクリーンショット用にパネルを指定した外観で描画し、その後Macの外観に戻します
--menu-bar-iconパネルを開かず、メニューバーアイコンだけを保存します
--with-indicatorエージェントが shipyard を使用中であることを示す黄色の点とバナーを表示したままにします。指定しない場合、スクリーンショットには含まれません
lease take実行中に shipyard を確保します。確保から5分後まで有効です(「交代で使用する」を参照)you hold shipyard until <HH:mm:ss>
lease take --for <purpose>同様に shipyard を確保し、パネルのバナーにユーザー向けの理由を短く表示します(--for "checking the header icons")。1行で、最大80文字です。必ず理由を記載してください。バナーには実行する各コマンドも実行時に表示されます(「スクリーンショットを撮影中…」、続いて「スクリーンショットを撮影しました · 12秒前」)。これにより、ユーザーはパネルを開いたままにするべきか判断できます同じ
lease take --wait <seconds>別のエージェントが shipyard を確保している間、先着順で指定秒数まで待機します(最大3600秒)確保後は同じ
lease release次のエージェントが使えるよう shipyard を解放します。自分が確保していない場合は何もしませんreleased shipyard

app status は複数行を出力します。demo: はデモ実行時のみ、tab: はタブレイアウト時のみ表示されます。

shipyard <version> is running
lease: free
panel: closed
view: projects
layout: tabs
tab: All
projects: shop, blog
folded: none
showing all: pull-requests in shop

--json を指定すると、キーは running(常に true)、version、panelOpen、view(projects、または表示されているステータスビュー:github、notion、skill、cli)、layout(list または tabs)、tab(リストレイアウトでは null)、projects(プロジェクトと、それに続くリモートマシンの一覧。名前は panel fold と panel show-tab が受け付けるものです)、folded、showingAll([{"kind":"pull-requests","project":"shop"}])、demo(デモフォルダー、それ以外は null)、lease(空いている場合は null、それ以外は {"holder", "place", "secondsLeft", "waiting"}:shipyard を使用しているエージェント。lease: の行に名前が示されています)です。操作するときは行ではなく、これを読み取ってください。

コマンドによる変更は、ユーザー自身がクリックした場合と同じように反映されます。パネルを閉じた後も折りたたみ状態は保持されるため、ユーザーのアプリで自分が折りたたんだものは展開してください。「Show more」とパネルの表示状態は自動的に元に戻ります。作業が終わったらパネルを閉じてください。データの読み込みなど、何かを待つためにこれらのコマンドをループで実行しないでください。app status を一度確認し、スクリーンショットを一枚撮影してください。

順番に操作する

Shipyard は、リースを保持しているエージェントに、一度に1つずつ応答します。リースが必要なのは、リースの状態を報告する app status を除くすべての app コマンドと panel コマンドです。自分の名前を指定する必要はありません。shipyard は Claude Code セッション(CLAUDE_CODE_SESSION_ID)であなたを識別し、それがない場合は、コマンドを実行するエージェントプロセスで識別するため、実行するコマンドはすべてあなたが実行したものとして扱われます。同じ Claude Code セッションに属するサブエージェントはセッション ID を共有するため、リースも共有します。リースによって互いに待たされることはないので、サブエージェント間の順番は自分たちで調整してください。ユーザーには、メニューバーアイコン上の黄色い点とパネル上のバナーに、あなたの名前とフォルダー(または Herdr ペイン)が表示されます。また、操作の開始時と終了時に通知が届きます。

  • 簡単な確認なら、それだけで十分です。 最初のコマンドでリースを取得し、それ以降のコマンドを実行するたびに更新されます。最後のコマンドから1分後、ただし取得から最大5分後にリースは終了します。その後、次のコマンドで新しいリースを取得します。ただし、別のエージェントが待機している場合はその限りではありません。
  • 一連の作業中はリースを保持します。 ビルドしてからスクリーンショットを何枚か撮るなど、手順の合間に作業が入る場合は、shipyard lease take を実行すると、取得から5分後までリースを保持できます。途中で何度取得しても終了時刻は延長されません。そこを超えて作業を続ける場合は、前述のとおり新しいリースを取得します。
  • 一連の作業が終わるたびにリースを解放してください。 デモの終了時に app open を実行した後も同様です。shipyard lease release を実行して、次のエージェントやユーザーがリースの終了を待たずに済むようにしてください。
  • アプリを再起動してもリースは維持されます。 app open --demo <folder> と、デモの最後に実行する通常の app open は、同じ終了時刻までリースを引き継いで次のアプリを起動します。app quit と app open を別々に実行すると、その間は shipyard が解放されます。
  • まず app status で確認してください。 lease: free、または lease: <name> in <place>, <n>s left, <k> waiting と表示されます(JSON では lease)。
  • スクリーンショットには黄色い点とバナーは表示されません。 そのため、ユーザーが通常目にする状態で shipyard が写ります。リース自体を写す場合は --with-indicator を指定してください。
  • shipyard がコマンドをあなたのものと判別できない場合(各コマンドが Claude Code セッションではない別々のプロセスとして実行され、自分のコマンド同士が「使用中」として拒否される場合)、一連の作業中は SHIPYARD_CONTROL_KEY=<k> をエクスポートし、自分で決めた名前を設定してください。以後、すべての app、panel、lease コマンドは <k> として実行されます。--key <k> を指定すると、1回の lease take または release に限り、同じように動作します。

shipyard が代わりに実行できないコマンドは、次のいずれかのメッセージを表示して終了コード 1 で終了します。

拒否メッセージ対応方法
shipyard is in use by <name> in <place> until <HH:mm:ss> (<n>s left); `shipyard lease take --wait <seconds>` to queue別のエージェントがリースを保持しています。shipyard lease take --wait <seconds> で、残り時間を十分に上回る秒数を指定して順番待ちしてください。リースを取得できると、すぐに戻ります。待ち時間に15秒を加えた時間より長いタイムアウトをコマンドに設定してください。それより早く打ち切られると、順番が失われます。タスクをそれほど待てない場合は、shipyard を保持しているユーザーを伝え、shipyard を必要としない作業を続けてください。
waited <n>s; shipyard is still in use by <name> in <place> until <HH:mm:ss> (<n>s left)待ち時間が経過しました。shipyard を保持しているユーザーを伝え、そのユーザーから指示があるまで再度順番待ちをしないでください。
the user took shipyard back; ask them before using it againユーザーがバナーの[Stop]を押しました。ここでアプリの操作を中止し、ユーザーの希望を確認してください。ユーザーの許可があるまで shipyard を再使用しないでください。ユーザーはすぐに操作を再開させることもできます。それ以外の場合、lease take を含めて5分間は拒否されます。5分待ってから再試行することや、別のキーを使うことは、ユーザーが求めた停止に反します。
終了コード
  • 0:完了しました。アプリがウィンドウをキャプチャできず、代わりにパネルを自前で描画した場合も、スクリーンショットの終了コードは 0 です。その画像を書き込み、パスを出力し、標準エラーに captured by rendering: <why> と表示します。その画像を確認してから、信頼できるか判断してください。
  • 1:拒否されました。理由を示す1行が標準エラーに出力されます。別のエージェントが shipyard を使用中であるか、ユーザーが使用権を取り戻しました(「順番交代」を参照)。Shipyard が起動していない(shipyard isn't running; `shipyard app open` )、または起動後10秒以内に応答しなかった場合です。その名前のプロジェクト、種類、タブがありません。行には、存在する項目の一覧が表示されます。たとえば no project is named `shopp`; the projects are `shop`, `blog` の場合は、その中から選んでもう一度試してください。リストレイアウトでの show-tab(the menu uses the list layout; tabs need `[menu] layout = "tabs"` )。種類別にグループ化されていないプロジェクトでの show-more。ユーザーがパネルを閉じてから30秒以内の panel open(再び開ける時刻が行に表示されます)。存在しないフォルダーへの書き込みなど、スクリーンショットを書き込めなかった場合です。
  • 2:引数を解釈できません(名前がない、不明なサブコマンドやオプション、.png ではないパス、存在しない --demo フォルダーなど)。行の末尾に、読むべきヘルプが表示されます。たとえば Run `shipyard panel --help` for usage. のようになります。Mac 以外のマシンでは、これらのコマンドはすべて終了コード 2 になります。shipyard: `shipyard app` runs on the Mac, where the app is
デモ実行

shipyard app open --demo <folder> は、ユーザーの設定に触れることなく、スクリーンショット撮影や確認のために、サンプルデータで shipyard を表示します。フォルダーには、ユーザーの設定と同じ形式の設定ファイル <folder>/shipyard/config.toml を置きます(上記の内容がすべて適用されます)。実行時の状態は <folder>/support に保持されます。ユーザーのアプリを終了して、そのフォルダーを使って shipyard を起動します。その後は、追加の引数なしで、すべての shipyard app、panel、screenshot がデモに接続されます。実行中は app status に demo: <folder> と表示されます。

  • ユーザーのファイルはそのままです。 ユーザーの config.toml、状態、ログイン項目には手を加えません。実行時に書き込むのは shipyard のサポートフォルダー内の小さなポインターファイルだけで、次回の通常の app open で削除されます。
  • 通常の shipyard app open でユーザーのアプリに戻ります:デモを終了し、ユーザー自身のアプリを起動します。ユーザーの shipyard が起動した状態になるよう、必ずこのコマンドでデモを終了してください。
  • 作成した項目を使えば、ユーザーの作業に影響しません。 フォルダーに demo-items.json がある場合、実行時にはそのファイルに記載されたアカウントのプルリクエスト、イシュー、ワークフロー実行、ノートが一覧表示され、GitHub と Notion への問い合わせは行われません。他の人が見るスクリーンショットには、このファイルを使用してください。作成する前に references/demo-items.md を読んでください。形式、各キー、例が記載されています。
  • そのファイルがない場合は、サインイン中のユーザーとして GitHub を読み取ります。デモの設定には、表示内容がスクリーンショットに残る公開リポジトリ名を指定してください。ノートは一覧表示されません。このようなデモのパネルからサインアウトすると、ユーザーもサインアウトしてしまいます。
  • その間に送信した Pings はデモではなくユーザーのアプリに届き、アプリが再び起動するとそこに表示されます。
  • フォルダーは /tmp のような共有フォルダーではなく、~/shipyard-demo のようにユーザーのホームフォルダー内に置いてください。Mac 上の別アカウントがそのフォルダーを先に作成し、あなたの app と panel コマンドにデモの代わりに応答する可能性があります。
  • フォルダーのパスは短くしてください。ソケットで扱える長さを超えるパスの場合、実行は拒否され、use a folder with a shorter path と表示されます。
できないこと
  • クリック。 行、ボタン、リンク、歯車メニューはクリックできず、パネルに文字を入力することもできません。panel コマンドだけで操作し、それ以外はユーザーに依頼してください。
  • ホバー。 ホバーカードやツールチップはスクリーンショットに表示されません。
  • 実際のメニューバー。 スクリーンショットに写せるのはパネルか、--menu-bar-icon で単独表示したアイコンです。件数やほかのアプリのアイコンがあるメニューバー自体はキャプチャできません。
  • 別のマシンのアプリ。 コマンドで操作できるのは、実行しているMac上のアプリです。別のマシンからは操作対象のアプリがないため、ユーザーに依頼するか、その人のMacで実行してください。
アプリ操作の例

「shipyardは起動していますか?」 確認し、起動していなければ起動します。

shipyard app status --json || shipyard app open

「shipyardを再起動して。」 終了してから、再び開きます。open は応答が返ると終了します。2つの操作の間、Shipyardは空いているため、別のエージェントがその間に操作する可能性があります。

shipyard app quit
shipyard app open

「パネルを見せて。」 パネルを開き、確認したら閉じます。

shipyard panel open
shipyard panel close

「blogプロジェクトを折りたたんで。」 slug で指定します。同じ方法で展開できます。

shipyard panel fold blog
shipyard panel unfold blog

「shopのすべてのプルリクエストを見せて。」 その種類のグループは、パネルを閉じるまで show-first の上限を超えて表示されます。

shipyard panel show-more shop pull-requests

「ダークモードでshopタブをスクリーンショットに撮って。」 タブレイアウトでタブを選択してからキャプチャします。表示されたパスがファイルの保存先です。

shipyard panel show-tab shop
shipyard app capture shop-dark.png --appearance dark

「Shipyard CLIビューをスクリーンショットに撮って。」 パネルを開き、ビューを表示してキャプチャしたら、プロジェクトに戻ります。

shipyard panel open
shipyard panel show-view cli
shipyard app capture cli-view.png
shipyard panel show-view projects

「メニューバーアイコンをスクリーンショットに撮って。」

shipyard app capture icon.png --menu-bar-icon --appearance light

「パネルを両方の外観でスクリーンショットに撮って。」 複数の手順をまとめて実行します。shipyardをその間保持し、保持中のエージェントがいる場合は最大1分待って、最後に解放します。

shipyard lease take --wait 60 --for "screenshots in both appearances"
shipyard app capture panel-light.png --appearance light
shipyard app capture panel-dark.png --appearance dark
shipyard panel close
shipyard lease release

「作業中にユーザーに見える状態を表示して。」 shipyardを保持している間は、バナーとドットを表示できます。画像に含めてください。

shipyard app capture lease.png --with-indicator

「サンプルデータでshipyardをスクリーンショットに撮って。」 公開リポジトリを指定したデモ設定を書き込み、デモを実行してキャプチャしたら、ユーザーのアプリに戻します。

mkdir -p ~/shipyard-demo/shipyard
cat > ~/shipyard-demo/shipyard/config.toml <<'TOML'
version = 1

[[projects]]
slug = "swift"
repositories = ["swiftlang/swift"]
TOML
shipyard app open --demo ~/shipyard-demo
shipyard app capture ~/shipyard-demo/panel.png
shipyard app open
shipyard lease release

リポジトリの実際の項目ではなく、架空の項目を表示するには、references/demo-items.md の説明に従って、app open --demo の前に ~/shipyard-demo/demo-items.json を書き込みます。

コメント