ワンクリックでManusで任意のスキルを実行

pr-conflict-resolve

スター3

フォーク0

更新日2026年4月7日 14:33

ローカルCLI（git / gh）を使ってGitHub PRのコンフリクトを解消する。merge vs rebase の戦略選択、コンフリクトマーカーの解消、安全な復旧手順、プッシュ後のPR確認チェックリストまでをガイドする。PRにコンフリクトが発生したとき、featureブランチをmainと同期するとき、コンフリクト解消後の復旧が必要なときに使う。コンフリクトを伴わないコードレビュー、PR以外の一般的なgit操作、リポジトリの初期セットアップには使わない。

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

53able

53able/skills

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

PR コンフリクト解消

手順

Step 1: 安全確認

作業を開始する前に、作業ディレクトリがクリーンであることを確認する:
```
git status
```
出力に "nothing to commit, working tree clean" が表示されていることを確認する。未コミットの変更がある場合は先にスタッシュまたはコミットする。
現在の状態を保存するバックアップブランチを作成する:
```
git branch backup-feature-branch
```
アップストリームの最新情報を取得する:
```
git fetch origin
```

Step 2: 戦略選択

作業前にチームの同期戦略を確認する。merge と rebase のトレードオフ比較マトリクスはスキル同梱の references/strategy-guide.md を読む。
選択した戦略を実行する:
- Merge（デフォルト — 共有ブランチに安全）:
```
git merge origin/main
```
- Rebase（履歴を一直線にする — 非共有ブランチ専用）:
```
git rebase origin/main
```

Step 3: コンフリクト解消

コンフリクトしているファイルをすべて確認する:
```
git status
```
"Unmerged paths" に列挙されたファイルが解消対象。
各コンフリクトファイルを開き、以下のマーカーを探す:
- <<<<<<< HEAD — 現在のブランチの変更
- ======= — 境界線
- >>>>>>> origin/main — 取り込もうとしているブランチの変更
双方の意図を汲み取り、最終的に正しいコードへ書き換え、3種のマーカーをすべて削除する。
ローカルでテストまたはビルドを実行し、ロジックが壊れていないことを確認する。
解消済みの各ファイルをステージする:
```
git add <解決したファイル名>
```

コミット前にマーカーの残留がないことを検証する。スキル同梱の scripts/check_markers.py を実行する。なければ rg で代替する:

# スキル同梱スクリプト（推奨）
python scripts/check_markers.py

# rg が使える場合（代替）
git diff --cached --name-only | xargs rg -l '<<<<<<<|=======|>>>>>>>' 2>/dev/null \
  && echo "マーカー残留あり — コミット前に解消すること" \
  || echo "OK: マーカーなし"

Step 4: コミットとプッシュ

Merge 戦略の場合 — マージコミットを作成する:
```
git commit
```
Rebase 戦略の場合 — リベースを再開する:
```
git rebase --continue
```
PRを更新するためにプッシュする:
- Merge: git push origin <ブランチ名>
- Rebase: git push --force-with-lease origin <ブランチ名> （--force-with-lease は自分が把握していないリモートの更新があった場合に上書きをブロックする。bare --force は使わない。）

Step 5: PR確認

ブラウザでPRを開く:
```
gh pr view --web
```
UI上の "Resolve conflicts" 警告が消え、"Merge pull request" が有効になっていることを確認する。
"Files changed" タブを開き、意図しない空白や書式の差分が混入していないかを確認する。
ステータスチェック（CI/CD・lint）の状況を確認する:
```
gh pr checks || true
```
注意: checks が1件も登録されていないリポジトリでは gh pr checks が exit 1 を返すが、これはエラーではない。出力に "no checks reported" や空行のみが表示される場合は CI 未設定と判断し、次のステップへ進む。実際に失敗している場合は failing/errored のチェック名が明示される。
CIが一時的なエラーで失敗した場合は、GitHub UI の再実行ボタンから手動再トリガーする。
非自明なロジック変更を伴う解消をした場合は、Conversation タブに調整内容のコメントを残す。
既存のインラインレビューコメントと、今回の解消内容が矛盾していないかを確認する。
CODEOWNERS の承認が必要なリポジトリ設定になっていないかを確認し、必要なら承認を依頼する。
以前に "Changes requested" が出されていた場合、解消済みになっているかを確認する。
Reviewers パネルの "Re-request review" アイコンから明示的に再レビュー依頼を実行する。

最小検証（30秒）

解消完了後、必ず以下の3コマンドを実行する:

