Git・PR・コミット

Issue番号またはPR番号を指定するだけで、対応に必要な情報をまとめたレポートが自動生成されます。 バグ報告、機能要望、プロンプト要望など、Issue の種別を自動判定し、対応すべき内容を明確にします。 コードベースを調査して、その要望を実現するために変更が必要なファイルや影響範囲を自動で洗い出します。 実装の難易度を Low / Medium / High / Very High で判定し、工数目安を提示するため、優先度判断がしやすくなります。 既存機能との重複がないか、プロトコル変更が必要か、セキュリティ上の懸念はないかなど、多角的に対応判断を支援します。 GitHub上の Issue / PR が大量に溜まっており、どれから対応すべきかを判断したい プロジェクトマネージャーやチームリード バグ報告や機能要望の優先度を決める際に、実装難易度を知りたい開発者 新しい外部PRの内容をサッと把握して、マージ判定する必要がある レビュアー 実装前に関連コードや影響範囲を把握したい エンジニア GitHub Issue / PR 番号を入力するとトリアージレポートが自動生成されます。手順は4フェーズで実行されます。Phase 1ではghコマンドで Issue またはPRの詳細情報、コメント、レビューを取得し、テンプレートやラベルから種別（Bug / Feature / Prompt Request / Dependabot / 外部PR）を判定します。プラットフォームサポート状況も評価し、実機検証が必要な環境（Windows Bridge Server、macOS Flutter等）は experimental / best-effort として区別します。Phase 2では関連コード、既存機能との重複、影響範囲、プロトコル変更の必要性をExploreサブエージェントで並列調査します。PRの場合は変更ファイル一覧、diff、規約準拠、テスト追加の有無、セキュリティ懸念をチェックします。Phase 3では調査結果をもとに難易度を判定（工数目安：Low ~1時間、Medium 数時間、High 1日以上、Very High 数日以上）し、具体的なファイルパスと変更箇所を根拠として示します。Phase 4でレポートをマークダウン形式で出力します。

バージョン自動計算とリリース分岐を一括生成：引数（patch/minor/major）またはバージョン直指定から、セマンティックバージョニング規則に従った次バージョンを計算し、git worktree + release ブランチを自動作成します。 commandmatedev エージェント委譲でリリース準備を自動化：package.json 更新、CHANGELOG 作成、ビルド・テスト・lintの品質チェック完全自動化をエージェント経由で実施、失敗時は中断報告。 3フェーズ制御でリリース完了まで一気実行：①worktree作成と登録確認、②エージェント委譲でリリース準備、③マージ・タグ・push を制御フロー通りに順序保証。 疎通確認と段階的ロールバック対応：commandmatedev サーバー状態確認、main ブランチ最新化、worktree 登録失敗時のユーザーガイダンスを自動判定。 リリースマネージャー・リードエンジニア：手動リリースの繰り返し作業を廃止し、リリース品質を標準化したい マイクロサービス・モノレポ運用チーム：複数パッケージの並行リリースを一元管理したい CI/CD パイプライン構築者：git worktree + エージェント委譲の組み合わせパターンを参考にしたい DevOps エンジニア：リリースプロセスのボトルネック自動化が必要な組織 3フェーズ実行フロー：Phase1（worktree準備）では commandmatedev 疎通確認→現在バージョン取得→次バージョン計算（セマンティックバージョニング準拠）→main ブランチ最新化→release ブランチと worktree 作成→npm install→worktree 登録確認。Phase2（エージェント委譲）では WT ID 取得→リリースタスク（package.json version更新、package-lock.json更新、CHANGELOG追加、品質チェック：lint・tsc・test・build）を commandmatedev send で送信→エージェント完了待機。Phase3（完了処理）では main マージ・タグ作成・push・worktree 削除。前提：main 最新、commandmatedev 起動、lint/tsc/test/build 全パス状態。

