ship

ship

このスキルは汎用です。リポジトリの情報は把握せず、出荷の方法だけを知っています。リポジトリに関する情報はすべて、docs/agents/ship.md の出荷プロファイルに基づきます。.claude/skills/ship にあるコピーは派生コピーで、ソースリポジトリ Gharib89/skills で変更され、リポジトリの CLAUDE.md にある ### Ship ブロックが示すコマンドを通じて更新されます。

バージョン。 ハーネスは読み込み時にこのファイルのフロントマターを取り除くため、実行の開始時に一度だけ、sed -n 's/^ version: //p' <base directory>/SKILL.md を使ってバージョンを読み取ります。デフォルトでは、最初の返信とマージの概要に ship <version> を表示し、どの ship が作成した PR か記録します。

引数とフラグ

$ARGUMENTS：

• <issue>：Issue 番号（Azure DevOps の作業項目 ID）です。prepare 単独の場合は不要です。フラグなしで省略された場合は、どの Issue か尋ねます。
• 数字ではなく自由記述のテキスト：タスク仕様そのものです。Issue の取得、claim、Closes、reflect は行わず、それらに言及する Done when: 条件も含めません。preflight、isolate、open-pr、merge、cleanup では、Issue 引数に none を指定します。
• --unattended：詳しくは reference/unattended.md を参照してください。無人実行では人間が介在しません。ブロックされた場合は質問せずに処理を返し、サンドボックスのクローンを分離環境として使い、マージゲートでは概要を PR コメントとして投稿して戻ります。<issue> がない場合は、最初に無人レーンを実行します。順序は prepare、PR 上限、選択です。
• --inline [--review]：インラインレーンです。prepare の前に、ルールを確認するため small-lane.md を読んでください。
• --rework ["<feedback>"]：手直し実行です。以前の実行がマージゲートで止めた PR を手直しします。run-file init の前に rework.md を読んでください。有人実行のみです。--inline との併用は可能です。

--unattended を指定しない実行は有人実行です。人間による対応が必要になった場合は停止して確認し、待機中も claim を保持します。すべての実行で、Issue なしレーンの内側の実行を除き、run-file init より前に準備を行います。準備では prepare を実行します（そのレーンでは --unattended）。クラウドサンドボックス（CLAUDE_CODE_REMOTE=true）内、またはそのフラグが指定されている場合は、tooling --install を実行してから、プロファイルの ## Cloud lane にある Bootstrap: を実行します。それ以外では何もしません。ステップが failed になった場合は、その末尾を添えて実行を停止し、claim は行いません。tooling の場合は host-unreachable、bootstrap の場合は bootstrap-failed です。

インライン化せず、組み合わせる

tdd（フェーズ 2）、writing-for-agents（フェーズ 4、エージェント向けドキュメント）、code-review（フェーズ 4）、find-docs（API に関する主張がある場合。プロファイルの Pinned: ライブラリも対象です。implement.md を参照）は、必要なタイミングで Skill ツールから読み込み、各スキルのロジックはスキル自体から取得してください。また、組み合わせるスキルに無人モードがある場合、実行が無人であることを明示的に伝えてください。ほかにそのことを知る手段がないためです。フェーズ 6 の Change outline では show-me を読むのではなく、参照してください。pr-body.md に理由があります。

パイプライン

フェーズを順番に進め、メインスレッドではオーケストレーションと判断に集中します。最初に reference/context-discipline.md を読みます。長時間の実行でウィンドウが膨らむのを防ぐ既定の方法と、それでも必要となる作業が記載されています。次に、実行における最初の書き込みを行います。prepare の後、Issue の read-issue の後、フェーズ 0 の前に、run-file init <issue|slug> --from-profile を実行して 10 項目のチェックリストを含む Run ファイルを初期化します。Issue の Run では、implement.md に従って --criteria - も追加します。以下の各フェーズでは run-file next、open、close または skip で状態を切り替え、Done when: の条件が満たされた時点で完了します。それより前に完了してはいけません。 ターンは計画を述べた行では決して終わりません。 以下の表に示す停止条件（マージゲートを含みます）に達したとき、または最後の行で名前を挙げた待機対象、つまり通知によって実行が再開されるバックグラウンドジョブやサブエージェントを待つときに終わります。次に何をするかを述べた行の後は、同じターン内でそれを実行します。そのジョブやサブエージェントから応答が戻ったら、次のステップに進む前に、1行で終了を知らせます。そうすれば、セッションを読む人にも実行が先へ進んだことが分かります。

