ワンクリックで
create-pr
// 「PR を作って」「pull request を出して」要求で発動。 push → 構造化 PR 本文 (pull_request_template.md 準拠) で PR 作成 → CI 監視ループ → review thread 返信+resolve まで 1 skill で完結。 skill 間 handoff を排除し工程の取りこぼしを防ぐ。 マイルストーン非付与、 auto-merge 非使用。
// 「PR を作って」「pull request を出して」要求で発動。 push → 構造化 PR 本文 (pull_request_template.md 準拠) で PR 作成 → CI 監視ループ → review thread 返信+resolve まで 1 skill で完結。 skill 間 handoff を排除し工程の取りこぼしを防ぐ。 マイルストーン非付与、 auto-merge 非使用。
| 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 |
/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 版。
明示呼び出し: /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 作成で終了feedback_pr_no_milestones): --milestone を付けない。 本文に「M1」等も書かないfeedback_merge_caution): gh pr merge --auto 等を使わない。 マージはユーザー判断feedback_pr_body_over_comments): 既存 PR 更新は gh pr edit --body-file。 新規コメント追記しない。 review thread への reply はこの制約の対象外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。
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 ブランチ必須)。
git log <base>..HEAD --pretty=format:"%h %s%n%b" で全 commit を読み、 機能カテゴリ・規模・トレードオフを抽出。 上記 10 セクションを埋めて /tmp/pr-body-<branch-slug>.md に書き出す。
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
# Risk Level は [x] ちょうど 1 個であること (出力が 1 でなければ fail)
awk '/^## Risk Level/{f=1;next}/^## /{f=0}f' "$B" | grep -cE '^- \[x\] '
# Affected Components は [x] 1 個以上
awk '/^## Affected Components/{f=1;next}/^## /{f=0}f' "$B" | grep -cE '^- \[x\] '
git push -u origin <branch-name> # upstream 未設定時。 設定済みなら git push
gh pr list --head <branch> --json number で既存 PR を判定:
# 新規
gh pr create --base <base> --title "<title>" --body-file /tmp/pr-body-<branch-slug>.md
# 既存 (本ブランチに PR があれば本文置換)
gh pr edit <PR#> --body-file /tmp/pr-body-<branch-slug>.md
--milestone は付けない。 PR URL / 番号を控える。
--no-watch 指定時はここで終了 (PR URL を報告)。 それ以外はフェーズ 5 へ自動継続 (確認を挟まない)。
PR 作成後、 CI を完了まで監視する。 /watch-pr skill は呼ばず以下を本 skill 内で実行する。
5.1 ポーリング — gh pr checks <PR> --json name,bucket を取得し bucket (pass/fail/pending/skipping/cancel) を集計。
5.2 判定:
5.3 継続監視 (self-pace):
Bash を run_in_background: true で):
gh pr checks <PR> --json name,bucket を ~120s 間隔でポーリングし、 pending=0 になったら集計行を出力して exit するループ。 完了通知でループに再入する。ScheduleWakeup(delaySeconds=1800, prompt="/create-pr ...<元の引数>") を設定。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 判断。
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 を分類:
git log <originalCommit.oid>..HEAD -- <path> が非空)author.login = copilot-pull-request-reviewer or *[bot]) + style noise (^Consider (using|renaming)\b ^Optional: \bnit: 等)6.3 SAFE 系の自動対応 — 各 SAFE thread に REST API で reply → GraphQL で resolve:
# reply (in_reply_to は REST の comment databaseId)
gh api repos/ayutaz/piper-plus/pulls/<PR>/comments --method POST \
-F in_reply_to=<databaseId> -f body="対応しました (commit <hash>)。<要約>"
# resolve (threadId は GraphQL node ID)
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を参照。 手順自体は上記で完結している。
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 禁止)
PR body 内に --no-verify 等の禁止文字列があると pre-commit / GitHub hook が誤検出することがある:
--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 作成のみ (監視ループに入らない)
/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)pull_request_template.md 準拠で validate-pr-body を必ず通るORT / openjtalk / ruff のような cross-runtime に canonical sync が必要な依存関係を 1 コマンドで bump する read-mostly skill。 既存の `check_ort_versions.py` / `check_openjtalk_version_sync.py` / `check_ruff_version_sync.py` が drift 検出後に「どこを何バージョンに上げる」を提示する逆方向 helper。
9 パッケージ × 5 レジストリの version bump と関連ファイル更新 (Cargo.lock / package-lock.json / Swift checksum / CHANGELOG 昇格) を 1 コマンドで適用案にする read-mostly skill。`release-prep` (確認用) の続きに呼び、 実 bump 差分の markdown 提案 + 順序付き publish ガイドを生成する。
学習済み Lightning checkpoint (.ckpt) を ONNX export → sanity check → RTF benchmark → HuggingFace upload まで連鎖実行する read-mostly skill。 export 仕様 (FP16 / EMA / emb_lang unify / opset 15) を `docs/spec/onnx-export-contract.toml` から取得し、 全 7 ランタイムでの load 可否を gate する。
PR レビューコメントへの対応 / review thread の resolve / Copilot や human reviewer のコメントに返信 する文脈で発動。修正コミット後に呼ぶと、各 unresolved thread に対して返信本文を生成し thread を resolve する。`--stale-check` で「コメント以降に該当ファイルが更新済」を自動 flag、`--skip-copilot-style` で Copilot 定型ノイズ regex 除外、`--dry-run` で計画のみ表示、`--auto-safe` で stale + Copilot ノイズ category のみ自動 reply + resolve (人間 reviewer / 非 stale はユーザ判断)。
`.claude/skills/*/SKILL.md` の frontmatter / referenced script 実在 / trigger 衝突 / `.claude/hooks/*.sh` の executable+shebang を検査する meta-skill。 メタワークフロー監査で「hook script rot が最高リスク」と判明したため、 commit 前または skill 編集後に呼んで health check を行う。
CI workflow の最近 run を集計し、 failure を「flake / drift / env / test bug」に自動分類する skill。 既存 `/watch-pr <PR>` の workflow-level 拡張。 引数なしで全 workflow の health check、 `--workflow <name>` で個別 workflow の最近失敗パターンを抽出。 docker-build 45% / go-ci 14% / csharp-ci 13% のような chronic flake を可視化する。