メニュー
コミット済みの現在ブランチを push して GitHub PR を作成する。 PR を開きたいとき、または implement-plan / commit-changes 完了後の PR 作成引き継ぎで使う。 例: 「PR作成」「PR作って」「プルリク」。 未コミット差分がある場合は commit-changes に引き渡す。 push / gh pr create は外向きの操作なので、実行前にユーザー確認を取る。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | open-pr |
| description | コミット済みの現在ブランチを push して GitHub PR を作成する。 PR を開きたいとき、または implement-plan / commit-changes 完了後の PR 作成引き継ぎで使う。 例: 「PR作成」「PR作って」「プルリク」。 未コミット差分がある場合は commit-changes に引き渡す。 push / gh pr create は外向きの操作なので、実行前にユーザー確認を取る。 |
既に commit 済みの branch を push し、チームの期待に沿った pull request を作るスキルです。
ticket-to-plan → implement-plan → commit-changes → open-pr の最後の段階として使えます。
commit-changes に引き渡す。references/pr-body-template.md: Step 2 で repo 固有 template がない場合に読む。gh pr create の前にユーザー確認を取る。"@me" を指定する。.claude/skills/open-pr/local.SKILL.md など、repo 固有の PR skill があるか確認する。.github/pull_request_template.md がある場合は、その template を使う。git branch --show-current
git status --short
ユーザー確認後に実行してください。
git push -u origin HEAD
gh pr create --base <default-branch> --title "<title>" --body "<body>" --assignee "@me"
<チケット名> <実装内容概要> の形式で書く。<チケット名> に反映し、なければ <チケット名> は空にする。.github/pull_request_template.md がある場合は、generic body ではなく template を埋める。references/pr-body-template.md の generic body を使う。日本語で次を報告してください。
open-pr-followup が次 step であることgh pr view --json url,title
承認済みの実装プランファイルを、同一セッションの継続または新しいセッションで端から端まで実行する。 feature branch を作成し、プランの `## タスク` をテスト込みで進め、lint / test を緑にする。 リスクに応じた AI レビューを受け、commit-changes で論理コミットを作り、open-pr-followup で PR 作成後の CI と AI レビュー初回フォローまで進める。 承認済みプランを渡されて実装を始めるときに使う。 例: 「implement-plan スキルで実装して」「プランを実装して」 ticket-to-plan がプランファイルを指す実装セッションを起動したときにも使う。 これは ticket-to-plan → implement-plan → commit-changes → open-pr-followup パイプラインの実装フェーズである。
GitHub や Linear のチケット、またはユーザーの自然言語の変更依頼を十分に調査し、承認済みの実装プランファイルに変換する。 コンテキストに余裕があれば同一セッションで implement-plan による実装まで続け、コンテキスト不足が予想されるときだけ別セッションへ引き継ぐ。 ユーザーがチケットを指しただけのとき、チケットを import したとき、またはチケットなしでコーディング前に plan / 計画を求めたときに使う。 例: 「https://github.com/foo/bar/issues/42」「plan ENG-1234」「このissueの実装計画」「github.com/foo/bar/issues/42 のプラン」「ticket-to-plan で X を Y にしたい」「X に変えるプラン」 issue / PR / Linear ID または自然言語の変更依頼を参照して、すぐ実装するのではなく設計、スコープ確定、タスク分解を求める場合にも使う。
GitHub PR の未解決レビューコメントとレビュー本文を取得し、実コードを読んで must-fix / recommend-fix / recommend-skip にトリアージして修正する。 bot コメントも対象にし、解決済みスレッドは除外する。 must-fix は自動で進め、任意対応はユーザー確認後に実装する。 PR のレビュー指摘を処理したいときに使う。 例: 「PRのコメントに対応して」「レビュー対応」「PRの指摘を直して」「レビューを反映」。 対応実装後に commit / push、`update-pr-description` による PR description 更新、対象レビューコメントへの対応済み reply、thread resolve まで行う。
現在のブランチまたは指定した PR の差分を読み、変更内容に応じた動作確認手順を `.ai-loacl/verification/*.local.md` に生成または追記する。 実装完了後やレビュー / CI 対応後に、手動確認が必要な差分を確認可能なチェックリストへ変換したいときに使う。 例: 「変更分の動作確認手順を作る」「PR 123 の verification を更新する」。
PR 作成後に一定時間待ち、GitHub Actions CI と AI レビュー / レビューコメントを確認して、既存スキルへ切り出して後追い対応する。 PR 作成は open-pr、CI 失敗は GitHub plugin の gh-fix-ci、レビューコメント対応は address-pr-comments または GitHub plugin の gh-address-comments を使い、必要なら `update-pr-description` で PR 本文も同期する。 例: 「PR作って、CIとAIレビューまで見て」「PR作成後にレビュー指摘とCI失敗も対応して」「open-pr のあとしばらく待って後追いして」。 implement-plan / commit-changes 完了後に、PR 作成だけで止めずに CI と AI レビューの初回フォローまで進めたいときに使う。
`.ai-loacl/verification/*.local.md` の動作確認手順を順に案内し、 各確認の結果を `✅` または `⏭️` として記録する。 実装完了後やレビュー / CI 対応後に、作成済み verification を対話的に消化したいときに使う。 例: 「今の verification を進める」「この verification ファイルを再開する」。