フェーズでは、名前が示す仕組みを実行します。 その仕組みが何を包んでいるかをあらためて導き出すことはしません。すべてのゲーティング呼び出しは仕組みを通します。 ここでいうゲーティング呼び出しとは、後続フェーズ、停止、マージ、リリースが依存するホスト呼び出しです。いずれの仕組みも実行しない呼び出しは、サマリーに記載する Ship の欠陥 です。手作業で代替してはならず、クリーンゲートを保留にしてはなりません。それ以外の未対応の呼び出しは、gh api または az rest を使った直接呼び出しとし、まず run-file call で記録します。回避策で対処した摩擦は Ship の注記 です。reference/mechanics.md には、ゲーティング呼び出し、各フェーズの仕組み、共通の契約が記載されています。--help も含まれます。

0 · 分離。 reference/isolate.md には、プリフライトで確認・拒否する内容とその理由、ワークツリーをこの方法で作成する理由が記載されています。preflight <issue>、続いて read-issue、最後に isolate を実行します。手順は phase-steps.md にあります。 完了条件： preflight が ok: true を返し、isolate がパスを出力し、## Worktree の Bootstrap: があれば正常に実行され、立ち会いがある場合は EnterWorktree でそのパスに入っていること。

1 · 理解。 read-issue の結果から計画を立てるには曖昧すぎる場合は、何も担当せず ambiguous で停止します。それ以外の場合は、作業の前に担当を宣言します。manage-issue <issue> take --fresh を実行します（作業のやり直しや再開では、すでに担当している場合は引数なしで実行します）。担当はマージまで保持し、その後の停止は停止条件の表に従います。 次に、issue が参照する各アンカーを grep し、Run ファイルで成功条件を確定します（後続の writer: true のブリーフまたはコメントは本文に優先します。これは仕様の優先順位です）。手順は phase-steps.md にあります。 完了条件： claim: taken が記録され、アンカーが grep され、成功条件が Run ファイルに記載されていること。

2 · 実装。 reference/implement.md には、変更の分類、TDD の例外、外部担当の調査、判断と実行の分離、隣接して見つかった項目の処置が記載されています。 変更を分類し、レーンキーと検証項目を判断して run-file grade を記録し、最初の編集から逸脱ログをつけ、1 つの PR に収められない場合は needs-split で停止します。手順は phase-steps.md にあります。 完了条件： 該当するテストがすべて成功し（分類ごとに、まず失敗すること）、トリップワイヤーと PR 内必須要件が追加され、Grade: が記録され、小規模レーンの差分が計測され、これまでの逸脱と隣接して見つかった項目すべてについて、その処置が Run ファイルに記載されていること。

3 · 検証。 reference/verify.md には、結果を表す語句、Without it: に記載する処置、unexercised の定義が記載されています。 該当する各検証の Run: 行を実行し、変更した範囲に限定します（phase-steps.md）。 完了条件： run-file close 3 で各 Verification に --result が指定され、該当する各項目が pass、deferred-to-ci、または unexercised のいずれかになっていること。それ以外の結果は記録し、その後、指定された停止条件に従います。または、スキップした内容を run-file skip 3 で記録していること。 4 · ドキュメントを同期し、セルフレビューします。 レビューでドキュメントの変更も差分の一部として確認できるよう、先にドキュメントを更新します。公開インターフェイスまたは観測可能な動作が変わった場合に限り、ドキュメント同期を実施します。プロフィールの Targets: を変更に合わせて更新し、その変更を今回の変更に含めるか、トラッカーのイシューに ドラフトしたセクションとして追加します。 内部リファクタリング、ドキュメントに記載された動作を復元するバグ修正、テストのみの変更やツール関連の変更、コメントについては省略し、マージゲートでその旨を1行で伝えます。 writing-for-agents のパスには独自のトリガーがあり、ドキュメント同期を省略する場合でも実施します。ドキュメント同期の変更を反映したうえで、code-review を読み込み、このパスと2つの軸を1回のターンで実行します。トリガー、ティア、小規模レーンの形式については、 phase-steps.mdを参照してください。

