ship

Ship

ship は、完成したブランチを最後まで仕上げます。適切にコミットし、プッシュし（必要に応じて Azure DevOps の認証問題に対処します）、プルリクエストを開き、作業項目にリンクし、マージ後にブランチと ワークツリーを削除します。現在の環境が Azure Repos か GitHub かを自動検出して、対応する手順を 実行するため、組織内でも github.com のリポジトリでも同じコマンドを使えます。

対象範囲は意図的に絞っています。ローカルでのマージ、パイプラインの実行、バックログの管理は行いません。 レビュー可能な PR をプラットフォームに渡し、マージ後にクリーンアップします。

これを使う場面と、似たツールとの使い分け

• ship — PR ベースのデリバリーフローです。プッシュ → PR →（プラットフォームでマージ）→ クリーンアップ。
• commit — 現在のブランチをステージングしてコミットし、プッシュするだけです。PR は作成しません。
• merge — ブランチをローカルで main にマージ（早送り）して、クリーンアップします。 PR の承認が不要な場合に使います。変更にレビューやポリシーの適用が必要な場合は ship を使います。
• azure-devops — REST/MCP の包括的なツールボックスです（WIQL、一括更新、パイプライン、コメントスレッドなど）。 ship は必要な最小限の機能だけを呼び出します。より幅広い操作には azure-devops を使います。

フロー

まず bun scripts/ship-detect.ts を実行します。プラットフォーム、Azure の組織／プロジェクト／リポジトリ（該当する場合）、 ブランチ、推定された作業項目 ID が表示されます。以下の手順はすべて、この結果に応じて分岐します。

初回のみのセットアップ： スクリプトには azure-devops-node-api と @octokit/rest が必要です。初回使用前に、 スキルディレクトリ（~/.claude/skills/ship/）で bun install を一度実行してください。

「ship」だけを指示された場合は、そのまま実行する

簡潔な ship／ship it は、「デリバリーを実行して」という意味であり、「説明して」という意味ではありません。 説明は最小限にしてフローを実行します。事前確認のスコープ結果（クリーンでない場合のみ）、pr_url、作成した 作業項目 ID、クリーンアップの確認だけを伝えます。セッションの状態を振り返ったり、計画を改めて声に出して説明したり、 実行前に手順をすべて列挙したりしないでください。簡潔な指示に対して説明しすぎること自体が、よくある失敗です。 停止して確認すべきなのは、事前確認（手順 0）で scope_clean=false が返された場合だけです。

0. 事前確認

bun scripts/ship-preflight.ts     # anything to deliver? + working-tree scope audit

• commits_ahead_of_upstream、staged／unstaged／untracked の件数、および scope_clean=true|false が表示されます。
• scope_clean=false の場合は、コミットする前に停止し、一覧表示されたファイルをユーザーに伝えてください。 それらが意図的に除外されていることを確認します。これは PR #192 の再発防止策です。別のディレクトリ内にある変更ファイルが ステージングされないまま残ると、PR から黙って抜け落ちます。このチェックは参考情報であり、処理をブロックすることはありません。 ただし、確認されていない false は、このチェックが防ごうとしているスコープの見落としそのものです。
• ship-detect.ts のプラットフォームを確認します。unknown（カスタム SSH ホストのエイリアスなど）と表示された場合は、 セッションで SHIP_PLATFORM=azure または SHIP_PLATFORM=github を設定します。

1. コミット — ツールではなく、作成者として

このタスクに関係するファイルだけをステージングしてコミットします。AI による帰属情報は絶対に追加しないでください。 Generated with Claude も Co-Authored-By: Claude も追加しません。コミットの作成者は人間です。ツールの使用履歴を git の履歴に残すべきではありません（このリポジトリの commit-msg フックは予防策としてトレーラーを削除しますが、 それに頼らず、そもそも記述しないでください）。無関係な問題でプリコミットフックが失敗する場合は --no-verify を使っても かまいません。自分の変更に問題があると指摘された場合は、修正してください。

2. ブランチの状態

• フィーチャーブランチ上にいる場合 → 問題ありません。そのまま続行します。
• main／master 上にいる場合 → main から main 自身への PR は作成できません。ブランチを作成し、 プッシュする前にコミットをそのブランチへ移します。

  git branch feature/<slug> && git reset --hard @{u} && git checkout feature/<slug>
  

  （コミットがまだ main にプッシュされていない場合に限り実行してください。判断できない場合は停止して確認します。）
