菜单
フィーチャーブランチをベースブランチ（main/master/developなど）にリベースし、リモートに反映するまでを1タスクとして実行するワークフローを提供します。「リベースして」「mainを取り込んで」「mainに追従して」「rebase」といった依頼、またはフィーチャーブランチがベースブランチから乖離している場合に使用します。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | x-rebasing-feature-branch |
| description | フィーチャーブランチをベースブランチ（main/master/developなど）にリベースし、リモートに反映するまでを1タスクとして実行するワークフローを提供します。「リベースして」「mainを取り込んで」「mainに追従して」「rebase」といった依頼、またはフィーチャーブランチがベースブランチから乖離している場合に使用します。 |
| allowed-tools | ["Bash","Read","Glob","Grep","AskUserQuestion","TaskCreate","TaskUpdate","TaskList"] |
git status -sbでローカルとリモートが同期（ahead/behindなし）するまでは完了したとみなしません。Successfully rebasedの表示やワーキングツリーのクリーン化は途中経過にすぎません。
ブランチ確定→状態確認→ベースブランチ最新化→ローカルrebase→[コンフリクト解消ループ→]リモートpush→完了確認
フローを開始する前に、全ステップをTaskCreateで登録します。各ステップを開始するときTaskUpdateでin_progressへ、完了したときcompletedへ更新します。
| # | subject | blockedBy |
|---|---|---|
| 1 | Step 1: ブランチを確定する | — |
| 2 | Step 2: ベースブランチを最新化する | 1 |
| 3 | Step 3: フィーチャーブランチに戻ってリベースする | 2 |
| 4 | Step 4: リモートにプッシュする | 3 |
| 5 | Step 5: 完了確認 | 4 |
git branch --show-current
フィーチャーブランチにいることを確認し、ブランチ名をFEATURE_BRANCHとして記憶します。
ユーザーの最初の指示にブランチ名が含まれている場合（例:「developを取り込んで」「stagingにrebaseして」）は、そのブランチ名を提示してAskUserQuestionで確認します（yesまたは正しいブランチ名を入力してもらいます）。
{
"question": "ベースブランチは「<検出したブランチ名>」でよいですか？別のブランチの場合は入力してください。",
"options": [
{ "label": "はい", "description": "<検出したブランチ名> にリベースします" }
]
}
含まれていない場合は、利用可能なローカルブランチを確認してからAskUserQuestionで確認します。
git branch | grep -v '^\*'
{
"question": "リベース先のベースブランチはどれですか？",
"options": [
{ "label": "main", "description": "mainブランチにリベースします" },
{ "label": "develop", "description": "developブランチにリベースします" },
{ "label": "staging", "description": "stagingブランチにリベースします" }
]
}
ブランチ一覧に応じてoptionsを調整し（存在するブランチのみ提示）、ユーザーが選択した値をBASE_BRANCHとして記憶します。
FEATURE_BRANCHとBASE_BRANCHの両方が確定したら次に進みます。
git status --short
変更がある場合はAskUserQuestionで対応を選択してもらいます。
{
"question": "未コミットの変更があります。どうしますか？",
"options": [
{ "label": "コミットする", "description": "変更をコミットしてからリベースします" },
{ "label": "スタッシュする", "description": "git stashで退避し、リベース後に復元します" }
]
}
ワーキングツリーがクリーンになってから次に進みます。
Step 1で確定したBASE_BRANCHを使います。
git checkout <BASE_BRANCH> && git pull origin <BASE_BRANCH>
Step 1で記憶したFEATURE_BRANCHとBASE_BRANCHを使います。
git checkout <FEATURE_BRANCH> && git rebase <BASE_BRANCH>
コンフリクトが発生した場合は「コンフリクト発生時」セクションに進みます。発生しなかった場合はStep 4に進みます。
--force-with-leaseを使うことで、他の人がプッシュした変更を誤って上書きするリスクを軽減します。
git push --force-with-lease origin <FEATURE_BRANCH>
git fetch origin <FEATURE_BRANCH> && git status -sb
期待される出力は## <FEATURE_BRANCH>...origin/<FEATURE_BRANCH>のみ（ahead/behindがゼロの状態）です。aheadが残っている場合はpushが失敗または不完全なので原因を調査して再pushします。behindが残っている場合は他の誰かが先にpushしているので、ユーザーに状況を報告して指示を仰ぎます。
完了確認に成功したら、ユーザーに以下を簡潔に報告して終了します。
リベース中にコンフリクトが発生した場合は、以下の手順A〜Dを繰り返します。すべて解消できてSuccessfully rebased and updated <branch>が表示されたら、メインフローのStep 4に戻ります。
コンフリクトが発生したファイルを一覧で取得します。
git diff --name-only --diff-filter=U
各ファイルをReadツールで開いて、<<<<<<<〜>>>>>>>のマーカーを全箇所読んでください。この読み取りはスキップ禁止です。merge.conflictstyle diff3が設定されている場合は3区画になります。
| マーカー範囲 | 内容 |
|---|---|
<<<<<<< HEAD〜` | |
| ` | |
=======〜>>>>>>> | フィーチャーブランチ側の変更内容 |
どちらかにしか存在しない行・型定義・import・設定項目がないかも確認します。
まずmergirafが利用可能か確認します。
command -v mergiraf
インストールされていなければこの手順をスキップして手順Cに進みます。
インストールされていれば、コンフリクトが発生しているファイルを確認し、1ファイルずつmergiraf solveを実行します。
git diff --name-only --diff-filter=U
mergiraf solve <ファイルパス>
終了コードで次のアクションを判断します（xargsパイプラインでは終了コードがxargsのものになるため、1ファイルずつ処理します）。
| 終了コード | 意味 | 次のアクション |
|---|---|---|
| 0 | 全コンフリクトを解消 | mergirafの変更内容を報告（後述）→git add |
| 2 | 一部のコンフリクトのみ解消 | mergirafの変更内容を報告（後述）→残りを手順Cで手動解消後にgit add |
| 1 | エラー（diff3が設定されていない・対応していないフォーマットなど） | そのファイルは手順Cへスキップ（mergirafによる変更はなし） |
終了コードが0または2のファイルは、git addまたは手順Cの手動解消へ進む前に、mergiraf review <マージID>を実行してユーザーへ変更内容を報告します。
mergiraf review <マージID>
報告には次を含めます。
すべてのファイルを処理したあと、残マーカーがないことを確認できれば手順Dへ進みます。
git diff --name-only --diff-filter=U
mergirafで解消できなかったファイルを手動で解消します。各コンフリクト箇所の内容と解消後のコード例を提示してAskUserQuestionで承認を得ます。
[!WARNING]
--ours/--theirsは、手順Aの確認で相手側に固有の変更が一切ないと確認できた場合のみ使用できます。確認を省くと有効な変更を無言で破棄します。--skipは、手順Aの確認でフィーチャーブランチ側（=======〜>>>>>>>）にHEADに含まれない変更が一切ないと判断できた場合のみ使用できます。そうでない場合は--oursで解消して--continueするのが正しい手順です。
{
"question": "<ファイル名> のコンフリクトをどのように解消しますか？\n\n[ベースブランチ側]\n<HEAD側の変更内容>\n\n[フィーチャーブランチ側]\n<フィーチャーブランチ側の変更内容>",
"options": [
{ "label": "両方取り込む", "description": "両方の変更をマージします（解消後のコードを提示して再確認します）" },
{ "label": "ベースブランチ側を優先", "description": "HEADの変更を採用し、フィーチャーブランチ側を破棄します。手順Aでフィーチャーブランチ側に固有の変更がないと確認済みの場合のみ選択できます" },
{ "label": "フィーチャーブランチ側を優先", "description": "フィーチャーブランチの変更を採用し、ベースブランチ側を破棄します。手順AでHEAD側に固有の変更がないと確認済みの場合のみ選択できます" },
{ "label": "このコミットをスキップ（--skip）", "description": "このコミット全体を履歴から削除します。手順Aでフィーチャーブランチ側にHEADに含まれない変更が一切ないと確認済みの場合のみ選択できます" }
]
}
承認を得たら、コードを修正してコンフリクトマーカーを除去します。リンターが自動で変更する可能性がある場合は、その影響も考慮します。
git add <解消したファイル> && git rebase --continue
「このコミットをスキップ」を選択した場合はgit addを実行せず、次のコマンドだけを実行します。
git rebase --skip
git rebase --continue（または--skip）の結果に応じて分岐します。
Successfully rebased and updated <branch>が表示された場合は、メインフローのStep 4に戻ります。--forceではなく--force-with-leaseを使用しますGitコミットを適切な粒度に分割し、有用なメッセージを付けて作成するスキル。「コミットして」「commitして」「変更をコミット」「まとめてコミット」など、コミット操作を依頼されたら必ず使う。
指定したスキルを3回繰り返し適用します。レビュー・計画・実装など、ファイルを変更するスキルに使います。「iterateで<スキル名>して」「<スキル名>を繰り返し適用して」のように使います。
既存テストをレビューして改善するスキル。「テストをレビューして」「テストを改善して」「テスト名を直して」のように頼まれたら使う。新規にテストを書くのではなく、`.claude/docs/test-implementation.md` のルール（テスト名・AAA構造・アサーション設計・テストダブル・非決定性制御・テスト間独立性・Testing Library 等のフロントエンド固有ルールまで全観点）に既存テストが沿っているかを見直す。対象は `.test.ts` / `.test.tsx` / `.spec.ts` ファイルと、テストコードブロックを含む `.md` ドキュメントファイル。
作った成果物について、ユーザーがその振る舞いと目的を確実に理解できているかを問いかけで確認します。細かな実装ではなく、何をするものか・目的にかなうかに焦点を当て、あらゆる可能性を踏まえてエージェントが判断して問いを立てます。「理解できているか確認して」「振る舞いを確認して」「目的にかなっているか見て」「作ったあとのすり合わせをして」と要望された際に必ず使用します。実装や変更が一段落したとき、作ったものの理解をすり合わせたいと感じたら積極的に提案してください。
`/compact`で要約する前に、残したい情報をユーザーに選んでもらい`/compact`の引数を組み立てます。 「compact前に整理したい」「コンテキストを圧縮したい」「/compactの引数を作って」 「会話が長くなってきたので整理したい」「重要な情報を引き継ぎたい」のように使います。
マージ済みのローカル・リモートブランチを整理するスキル。「ブランチ掃除」「マージ済みブランチを削除」「ブランチ整理」「gh poiを実行」「不要なブランチを片付けて」「リモートのブランチも消したい」「mainだけ残して」のような依頼で必ず使う。gh-poi拡張がインストール済みであることを前提とする。mainなどベースブランチは絶対に削除しない。