セルフレビューはすべてのレーンで必須であり、ループとして行います。1回目はorigin/HEADからの差分に対してcode-reviewを実行し、すべてのReportファイルが揃うまでトリアージを待ち、各指摘に1つの処置を決めます。Standards軸は、tree unchangedまたはcapになるまで、各ラウンドの修正のみの差分に対して再実行します。証拠の行がなければ、run-file close 4は拒否されます。手順： phase-steps.md。 完了条件： 実施されたすべてのレポートについてReportファイルがディスク上にあり、そのパスがRunファイルに記載されていること、すべての指摘に処置が記載されていること、close 4が証拠の行を受け取っていること、そしてドキュメント同期が反映済みか、省略する旨が1行で記載されていること。

5 · ローカルゲート。 前提条件： 該当するすべての検証がpass、deferred-to-ci、unexercisedのいずれかであるか、該当する検証がないこと、かつフェーズ4のすべての指摘に処置が記載されていること。それ以外の場合は戻ります。 まずbase-freshを実行します（behindの場合は、その指示に従って再実行してから続行します）。すべてのCarry:ファイルがメインのチェックアウトのコピーと一致することを確認し、ワークツリーからプロフィールのLocation:にあるゲートをインラインで実行して、そのJSONをrun-file gate recordに記録します。判定に使う語句とそれぞれの処理については、 phase-steps.mdを参照してください。 完了条件： base-freshの結果がfresh: trueであること、Carry:ファイルが一致すること、記録された判定がverdict: passで、gates.secretsが含まれていること。

6 · PRを作成します。 reference/pr-body.mdには、本文に含める内容と、その記述方法および読み戻し方法が記載されています。open-pr <issue> --title --body-fileで、ドラフトではないPRを作成します（ドラフトではレビュアーがトリガーされない場合があります）。タイトルには、Subject constraints:に従ったConventional Commitのサブジェクトを使います。後からupdate-pr-titleで修正します。オープン中のPRのタイトルまたは本文を書き換えた後は必ず read-pr <pr>を実行し、本文に必要な## 見出しが含まれていることを確認します。その後、reflect <issue> <pr>を実行します。 完了条件： read-prの結果に、本文に必要な見出しを含む、オープン中でドラフトではないPRが表示されていること。さらに、reflectが投稿済みであること。

7 · レビュアー。 reference/review-loop.mdには、トリガーごとのラウンド、予算としての上限、ラウンドの読み方、終了条件の文言とフォールバックが記載されています。 可能な範囲で、## Reviewersに記載された各レビュアーに対してラウンドを実施します。まずFallback-for:がNone.となっているレビュアー全員を対象とし、その後でフォールバックを実施します。ラウンドは各ブロックのTrigger:をきっかけに開始し、poll-pr --briefの1ウィンドウ分待ってから、反映された内容をトリアージし、修正を1回でプッシュして、各スレッドに回答します。手順、終了語句、終了時の記録については、 phase-steps.mdを参照してください。 完了条件： 各レビュアーに終了語句が記載されていること、poll-prで返されたすべてのスレッドに回答し、Resolve:に従って解決していること、ラウンドで拡充された各セクションを書き直していること、タイトルがGrade:に一致していること、実施したローカルレビュー、上限に達したラウンド、ドキュメントのみのラウンド、または未反映のラウンドに処置が記載されていること、close 7が各レビュアーのRound:とStop:の行を受け取っていること、そしてread-prの結果にレビュアーごとの## Review行が表示されていること。 8 · CI. CI は PR が開かれた時点で実行され、フェーズ 7 と並行します。ci-wait <pr> で CI の完了を待ち、プロファイルの Legs: を読み取ります。 待機、競合、no-checks、失敗したレッグ、Push policy: の読み取り方法については、phase-steps.md を参照してください。 完了条件： ci-wait が green を返した場合、各 missing_legs エントリーについて No-checks legal: が認める場合、または認められる場合に no-checks を使用した場合です。