GitHub プルリクエストを統一された標準フォーマットで作成・更新でき、チームのコードレビュープロセスを効率化できます。 実装内容（何が変わったか、何が良くなるか）を人間向けの自然な文章で記録し、動作確認の結果と実装メモを一箇所に集約できます。 計画や技術的意思決定は Issue に記録し、PR は実装結果のみに集中させることで、ドキュメント管理の役割分担を明確化できます。 Verification チェックリスト（対象機能の動作確認、既存機能への影響確認）により、マージ前の品質確認を可視化できます。 チーム全体で PR フォーマットを統一し、コードレビューの効率を上げたい技術リード 実装の意図と実装結果を明確に分離して管理したいエンジニアチーム Issue と PR の役割分担を徹底し、ドキュメント管理を整理したい開発チーム 実装時に気づいた補足情報や次回への申し送りを体系的に記録したいコントリビューター PR の目的は「何が変わったか」を人間がレビューできるようにすること。必須セクション: (1) closes 行（Issue リンク）、(2) 冒頭の概要（見出しなし、自然な文章で何が変わるか・何が良くなるかを記述、リスクや影響を含める）、(3) Verification（実際にブラウザ操作や API 呼び出しで確認した内容、test/build などの技術的チェックは含めない）。ルール: 計画・技術的意思決定は Issue の Plan セクションに記録して PR には書かない。必須セクション後に任意セクション（Implementation Notes、Breaking Changes、Screenshots など）を自由に追加可能。Claude が残したい実装メモは何でも記録してよい。プロパティ形式（「リスク評価:」など）は使わない。Notion タスクが存在する場合は closes 行に [TASK-{番号}](Notion URL) を追記。

コンテキストから最適なフォーマットを自動選択：障害・バグ・設計・企画など事象の種類を判定し、4F形式（事実・原因・対応・再発防止）またはSTAR形式（状況・課題・計画・成果）を自動選択して起票します。 既存Issueとの重複をチェック：起票前にキーワード検索で重複がないか確認し、既存Issue がある場合はコメント追加を提案します。 優先度・ラベルを自動判定：P0（本番障害）、P1（開発支障）、P2（改善）、ラベル（troubleshooting / planning / design / knowledge）を自動で付与します。 トラブルシューティング完了時に自動起票：Claude Codeのエージェント作業中に問題が解決したら、その知見を自動的にIssueとして記録できます。 開発チーム全体：バグ報告、設計議論、技術調査の結果を一元管理したい人 プロジェクトマネージャー：タスクの状態把握と優先順位付けを効率化したい人 テクニカルリード：解決済みのトラブルを組織的なナレッジ資産に変えたい人 AIエージェント連携開発者：自動化したトラブルシューティング結果をすぐにIssue化したい人 このスキルはコンテキスト分析、フォーマット自動選択、重複チェック、起票、プロジェクト追加の5ステップで動作します。コンテキスト分析では事象の種類（障害/バグ/企画/検討）、時制（過去/未来）、ラベル、優先度を判定します。4F形式は既発生の障害・バグ・調査結果に、STAR形式は未来の機能検討・設計議論・アップグレード計画に、フリーフォーマットはナレッジ共有・議論の記録に選択します。gh issue list コマンドで重複確認し、重複がなければ gh issue create で起票、gh project item-add でプロジェクトに追加します。トラブルシューティング自動起票ルール では、Claude Code エージェント作業中に問題が解消したら自動的に /issue を実行し、作業コンテキスト（エラー内容、原因、修正内容）から4F形式でIssueを生成し、ユーザー承認後に起票します。

バージョン番号を指定するだけで、CHANGELOGの更新、Cargo.tomlのバージョン変更、Gitタグ作成をまとめて自動実行できます。 GitHub Actionsが自動的にテスト実行、クロスプラットフォームビルド（Linux/macOS、x86_64/arm64）、GitHubリリース作成を行います。 Semantic Versioning（メジャー・マイナー・パッチ）のルールに基づいた適切なバージョン番号選定をガイドします。 Homebrewへの公開も自動化できるため、複数プラットフォームでのリリース管理が簡単になります。 Rustプロジェクトを定期的にリリースしている開発者・チーム リリース作業のミスを減らしたいメインテナー クロスプラットフォーム対応のコマンドラインツール開発者 自動化を通じてリリース頻度を高めたいプロダクトマネージャー /release vで呼び出します。mainブランチにいること、未コミット変更がないこと、CIが通っていることが前提条件です。最新タグと前回リリース以降のコミット一覧を確認し、Semantic Versioningガイド（BREAKING CHANGEでメジャー更新、feat:でマイナー更新、fix:でパッチ更新）に従ってバージョンを決定します。cargo fmt・cargo clippy・cargo testで品質チェック後、CHANGELOG.mdの[Unreleased]を[] - に変更、Cargo.tomlの[workspace.package]versionを更新し、コミット・タグ作成・プッシュします。GitHub Actionsが自動実行してテスト、Linux/macOS各アーキテクチャ用ビルド、GitHubリリース作成を行い、その後Homebrewフォーミュラの更新も可能です。