• ブランチポリシーによって main への直接プッシュが拒否された場合は、PR の手順に切り替える合図です。 強制プッシュしたり、ポリシーを回避したりしてはいけません。

3. プッシュ

bun scripts/ship-push.ts         # pushes current branch, sets upstream

Azure DevOps で通常のプッシュが認証エラーになった場合は、az OAuth トークンを自動的に発行し、 Bearer ヘッダーを使って再試行します。これは、SSH も HTTPS の認証情報ヘルパーも利用できない場合の代替手段です。 仕組みについては references/azure-devops.md を参照してください。

4. PR を作成する（作業項目の確認／リンクと状態の更新も行う）

不変のルール — 作業項目 ID をユーザーに尋ねてはいけません。 作業項目の特定 → 検証 →（見つからない場合は） 作成＋割り当て＋リンクまで、すべて自動で行われます。Board の作業項目にリンクされていない PR を、準備完了として提示してはいけません。「作業項目 ID は何ですか？」と尋ねようとしているなら、 立ち止まってください。その質問こそ、このスキルで防ぐべき失敗です。ID は --work-item、ブランチ名、または新たに作成した項目から取得します。質問によって取得することはありません。

コードレビューでは作業項目を扱いません。 PR を作成する時点でリンク済みの作業項目があることを ship が保証するため、 レビューのステップ（人間のレビュアー、または code-review / bmad-code-review スキル）は、作業項目について再度尋ねたり、 それを理由に作業を止めたりしてはいけません。この条件は上流ですでに満たされています。

実際の説明を作成します。assets/pr-template.md を一時ファイルにコピーし、Summary / Changes / Verification を記入して、作業項目をリンクするために AB#<id> の行は残してください。

bun scripts/ship-pr.ts --title "<title>" --body-file /tmp/pr-body.md \
  --work-item <id> --transition Resolved \
  --reviewer [email protected] --required-reviewer [email protected] --tag needs-review

• プラットフォームは自動検出されます。スクリプトは azure-devops-node-api SDK（createPullRequest）または Octokit（pulls.create）を使用します。
• 前提条件は作成時にまとめて処理され、後続の追加リクエストは不要です。 Azure では、作業項目、タグ／ラベル、レビュー担当者がすべて 1 回の createPullRequest 呼び出しにまとめられます。GitHub の作成 API はこれらを受け付けないため、ラベルとレビュー担当者は後続の呼び出しで追加されます。結果は同じですが、GitHub ではこれを避けられません。
• レビュー担当者 — --reviewer <upn|username> は任意の（ブロックしない）レビュー担当者を追加し、--required-reviewer は Azure でレビュー担当者を必須（完了をブロック）にします。どちらもカンマ区切りで指定でき、複数回指定することもできます。Azure では UPN／メールアドレスが ID に解決されます。名前を解決できない場合は警告を出してスキップされます（reviewer_skipped=…）。PR がブロックされることはありません。GitHub には PR 単位の「必須」レビュー担当者の仕組みがないため（ブランチ保護の設定にあたります）、必須として指定したレビュー担当者も単にレビュー依頼されます。スクリプトはレビュー担当者ごとに reviewer_added=<name> required=<bool> を出力します。 Azure でどちらのフラグも指定されていない場合は、$SHIP_ADO_DEFAULT_REVIEWER が設定されていれば任意のレビュー担当者として追加されます（ADO の ID は意味を持たないため、GitHub では無視されます）。レビュー担当者の記録がない PR には、誰かに依頼した形跡が残りません。未設定の場合はレビュー担当者が追加されず、従来どおりの動作になります。
• Azure では、Board の作業項目がリンクされていない PR は作成されません。 スクリプトは --work-item（またはブランチ名）から ID を解決し、SDK の getWorkItem を使って実際に存在することを確認します。ブランチ名からの解析はあくまで推測です。たとえば 1234-foo のようなブランチ名には実在しない項目番号が含まれる場合があるため、存在を推測せず確認します。
• 実在する作業項目が見つからない場合、タスクごとに 1 つ作成して PR にリンクし、それぞれを $SHIP_ADO_ASSIGNEE（既定値は [email protected]。--assignee で上書き可能）に割り当てます。 --task "<title>" をタスクごとに 1 回指定する（複数回指定可能）か、--tasks-file <file>（1 行にタイトルを 1 つ）を渡すと、タスクごとに項目が 1 つ作成されます。--task を指定しない場合は、PR の --title から項目が 1 つ作成されます。種類の既定値は Task です（--work-item-type "User Story"|Bug）。既存 ID のみをリンクするには、--no-create-work-item で作成を無効にします。
  • スクリプトは作成された項目ごとに work_item_created=<id> を、作成された項目一式について work_items=<ids> を出力します。新しい ID をユーザーに伝えてください（捏造せず、SDK の応答から取得してください）。
