mcpField
P
prepare-paperclip-pr

prepare-paperclip-pr

github.com/paperclipai開発108.3k79 回インストール今日更新
リポジトリ

prepare-paperclip-pr について

prepare-paperclip-pr は、Paperclip リポジトリで PR を準備する標準スキルです。専用の Git worktree でレビュー用の変更を整える開発者向けに、コミット、rebase、リポジトリの制約、Greptile と CI のレビュー手順、引き継ぎ報告を定めています。

主な機能

  1. 01専用 Git worktree での作業を必須化
  2. 02変更をコミットして対象 master に rebase
  3. 03PR、マイグレーション、ワークフローの制約確認
  4. 04gh で PR を作成し URL を記録
  5. 05Greptile と CI のレビューサイクル実行

活用シーン

  1. 01ブランチの変更をレビュー用 PR にまとめる
  2. 02push 前に Paperclip リポジトリの規則を確認
  3. 03PR レビュー後に引き継ぎ情報を記録

インストール

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

$npx skills add https://github.com/paperclipai/paperclip --skill prepare-paperclip-pr

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

詳細

Paperclip PR の準備

ブランチでの作業をレビュー済みの、paperclipai/paperclip の master 向けプルリクエストにするための標準的な Paperclip 手順です。PR ごとに 1 回適用してください(タスクでブランチを複数の PR に分割する場合は、それぞれに対して手順全体を実行してください)。

0. 前提条件 — worktree の安全性

  • PR に関する作業はすべて、専用ブランチの git worktree で行ってください。メインの ~/paperclip チェックアウトでは通常、Paperclip サーバーが稼働しています。そこでブランチをチェックアウトしないでください。すでに worktree/ブランチにいる場合は、確認して(git rev-parse --git-dir、git branch --show-current)、作業を続けてください。
  • メインのチェックアウトが予期せず master 以外になっている場合は、作業を失わないよう、まず修正してください(通常は、そのブランチの作業を worktree に移します)。
  • 対象のリモート/ref を確認してください(通常は paperclipai/paperclip リポジトリの master。タスクで origin や public-gh など、特定のリモートが指定される場合があります)。

1. すべてコミットする — 作業を失わない

  • 何よりも先に、コミットされていない変更をすべて 論理的な単位でコミット してください。stash して忘れたり、ファイルを残したりしないでください。コミットが不足している場合は作成してください。
  • コミットメッセージの末尾には、次の行を必ずそのまま記載してください。 Co-Authored-By: Paperclip <[email protected]>

2. master に変更をきれいに積み重ねる

  • 対象のリモートを fetch し、ブランチを対象の master 上に rebase(または同等の方法で再適用)して、PR にマージコンフリクトがない状態にしてください。
  • rebase 後に再確認してください。変更に関連するビルド/テストが、タスクに応じた適切な範囲で引き続き成功することを確認してください。

3. ガードレールのチェックリスト(すべての PR)

  • pnpm-lock.yaml は絶対にコミットしないでください — リポジトリにはこれを管理するアクションがあります。すでにコミットに含まれている場合は、push する前にその変更を書き換えるか取り除いてください。
  • .github/workflows/* は絶対に変更しないでください。変更の元となったコミットが明示的にワークフローに関するものであり、タスクでもその変更が指示されている場合を除きます。
  • デザインのスクリーンショット/ワイヤーフレーム画像 は、成果物として本当に必要なものでない限り、リポジトリにコミットしないでください。
  • マイグレーション:番号は連番にし、master と競合しないようにしてください。master が進んで番号が使われた場合は、その後ろの番号に付け直してください。すでに古い番号を適用済みのユーザーに影響しないよう、マイグレーションを 冪等 にしてください。
  • Greptile のファイル数制限:各 PR の変更ファイル数を 100 未満 にしてください。これを超える場合は、2 つに分割してください。

4. PR を作成する

5. レビューループ

  • 会社のスキル /greploop を実行してください。Greptile のレビューを起動し、コメントに対応して push し、Greptile の評価が 5/5 で未解決コメントがゼロ になるまで繰り返してください(最大 20 ターン)。ターンが残っている間は、途中で止めないでください。
  • 次に、会社のスキル /prcheckloop を実行し、対応可能な検証/CI の失敗に対処してください。
  • Greptile が 5/5 になるまで実行してください — Greptile が 5/5 になるまで止めないでください。すべてのテストと検証チェックが成功し、マージコンフリクトがない状態にしてください。

6. 作業を報告して引き継ぐ

  • 進行中のタスクに、実施内容、PR の URL、worktree のパス(ホームディレクトリには ~ を使用)、Greptile のスコア、チェックのステータスをコメントしてください。
  • 作成した PR ごとに pull_request の成果物を作成してください(ブランチまたはコミット自体が引き継ぎ対象の場合は、branch/commit の成果物も作成してください)。
  • タスクで PR ごとのフォローアップ(PR ごとのサブイシューなど)が必要な場合は、指示に従って作成し、リンクしてください。

厳守事項

  • 作業を絶対に失わないでください。孤立した stash を残したり、ファイルを削除したり、コミットを破棄する force-push をしたりしないでください。
  • 作成したすべてのプルリクエストの URL を必ず投稿してください。

コメント