Issueからブランチ自動作成: GitHub Issue から修正内容を自動抽出し、命名規則に従ったブランチを一発生成できます。 段階的な修正案実行: Issue に記載された複数の修正案を上から順に試行し、各案の効果を検証します。 無効な修正は自動ロールバック: 修正を適用してテストした結果、効果がなければ git revert で修正前の状態に戻すため、失敗による影響を最小化できます。 恒久対応を強制: 一時ファイル削除やタイミング依存などの暫定策を排除し、本質的な原因改善のみを実施します。 修正完了後の自動PR作成: 修正完了時点で Pull Request を自動作成し、Closes #{ISSUE_NUMBER} で Issue に紐づけるため、マージ時に自動的に Issue がクローズされます。 開発チーム全体: バグ修正プロセスを標準化し、修正漏れや暫定対応の混在を防ぎたい 本番バグに迅速対応したい方: Sprint統合バグと本番緊急バグを分けて管理し、ホットフィックスを素早く対応したい 品質保証エンジニア: テスト実行と効果検証を自動化し、修正の有効性を数値で判定したい DevOpsエンジニア: CI/CDパイプラインにバグ修正フローを統合し、マージから自動デプロイまで一貫させたい バグ修正をブランチ作成から PR 作成まで実行する自動化スキルです。前提ポリシーは「安全第一」「検証必須」「可逆性」「恒久性」です。 実行手順：(1) Issue 内容を gh issue view で取得し、問題概要・再現手順・修正策候補を抽出、(2) .claude/rules/git.md に従いブランチ作成（feature_fix/{ISSUE_NUMBER}-{short-description}、base は sprint/* または main）、ベースブランチは sprint/* の存在確認後に決定、並行修正時は git worktree 利用、(3) Issue にコメント「修正着手」を記入、(4) 修正案を逐次実行ループ（最小コミット→検証→効果判定）し、無効時は git revert でロールバック、(5) 各修正後に pnpm lint --fix && pnpm type-check && pnpm test を実行して効果検証、(6) 修正完了後 PR 作成時に Closes #{ISSUE_NUMBER} で Issue に紐づけマージ時に自動close。

GitHub Issue の情報を読み込んで、自動で実装計画を生成できます 大きなタスクを実装可能な小さなサブタスクに分解し、Issue チェックリスト化できます バックエンド・フロントエンド・UI など領域別に専門エージェントに実装を委任し、タスク進捗をリアルタイム追跡できます コードレビューから修正、テスト実行、PR 作成まで一貫した品質管理プロセスを自動実行できます 「この Issue を実装して」と指示するだけで、Planning → Implementation → Review → Test → PR の全サイクルが自動で進行します Issue 駆動開発を実践し、毎回の手作業を削減したい開発チーム バックエンド・フロントエンドの並行開発を効率化したいテックリーダー コードレビューから PR マージまでの時間短縮を実現したい組織 GitHub Issue と実装作業の連動を強化したいアジャイル開発チーム ステップ 0：Issue 確認と前提チェック（gh CLI 認証確認、Issue 番号またはタスク説明を判定）。ステップ 1：planner エージェント起動、AGENT.md フォーマットに従い「実装計画」と「Issue タスクリスト」を出力依頼。ステップ 2：planner 出力の「Issue タスクリスト」を GitHub Issue body に追記（既存タスクセクション重複チェック）。ステップ 3：Issue タイトルからブランチ名自動生成、feature/[issue-name] 形式で checkout。ステップ 4：planner 計画順序に従い backend-dev → frontend-dev エージェント起動、タスク完了時に Issue チェックボックスを gh issue edit で更新。ステップ 5：reviewer エージェント起動、git diff main...HEAD でコードレビュー実施。allowed-tools：Read, Glob, Grep, Edit, Write, Bash(git/gh/pnpm/npx/jq)。