• --transition（Azure のみ）を指定すると、PR の作成後にリンク済み／作成済みの各項目が遷移します。状態名はプロセスによって異なります（Agile：Resolved、Scrum：Committed、Basic：Doing）。有効な次の状態を事前に確認してください。references/azure-devops.md を参照してください。--transition を省略すると Board は変更されません。 （作成された項目は、種類ごとの初期状態（例：New／To Do）になります。）
• Complete ダイアログの「マージ後にリンクされた作業項目を完了する」チェックボックスは、あらかじめオンになっています。 Ship は作成呼び出しの直後に PATCH を実行して completionOptions.transitionWorkItems=true を設定します。そのため、PR で Complete をクリックすると、リンクされた項目が遷移し、マージ済み PR の背後に未完了のまま残ることはありません。これは --transition とは別の動作です。--transition は PR 作成時に実行され、こちらはマージ時に実行されます。マージ時にチェックボックスをオンにするのを誰も覚えていないため、これが一連の処理を完了させる仕組みです。チェックをオフのままにするには --no-complete-transition を渡します。スクリプトは PATCH の応答から読み戻した complete_transitions_work_items=true|false を出力します。GitHub では無視されます。GitHub では、本文の Closes #<id> が同じ役割を果たします。
• スクリプトは pr_url=… を出力します。URL をユーザーに伝えてください。

4b. タグとレビュアー（デフォルトで適用）

Azure DevOps では タグ、GitHub では ラベル と呼ばれますが、考え方は同じです。レビュアーがトリアージしやすくなり、チームが PR を整理するのに役立つ、簡潔で目に見える合図です。Microsoft のガイダンスによると、タグは「PR がまだ作業中であることや、今後のリリースに向けたホットフィックスであることなど、レビュアーに追加情報を伝えます」（プルリクエストにタグを追加する）。

PR は必ずタグ付きで開きます。 --tag を指定しない場合、ship-pr.ts は次の順にタグを決定します。

1. Conventional Commit 形式のタイトルから取得します。docs(finops): … → docs、finops。
2. ブランチのプレフィックスから取得します。feat/… → feat、fix/|hotfix/|bugfix/ → fix、docs/ → docs、chore/ → chore、refactor/ → refactor。
3. それ以外の場合は needs-review を付け、WARNING を出します。

ここで処理が失敗することはありません。どのプラットフォームにも「ラベルを必須にする」ポリシーはないため、ここが唯一の適用ポイントです。ハードエラーにすると、別の規約を使うリポジトリで処理が止まってしまいます。タグなしで PR を開くには --no-tag を指定します。--reviewer／--required-reviewer を指定しない場合、$SHIP_ADO_DEFAULT_REVIEWER が設定されていれば、任意のレビュアーとして追加されます。追加を省略するには --no-reviewer を指定します。

--tag を指定して PR を開くときにタグを適用します（カンマ区切り、または複数回指定できます）。

bun scripts/ship-pr.ts --title "<title>" --body-file /tmp/pr-body.md \
  --work-item <id> --transition Resolved --tag "hotfix,do-not-merge"

…または、すでに開いている PR のタグを ship-tag.ts で管理します（ID は Azure では pr_id=、GitHub では pr_number= で、どちらも ship-pr.ts が出力します）。

bun scripts/ship-tag.ts <pr-id> --add "needs-review"     # add
bun scripts/ship-tag.ts <pr-id> --remove "do-not-merge"  # remove
bun scripts/ship-tag.ts <pr-id> --list                   # show current tags

どちらのプラットフォームでもタグは自由形式です（Azure は初回使用時にタグ定義を作成し、GitHub は存在しないラベルを自動作成します）。do-not-merge、work-in-progress、hotfix に加え、タイプ／領域の規約を含む、推奨される一貫したタグセットについては、references/azure-devops.md／references/github.md の 推奨タグ セクションを参照してください。

4c. ブラウザーで PR を開く（任意）

