file-pr

PR の作成

作成する前に、このブランチの PR がすでに存在するか確認してください。差分をローカルでベースブランチ（通常は origin/main）と比較し、内容が目的に合っていることを確認してください。

PR のタイトルは通常コミットメッセージにもなるため、リポジトリのタイトル規則に従ってください。最近マージされた PR や Git の履歴を見て、参考にしてください。変更が重要な理由を伝える、簡潔でわかりやすいタイトルを優先してください。

BAD

❌ perf(server): negotiate permessage-deflate on the websocket

GOOD

✅ perf(server): cut websocket frame size by 70%+ with gzipping

説明文は、ユーザーの元のプロンプトに基づいて問題を簡潔に説明して始め、その後、解決策を手短に説明してください。実装項目の羅列から始めないでください。

BAD

❌ Removed implicit workspace carry-over from every "new thread" entry point (cmd+n / cmd+shift+o, sidebar v1/v2 buttons, command palette). New threads inherit only the project from context; branch, worktree, and env mode always come from the configured defaults. Deleted buildContextualThreadOptions, startNewThreadInProjectFromContext, and the v1 sidebar's seed-context machinery.

GOOD

✅ My "new worktree" default was ignored when starting new threads on existing worktrees. Super unintuitive. Now your preferences always apply.

説明文の最後に、変更を作成した公開モデル名とハーネスを、たとえば Created with <model> in <harness>. のように記載してください。変更の一部を作成したサブエージェントのモデルも含めてください。ハーネスが報告するモデル名を使用してください。モデルの識別情報が不明な場合は、モデル名を推測せず、ハーネス名のみを記載してください。

送信する前に、タイトル、説明文、引用、添付ファイルに秘密情報や個人情報が含まれていないか確認してください。

レビュー用ボットが実行されるよう、ドラフトではなく実際の PR を作成してください。GraphQL のレート制限を使い切ったために gh pr create が失敗した場合は、gh api repos/<owner>/<repo>/pulls -f title=... -f head=... -f base=... -F body=@<file> を使って REST 経由で作成してください。ユーザーから監視も依頼されている場合は、babysit-pr スキルを続けて使用してください。

ユーザーの依頼に必要でない限り、PR に追加コメントを投稿しないでください。コメントが必要な場合は、leaving-pr-comments スキルを使用してください。