ファイルの性質に応じたコミット先の自動判別: 正本ディレクトリ（_codex, _tasks など）はmain直接、プロジェクトコードはセッションブランチ、という分離ルールを適用できます。 シンボリックリンク方式の正本管理: worktree 作成時に正本ディレクトリへのシンボリックリンクを自動生成し、すべてのセッションで同じ最新正本を参照できます。 セッション終了時の自動マージ処理: /merge コマンドで（1）セッションブランチの変更確認 → （2）正本の変更確認 → （3）マージ実行、を自動で実行できます。 worktree 作成時のセットアップ自動化: ブランチ・シンボリックリンク・CLAUDE.md の初期配置を一括処理できます。 brainbase-ui で複数の worktree を同時運用し、正本ファイルの競合を避けたい開発者 セッションごとに独立した feature ブランチを作りながら、共有ナレッジ（_codex など）は常に最新に保ちたい人 Git worktree のセットアップと mergeプロセスを標準化・自動化したいチーム ブランチ分岐とファイル共有の複雑さを「ファイル性質による分離」で整理したい人 基本原則: ファイルの性質によってコミット先を分離 — 正本ディレクトリ（全セッション共有、性質：常に最新）は main 直接、プロジェクトコード（ブランチローカル）はセッションブランチ。 正本ディレクトリ: /Users/ksato/workspace/ 配下の _codex, _tasks, _inbox, _schedules, _ops, .claude, config.yml。 Worktree構造: /Users/ksato/workspace/.worktrees/session-xxx/ に正本ディレクトリへのシンボリックリンクを配置。CLAUDE.md, brainbase-ui/, projects/ は実ファイル（ブランチローカル）。 コミットフロー: プロジェクトコードはセッションブランチ（git add brainbase-ui/ → git commit）、正本ファイルは main 直接（cd /Users/ksato/workspace → git add _codex/ .claude/ → git commit）。 /merge コマンド: (1) セッションブランチの変更確認・コミット → (2) 正本の変更確認・mainへの直接コミット（確認含む） → (3) セッションブランチを main にマージ。

複雑な変更を論理的に分割し、複数のコミットに整理して管理できます。 Conventional Commits形式（feat:、fix:、refactor:、test:、docs:）に従った見やすいコミットメッセージを自動生成できます。 コア実装、テスト、ドキュメントを別のコミットに分割し、コードレビューの質を向上させられます。 Draft PR（下書きPR）を自動作成でき、CI/CDを避けながら早期にコードをレビュー用に共有できます。 PR本文をpr-template.mdに従って自動生成し、必要な情報を漏れなく記載できます。 チーム開発でコードレビューを効果的に行いたい開発者 コミット履歴を見やすく保つ必要がある方 Draft PRで実装途中の意見をもらいたい方 /develop フェーズ7の自動フローに組み込みたい開発チーム コミットとPR作成スキルは、変更を論理的にコミット分割し、Draft PRを自動作成します。Step 1で分割計画をユーザーに提示（コア実装1モジュール1コミット、テストは実装と別、ドキュメントは1コミットにまとめる）します。Step 2でユーザー承認後にコミットを実行、Step 3でgh pr create --draftでDraft PRを作成します。PR本文はpr-template.mdに従い、CLAUDE.mdに言語・フォーマット指定がある場合はそれに従います。Step 4で作成されたPRのURLをユーザーに共有します。破壊的操作（force push、reset --hard）は絶対に行いません。単体使用または/developの自動呼び出し両対応です。

PR本文の形式チェックと修正を自動化できるため、手作業でのテンプレート確認を省略できます review threadの状況確認とCI失敗の検出を自動で行うため、見落としやすい指摘や失敗に気づきやすくなります ブランチ名からバージョン情報を読み取り、package.json・CHANGELOG.mdとの整合性を自動確認・修正できるため、リリース時のバージョン不一致を防げます dry-run モードで実行確認してから本実行できるため、間違った修正による失敗を事前に防ぐことができます live monitor機能で遅延到着のレビュー指摘を継続的に拾えるため、マージ直前の指摘漏れを防ぐことができます GitHub CLI と PowerShellが使える環境でPR修正を頻繁に行う開発者 リリース時のバージョン管理を自動化したい人 CI失敗時の修正と確認をまとめて行いたい人 PR修正後のhandoff生成まで一気に進めたい人 PR修正スキルは実行前の必須ガード、バージョン整合チェック、PR対象決定を段階的に実行します。ガードではgit branch・gh pr viewで現ブランチとPR番号を確認、baseRefNameがmain確認、headRefNameと現ブランチの一致を検証します。バージョン整合チェックはブランチ名がfeature/vX.Y.Z形式の場合のみ実行し、package.json・CHANGELOG.mdの期待バージョン検査、不整合時の自動更新（version更新、CHANGELOG.mdに新セクション追加）を行います。実行時は最初のdry-run実行時に-DryRunフラグ、-SleepSeconds 0、-RequiredZeroStreak 1を指定します。実行スクリプトはscripts/pr-fix/run-pr-fix.ps1、参照ファイルは.github/PULL_REQUEST_TEMPLATE.md・.github/workflows/ci.yml・package.jsonです。

