القائمة
PR が作成された後、またはそのベースブランチが進んだ可能性があるときに起動する。 GitHub が計算を終えるまで、PR のマージ可能性 (`gh pr view --json mergeable,mergeStateStatus`) をポーリングする。結果が CONFLICTING の場合、 rescue__pull_request_conflict スキルを自律的に起動してコンフリクトを解消し、 その後に再チェックする。ユーザーへの確認は不要である。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
ソースコードを編集・作成した後に起動する。変更したファイルから、共有 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 | 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 を使用してはならない。