# 未解決ファイル・未ステージの変更がないか確認
git status

# 直近のコミットが正しく積まれているか確認
git log --oneline -n 3

# CLIからCIチェック状況を確認（checks 未登録でも exit 1 になるため || true で継続）
gh pr checks || true

エラーハンドリング

マーカー残留チェック（rg またはスキル同梱の scripts/check_markers.py）がマーカーを報告した場合は、対象ファイルを再度開いてマーカーを削除してからコミットする。
マージまたはリベースを完全に中断したい場合:
```
git merge --abort
# または
git rebase --abort
```
どちらのコマンドも操作開始前の状態に安全に戻す。
ブランチの状態をバックアップに完全リセットしたい場合:
```
git reset --hard backup-feature-branch
```
誤ったコミットをすでにプッシュしてしまった場合は git reflog で履歴を確認し、安全な時点に戻す:
```
git reflog
git reset --hard HEAD@{n}
```
.orig などの一時ファイルを誤ってステージした場合は git restore --staged <ファイル名> でアンステージし、.gitignore に追加する。
典型的なコンフリクトパターンの詳細と復旧手順はスキル同梱の references/conflict-patterns.md を読む。

このリポジトリの他の Skills

同じリポジトリ

sentence-logic-guard

53able/skills

日本語の文章で文と文のつながりを点検し、直前の文の不足、常識的な連続性、読者視点から論理のほころびを防ぐ。エッセイ、記事、レポート、解説文の執筆・推敲・レビューで使う。法的判断、数学的証明、事実確認のみ、文法校正のみ、意図的なシュール表現や断片的表現の矯正には使わない。

2026-07-043

natural-expression-refiner

53able/skills

日本語の文章を、誇張、借り物の美辞麗句、過剰な謙遜を避け、実感に近い等身大な表現へ整える。エッセイ、プロフィール、商品説明、自己紹介、note、スピーチ、振り返り文の推敲で使う。法的文書、逐語訳、意図的に言葉を高める詩、学術的な出典確認、事実検証には使わない。

2026-06-273

macos-screenshot-capture

53able/skills

macOSのスクリーンショットを、screencaptureと補助CLIで取得する。画面全体、ウィンドウ指定、選択範囲、タイマー撮影、クリップボード保存に対応する。macOS上でエージェントが再現可能なパスへスクリーンショットを保存したい場合に使う。OCR、画像編集、動画収録、macOS以外のスクリーンショット取得には使わない。

2026-06-253

logical-consistency-reviewer

53able/skills

文章、記事、レポート、企画書の論理破綻をレビューし、論点、必要情報、推論、結論と根拠の構造を確認する。Why So、So What、MECEの観点で飛躍、矛盾、論点ずれ、根拠不足を検出する。公開前や改稿前に文章の筋道を点検するときに使う。単なる校正、文体調整、事実確認のみ、法的助言、数学的証明の厳密検証には使わない。

2026-06-243

pr-evidence-capture

53able/skills

UI 変更や状態遷移を伴う PR に、E2E テスト計画・操作後スクリーンショット・検証結果・検証データの副作用を確認エビデンスとして残す。 gh image で画像をアップロードし、Chrome DevTools MCP で画面を操作・撮影し、gh でテスト計画と結果を PR コメントへ投稿する際に使用。「PR にスクショを貼る」「UI エビデンスを残す」「E2E 確認結果を PR にまとめる」「レビュー用に画面の証跡を添付」と依頼された時に適用。内部ロジックのみの変更や、既存の自動テストで担保できる変更には使わない。コミット作成や PR 本体の作成フローには使わない。

2026-06-243

wxt-extension-development

53able/skills

WXTを使ったブラウザ拡張開発を支援する。プロジェクト調査、entrypoint設計、manifestと権限変更、content script UI、storage、messaging、build、zip、ブラウザ検証を扱う。WXTプロジェクトの作成、変更、監査、デバッグ時に使う。非WXT拡張、汎用フロントエンド、拡張ストア審査には使わない。

2026-06-203

name

pr-conflict-resolve

description

PR コンフリクト解消

手順

Step 1: 安全確認

作業を開始する前に、作業ディレクトリがクリーンであることを確認する:
```
git status
```
出力に "nothing to commit, working tree clean" が表示されていることを確認する。未コミットの変更がある場合は先にスタッシュまたはコミットする。
現在の状態を保存するバックアップブランチを作成する:
```
git branch backup-feature-branch
```
アップストリームの最新情報を取得する:
```
git fetch origin
```

Step 2: 戦略選択

