mcpField
F
forge-ship

forge-ship

github.com/mgratzer開発8333 回インストール3 日前に更新
リポジトリ

forge-ship について

forge-shipは、変更の実装から別コンテキストでのレビュー手配、結果報告までを行うスキルです。任意の無人実行モードとguardモードでは、指摘の振り分けやPR検査を自動で進めます。

主な機能

  1. 01変更をエンドツーエンドで実装
  2. 02新しいコンテキストにレビューを委任
  3. 03レビュー指摘を振り分け
  4. 04guardモードで品質とCIを検査
  5. 05PRと実装結果を報告

活用シーン

  1. 01GitHub Issueの実装
  2. 02引き渡し前の変更レビュー
  3. 03guardモードでのPR検査

インストール

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

$npx skills add https://github.com/mgratzer/forge --skill forge-ship

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

詳細

変更をリリースする

実装からリリースまで一貫して行います。コードを書き、レビューし、リリースします。実装は現在のセッションで行い、レビューは常に新しいコンテキストに委任します。リスクに応じてのみ、レビューを深めます。

入力

forge-implement($ARGUMENTS)と同じです。Issue 番号/URL、計画ファイルのパス、または自由形式のテキストを指定します。任意:-- <additional context>。

無人モード: --unattended を指定すると、計画の承認を省略し、重要度に応じて指摘を自動的にトリアージします。

ガードモード: --guard を指定すると、PR の作成後も forge-guard のプロセス(品質チェック、CI、ピアレビュー、フィードバックへの対応)を続け、その後 forge-land のリスク判定を実施します。最終状態は merged(プロジェクトが自動マージをオプトインしている場合のみ)、merge-ready、review-ready、または needs-human です。--unattended も有効になります。

プロセス

ステップ 1:実装

完全な forge-implement プロセスを実行します。ただし、以下の点を変更します。forge-implement の要約は作成しないでください。以下のレビューを踏まえて、最終レポートを 1 つにまとめます。

ステップ 2:レビュー(委任)

review-delegation のプロセスに従います。実装の差分を収集し、デフォルトで新しいコンテキストによるレビューを 1 回行います(このセッションで差分を作成したため、インラインの小規模差分レビューは適用されません)。リスクに応じてのみ 2 回目のレビューを追加し、指摘を集約します。

サブエージェントに提供する入力: ブランチの差分、変更したファイルの一覧、review-delegation に記載されたプロジェクト規約。 想定される出力: ファイルごとにグループ化され、重要度タグ(P0/P1/P2)が付いた重複のない指摘。

ステップ 3:指摘のトリアージ

有人モード(デフォルト): 各指摘に推奨対応を添えてユーザーに提示します。今すぐ修正する方針を強く優先し、PR のスコープを実質的に広げる変更、または本当にスコープ外の変更に限って先送りしてください。

無人モード: レビュー基準 に従い、重要度とスコープに基づいて自動的にトリアージします。スコープ内の P0~P2 の指摘は今すぐ修正し、本当にスコープ外または実質的に規模の大きい P1~P2 の項目は先送りし、P3 は無視します。

修正した指摘はコミットしてプッシュします。先送りした項目は Issue にします。詳しくは issue-operations を参照してください。

ステップ 4:ガードとマージ(--guard を指定した場合のみ)

ステップ 1 で作成した PR に対して、完全な forge-guard プロセスを実行します。needs-human で終了した場合、それがこのスキルの最終状態です。review-ready に達した場合、その状態は報告せず、同じ PR に対して完全な forge-land プロセスを実行します。その最終状態が、このスキルの最終状態になります。--guard を指定しない場合は、status-reporting に従って pushed と報告します。PR はオープンされ、自己レビュー済みの状態です。以降は人間が対応します。

ステップ 5:要約

実装、レビュー、ガード、マージの結果をまとめて報告します。

出力形式

## Ship Summary

**PR:** #<number> — <title>
**Branch:** <branch-name>
**Result:** pushed | merged | merge-ready | review-ready | needs-human — <reason>

### Implementation
- <N> commits, <M> files changed
- Tests: <added/modified/none>
- Docs: <updated/none>
- Exercised: <intended | wrong: <observed vs expected> | not exercised: <why>> (plus "not run: <parts>" when parts were skipped)

### Review Findings
- Fixed in PR: <list or "none">
- Deferred: #<issue> — <title> (or "none")

### Guard   (guard mode only — the Passes, Rounds, and Open sections from forge-guard; Result above is authoritative)

### Land    (guard mode only, when guard reached review-ready — Judged, Checks, and Review requested from forge-land)

### Quality Gates
- Lint: ✓/✗
- Format: ✓/✗
- Types: ✓/✗
- Tests: ✓/✗
- Coverage: ✓/✗/not configured

ガイドライン

  • どんなに小さな差分でもレビューを委任してください。このセッションで変更を作成したため、インラインレビューは自己レビューになります。
  • レビューを省略しないでください。実装に問題がなさそうに感じても、必ずレビューします。
  • 同じ PR での修正を優先してください。ただし、指摘の規模が本当に大きい場合、またはスコープ外の場合を除きます。

関連スキル

構成要素: forge-implement、forge-reflect と共有する新しいコンテキストでのレビューフロー(_shared/review-delegation.md)、および --guard を指定した場合の forge-guard と、それに続く forge-land を組み合わせます。 ピアレビューの後: レビュアーのコメントに対応するには forge-address-pr-feedback を使用します(ガードモードでは自動的に対応します)。 複数の Issue をまとめて処理する場合: forge-batch を使用して Issue を Wave にまとめ、Issue ごとに forge-ship --guard セッションを 1 つ開始します。

使用例

/forge-ship 42
/forge-ship 42 -- keep the diff minimal
/forge-ship docs/roadmap.md
/forge-ship --unattended 42
/forge-ship --guard 42

コメント