レビューは実際には PR ページで行われます。複数のアカウント（仕事用、個人用、クラウド用）を使い分けている場合、どのサインイン済みアカウントで開くかが重要です。間違ったプロフィールでは、権限が正しく表示されなかったり、まったくアクセスできなかったりします。そのため、PR を開いたら、必ず pr_url を提示し、ブラウザーで開くかどうかを尋ねます。ブラウザーで開く操作は任意であり、自動では行いません（ブラウザーウィンドウの表示は目に見える副作用であり、ユーザーは確認を求められることを希望しています）。

ship-open.ts はブラウザー自身の Local State を読み取り（プロフィール切り替えメニューに表示されるものと同じアカウント一覧です）、メールアドレス → ブラウザープロフィール を解決して、そのプロフィールで URL を開きます。WSL（→ Windows Edge／Chrome）と macOS（→ Chrome／Edge）で動作します。設定は固定されていません。アカウント一覧は実行のたびに動的に検出され、メールアドレスは引数で渡し、記憶されるのはデフォルトのメールアドレスのみです。保存先は ~/.config/ship/open.json（このスキルの外部）です。

アカウントを検出してから、AskUserQuestion でどのアカウントを使うかユーザーに尋ねます（複数ある場合にのみ尋ねる価値があります。各アカウントと「開かない」の選択肢を提示してください）。

bun scripts/ship-open.ts --list-profiles   # prints browser= + one `profile=<dir>\t<email>\t<name>` per account

選択したアカウントで PR を開きます（ウィンドウを開かずに解決されたプロフィールを確認したい場合は、先に --dry-run を追加します）。

bun scripts/ship-open.ts "<pr_url>" --profile <email>              # opens; prints opened_url= / profile_dir=
bun scripts/ship-open.ts "<pr_url>" --profile <email> --dry-run    # resolve only, no window

選択したアカウントをデフォルトとして記憶すると、今後はキーを 1 回押すだけで選択できます。

bun scripts/ship-open.ts --set-default <email> [--browser edge|chrome]

不明なメールアドレス、またはメールアドレスを省略した場合は、誤ったプロフィールを推測するのではなく、ブラウザーの Default プロフィールにフォールバックします（stderr に注記を出力します）。この手順は、以下のマージ／クリーンアップとは独立しています。レビューのために PR を開いても、処理が先に進んだり、妨げられたりすることはありません。

5. マージ後 — クリーンアップ

PR が実際にマージされた後にのみ実行します（PR が開いたままブランチを削除しないでください）。merge スキルのクリーンアップ手順にならい、削除する前に確認してください。

• ブランチを worktree で開発した場合は、まずメインリポジトリのディレクトリに cd してから、git worktree remove <path> を実行します。worktree の内部から、その worktree 自体のブランチを削除することはできません。
• git branch -d <branch>（小文字の -d は未マージのブランチを拒否します。この拒否が安全策です。ユーザーが明示的に確認した場合にのみ -D に切り替えてください）。
• git push origin --delete <branch>（ローカルのみのブランチだった場合は失敗を無視します）。

6. 状態をスナップショットする（任意）

PR のフローとは独立しており、戻れる地点を作りたいときはいつでも使えます。main へのマージが問題なく完了した後、リスクのある移行の前、あるいは単に「ここまではすべて正常」と記録したいときなどです。HEAD に注釈付き git タグを作成します（作業ツリーの状態は関係ありません。タグはコミットを指すものです）。

bun scripts/ship-snapshot.ts \
  -m "what changed / why you're saving here" \
  -m "verification status"

スクリプトは、手作業で間違えやすい項目を自動入力します。

• 名前のデフォルトは v<YYYY.MM.DD-HHMM> です（分単位なので、同じ日に複数のスナップショットを作成しても名前が重複しません）。1 日に 1 つだけ作成する場合は --daily を、名前を指定する場合は --name <tag> を渡します。
• 最初のメッセージ段落は Snapshot <tag> — <branch> @ <shorthash> として自動生成されるため、-m を指定しなくてもタグの内容が分かります。追加した各 -m はそれぞれ独立した段落になります（引数の配列で渡すため、実際の改行や句読点も保持されます。単一のシェル文字列内の \n とは異なります）。
• タグが重複する場合は上書きせず、処理を拒否します（終了コード 3）。誰かが利用しているタグが、スナップショットによって予期せず移動することはありません。

タグはプッシュするまではローカルのみです（共有され、他のユーザーから見える状態にする前に、PR を作成する場合と同様に確認してください）。--push を追加すると origin にプッシュします。Azure では、ship-push.ts と同じように、az の OAuth Bearer ヘッダーにフォールバックします。スクリプトは tag=、commit=、branch=、pushed= を出力します。

同梱ツール

