| name | create-pr |
| description | 「PR を作って」「pull request を出して」要求で発動。 push → 構造化 PR 本文 (pull_request_template.md 準拠) で PR 作成 → CI 監視ループ → review thread 返信+resolve まで 1 skill で完結。 skill 間 handoff を排除し工程の取りこぼしを防ぐ。 マイルストーン非付与、 auto-merge 非使用。 |
| argument-hint | [base-branch] [--title <title>] [--no-watch] |
| disable-model-invocation | false |
| allowed-tools | Bash(git *) Bash(gh *) Bash(sleep *) Bash(python *) Bash(cat *) Read Write ScheduleWakeup TaskList TaskStop |
PR 作成 + CI 監視 + レビュー対応 (end-to-end)
/create-pr 1 コマンドで PR ライフサイクル全体を完結する skill:
push → PR 作成 → CI 監視ループ → review thread 返信 + resolve → 報告
過去 /create-pr → /watch-pr → /reply-review を別々の skill 呼び出しで連鎖していたが、 「次の skill を Skill ツールで呼べ」 という散文 handoff は LLM が実行を飛ばすと工程が抜ける (PR #496 / #505 で発生)。 本 skill は全工程を inline フェーズ として持ち、 skill 間 handoff をゼロにする。
単体利用: CI 監視のみ → /watch-pr <PR#>、 review 対応のみ → /reply-review <PR#>、 backlog 集計 → /check-review-backlog。 これらは本 skill のフェーズ 5 / 6 と同一手順の standalone 版。
自動発動条件
- 「PR を作って / 出して」「pull request を作って」「この変更で PR にして」「branch を push して PR にして」
明示呼び出し: /create-pr / /create-pr <base-branch> / /create-pr --no-watch (PR 作成のみ、 監視ループに入らない)
引数
$ARGUMENTS 空: base = dev (memory feedback_merge_caution: 通常 dev を base)<base-branch>: 明示指定 (例: main)--title <title>: title 上書き (デフォルトは最新コミット message から抽出)--no-watch: フェーズ 5/6 (CI 監視・review 対応) を skip し PR 作成で終了
制約 (memory 参照)
- マイルストーン非付与 (
feedback_pr_no_milestones): --milestone を付けない。 本文に「M1」等も書かない
- auto-merge 禁止 (
feedback_merge_caution): gh pr merge --auto 等を使わない。 マージはユーザー判断
- 本文書き換えは body-file (
feedback_pr_body_over_comments): 既存 PR 更新は gh pr edit --body-file。 新規コメント追記しない。 review thread への reply はこの制約の対象外
- --no-verify 禁止 (CLAUDE.md): hook bypass 系を使わない
- review thread の自動 reply は SAFE 系のみ: stale / Copilot style noise のみ自動 reply+resolve。 人間 reviewer・logic/security 指摘は user 判断 (フェーズ 6)
PR 本文フォーマット (重要 — テンプレート準拠必須)
PR 本文は .github/pull_request_template.md の必須セクションをすべて含むこと。 validate-pr-body CI ゲートが以下を検査し、 欠けると PR が必ず red になる (PR #505 で発生した既知バグ — 旧フォーマットはこのゲートを通らなかった):
## Test Plan セクションが存在し非空 (大文字 P。 ## Test plan は grep ^## Test Plan に不一致で fail)## Risk Level セクションでチェックボックスがちょうど 1 個 - [x]## Affected Components セクションでチェックボックス最低 1 個 - [x]
PR title は 70 文字以内、 type(scope): prefix (例 fix(g2p): ci: feat(workflow):)。
PR 本文は以下を この順 で含める (1-8 は template 準拠の必須セクション、 9-10 は create-pr 独自の value-add):
## Summary — 解決する問題 / 動機 (1-3 文)。 時系列表現 (Phase 1/2) は使わない## Affected Components — 該当を - [x]: Python / Rust / C# / C++ / Go / WASM-npm / Docker / CI-CD / Documentation## Type — Bug fix / New feature / Refactoring / Documentation / CI/CD / Dependencies## Risk Level — patch / minor / major の ちょうど 1 個を - [x] (patch=bugfix/内部, minor=新機能/非破壊, major=破壊的変更)## Contract Impact — docs/spec/*.toml 影響。 無ければ - [x] None## 変更内容 — 機能カテゴリ別の表 機能名 / 動作 / これがないと起こること の 3 列## 設計判断 — 意思決定の根拠 bullet (conservative/aggressive 判断・誤検出回避・bypass 経路・既存整合)## Test Plan — - [ ] で reviewer がそのまま使える具体的手順 (抽象表現禁止)## Checklist — Tests pass locally / No GPL-LGPL deps / Documentation updated## Related Issues — Closes #N 等、 無ければ「なし」
禁止: 時系列 (Phase/開発過程)、 マイルストーン番号、 「LLM が生成」 等の co-authored note。
実行手順
フェーズ 1: ブランチ状態確認
git status --short
git log --oneline <base>..HEAD
git diff --stat <base>..HEAD
git rev-parse --abbrev-ref HEAD
git rev-parse --abbrev-ref @{u} 2>/dev/null || echo "no-upstream"
確認: working tree、 commit が 1 つ以上 ahead か、 upstream 設定済みか。 ブランチが dev/main なら停止 (feature ブランチ必須)。
フェーズ 2: PR 本文 draft 作成
git log <base>..HEAD --pretty=format:"%h %s%n%b" で全 commit を読み、 機能カテゴリ・規模・トレードオフを抽出。 上記 10 セクションを埋めて /tmp/pr-body-<branch-slug>.md に書き出す。
フェーズ 2.5: PR 本文 self-check (validate-pr-body 先取り)
push 前に必須セクションを検証する。 1 つでも欠けたら修正してからフェーズ 3 へ:
B=/tmp/pr-body-<branch-slug>.md
for s in "## Summary" "## Affected Components" "## Type" "## Risk Level" "## Contract Impact" "## Test Plan" "## Checklist" "## Related Issues"; do
grep -qF "$s" "$B" || echo "MISSING: $s"
done
awk '/^## Risk Level/{f=1;next}/^## /{f=0}f' "$B" | grep -cE '^- \[x\] '
awk '/^## Affected Components/{f=1;next}/^## /{f=0}f' "$B" | grep -cE '^- \[x\] '
フェーズ 3: push
git push -u origin <branch-name>
フェーズ 4: PR 作成 / 既存 PR 更新
gh pr list --head <branch> --json number で既存 PR を判定:
gh pr create --base <base> --title "<title>" --body-file /tmp/pr-body-<branch-slug>.md
gh pr edit <PR#> --body-file /tmp/pr-body-<branch-slug>.md
--milestone は付けない。 PR URL / 番号を控える。
--no-watch 指定時はここで終了 (PR URL を報告)。 それ以外はフェーズ 5 へ自動継続 (確認を挟まない)。
フェーズ 5: CI 監視ループ (inline — skill handoff なし)
PR 作成後、 CI を完了まで監視する。 /watch-pr skill は呼ばず以下を本 skill 内で実行する。
5.1 ポーリング — gh pr checks <PR> --json name,bucket を取得し bucket (pass/fail/pending/skipping/cancel) を集計。
5.2 判定:
- pending ≥ 1 → 5.3 (継続監視)
- fail = 0 かつ pending = 0 → all green。 フェーズ 6 を実行し all-resolved ならフェーズ 7 で完了報告
- fail ≥ 1 → 5.4 (失敗分析) を実行後、 フェーズ 6 → フェーズ 7
5.3 継続監視 (self-pace):
- background watcher が未 arm なら arm する (
Bash を run_in_background: true で):
gh pr checks <PR> --json name,bucket を ~120s 間隔でポーリングし、 pending=0 になったら集計行を出力して exit するループ。 完了通知でループに再入する。
- fallback として
ScheduleWakeup(delaySeconds=1800, prompt="/create-pr ...<元の引数>") を設定。
- watcher 完了通知 か wakeup で 5.1 に再入。 各再入でフェーズ 6 (review) も実行する。
- 4 時間以上 pending が続く場合はループを終了し user に報告。
5.4 失敗分析 — 失敗 job のログを gh run view <run-id> --log-failed で fetch し分類:
| 分類 | signature | 推奨アクション |
|---|
| format drift | ruff cargo fmt gofmt clippy 系 | pre-commit run --all-files で修復 |
| test fail | FAILED assert panicked | テスト名を抽出して提示 |
| build error | error[E cannot find | ログ提示、 user 方針確認 |
| flake | timeout network rate limit | gh run rerun <id> --failed 提案 |
| contract drift | MISMATCH OUT OF SYNC | 該当 /check-* skill 案内 |
| validate-pr-body | Missing required section | フェーズ 2 に戻り本文修正 → gh pr edit --body-file |
分類結果と推奨アクションを user に提示。 format drift / validate-pr-body は本 skill で修正→push まで実施してよい。 test/build error は user 判断。
フェーズ 6: review thread 返信 + resolve (inline — skill handoff なし)
CI 監視の各 iteration および all-green 時に 必ず実行する。 /reply-review skill は呼ばず以下を実行:
6.1 未解決 thread 取得:
gh api graphql -f query='
query($pr: Int!) {
repository(owner: "ayutaz", name: "piper-plus") {
pullRequest(number: $pr) {
reviewThreads(first: 50) { nodes {
id isResolved
comments(first: 1) { nodes {
databaseId path body author { login } originalCommit { oid }
} }
} }
}
}
}' -F pr=<PR> --jq '.data.repository.pullRequest.reviewThreads.nodes[] | select(.isResolved==false)'
6.2 各 thread を分類:
- SAFE-stale: コメント以降に該当ファイル更新済 (
git log <originalCommit.oid>..HEAD -- <path> が非空)
- SAFE-copilot-style: Copilot bot (
author.login = copilot-pull-request-reviewer or *[bot]) + style noise (^Consider (using|renaming)\b ^Optional: \bnit: 等)
- REVIEW-human: author が人間 reviewer
- REVIEW-blocker: Copilot/CodeQL の logic / security / API 指摘 (style noise でない)
6.3 SAFE 系の自動対応 — 各 SAFE thread に REST API で reply → GraphQL で resolve:
gh api repos/ayutaz/piper-plus/pulls/<PR>/comments --method POST \
-F in_reply_to=<databaseId> -f body="対応しました (commit <hash>)。<要約>"
gh api graphql -f query='mutation($id:ID!){resolveReviewThread(input:{threadId:$id}){thread{isResolved}}}' -f id=<threadId>
6.4 REVIEW 系 — 自動 reply / resolve せず、 表形式で user に提示し判断を促す。 user が修正を指示したら: 修正 → commit → push → 該当 thread に reply (commit hash 付き) → resolve。 修正コミット後の reply+resolve を忘れないこと (PR #505 で抜けた工程)。
詳細な分類 regex と API の注意点 (node ID と databaseId の取り違え等) は reply-review/SKILL.md を参照。 手順自体は上記で完結している。
フェーズ 7: 最終報告
PR #<N>: https://github.com/ayutaz/piper-plus/pull/<N>
CI: <all green / red N 件 / pending N 件>
Review: <resolved N 件 / 自動対応 N 件 / user 判断待ち N 件>
次のアクション:
- <red なら> 失敗分類と推奨アクション
- <REVIEW 残あれば> user 判断が必要な thread
- <all green + resolved 全部> merge 判断は user に委ねる (auto-merge 禁止)
guard hook 回避
PR body 内に --no-verify 等の禁止文字列があると pre-commit / GitHub hook が誤検出することがある:
- 実行コマンドは抽象表記にする (「auto-merge」「hook bypass フラグ」等)
- 禁止文字列を含めたい場合は
--body-file 経由で渡す (引数で渡さない)
使用例
/create-pr # dev base に PR 作成 → CI 監視 → review 対応まで自動
/create-pr main # main base
/create-pr --title "fix(g2p): ..." # title 上書き
/create-pr --no-watch # PR 作成のみ (監視ループに入らない)
関連 skill
/watch-pr <PR#>: 本 skill フェーズ 5 の standalone 版 (既存 PR の CI 監視のみ)/reply-review <PR#>: 本 skill フェーズ 6 の standalone 版 (既存 PR の review 対応のみ)/check-review-backlog: 全 open PR の未解決 review 集計/loop /watch-pr <PR#>: CI を長時間継続監視 (本 skill フェーズ 5 を loop 化)/sync-docs: PR 作成前のドキュメント整合性監査 (推奨フロー: /sync-docs → /create-pr)
期待効果
- skill 間 handoff ゼロ — push / PR 作成 / CI 監視 / review 対応が 1 skill の連続フェーズ。 「次の skill を呼び忘れて工程が抜ける」 (PR #496 / #505) を構造的に防止
- PR 本文が
pull_request_template.md 準拠で validate-pr-body を必ず通る
- PR body の構造標準化、 フェーズ/マイルストーン表記の排除
- review thread の reply+resolve 漏れ防止