作業前にチームの同期戦略を確認する。merge と rebase のトレードオフ比較マトリクスはスキル同梱の references/strategy-guide.md を読む。
選択した戦略を実行する:
- Merge（デフォルト — 共有ブランチに安全）:
```
git merge origin/main
```
- Rebase（履歴を一直線にする — 非共有ブランチ専用）:
```
git rebase origin/main
```

Step 3: コンフリクト解消

コンフリクトしているファイルをすべて確認する:
```
git status
```
"Unmerged paths" に列挙されたファイルが解消対象。
各コンフリクトファイルを開き、以下のマーカーを探す:
- <<<<<<< HEAD — 現在のブランチの変更
- ======= — 境界線
- >>>>>>> origin/main — 取り込もうとしているブランチの変更
双方の意図を汲み取り、最終的に正しいコードへ書き換え、3種のマーカーをすべて削除する。
ローカルでテストまたはビルドを実行し、ロジックが壊れていないことを確認する。
解消済みの各ファイルをステージする:
```
git add <解決したファイル名>
```

コミット前にマーカーの残留がないことを検証する。スキル同梱の scripts/check_markers.py を実行する。なければ rg で代替する:

# スキル同梱スクリプト（推奨）
python scripts/check_markers.py

# rg が使える場合（代替）
git diff --cached --name-only | xargs rg -l '<<<<<<<|=======|>>>>>>>' 2>/dev/null \
  && echo "マーカー残留あり — コミット前に解消すること" \
  || echo "OK: マーカーなし"

Step 4: コミットとプッシュ

Merge 戦略の場合 — マージコミットを作成する:
```
git commit
```
Rebase 戦略の場合 — リベースを再開する:
```
git rebase --continue
```
PRを更新するためにプッシュする:
- Merge: git push origin <ブランチ名>
- Rebase: git push --force-with-lease origin <ブランチ名> （--force-with-lease は自分が把握していないリモートの更新があった場合に上書きをブロックする。bare --force は使わない。）

Step 5: PR確認

ブラウザでPRを開く:
```
gh pr view --web
```
UI上の "Resolve conflicts" 警告が消え、"Merge pull request" が有効になっていることを確認する。
"Files changed" タブを開き、意図しない空白や書式の差分が混入していないかを確認する。
ステータスチェック（CI/CD・lint）の状況を確認する:
```
gh pr checks || true
```
注意: checks が1件も登録されていないリポジトリでは gh pr checks が exit 1 を返すが、これはエラーではない。出力に "no checks reported" や空行のみが表示される場合は CI 未設定と判断し、次のステップへ進む。実際に失敗している場合は failing/errored のチェック名が明示される。
CIが一時的なエラーで失敗した場合は、GitHub UI の再実行ボタンから手動再トリガーする。
非自明なロジック変更を伴う解消をした場合は、Conversation タブに調整内容のコメントを残す。
既存のインラインレビューコメントと、今回の解消内容が矛盾していないかを確認する。
CODEOWNERS の承認が必要なリポジトリ設定になっていないかを確認し、必要なら承認を依頼する。
以前に "Changes requested" が出されていた場合、解消済みになっているかを確認する。
Reviewers パネルの "Re-request review" アイコンから明示的に再レビュー依頼を実行する。

最小検証（30秒）

解消完了後、必ず以下の3コマンドを実行する:

# 未解決ファイル・未ステージの変更がないか確認
git status

# 直近のコミットが正しく積まれているか確認
git log --oneline -n 3

# CLIからCIチェック状況を確認（checks 未登録でも exit 1 になるため || true で継続）
gh pr checks || true

エラーハンドリング

マーカー残留チェック（rg またはスキル同梱の scripts/check_markers.py）がマーカーを報告した場合は、対象ファイルを再度開いてマーカーを削除してからコミットする。
マージまたはリベースを完全に中断したい場合:
```
git merge --abort
# または
git rebase --abort
```
どちらのコマンドも操作開始前の状態に安全に戻す。
ブランチの状態をバックアップに完全リセットしたい場合:
```
git reset --hard backup-feature-branch
```
誤ったコミットをすでにプッシュしてしまった場合は git reflog で履歴を確認し、安全な時点に戻す:
```
git reflog
git reset --hard HEAD@{n}
```
.orig などの一時ファイルを誤ってステージした場合は git restore --staged <ファイル名> でアンステージし、.gitignore に追加する。
典型的なコンフリクトパターンの詳細と復旧手順はスキル同梱の references/conflict-patterns.md を読む。