GitHub PR を素早く作成でき、適切なラベル（feature、bug、refactoring、documentation、chore、AI、test）を自動または手動で付与します。 PR の一覧表示、詳細表示、ブラウザでの確認、ブランチのチェックアウトなどを効率的に行えます。 PR に寄せられたコメント（会話コメント・インラインレビューコメント）を一括取得し、複数のコメントを見落とさず確認できます。 マージ前に VRT（ビジュアルリグレッションテスト）の実行状況を確認し、UI 変更の意図的性を検証できます。 他リポジトリへの誤操作を防ぎ、sh1ma/blog リポジトリのみで安全に PR 管理できます。 GitHub を使用したチーム開発を行っており、PR ワークフローを効率化したい開発者 PR 作成時に必要なラベル付けやテンプレート遵守を自動化したい方 複数の PR コメント・レビュー指摘を見落とさず、確認漏れを防ぎたい方 UI 変更を含む PR で VRT スナップショット更新の判断を適切に行いたい方 このスキルは sh1ma/blog リポジトリのみを対象とし、他リポジトリへの --repo 指定は禁止です。主要コマンドは以下：gh pr list で PR 一覧を状態・author・assignee・ラベルでフィルタ表示。gh pr view 123 で PR #123 の詳細を表示し、--comments で会話コメントを、--json comments で詳細 JSON を取得。gh pr checkout 123 で PR のブランチをチェックアウト。gh pr create で新規 PR を作成する際、.github/pull_request_template.md テンプレートを遵守し、「概要」「変更内容」「関連Issue」「テスト項目」「VRT設定」「スクリーンショット」「備考」の各セクションを記入。ラベルは必ず feature・bug・refactoring・documentation・chore・AI・test から 1 つ以上を指定。複数ラベルは --label "feature" --label "AI" で付与。PR 作成後は自動で VRT が実行され、UI 変更時には R2 からベースライン（main ブランチ最新スナップショット）と比較されます。

ファイルの変更をワンコマンドで検出し、自動でコミットメッセージを生成してコミット・プッシュまで完了できます。 git pull → git status → メッセージ自動生成 → git add -A → git commit → git push の全ステップを一括実行します。 変更内容から40文字以内の簡潔な日本語コミットメッセージを自動生成するため、毎回メッセージを考える手間が不要です。 変更がない場合は自動判定して「変更なし」と返すため、無駄なコミットを防げます。 Gitの操作を頻繁に行う開発者 コミットメッセージを短時間で済ませたい人 日々の小さな変更を素早く記録したい人 Git操作の手間を最小化したい人 1. git pull でリモートの最新を取得、2. git status で変更を確認、3. 変更がなければ「変更なし」と伝えて終了、4. 変更内容から40文字以内の日本語コミットメッセージを自動生成、5. git add -A で全変更をステージング、6. git commit -m "" でコミット、7. git push でリモートにプッシュ。ルールは、コミットメッセージは必ず40文字以内、日本語で簡潔に変更内容を要約、絵文字は使わない、ユーザーに確認せず即実行する。

差分から自動的に単一Issueを作成: 現在の変更内容を解析し、自動的にプロジェクト用のIssueを1つ作成して登録できます。 ファイル単位・機能単位で細かくコミット分割: 大きな変更を自動的に複数のコミットに分け、巻き戻しやすい粒度で履歴を管理できます。 Gitフロー全体を自動実行: ブランチ作成、複数コミット、プッシュ、PR作成、マージまで、手動操作なしに一気に実行できます。 Issue登録時の自動設定: マイルストーン取得・ステータス設定（Done）・日付設定など、プロジェクト管理の手順を自動化します。 各コミットにIssue番号を自動付与: すべてのコミットメッセージにIssue番号を含めるため、変更追跡と関連づけが簡単になります。 小〜中規模な機能改善を素早くリリースしたい開発者 複数の小さな変更を細粒度で管理し、巻き戻しやすいようにしたいチーム Issue作成、コミット、PR、マージの定型手順を自動化したい組織 単一の機能改善で、Issue＋コミット＋Gitフローを一気に処理したい方 差分からIssueを作成してプロジェクトに登録し、ファイル単位・機能単位で複数のコミットに分けてGitフローを実行する省略形スキルです。サブイシューは作成せず1つのIssueのみ作成し、ファイル単位・機能単位で複数コミットを行います。フロー：analyze-diff→project-mgmt→複数コミット→repo-flowです。ワークフローはフェーズ1（analyze-diffで現在の差分を解析してタスク分割案を作成）、フェーズ2（project-mgmtで単一Issueを作成、マイルストーン取得・設定、プロジェクト追加、ステータス設定、日付設定）、フェーズ3（developからfeature/-ブランチを作成）、フェーズ4（ファイル単位・機能単位で複数のコミットに分け、すべてのコミットメッセージにIssue番号を含める）、フェーズ5（repo-flowでプッシュ、PR作成、developへマージ、クリーンアップ）で構成されています。reg-commitとの違いは、reg-commitは親Issue+サブイシュー構造で大規模変更に対応し、reg-commit-flatは単一Issue＋複数コミットで小〜中規模変更に対応する点です。