スクリプト	説明
bun scripts/ship-preflight.ts [remote]	配信対象の確認と作業ツリーのスコープ監査（scope_clean=…）。助言のみで、処理をブロックしません。最初に実行します
bun scripts/ship-detect.ts [remote]	プラットフォーム、Azure の情報、ブランチ、推定された作業項目を出力します
bun scripts/ship-push.ts [-r remote] [-b branch]	プッシュしてアップストリームを設定します。認証に失敗した場合は Azure OAuth Bearer にフォールバックします
bun scripts/ship-pr.ts --title … [opts]	検出されたプラットフォームで PR を作成します。作業項目の作成または確認とリンクを行います（設定済みユーザーに割り当て）。任意で Board の状態を変更できます。タイトルまたはブランチ名からタグを自動設定します（--tag で上書き、--no-tag で無効化）。任意で --reviewer／--required-reviewer を指定できます（デフォルトは $SHIP_ADO_DEFAULT_REVIEWER。--no-reviewer で無効化）。「リンクされた作業項目をマージ後に完了にする」を事前確認します（--no-complete-transition で無効化）。Azure では、作業項目、タグ、レビュアーを 1 回の作成呼び出しにまとめます
bun scripts/ship-tag.ts <pr-id> [--add|--remove "t1,t2"] [--list]	既存の PR のタグ（Azure）またはラベル（GitHub）を追加、削除、一覧表示します
bun scripts/ship-open.ts <url> [--profile <email>] [--dry-run]	選択したブラウザーのアカウントプロファイルで PR／URL を開きます（ブラウザーの Local State を使ってメールアドレスからプロファイルを特定）。WSL では Edge／Chrome、macOS では Chrome／Edge を使用します。--list-profiles、--set-default も指定できます
bun scripts/ship-snapshot.ts [-m "para"]… [--daily] [--name <tag>] [--push]	現在の状態を注釈付きgit タグとして保存します（日付ベースの名前で、件名から内容が分かります）。Azure OAuth によるフォールバック付きのプッシュも任意で行えます

スクリプトは bun で実行する TypeScript です。共通ヘルパーは scripts/ship-lib.ts にあります。スキルのディレクトリで一度 bun install を実行してください（azure-devops-node-api と @octokit/rest がインストールされます）。Git／プッシュの処理にはサブプロセス呼び出しを使用します（git の操作であるためです）。SDK を使うのは ADO／GitHub REST の処理のみです。プラットフォーム固有の詳細については references/azure-devops.md と references/github.md にあります。検出されたプラットフォームに対応するものを読んでください。PR の説明は assets/pr-template.md を基に作成されます。

安全性

• 破壊的な操作や他のユーザーに見える操作を行う前に、必ず確認します。ブランチ／作業ツリーの削除や、PR の作成（チームに表示されます）が該当します。機能ブランチのプッシュやドラフトの作成は低リスクですが、レビュー可能な状態の PR を作成する場合や、ブランチを削除する場合は確認が必要です。
• 拒否されたプッシュを回避するために、強制プッシュをしてはいけません。拒否された場合は、履歴の分岐かポリシーが原因です。調査し、上書きしないでください。
• トークンはヘッダーで渡し、有効期間は短く保ち、出力したり URL に含めたりしません。
• コミットメッセージ、PR タイトル、PR 本文を含め、どこにも AI への帰属表記を入れません。

注意事項