9 · マージゲート。 reference/merge-gate.md に、サマリーの形式、merge の動作、その拒否条件、トラッカーの下書きが記載されています。 そのファイルに従ってサマリーを作成してください。マージの承認から復帰までの手順は、phase-steps.md を参照してください。 完了条件： 立ち会いありの場合、merge とすべての update-issue-body が false なしで終了コード 0 を返し、その後 close 9、ExitWorktree、cleanup <issue|none> が false なしで終了コード 0 を返した場合です。立ち会いなしの場合、comment-pr がコメントを投稿した場合です。

停止条件

マージゲートではフェーズ 9 に記載されているとおり停止し、無人レーンは投稿して終了します。 以下の停止条件表が正式な基準です。 それ以外の作業、つまり自分の調査結果のトリアージ、修正、再実行は自律的に行います。その際は、次の 2 つのガードレールを守ります。

• 失敗は修正するか、報告します。 マージゲート到達前の失敗は、再試行で進展がある間は再試行します（2 回の試行が妥当な目安です）。進展がなくなったら red-after-retry: <what> とし、アプローチが誤っているとわかった時点で直ちに停止します。いずれの場合も、具体的な証拠と、手間がかからない場合は動作確認済みの代替案を添えて停止して報告します。これにより、報告を受けた側がすぐに可否を判断できます。
• すべての停止条件には名前があります。 以下のアクションを適用し、記載どおりの名前を報告します。

停止条件	理由	claim
プロファイルがない、または無効、ホストに到達できない	profile missing、profile invalid: <detail>、host-unreachable	claim なし
スキル composes が指定の pin でインストールされていない、または pin の形式が不正	skill missing: <skill>; run <install line>、skill off pin: <skill> at <ref>, pinned <sha>; run <install line>、skills lock unreadable: skills-lock.json; repair it, then re-run preflight、composes pin invalid: <entry>; want <form>	claim なし
事前チェックで対応可能な状態ではない	closed、is a pull request、already claimed、existing PR、existing branch、worktree exists、not triaged: run /triage first、ready-for-human: attended only	claim なし
Issue の内容が曖昧すぎて計画できない	ambiguous	claim なし
事前チェック後、別の実行が claim した	contested: <others>、held: another run of this identity holds it	contested：claim なし、held：もう一方の実行のもの
--rework 実行が承認されない、または手直しするものがない	not reworkable: <detail>、no feedback	変更なし
変更が 1 つの PR に収まらない、または Issue の範囲外の再設計が必要	needs-split	対面実行：確認を求める、無人実行：差し戻す
調査により Issue の仕様が誤っていると判明	mis-specified	対面実行：確認を求める、無人実行：差し戻す
検証の前提条件が不足	hand-off（対面実行は待機し、claim を保持）／blocked-verification	対面実行：保持、無人実行：差し戻す
ローカルゲートの判定が unavailable	local gate unavailable: <gates>	対面実行：確認を求める、無人実行：差し戻す
引き継いだファイルが変更された	carried file modified: <file>	対面実行：確認を求める、無人実行：差し戻す
再試行後も失敗	red-after-retry: <what>	対面実行：確認を求める、無人実行：差し戻す
マージ前にブランチがベースから遅れている	stale-base: behind <n> on <base>	対面実行：ベースをマージするまで保持、無人実行：差し戻す
マージゲートで PR がクローズされている	pr-closed: <state>	対面実行：確認を求める、無人実行：差し戻す
マージゲートが読み取った後に PR の head が移動した	head-moved: <current> != <gated>	対面実行：ゲートが新しい head を再読み込みするまで保持、無人実行：到達しない（レーンではマージを実行しない）
--inline と --unattended または自由記述を併用	inline refused	claim なし
prepare で Cloud レーンの Bootstrap: が失敗	bootstrap-failed	claim なし
オープン中の PR 数がプロファイルの PR cap: 以上	pr-queue-full	claim なし
選択条件を満たす Issue がない	nothing-ready	claim なし
ホストに blocker クエリが存在し、それが失敗	blockers-unavailable	claim なし
マージゲートに到達	なし：実行成功	マージまで保持

