菜单
コミット差分からタイトル・本文を生成し、PR を素早く作成できる。 トリガー: "PR を作成", "プルリクエスト作成", "create-pr", "PR 出して"
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | create-pr |
| description | コミット差分からタイトル・本文を生成し、PR を素早く作成できる。 トリガー: "PR を作成", "プルリクエスト作成", "create-pr", "PR 出して" |
| user-invocable | true |
| argument-hint | [base-branch] |
現在のブランチのコミット差分を解析し、GitHub PR をドラフト作成する。
/anvil:create-pr [base-branch]
| 引数 | 内容 |
|---|---|
| base-branch | ベースブランチ（省略時は .git_information.yaml > develop > main > master の順で決定） |
gh --version
Error: gh CLI が必要です。
インストール: https://cli.github.com/
gh auth status
Error: gh CLI が認証されていません。
実行してください: gh auth login
.git_information.yaml がプロジェクトルートに存在するか確認する。
owner / repo / default_base_branch / pr_template を取得git remote get-url origin
.git_information.yaml の生成をユーザーに提案（任意。拒否してもスキップして続行）version: "1.0"
github:
owner: "<org-or-user>" # git remote URL から抽出
repo: "<repo-name>" # git remote URL から抽出
remote_url: "<url>" # git remote get-url origin の出力
default_base_branch: main # 初回確認済みのデフォルトベースブランチ
pr_template: .github/PULL_REQUEST_TEMPLATE.md # 存在すれば記録
git branch --show-current
優先順位: 引数 > .git_information.yaml の default_base_branch > develop > main > master
git branch -a | grep -E "(develop|main|master)"
で存在確認してから決定する。
git log <base>..HEAD --oneline
Error: <base> からのコミットがありません。
変更をコミットしてから再試行してください。
注意:
git statusの状態（ステージングされた変更等）は PR 作成可否の判断に使用しない。
git log <base>..HEAD # コミット詳細（本文生成に使用）
git diff <base>...HEAD --stat # 変更ファイル統計（概要に使用）
ブランチ名から変換:
| ブランチ名パターン | PR タイトル |
|---|---|
feature/xxx-yyy | [Feature] Xxx yyy |
fix/xxx | [Fix] Xxx |
chore/xxx | [Chore] Xxx |
docs/xxx | [Docs] Xxx |
refactor/xxx | [Refactor] Xxx |
| その他 | ブランチ名をそのまま使用 |
コミット内容からタイトルを補正する（コミットメッセージが明確な場合はそちらを優先）。
PR テンプレートの適用:
.git_information.yaml の pr_template パスを確認.github/PULL_REQUEST_TEMPLATE.md を確認## 概要
{コミットメッセージ・差分から自動生成}
## 変更内容
{git diff --stat の結果を整形}
## テスト
- [ ] 動作確認済み
テンプレートが存在する場合は Read して骨格に使用し、コミット差分から内容を補完する。
コミットメッセージ（git log <base>..HEAD）や会話コンテキストから、この PR が解決する Issue 参照（Fixes #N / Closes #N / Resolves #N 等）を検出する。検出した Issue ごとに、参照先リポジトリに応じて PR 本文（概要セクション付近）に以下を追記する:
| 参照先 Issue | 追記する記法 |
|---|---|
| 同一リポジトリ | Closes #<N>（GitHub の自動クローズキーワードとして機能する） |
| 別リポジトリ | Closes https://github.com/<owner>/<repo>/issues/<N>（フル URL。自動クローズキーワードは同一リポジトリ限定のため機能しないが、追跡用リンクとして明記する） |
該当 Issue が見つからない場合はこの節をスキップする（無理に追記しない）。
現在ブランチがリモートに存在するか確認:
git ls-remote --heads origin <current-branch>
git push -u origin <current-branch>
verify_pushed.py と同様に git ls-remote でリモートを直接問い合わせる）:
git rev-parse HEAD
git ls-remote --heads origin <current-branch> # 出力の先頭列（sha）と HEAD を比較
git push origin <current-branch>
/bin/bash -c 'gh pr create --draft --base <base> --title "<title>" --body "$(cat <<'\''EOF'\''
<body>
EOF
)"'
PR 本文に含めないもの:
🤖 Generated with [Claude Code](https://claude.com/claude-code)Co-Authored-By: Claude <noreply@anthropic.com>PR URL を表示する。
PR を作成しました:
<PR URL>
ブラウザで開くか確認（AskUserQuestion）:
ブラウザで PR を開きますか？
gh pr view --webgit rev-parse --show-toplevel
で取得したリポジトリルート配下に .github/workflows/*.yml または .github/workflows/*.yaml が存在するか確認する。
Phase 4.2 で作成した PR の番号に対し、gh pr checks の --watch オプションで CI 完了までブロッキング待機する（自前のポーリングループは実装しない。gh CLI 標準機能に委譲する）:
gh pr checks <PR番号> --repo <owner>/<repo> --watch
完了報告に CI 結果を追記する:
CI: ✅ すべてのチェックが成功しました
gh pr checks <PR番号> --repo <owner>/<repo>
の出力から失敗したチェック名・詳細 URL を要約し、ユーザーに提示したうえで AskUserQuestion で対応を確認する:
CI が失敗しました:
<失敗したチェックの要約>
対応を選択してください:
- 修正する: 失敗原因を調査し、修正してから再度 push する
- このまま報告して終了: 現状の PR URL と CI 失敗内容を報告して終了する
| エラー | 対応 |
|---|---|
| gh CLI 未インストール | https://cli.github.com/ のインストール手順を案内して終了 |
| gh CLI 未認証 | gh auth login を案内して終了 |
| main/master/develop ブランチから実行 | AskUserQuestion で警告し確認（続行 or 中止） |
| コミット差分なし | エラー終了・コミットを促す |
| push 失敗 | AskUserQuestion でエラー内容を提示し対応を確認 |
| リモートブランチが stale（未 push commit あり） | ローカル HEAD を origin へ push してから続行。失敗時は AskUserQuestion で対応を確認 |
| PR 作成失敗 | エラー内容を表示して終了 |
| CI 失敗 | 失敗内容を要約して提示し、AskUserQuestion で対応（修正する / このまま報告して終了）を確認 |
msg-sys 通信基盤（常駐 Codex セッションとの Stop フック経由の非同期往復）の上で、 Codex とのレビュー依頼・所見受領・修正・完了判定を駆動する。3モード（依頼/受信/再開）を持つ。 依頼モードのトリガー句: "msg-reviewでレビュー依頼", "Codexとレビュー往復したい", "常駐Codexにレビューを依頼", "msg-reviewを実行して", "Codexセッションにコードレビューを頼みたい"。 受信モードの起動契機（トリガー句ではなくメッセージ本文の形式で成立）: Stop フックが差し戻した メッセージ本文の先頭が `[msg-review] <種別> review_id=<review_id> round=<n>` である。 再開モードのトリガー句: "msg-reviewを再開したい", "レビューの往復上限到達通知が来た、状況を確認して", "review_idの未解決所見を要約して", "msg-reviewの続きを確認したい"。
設計書から実装戦略を策定し、タスクを抽出して YAML 計画書を作成・更新する。レビュー+自動修正→commit まで一貫実行。 トリガー: "計画書作成", "計画開始", "start plan", "start planning"
計画書からタスクを選び、実装・レビュー・計画更新まで一貫して実行する。 トリガー: "実装開始", "タスク実行", "start implement"
コード・文書をレビューし、品質問題の発見から修正まで自動化できる。重大度 🔴🟡🟢 で分類。 --auto で修正まで一貫実行。code/requirement/design/plan/uxui/generic の6種別に対応。 トリガー: "レビュー", "review", "レビューして", "確認して"
GitHub Issue を軽量実装で進めるか forge の SDD フロー（start-requirements/start-design/start-plan）に委ねるかを判定するスキル。feature namespace の要否も判定する。トリガー：「このIssueをトリアージして」「Issueの進め方を判定して」「#N はどう進めるべきか判定して」
GitHub Issue の実装を準備から完了まで一貫して行う。triage の判定調査結果（仕様書・ルール・類似PR・既存コードの特定）を引き継ぎ、実装計画の策定・Issue への解決内容記載・実装・レビューまで進める。UI Issue の場合は Figma デザイン仕様書・実装設計書の作成、UI 実装、実装レビューまでカバーする。 `/anvil:triage-issue` が軽量実装と判定した Issue に対して Skill ツール経由でのみ起動される（ユーザーからの直接起動は不可）。