実装内容をレビュアーが理解しやすいプルリクエスト説明文を自動生成でき、レビュー効率が向上します。 動作確認（Verification）チェックリストを備えた標準フォーマットで、実装の品質保証が統一されます。 技術的な実装メモやBreaking Changes、スクリーンショットなどを自由に追加でき、関連する全情報が一箇所に集約されます。 Issue番号やNotionタスク番号を自動でリンクでき、プロジェクト管理との連携が効率化されます。 計画や技術的な意思決定の記録をIssueに統一することで、PR/Issue の役割分担が明確になります。 開発チーム全体でコードレビュープロセスを標準化したい人 GitHub上でプロジェクト管理とコード実装を連携させたい人 チーム内でPRの品質と可読性を高めたい人 Notion などの外部タスク管理ツールを使用している人 GitHubプルリクエストの標準テンプレートを提供します。必須セクションは「closes行（Issue/Notionリンク）」「冒頭の概要（見出しなし、何が変わるか自然な文章で記述）」「Verification（ブラウザ操作やAPI呼び出しで実際に確認した内容）」です。Verification後は任意セクション（Implementation Notes、Breaking Changes、Screenshots など）を自由に追加可能。プロパティ形式は使用禁止、計画や技術的意思決定はIssueのPlanセクションに記載します。実装メモは何でも記述OK。Notionタスク存在時はcloses行に[TASK-{番号}](Notion URL)を追記します。

Claude Code Actionによる自動レビューコメントを確認し、修正が必要な指摘は半自動で修正案を提示、問題なければそのままマージできます。 PR の状態（Draft状態、CI未通過、base branch同期の確認）を一括確認して、マージ前に必要な前提条件をクリアできます。 base branch に差分がある場合は rebase + push を自動実行し、その後 CI 再実行時に既存レビューコメント（review comment）を先行確認して効率化できます。 Claude Auto Review のステータス（pending/in_progress/success/failure）をポーリング監視し、完了まで待機または即座に進行するか判定できます。 レビューコメント取得・分析、修正案提示、マージ実行まで、1回の呼び出しで 1 つの PR を完全に処理できます。 GitHub での Pull Request レビュー・マージプロセスを自動化・効率化したい開発チーム Claude Code Action によるAI自動レビューを導入済みで、その結果を素早く確認したいエンジニア base branch 同期や CI 再実行時のレビューコメント確認を手動で行うのが煩雑に感じているリードディベロッパー 複数 PR を同時管理していて、ボトルネックを解決したい組織 このスキルは Claude Code Action による自動レビュー結果の確認と PR マージを半自動化するワークフローです。 対象 PR の決定：引数で PR 番号を指定、または現在のブランチに PR がある場合はそれを対象、どちらもない場合は Ready 状態の PR を一覧表示してユーザーに選択させる（1回の呼び出しで処理するのは必ず 1 つのみ）。 Step 1: PR状態確認 + base branch同期：gh pr view で PR の状態（Draft/CI 未通過等）を確認、git fetch で base branch との差分を確認。Draft は解除するか確認、CI 未通過は待機するか確認。base branch 差分がある場合は rebase + push を実行し、既存レビューコメントを先行確認する。 Step 2: Claude Auto Review 完了確認：gh pr checks で「Claude Auto Review」ステータスを確認、pending/in_progress なら 20～30秒間隔でポーリング待機、success/failure なら次へ。 Step 3: レビューコメント取得・分析：gh api で claude[bot] の全レビュー情報を取得、Review コメント（置き入れ、suggest 等）を分析。 Step 4: 対応判定と修正：APPROVED なら次へ、CHANGES_REQUESTED なら修正案を提示してユーザーに対応させる。 Step 5: マージ実行：gh pr merge で指定マージ戦略（squash/rebase/merge commit）に基づいてマージ完了。

