Menu
変更のコミットからPR作成まで一括実行する。汎用ブランチにいる場合は新規ブランチを作成。リポジトリのPRテンプレートがあれば自動適用。ユーザーが「PR作成」「プルリク」と言ったとき、または /git-workflow を実行したときに使用。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | git-workflow |
| description | 変更のコミットからPR作成まで一括実行する。汎用ブランチにいる場合は新規ブランチを作成。リポジトリのPRテンプレートがあれば自動適用。ユーザーが「PR作成」「プルリク」と言ったとき、または /git-workflow を実行したときに使用。 |
Run the full workflow from commit to PR creation in one shot.
Run these commands in parallel to gather context:
# Current branch name
git branch --show-current
# Check for changes
git status --short
# Check remote
git remote -v
現在のブランチが以下の汎用ブランチに該当するか判定する:
mainmasterdevelopdevelopmentstagingrelease汎用ブランチにいる場合:
git diff と git diff --cached で分析する<type>/<短い説明>feat, fix, refactor, chore, docs, testfeat/add-user-auth, fix/null-response-handling）※ 独自のブランチtypeを絶対に使用しないこと。必ず上記のtypeを使用すること。
# ❌ NG: custom branch type
git checkout -b db/my-feature
# ✅ OK: standardized branch type
git checkout -b feat/add-user-auth
汎用ブランチでない場合: そのまま続行する。
/commit スキルを呼び出してコミットを実行する。
/commit が失敗またはユーザーがキャンセルした場合はワークフローを停止する。
プッシュ前に現在のブランチが汎用ブランチでないことを再確認する:
CURRENT=$(git branch --show-current)
汎用ブランチ（main, master, develop, development, staging, release）の場合はプッシュを中止し、ユーザーに報告する。
安全が確認できたらリモートにプッシュする:
git push -u origin $(git branch --show-current)
リポジトリ内のPRテンプレートを Glob で検索する:
**/*pull_request_template*
見つかった場合はその内容を読み込み、テンプレートの構造に従ってPR本文を生成する。
複数見つかった場合は、以下の優先順で選択する:
.github/pull_request_template.md.github/PULL_REQUEST_TEMPLATE.md現在のブランチに既存のPRがあるか確認する:
gh pr view --json url 2>/dev/null
PRが既に存在する場合は、ユーザーに通知する。追加コミットのプッシュでPRは自動更新されるため、PR作成をスキップして終了する。
ベースブランチを検出し、PR情報を収集する:
# Detect base branch (reuse this in Step 8)
BASE_BRANCH=$(git remote show origin | grep 'HEAD branch' | awk '{print $NF}')
# Commit history against base
git log origin/${BASE_BRANCH}...HEAD --oneline
# Change summary
git diff origin/${BASE_BRANCH}...HEAD --stat
テンプレートがある場合: テンプレートの各セクションに沿って内容を埋める。
テンプレートがない場合: 以下のデフォルト形式を使用する:
## Summary
<変更の要約を1〜3個の箇条書きで>
## Changes
<変更ファイルと内容の概要>
## Test Plan
- [ ] <テストの手順やチェック項目>
PRタイトルのルール:
<type>: <description>基本的に確認不要で自動的にPRを作成する。ただし、変更が大きく複数の機能や不具合にまたがる場合のみ、PRタイトル・本文の確認を求めてよい。
ドラフト判定:
/git-workflow --draft, 「ドラフトで」「WIPで出して」等gh pr create \
--base "${BASE_BRANCH}" \
--title "<PR title>" \
--body "$(cat <<'EOF'
<PR body>
EOF
)"
作成後、PR URLをユーザーに表示する。
PRタイトル・本文・コミットメッセージの記述言語は、明示的な指定がない限り、そのリポジトリで主として使用されている言語に従う。
git log）、PR履歴、ドキュメントから主要言語を判定するgit push --force は絶対に使用しない1. Branch: main (generic branch)
2. Diff analysis → auto create branch: feat/add-password-reset
3. /commit → "feat: パスワードリセット機能を追加 @feat/add-password-reset"
4. Verify branch is not generic → push
5. PR template found → .github/pull_request_template.md
6. No existing PR → proceed
7. Collect diff and commits against base
8. gh pr create --draft --title "feat: add password reset functionality" ...
9. → https://github.com/user/repo/pull/42
1. Branch: feat/user-auth (not a generic branch)
2. Continue as-is
3. /commit → "fix: トークン検証のエッジケースを修正 @feat/user-auth"
4. Verify branch → push
5. PR already exists → notify user, skip PR creation
6. Done
1. Branch: feat/user-auth (not a generic branch)
2. Continue as-is
3. /commit → "feat: ユーザー認証を実装 @feat/user-auth"
4. Verify branch → push
5. No PR template → use default format
6. No existing PR → proceed
7. Collect diff and commits
8. gh pr create --draft --title "feat: implement user authentication" ...
9. → https://github.com/user/repo/pull/43
User: /git-workflow --no-draft
1. ... (same workflow)
8. gh pr create --title "feat: ..." ... (no --draft flag)
dev系パイプライン（dev-pr-review / dev-pr-review-resolve / dev-issue-implement / dev-issue-review）を人間の確認なしで自律的に1タスク回すオーケストレーター。main を最新化した後、レビュー系を優先する固定順で対象を探し、最初に見つかった1件を対応するスキルで処理する。途中で解決済みIssueを見つけたら理由を書いてcloseする。needs-info によるユーザー確認待ちは禁止で、必ず自律判断する。ユーザーが「devパイプライン回して」「自律で開発回して」と言ったとき、または /dev-hotl を実行したときに使用。
reviewed ラベルがついたIssueを見つけて実装する。対象Issueに WIP ラベルをつけ、git worktree で main を汚さずに開発し、テストがPASSすることを確認した上でIssueに紐づくPR（Closes
現在のリポジトリの開発Issueが妥当かどうかをレビューする。リポジトリの目的に沿っているか、調査内容・設計に問題がないかをチェックし、WebSearch や Parallel Search MCP で裏取りして本文を追記・修正する。レビュー着手時に in-review ラベルで排他し、問題なければ reviewed ラベルをつけ、あまりに見当違いな場合は理由を記述してcloseする。Issue番号・URLを引数に取るか、未レビューのIssueを自動で探す。ユーザーが「Issueレビュー」「Issueの妥当性チェック」と言ったとき、または /dev-issue-review を実行したときに使用。
reviewed ラベルがついたPRを見つけて、レビュー指摘事項を検討・修正する。着手時に in-review ラベルで排他する。妥当な指摘は worktree 上で修正し、反論がある場合は根拠をコメントに記述して、各レビュースレッドをresolveしていく。すべてのレビューをresolveしたら必ずmergeする。PR番号・URLを引数に取るか、対応待ちのPRを自動で探す。ユーザーが「レビュー指摘を解消して」「reviewedのPRを片付けて」と言ったとき、または /dev-pr-review-resolve を実行したときに使用。
in-review ラベルがついていないオープンPRを見つけてレビューする。git worktree でPRのコードをローカルに取得し、変更箇所以外との整合性・紐づくIssue通りの実装かを確認する。問題なければmerge、軽微な指摘なら修正してmerge、問題が多い場合はレビューを記述して reviewed ラベルをつけ、見当違い・修正済みのPRは理由を記述してcloseする。PR番号・URLを引数に取るか、レビュー待ちのPRを自動で探す。ユーザーが「PRレビューして回して」「レビュー待ちPRを処理して」と言ったとき、または /dev-pr-review を実行したときに使用。
ローカルにインストール済みの Codex CLI (OpenAI) を使って、別 LLM からのコードレビュー・セカンドオピニオン・意見交換を取得する。Claude が書いたコードに対して「別モデルの目」を入れたいとき、設計判断で複数モデルの見解を突き合わせたいとき、`codex` / `/codex` と言われたときに使用。