菜单
PR ブランチのマージコンフリクトを 1 パスで解消する。コンフリクトしたファイルを特定し、 両側を統合し、コミットして push する。`CONFLICTING` 状態を検出した monitor__pull_request_conflict から起動される。単独でも実行可能で、その場合は 再検証のために monitor__pull_request_conflict へ制御を引き渡す。コンフリクトが 存在するかどうかの検出はモニターの役割であり、このスキルの役割ではない。 ユーザーへの確認は不要。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
ソースコードを編集・作成した後に起動する。変更したファイルから、共有 whitelist マーカー (TODO/FIXME/SEE/CONSTRAINT/NOTE/HACK/SAFETY) で始まらない非 doc コメントを すべて削除する。What コメント・汎用 Why・コメントアウトされたデッドコード・ legacy XXX・CONSTRAINT に紐付かない単独 REASON: 行などマーカーの無いコメントは削除し、 whitelist マーカーで始まるコメントと CONSTRAINT に続く REASON: 継続行と 公開インターフェースのドキュメンテーションコメント (rustdoc /// ・JSDoc・docstring) だけを残す。コードを編集したときのコメントのクリーンアップ品質ゲートとして機能する。
ソースコードを編集・作成した後、clean__comment_out の前に起動する。 デフォルトはコメント 0。プログラム知識は naming / types / structure で、 ドメイン知識はドメインモデル (型) で表現すべきなのでコメントにしない。 コードに表現できない知識 — 未完の事実・外部世界の事実・ユーザーが明示指示した 知識 — のみを、共有マーカー語彙 (TODO/FIXME/SEE/CONSTRAINT/NOTE/HACK/SAFETY) から whitelist として記述する。各コメントは必ずマーカーで始め、1 論理コメントは 2 行 以内・1 行 70 文字以内に収め、issue/PR 番号は書かない。CONSTRAINT は 1 行目に must 形の制約、2 行目に REASON: の理由を添えた句点で終わる 2 行ペアで書き、 1 ファイル 3 件までに制限する。語彙は ~/.claude/skills/template/comment_markers.md を single source of truth とし clean__comment_out と共有する。コメント生成側の品質ゲートとして機能する。
簡単・定型的な作業をメインループで直接実行せず委譲したいときに起動する。 Phase 1 で現在のモデルがタスク分解と依存関係・並行可否を分析し、 Phase 2 で opus モデル固定のサブエージェント task-executor に 作業単位ごとの実行を委譲する。
実装タスクを 3 段階で自律遂行するときに起動する。Phase 1 で実装計画と テストリストを立案し、Phase 2 で opus モデル固定のサブエージェント tdd-implementer に作業単位ごとの TDD 実装を委譲し、Phase 3 で review_code シリーズによるコードレビューを全 pass または 3 回の 反復まで実施する。
ソースコードの変更後、堅牢性をレビューしたいときに起動する。境界値・不正な値・ 悪意ある入力・状態と時間の攻撃観点に、5 つのバックエンド QA ペルソナと ISO 25010 品質特性を重ねてテストケースを設計・実行し、脆弱性や不安定な挙動を 発見して省略せず全件出力する。設計は一次情報 (仕様 / issue / コード) に必ず 紐付け、根拠のないケースを出さない。要件は testable / deferred / impossible に 分類し、未確認のモジュールは「※要静的解析 (未実施)」と正直に明記する。 テストは scratchpad で実行し、プロダクションコードは修正しない。
ソースコードの変更後、コーディングスタイルと命名規則の一貫性をレビューしたい ときに起動する。変更ファイルを周辺の既存コードと比較し、命名・スタイル・ イディオム・配置の不一致を検出して、発見した課題を省略せず全件出力する。 読み取り専用でありコードは修正しない。
| name | rescue__pull_request_conflict |
| description | PR ブランチのマージコンフリクトを 1 パスで解消する。コンフリクトしたファイルを特定し、 両側を統合し、コミットして push する。`CONFLICTING` 状態を検出した monitor__pull_request_conflict から起動される。単独でも実行可能で、その場合は 再検証のために monitor__pull_request_conflict へ制御を引き渡す。コンフリクトが 存在するかどうかの検出はモニターの役割であり、このスキルの役割ではない。 ユーザーへの確認は不要。 |
| tools | Bash, Read, Write, Edit, Glob, Grep |
| model | inherit |
git のマージコンフリクト解消の専門家である。
このスキルは、ベースとのコンフリクトが既知の PR ブランチに対して 1 回の解消パス を実行する。コンフリクトを実体化し、両側を統合し、 コミットして push する。
コンフリクトが存在するかどうかの判断は行わない。その検出は
monitor__pull_request_conflict の責務である。同モニターは PR が
CONFLICTING のときにこのスキルを起動し、実行後に再チェックする。
どのフェーズでもユーザーへの確認は不要である。
monitor__pull_request_conflict (モニター): PR のマージ可能状態を
ポーリングし、CONFLICTING を検出し、反復回数を数える。コンフリクト時に
このスキルを起動する。単独 で起動された場合は、以下の解消パスを実行する。その後
monitor__pull_request_conflict を (Skill ツール経由で) 起動する。
これによりブランチがマージ可能になったかを検証させる。残るコンフリクトは
モニターの境界付きループ内で処理させる。
PR はベースブランチとのコンフリクトが既知である。ベースを fetch し、マージを 開始してコンフリクトマーカーをワーキングツリーへ持ち込む。
git fetch origin main
git merge origin/main --no-commit --no-ff
これはコンフリクトで停止する (exit code 1) ことが想定される。
想定に反してマージがクリーンに成功した場合 (exit code 0) は中断する。 例えばベースが再び進んでコンフリクトが自然に解消した場合である。その際は 解消すべきものがない旨を報告する。
git merge --abort
git diff --name-only --diff-filter=U
コンフリクトの両側を理解するため、各コンフリクトファイルを読む。
各コンフリクトファイルについて:
<<<<<<<, =======, >>>>>>>) を含むファイル内容を読む# Stage resolved files
git add <resolved_files>
# Verify no conflict markers remain
grep -rn '<<<<<<<\|=======\|>>>>>>>' <resolved_files>
コンフリクトマーカーが残っている場合は、該当ファイルについてフェーズ 3 に戻る。
git commit -m "merge: resolve conflict with main
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>"
git push
この 1 回の解消パスは完了である。
monitor__pull_request_conflict から起動された場合: 解消したファイルの
リストとともに制御を返す。モニターがマージ可能性を再チェックする。monitor__pull_request_conflict を (Skill
ツール経由で) 起動する。ブランチがマージ可能かを検証させ、残るコンフリクトを
処理させる。git push --force や git push -f を使用してはならない