Conventional Commits 規約に基づいたコミットメッセージの書き方を確認できます。 feat:（新機能）、fix:（バグ修正）、chore:（内部改善）、ci:（CI設定）など、適切なプレフィックスを状況に応じて選べるようになります。 正しいプレフィックスでコミットするだけで、自動生成される CHANGELOG（変更履歴）に機能や修正が自動で掲載される仕組みになり、リリース時の情報整理が楽になります。 スコープ（例：feat(logs):）を追加して、変更箇所をより詳しく伝えられます。 プロジェクトで統一されたコミットメッセージルールを守りたい開発者 CHANGELOG を自動生成する仕組みを構築しているプロジェクトチーム ユーザー向けリリースノートを効率的に作成したい開発リード コミット履歴から機能変更と内部改善を明確に区分したい組織 本プロジェクトでは Conventional Commits を採用し、GoReleaser による自動 CHANGELOG 生成に対応しています。ユーザー向けプレフィックスは feat:（新しいCLIコマンドや機能）、fix:（ユーザーが遭遇するバグ）、BREAKING CHANGE: （既存動作の変更）で CHANGELOG に含まれ、内部向けは ci:（CI設定・linter）、chore:（開発ツール・依存更新）、docs:、refactor:、test:、style:、perf:、build: で CHANGELOG に含まれません。判定基準として feat と chore は「ユーザー向け機能か開発者向けツールか」、fix と ci は「ユーザーが遭遇するバグか CI パイプライン問題か」で区別します。スコープはオプションで追加可能（例：feat(logs):）です。

プルリクエストの作成・管理を高速化 — ghコマンドでPRの作成、確認、編集をターミナルから一括実行でき、ブラウザを往復する手間が減ります。 コンフリクト（競合）の解決フロー — マージ時に発生したコードの競合を、ステップバイステップで確認・解決し、安全にマージできます。 Issue管理も同じツールで統一 — Issue作成・確認・クローズもコマンドラインから行え、GitHub操作全体をスムーズに。 PR情報をJSON形式で取得・確認 — マージ可能状態、レビューステータス、CI/CDの状態などを詳細に確認し、問題の早期発見ができます。 実装からマージまでの実践的な流れ — ブランチ作成→コミット→PR作成→マージまで、実例付きで全プロセスを標準化できます。 開発エンジニア — 毎日複数のPRを作成・レビューする人で、GitHub操作を高速化したい方。 チームリード — チームメンバーのPRレビューを効率化し、マージ作業をスムーズにしたい方。 Git初心者からの脱却を目指す人 — GUIではなくコマンドラインで自信を持ってGitHub操作をしたい方。 コンフリクト解決に不安がある人 — マージ時のコンフリクトに直面したとき、体系的に対応できるようになりたい方。 GitHub CLIの認証確認（gh auth status）から始まり、プルリクエストの作成・確認・編集（タイトル、説明、ラベル、レビュアー追加）の操作方法を網羅します。コンフリクト解決は4ステップで構成：(1)マージ可能状態の確認、(2)mainブランチのマージ、(3)競合ファイルの特定、(4)マーカー削除後のコミット・プッシュ。Issue操作（作成・一覧・確認・クローズ）も含まれます。JSONクエリを使用したPR情報取得（title、body、state、mergeable、files、reviewDecision、statusCheckRollup）、および「PR作成からマージまで」と「コンフリクト解決」の2つの実践例を提供し、実装フローを具体的に示します。

