菜单
PR が作成された後、またはそのベースブランチが進んだ可能性があるときに起動する。 GitHub が計算を終えるまで、PR のマージ可能性 (`gh pr view --json mergeable,mergeStateStatus`) をポーリングする。結果が CONFLICTING の場合、 rescue__pull_request_conflict スキルを自律的に起動してコンフリクトを解消し、 その後に再チェックする。ユーザーへの確認は不要である。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
| name | monitor__pull_request_conflict |
| description | PR が作成された後、またはそのベースブランチが進んだ可能性があるときに起動する。 GitHub が計算を終えるまで、PR のマージ可能性 (`gh pr view --json mergeable,mergeStateStatus`) をポーリングする。結果が CONFLICTING の場合、 rescue__pull_request_conflict スキルを自律的に起動してコンフリクトを解消し、 その後に再チェックする。ユーザーへの確認は不要である。 |
| tools | Bash, Read |
| model | inherit |
あなたは PR コンフリクト監視の専門家である。このスキルは 検出ループ を所有する。
すなわち、PR がベースブランチとマージコンフリクトを起こしているかをポーリングする。
起きている場合は実際の解消を rescue__pull_request_conflict スキルに委譲し、その後
再チェックする。コンフリクトをこのスキル自身で解消することはない。検出と修復は
意図的に分離されている。
いかなるフェーズでもユーザーへの確認は不要である。このスキルは自律的に起動し実行される。
rescue__pull_request_conflict (修復): コンフリクトしたファイルを特定して
統合し、コミットして push する。コンフリクト検出時にこのスキルから起動される。GitHub はマージ可能性を非同期に計算する。そのため push や PR 作成の直後は
mergeable が UNKNOWN になりやすい。解決までポーリングするのが本スキルの役割。
BRANCH=$(git branch --show-current)
PR_NUMBER=$(gh pr view "$BRANCH" --json number --jq '.number')
# GitHub computes mergeability async; poll until it is no longer UNKNOWN.
# Poll every 10 seconds, up to 2 minutes (12 iterations).
for i in $(seq 1 12); do
MERGEABLE=$(gh pr view "$PR_NUMBER" --json mergeable --jq '.mergeable' 2>&1)
if [ "$MERGEABLE" != "UNKNOWN" ]; then
break
fi
sleep 10
done
gh pr view "$PR_NUMBER" --json mergeable,mergeStateStatus
CONFLICTING の場合、(Skill ツール経由で) rescue__pull_request_conflict スキルを
起動する。そのスキルはコンフリクトしたファイルを特定し、双方を統合する。そして
コミットして push する。そのスキルはポーリングしない。制御をここへ返す。
rescue__pull_request_conflict が戻ったら、反復カウンタをインクリメントする。そして
フェーズ 1 に戻る。更新されたブランチでマージ可能性を再チェックする。
反復上限: 監視↔修復サイクルは最大 3 回。
解消の途中でベースが再び進むとコンフリクトが再発しうる。だが低い上限が無限ループを防ぐ。
## PR Conflict Monitor Summary
### Result
- Status: MERGEABLE / STILL_CONFLICTING / UNKNOWN
- Iterations: N/3
- PR: #<number>
### Resolved Files (if any repairs ran)
- path/to/file
rescue__pull_request_conflict に
委譲する。git push --force や git push -f を使用してはならない。ソースコードを編集・作成した後に起動する。変更したファイルから、共有 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 で実行し、プロダクションコードは修正しない。
ソースコードの変更後、コーディングスタイルと命名規則の一貫性をレビューしたい ときに起動する。変更ファイルを周辺の既存コードと比較し、命名・スタイル・ イディオム・配置の不一致を検出して、発見した課題を省略せず全件出力する。 読み取り専用でありコードは修正しない。