• どちらの PR 作成方法（Octokit の pulls.create、ADO の createPullRequest）でも、ブランチを先にプッシュする必要があります。手順 3 は手順 4 より前にしてください。
• ship-detect.ts が unknown を返す場合、ほとんどはカスタム SSH ホストエイリアスが原因です。SHIP_PLATFORM を設定してください。 （dev.azure.com-<alias> という SSH ホストは azure として検出されますが、org/project/repo は解析できません。これはシェル版と同じ制限です。必要に応じて、座標や --work-item を明示的に渡してください。）
• スクリプトには依存関係が必要です。Cannot find module 'azure-devops-node-api' が表示された場合は、スキルのディレクトリで bun install を実行してください。
• リンクされた作業項目の状態は自動では変わりません。別々の操作が 2 つあります。--transition は PR のオープン時に状態を変更し、completionOptions.transitionWorkItems（デフォルトで有効です。手順 4 を参照）は PR の完了時に状態を変更します。このデフォルトが設定される前に作成された PR には完了オプションが一切ないため、チェックボックスは未チェックのままです。この設定は作成時に組み込まれ、すでにマージされた PR に後から追加することはできません。
• AZURE_DEVOPS_EXT_PAT が設定されていても、スコープが不十分な場合（例：Code のみで、Work Items / Pull Request への書き込み権限がない場合）、ship-pr.ts は 401/403 を自動検出し、az の OAuth ベアラートークンで再試行します。PAT を手動で解除する必要はありません。このフォールバックを使うには、組織メンバーとして az login している必要があります。
• 作成時に GitHub の 404 Not Found が返る場合、ほとんどはリポジトリが存在しないのではなく、アカウントが間違っています。 gh auth token は、リポジトリの所有者に関係なく、現在アクティブなアカウントのトークンを返します。また GitHub は、アクセスできないプライベートリポジトリに対して 403 を返す代わりに、そのリポジトリを隠します。ship-pr.ts / ship-tag.ts は githubToken(owner) を呼び出すようになりました。これは gh auth token -u <owner> を優先し、ログイン済みアカウントではない所有者の組織リポジトリの場合はアクティブなアカウントにフォールバックします。GH_TOKEN / GITHUB_TOKEN が設定されていれば、引き続きすべてに優先されます。それでも 404 が返る場合は、gh auth status に所有者のアカウントが表示されているか確認してください。
• 生の az repos pr create / gh pr create（または repo_create_pull_request MCP ツール）を使って PR を手作業で作成し、その後で作業項目を追加しないでください。この方法では自動作成とリンクの不変条件が守られず、「ID は何ですか？」とユーザーに手動で確認するやり取りが発生します。また、タイトル内の & が二重にエスケープされ、API がデコードしないエンティティの & になるため、タイトルが正しく表示されません。ship-pr.ts は SDK と引数配列を介してタイトルをそのまま渡すので、& は & のままです。生の方法ではなくスクリプトを使う理由はほかにもあります。
• createPullRequest は completionOptions を黙って破棄します。 ペイロードは受け付けられますが、PR は completionOptions: null で返されるため、作成時に渡した設定は反映されません（ADO PR 1050 で確認済み）。完了オプションは、PR の作成後に updatePullRequest で設定する必要があります。渡したフラグだけを根拠に設定済みと報告しないでください。API レスポンスから値を読み取ってください。
• スクリプトは対象リポジトリから絶対パスで実行してください。スキルのディレクトリに cd してはいけません。 プラットフォームの検出には現在の作業ディレクトリの Git リモートが使われます。また、スキルのディレクトリ自体が独自の GitHub リポジトリなので、cd ~/.claude/skills/ship && bun scripts/ship-pr.ts を実行すると、そのリポジトリに対する PR が作成されます（2026-09-23：main と main の間にコミットがないことを示す 422 だけが処理を止めました）。作業対象のリポジトリから bun ~/.claude/skills/ship/scripts/ship-pr.ts を実行してください。
• PR がまだオープンの状態でブランチを削除すると、その PR は放棄されます。クリーンアップはマージ後にのみ行ってください（手順 5）。
• ship-open.ts は、ブラウザーでサインインしているアカウントのメールアドレスに対して --profile <email> を照合します。そのため、アカウントが紐付いていないプロファイルは、メールアドレスではなく Default のフォールバックとしてのみ選択できます。インストール済みのブラウザーを自動選択し（両方ある場合は chrome を優先）、依存関係もネットワークも不要です。必要なのはブラウザーのローカルな Local State ファイルだけです。このファイルが見つからない場合、ブラウザーが想定された場所にインストールされていません。--browser を渡すか、表示されたパスを確認してください。
• 「タグ」は 3 種類あります。混同しないでください。 (1) PR タグ／ラベル（--tag、ship-tag.ts）— PR のトリアージ用シグナルです。(2) 作業項目（手順 4）— トレーサビリティ用のリンクです。(3) Git タグ（ship-snapshot.ts）— 履歴におけるコミットのチェックポイントです。ship-tag.ts には PR ID を渡します。ship-snapshot.ts は位置引数を受け取らず、HEAD にタグを付けます。同じ言葉でも、概念は 3 つあります。
• タグの再追加は安全です。 Azure の createPullRequestLabel はエラーを返さず既存の定義を返し、GitHub は重複を除去します。また、parseTags は CSV から空の名前や重複した名前を除外します。
• ship-tag.ts には PR ID が必要です。 Azure では数値の pr_id、GitHub では pr_number を使います（どちらも ship-pr.ts が出力します）。GitHub では、存在しないラベル名のタグを指定すると、そのラベルが自動作成されます。