差し戻しは manage-issue <issue> handback "<reason>" で行います。対面実行と無人実行のルールについては、 phase-steps.md を参照してください。

レーン

変更が小さいと判断できるまで、すべての実行はフルレーンです。フェーズ 2 で判断する以下の 3 つの条件をすべて満たす必要があります。迷った場合は、小さい変更ではありません。

1. 公開サーフェスに変更がない。 公開サーフェスはプロファイルの ## Public surface に記載されています。Default. は、エクスポートまたは公開される API、CLI フラグと終了コード、設定スキーマ、ファイル形式、文書化された動作を指します。
2. 実物がなくても検証できる。 ユニットテストまたは回帰テストで完全に証明できるか、クラスが docs でテスト対象となる動作がないこと。いずれの場合も、プロファイルの ## Verification に記載された検証は適用されません。
3. 変更の範囲が限定されている。 新しい依存関係がなく、プロファイルの Tripwires: に該当するものがなく、差分の規模が small-lane.md の説明に収まっていること。

動作の変更も認められます。バグ修正もその一つです。ガード、許可リスト、または拒否ルールに触れる差分は、--review 内で行う場合を除き、フルレーンです。小規模変更またはインライン変更の場合は、まず reference/small-lane.md を読んでください。

モデルのティア

context-discipline.md のティア表は、各サブエージェントのデフォルトモデルを示しています。各サブエージェントのプロンプトにはスクラッチディレクトリが指定されます。このディレクトリは引き継がれません。

作業基準

個人用の ~/.claude/CLAUDE.md、~/.claude/rules/、個人用スキルの有無にかかわらず、これらの基準は、あらゆるリポジトリで実行中に行うすべての編集に適用されます。

• 問題を解決する最もシンプルな形にする。 単発のコードに、憶測に基づく機能、設定可能性、抽象化を持ち込まないでください。差分を 3 分の 1 の規模にできるなら、書き直してください。
• 必要な箇所だけを変更する。 課題の解決に必要な箇所だけに触れ、変更するすべての行が課題または記録された逸脱に結び付くようにしてください。既存のスタイルに合わせ、周辺のコード、コメント、書式には手を加えないでください。
• 症状ではなく根本原因に対処する。 一時的なパッチやエラーの握りつぶしで済ませず、修正の代わりに TODO を置かないでください。本当の修正がスコープ外なら、その旨を伝えて課題として登録してください。
• 呼び出し元を確認し、依存関係には根拠を示す。 コントラクトを変更する前に、その呼び出し元とテストを確認し、変更によって動作しなくなるものをすべて更新してください。標準ライブラリ、またはリポジトリにすでにインストールされているものを優先し、新しい依存関係を追加する場合は PR 本文で理由を説明してください。implement.md のフェーズ 2 に手順が記載されています。
• コメントには理由を記録する。 公開 API と、自明でない制約、不変条件、回避策を文書化してください。内部実装の説明にすぎないコメントは避けてください。
• PR 本文は簡潔にし、必ず理由を書く。 何を変更したか、なぜ変更したかを記載してください。どのように変更したかは差分を見れば分かります。マージサマリーは例外です。省略せずに記載してください。