mcpField
S
ship-it

ship-it

github.com/hcaiano開発66 回インストール
リポジトリ

ship-it について

ship-itは、コード変更を検証・レビューし、マージ可能なプルリクエストにまとめるためのスキルです。チェックやフィードバックへの対応を定め、マージとデプロイには明示的な許可を求めます。

主な機能

  1. 01作業ブランチで変更範囲を限定
  2. 02変更内容に応じたチェックの実行
  3. 03review-itによる変更レビュー
  4. 04単一のPRを公開・更新
  5. 05検証済みHEADごとの証跡管理
  6. 06マージとデプロイに許可を要求

活用シーン

  1. 01コード変更をレビュー用に準備
  2. 02プッシュ前にブランチを検証
  3. 03PRのフィードバックとチェックに対応
  4. 04マージ可能な成果物を引き継ぐ

インストール

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

$npx skills add https://github.com/hcaiano/skills --skill ship-it

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

同梱ファイルagents/openai.yamlscripts/skill-contract.test.mjs

詳細

リリースする

マージ可能な PR を仕上げます。この対応でのマージとデプロイには、ユーザーによる明示的な承認が必要です。委任やマージポリシーは、その承認の代わりにはなりません。

現在の HEAD に対するアクセス可能なデリバリーレコードがある既存の PR では、手順 6 から開始します。それ以外の場合は、ゲート全体を実行します。従来の PR 本文にある受領記録は受け入れ、PR を更新する際に内部レコードへ移します。

  1. 準備する。 リポジトリの指示に従い、タスクブランチで作業し、無関係な変更は除外します。

  2. 検証する。 変更したすべての動作と、直接的な契約利用者を網羅する、リポジトリで最小限のチェックを実行します。プラットフォーム上の制約でチェックを実行できない場合は、実際に一度試し、そのコマンドとエラーを記録して、代行する CI チェックを明記します。

  3. レビューする。 検証済みのブランチで review-it を実行します。その評価、修正、停止判断に従います。レビュー記録を保持し、ここで独自のレビューを追加しません。

  4. 検証してプッシュする。 先に進んでいる origin/<target-branch> をマージします。強制プッシュはしません。最終 HEAD がクリーンな状態で、対象を絞った検証と、変更したコードに対するリポジトリの lint、型チェック、ビルドを再実行します。リポジトリで必須の場合に限り、キューまたはリースを使ってローカル CI 全体を実行します。検証済みの HEAD をプッシュします。

  5. 公開する。 ドラフトではない PR を 1 件に保ちます。マージ前に確認する人向けに、変更内容と理由を述べる短い文を 1～2 文、その後に検証内容を 1 行で記載します。通常の PR は、80 語未満を目安にします。レビューやマージに影響するリスク、未解決事項、判断、証拠のみを追加し、重要なブロッカーは見える状態に保ちます。必要に応じて、ローカルのチェック、CI、本番環境での確認を区別します。平易な言葉を使い、リポジトリで必須のテンプレートに従います。プロセスの履歴、ファイル一覧、監査の詳細、ボットによる要約を含む繰り返しの要約は省略します。最終的な変更内容に合わせて本文を書き直します。受領記録は内部レコードに保管します。

  6. フィードバックを処理する。 すべてのレビュー、コメント、未解決および古いスレッド、チェックを取得します。失敗、重大な欠陥、人からの依頼を修正します。細かな指摘、重複、根拠のない指摘には、プッシュせずに説明して解決します。スコープ、プロダクトやアーキテクチャに関する判断、または相反する指示については質問します。スレッドを解決する前に、修正のコミットまたは理由を返信します。ユーザーの判断を必要とするものは未解決のままにします。クラウドレビューのボットを呼び出したり、反応がなくなるのを待ったりしてはいけません。

    修正の各バッチを 1 つのコミットにまとめます。動作、スコープ、セキュリティ、アーキテクチャに関わる変更では、レビュー上限の範囲内で、そのコミットに対して review-it を実行します。手順 4 を繰り返し、デリバリーレコードを更新します。必要に応じて PR の要約も更新します。ベースブランチのマージも 1 回として数え、修正バッチは 2 回までです。その後は残りの項目と推奨事項を報告します。最終プッシュ後に寄せられたフィードバックで、このループを再開することはありません。このデリバリーで作成していないリモートコミットがある場合は、ユーザーの指示を仰ぎます。

    デリバリーごとに、2 回目以降のレビューや以前にユーザーが実行した /code-review を含め、LLM レビューは 3 回までです。手順 3 は必ず実行します。上限を超えた場合は、最新のコミットに起因するリグレッションのみをレビューし、それ以外の指摘は残存項目として記録します。

    フィードバックを最新の状態で再取得し、スレッドが解決済みかユーザーの判断待ちであり、headRefOid が Final validated HEAD と一致し、GitHub がマージ可能と報告し、その HEAD で必須チェックと委任されたチェックがすべて成功している場合にのみ完了とします。保留中または利用できないチェックがある場合は完了できません。利用可能な場合はランタイムの PR ウォッチャーを使用し、そうでない場合は 60～120 秒ごとに確認します。

  7. 承認済みの場合はマージする。 リポジトリの方法に従ってマージし、マージコミットを検証します。スコープ内で承認されている場合に限り、文書化されたデプロイを実行して検証します。委任されたデリバリーは、マージ可能な状態で呼び出し元に戻します。

  8. 報告する。 数文で PR のリンク、準備状況、ブロッカーまたは判断事項を伝えます。ローカルのチェック、CI、本番環境での証拠を区別します。依頼がない限り監査の詳細は内部に保管します。未解決の重要な指摘がある場合、マージ可能とは報告できません。

内部記録

検証済みの HEAD ごとに 1 件の記録を $(git rev-parse --git-path agent-receipts)/ship-it/<branch>/ に保存します。呼び出し元にはその絶対パスを伝えるか、アクセスできない場合はエージェントの通信手段を通じて内容を送信してください。 これらはローカルの証跡であり、GitHub のリンクではありません。

## Delivery gate
- Focused proof: <commands and behavior covered>
- Final validated HEAD: <full SHA from git rev-parse HEAD>
- Review-checked timestamp: <UTC time of the final PR feedback fetch>
- Final checks: <commands and results on that SHA>
- Delegated to CI: <check and reason, or none>
- Residual findings: <open findings, or none>

<review-it's internal Review gate record>

コメント

Markdown 対応