PR番号とJiraチケット番号を指定するだけで、マージ・ブランチ削除・ローカル最新化・チケット完了をまとめて実行できます。 PR をSquash形式でマージし、自動的にリモートブランチを削除するので、手動でのクリーンアップ作業が不要になります。 ローカルbranchを最新化（main pullして古いbranchを削除）し、開発環境を常に清潔に保てます。 Jiraチケットのステータスを「完了」に遷移させるので、プロジェクト管理とコード変更が同期します。 複数の手作業を1コマンドで完結させるため、作業ミス（チケット完了忘れなど）を防げます。 PR マージ後の「Jiraチケット完了し忘れ」を防ぎたい開発者 ローカルブランチの削除漏れで環境が汚れるのを避けたい人 複数の手作業ステップを一気に終わらせて時間を短縮したい人 Jiraとコード管理を密接に連携させたいチーム 引数は[PR番号]と[Jiraチケット番号]の2つで、実行順序は厳密に決まっています。Step 1 でgh pr merge $0 --squash --delete-branchでPRをSquashマージしリモートブランチ削除、Step 2 でgit checkout main && git pullでローカル最新化し、git branch -vv | grep '[origin/.*: gone]' | awk '{print $1}' | xargs -r git branch -dで gone状態のローカルブランチを削除します。Step 3 ではJiraチケット$1のステータを「完了」に遷移させ、getTransitionsForJiraIssueで利用可能な遷移を取得、「完了」遷移のIDを特定、transitionJiraIssueで遷移を実行します。cloudIdはignission.atlassian.netを使用します。完了後は「PR #$0 マージ完了」「$1 → 完了」「ブランチ: main (最新)」を報告します。

コミットメッセージを統一フォーマット（feat/fix/docs/refactorなど）で記述でき、変更履歴が一目瞭然になります。 プルリクエスト作成時に標準テンプレート（概要・変更内容・テスト方法）を使用し、レビュアーがコンテキストを素早く把握できます。 feature/song-search のようなブランチ命名規則に従うことで、どの機能・修正・リファクタなのかが明確になります。 コミット前に自動的にLintやビルドチェックを実行する習慣が定着し、品質の低いコードがマージされるのを防げます。 チーム全体のGit運用が統一され、機密情報の誤コミットや不適切なコミットメッセージが減少します。 チーム開発でGitワークフローを統一したい開発リーダー コミットメッセージの質を上げたい個人開発者やチーム プルリクエストレビューを効率化したいコード審査者 プロジェクト初期段階でGitルールを定めたい開発チーム コミットメッセージは: 形式で、typeは7種類（feat/fix/docs/style/refactor/test/chore）のいずれかです。コミット作成は3ステップ：(1)git status/git diffで変更確認、(2)git add で特定ファイルをステージング、(3)git commit -mでメッセージ入力。プルリクエスト作成時はタイトルにコミットメッセージ規約を使用し、本文には概要・変更内容・テスト方法・スクリーンショット・関連Issue番号を記載します。ブランチ命名規則はfeature/、fix/、docs/、refactor/です。注意事項として、コミット前にpnpm lint (FE) や dotnet build (BE) を実行、機密情報をコミットしない、大きな変更は小さなコミットに分割、論理的な単位でコミットすることが重要です。

GitHubのIssue番号またはテキスト指示から自動的に要件を読み取り、実装計画を立てて、ブランチ作成・コード変更までを一括実行できます。 gh issue viewでIssue内容を取得し、タイトル・本文・ラベルから必要な作業を自動判別します。 関連ファイルを自動調査し、既存実装パターンを確認した上で、変更内容・影響範囲を明確に提示してからコード変更を開始するため、実装ミスを防げます。 コード変更完了後、自動的にlint・テスト・コミット・PRまでの次のアクションを確認し、開発フローを途切れさせません。 GitHub Issueベースのチーム開発で、毎回のブランチ作成・計画立案を自動化したい開発者。 Issue内容の読解から実装完了まで、手作業の手間を減らしたいエンジニア。 実装前に「本当にこの理解で合ってる？」と確認したい、慎重な開発スタイルの人。 複数ファイルの変更が必要な機能実装を、見落としなく完了したい人。 ワークフロー5ステップ：(1)入力解析＝Issue番号ならgh issue view取得・要件整理・ユーザー確認、テキスト指示ならそのまま要件化、引数なしはAskUserQuestion；(2)ブランチ作成＝git status/git branch --show-current確認、/形式命名、既存フィーチャーブランチなら継続確認；(3)実装計画＝コードベース調査（Glob/Grep/Read）、関連ファイル特定、既存パターン把握、影響範囲確認、Markdown形式で変更内容・影響範囲提示、AskUserQuestion で「実装」「修正」「キャンセル」確認（承認なしにコード変更しない）；(4)実装＝計画に従いEdit/Write実行、進捗報告、必要時ユーザー相談；(5)動作確認＝CLAUDE.md「検証」セクションコマンド実行、エラー時その場で修正；(6)完了報告＝ブランチ・変更ファイル報告、同レスポンス内でAskUserQuestion「lint・コミット・PR一括」「個別lint」「追加変更」。注意：.env読取禁止、gh未認証時エラー表示中断、実装計画未承認でコード変更開始禁止。