skills

自分が作成・出荷した PR を merge / close まで長期間ポーリングで監視し、放置中に起きる CI 失敗と新規レビューコメントへの対応までを回すスキル。毎ポーリングで同梱スクリプト `prm status <PR>` により state / head SHA / 失敗・pending checks / 未解決レビュースレッド全量を 1 回で観測し、`checks.failing` に未対応の新規失敗があれば `ci-self-heal` を、`known_comment_ids` に無い新規の未解決レビュースレッドがあれば `pr-review-respond` を、それぞれ subagent (Task) で dispatch する。新規分の author が全て CodeRabbit なら、`pr-review-respond` への契約入力で修正適用を `coderabbit:autofix` に委譲する (plugin がある環境のみ)。呼出側 (`shipping` Phase 6 / main セッション) は本スキル自体も subagent で dispatch し、main を長時間監視で塞がない。ポーリング間隔は状態変化なしで指数バックオフ (60 秒起点、上限 1800 秒)、新規 push・新規失敗・新規コメント・決着のいずれかがあれば 60 秒にリセットする。決着 (MERGED / CLOSED) を検出したら `retro` を自動起動する。待機手段は `/schedule` (cron) → `ScheduleWakeup` → 手動 `--check-only` の優先順で環境依存を吸収する。`shipping` 完了直後・`gh pr create` 直後・「PR 監視して」「マージされるまで見張って」「マージ/クローズしたら振り返りまで回して」「CI とコメントも見張って対応まで回して」のような要請で必ず起動する。CI 完了までの短時間監視や修復の実体は `ci-self-heal`、コメント対応の実体は `pr-review-respond` (CodeRabbit 起因は `coderabbit:autofix`) が持ち、本スキルは検知と dispatch のループ制御に閉じる。PR の merge 操作そのものは行わない — 決着の事実を待つだけ。

自分が作成・出荷した PR を merge / close まで長期間ポーリングで監視し、放置中に起きる CI 失敗と新規レビューコメントへの対応までを回すスキル。毎ポーリングで同梱スクリプト `prm status <PR>` により state / head SHA / 失敗・pending checks / 未解決レビュースレッド全量を 1 回で観測し、`checks.failing` に未対応の新規失敗があれば `ci-self-heal` を、`known_comment_ids` に無い新規の未解決レビュースレッドがあれば `pr-review-respond` を、それぞれ subagent (Task) で dispatch する。新規分の author が全て CodeRabbit なら、`pr-review-respond` への契約入力で修正適用を `coderabbit:autofix` に委譲する (plugin がある環境のみ)。呼出側 (`shipping` Phase 6 / main セッション) は本スキル自体も subagent で dispatch し、main を長時間監視で塞がない。ポーリング間隔は状態変化なしで指数バックオフ (60 秒起点、上限 1800 秒)、新規 push・新規失敗・新規コメント・決着のいずれかがあれば 60 秒にリセットする。決着 (MERGED / CLOSED) を検出したら `retro` を自動起動する。待機手段は `/schedule` (cron) → `ScheduleWakeup` → 手動 `--check-only` の優先順で環境依存を吸収する。`shipping` 完了直後・`gh pr create` 直後・「PR 監視して」「マージされるまで見張って」「マージ/クローズしたら振り返りまで回して」「CI とコメントも見張って対応まで回して」のような要請で必ず起動する。CI 完了までの短時間監視や修復の実体は `ci-self-heal`、コメント対応の実体は `pr-review-respond` (CodeRabbit 起因は `coderabbit:autofix`) が持ち、本スキルは検知と dispatch のループ制御に閉じる。PR の merge 操作そのものは行わない — 決着の事実を待つだけ。

自分が作成・出荷した PR を merge / close まで長期間ポーリングで監視し、放置中に起きる CI 失敗と新規レビューコメントへの対応までを回すスキル。毎ポーリングで同梱スクリプト `prm status <PR>` により state / head SHA / 失敗・pending checks / 未解決レビュースレッド全量を 1 回で観測し、`checks.failing` に未対応の新規失敗があれば `ci-self-heal` を、`known_comment_ids` に無い新規の未解決レビュースレッドがあれば `pr-review-respond` を、それぞれ subagent (Task) で dispatch する。新規分の author が全て CodeRabbit なら、`pr-review-respond` への契約入力で修正適用を `coderabbit:autofix` に委譲する (plugin がある環境のみ)。呼出側 (`shipping` Phase 6 / main セッション) は本スキル自体も subagent で dispatch し、main を長時間監視で塞がない。ポーリング間隔は状態変化なしで指数バックオフ (60 秒起点、上限 1800 秒)、新規 push・新規失敗・新規コメント・決着のいずれかがあれば 60 秒にリセットする。決着 (MERGED / CLOSED) を検出したら `retro` を自動起動する。待機手段は `/schedule` (cron) → `ScheduleWakeup` → 手動 `--check-only` の優先順で環境依存を吸収する。`shipping` 完了直後・`gh pr create` 直後・「PR 監視して」「マージされるまで見張って」「マージ/クローズしたら振り返りまで回して」「CI とコメントも見張って対応まで回して」のような要請で必ず起動する。CI 完了までの短時間監視や修復の実体は `ci-self-heal`、コメント対応の実体は `pr-review-respond` (CodeRabbit 起因は `coderabbit:autofix`) が持ち、本スキルは検知と dispatch のループ制御に閉じる。PR の merge 操作そのものは行わない — 決着の事実を待つだけ。

GitHub PR で発生した merge conflict を自動修正するための手順とベストプラクティス。 PR コメントで `@claude` 経由で呼ばれた conflict 解決タスクや、ローカルでの rebase / merge conflict を解決するときに必ず参照する。チェックアウト → merge → conflict 解決 → lock ファイル再生成 → 検証 → commit で merge を確定 → push までの一連の安全な流れを、 同梱スクリプト (`scripts/*.sh`) の決定的な実行として定義する。

PR に投稿された自動レビュー (CodeRabbit / Devin) と人間レビュアーのコメントを取得し、各指摘の妥当性を検証したうえで対応するスキル。VALID は修正コミットを当てて該当スレッドに「Fixed in <SHA>」と返信、INVALID_PUSH は根拠付きの pushback コメントを残し resolve しない、VALID_DEFER は issue 化して参照、DUPLICATE は既存対応スレッドを指す。最後に PR へ集約サマリコメントを 1 件投稿し「何を・どう対応した／なぜ対応しなかったか」を 1 箇所で追えるようにする。`gh pr create` 直後・**既存 PR ブランチへ push した直後 (レビュー対応後の再 push を含む)**・「レビュー対応して」「コメント見て対応して」「コードラビット対応」「Devin の指摘片付けて」「PR のコメント全部捌いて」「push したのでスレッド対応して」のような要請、CodeRabbit / Devin / 人間レビュアーが新規コメントを残した時 (監視やイベントでの検知を含む)、PR を merge する前に未解決スレッドを確認したい時、いずれでも必ず起動すること。未解決スレッドが残る PR を離れる前に必ず一度起動する。レビュアー判別はコメント author と本文を読んで行い、bot suffix のような表面的なルールは持たない。本スキルは「読む・直す・返信する・サマリ投稿する」までで、レビュー自体を実行する (CodeRabbit や Devin を呼び出す) ことはしない — 既にレビュー済みの PR に後追いで対応するスキル。GitHub API 呼び出しは同梱の単一エントリ `scripts/prr` (subcommand: `fetch`/`reply`/`resolve`/`summary`/`wait-ci`) に集約しており、`allowed-tools` で consumer 側の追加 permission は不要。CodeRabbit 指摘の修正適用は coderabbit plugin がある環境では `coderabbit:autofix` に委譲し、本スキルは triage・返信・resolve・サマリに徹する。

テスト変更を含む diff に対して静的 assertion 監査 (Phase 1) と unit テスト限定の mutation smoke (Phase 2、実コードへの変異注入 + 再実行) を行い、PASS/BLOCK を判定するゲート用スキル。tautology-literal-sharing (critical) / assertion-roulette / overstated-coverage / boundary-gap の 4 チェックを正規表現ベースで実行し、critical が 1 件でもあれば BLOCK として呼び出し元に差し戻す。加えて対象が unit テスト (プロセス内で完結・外部 I/O 無し) の場合のみ `scripts/mutate_and_run.py` で変異注入を行い、survived mutant が 1 件でもあれば BLOCK にする。主経路は `tdd` Step 3.5 (GREEN 確認後・commit 前)・`pr-review-respond` Phase C (VALID 修正のテスト側 diff)・`verify-done` Step 4 (完了宣言直前) の各本文に組み込まれた強制サブステップ呼び出しであり、ユーザからの直接要請にも対応する。「このテスト検出力ある?」「テスト弱くない?」「assertion 監査して」「tautology チェックして」「このテスト実装をなぞってるだけじゃない?」「テストがバグをロックインしてないか見て」「このテスト mutation testing して」のような口語、いずれでも必ず起動すること。テストコードの網羅的レビューは `test-review`、push 後の CI 赤対応は `ci-self-heal`、skill の eval trigger JSON 採点は `skill-builder` Mode B、テストスイート全体の mutation score 算出 (Stryker/mutmut 相当の運用) は、いずれも本スキルの範囲外。

GitHub PR で発生した merge conflict を自動修正するための手順とベストプラクティス。 PR コメントで `@claude` 経由で呼ばれた conflict 解決タスクや、ローカルでの rebase / merge conflict を解決するときに必ず参照する。チェックアウト → merge → conflict 解決 → lock ファイル再生成 → 検証 → commit で merge を確定 → push までの一連の安全な流れを、 同梱スクリプト (`scripts/*.sh`) の決定的な実行として定義する。

テスト変更を含む diff に対して静的 assertion 監査 (Phase 1) と unit テスト限定の mutation smoke (Phase 2、実コードへの変異注入 + 再実行) を行い、PASS/BLOCK を判定するゲート用スキル。tautology-literal-sharing (critical) / assertion-roulette / overstated-coverage / boundary-gap の 4 チェックを正規表現ベースで実行し、critical が 1 件でもあれば BLOCK として呼び出し元に差し戻す。加えて対象が unit テスト (プロセス内で完結・外部 I/O 無し) の場合のみ `scripts/mutate_and_run.py` で変異注入を行い、survived mutant が 1 件でもあれば BLOCK にする。主経路は `tdd` Step 3.5 (GREEN 確認後・commit 前)・`pr-review-respond` Phase C (VALID 修正のテスト側 diff)・`verify-done` Step 4 (完了宣言直前) の各本文に組み込まれた強制サブステップ呼び出しであり、ユーザからの直接要請にも対応する。「このテスト検出力ある?」「テスト弱くない?」「assertion 監査して」「tautology チェックして」「このテスト実装をなぞってるだけじゃない?」「テストがバグをロックインしてないか見て」「このテスト mutation testing して」のような口語、いずれでも必ず起動すること。テストコードの網羅的レビューは `test-review`、push 後の CI 赤対応は `ci-self-heal`、skill の eval trigger JSON 採点は `skill-builder` Mode B、テストスイート全体の mutation score 算出 (Stryker/mutmut 相当の運用) は、いずれも本スキルの範囲外。

汎用性のあるハーネス片 (rule / slash command / subagent / hook / 定型スクリプト) を、 ローカル設定ではなく **配布元 skills リポジトリの feature 枠** (rules/ commands/ subagents/ hooks/) に canonical 形式で収録し、タグリリース → rulesync 経由で consumer 全 repo とクラウド実行 (Routines / cloud セッション / Actions) に届ける ための判定と手順のスキル。ローカル (`~/.claude/*`, `settings.local.json`) に置いた ハーネスはそのマシンでしか効かず、クラウド実行に届かない — 本スキルはその置き場所 ミスを防ぐ。機密 (トークン・private repo 名・内部 URL) や特定マシン依存の内容を **配布しない**判定も担う。 「このルール他の repo でも使いたい」「rulesync で配布して」「これは汎用だから skills repo に」「クラウド実行でも効くようにして」「この hook / command を共通化 して」「どこに置くべき?」のような要請、session-retro の rule handoff で宛先を 決める時、新しい rule / command / hook / subagent を書いた直後の置き場所判定、 いずれでも必ず起動すること。 範囲外: skill 本体の新規作成・トリガ改善 (skill-builder)、rule や教訓の中身の考案 (session-retro 等の生成元)、単一プロジェクト固有の permissions / settings 変更 (update-config 系)、リリース手順単体の質問 (RELEASING.md)。本スキルが持つのは 「配布判定 → 枠選択 → canonical 収録 → リリース → consumer 反映」の経路のみ。

汎用性のあるハーネス片 (rule / slash command / subagent / hook / 定型スクリプト) を、 ローカル設定ではなく **配布元 skills リポジトリの feature 枠** (rules/ commands/ subagents/ hooks/) に canonical 形式で収録し、タグリリース → rulesync 経由で consumer 全 repo とクラウド実行 (Routines / cloud セッション / Actions) に届ける ための判定と手順のスキル。ローカル (`~/.claude/*`, `settings.local.json`) に置いた ハーネスはそのマシンでしか効かず、クラウド実行に届かない — 本スキルはその置き場所 ミスを防ぐ。機密 (トークン・private repo 名・内部 URL) や特定マシン依存の内容を **配布しない**判定も担う。 「このルール他の repo でも使いたい」「rulesync で配布して」「これは汎用だから skills repo に」「クラウド実行でも効くようにして」「この hook / command を共通化 して」「どこに置くべき?」のような要請、session-retro の rule handoff で宛先を 決める時、新しい rule / command / hook / subagent を書いた直後の置き場所判定、 いずれでも必ず起動すること。 範囲外: skill 本体の新規作成・トリガ改善 (skill-builder)、rule や教訓の中身の考案 (session-retro 等の生成元)、単一プロジェクト固有の permissions / settings 変更 (update-config 系)、リリース手順単体の質問 (RELEASING.md)。本スキルが持つのは 「配布判定 → 枠選択 → canonical 収録 → リリース → consumer 反映」の経路のみ。

汎用性のあるハーネス片 (rule / slash command / subagent / hook / 定型スクリプト) を、 ローカル設定ではなく **配布元 skills リポジトリの feature 枠** (rules/ commands/ subagents/ hooks/) に canonical 形式で収録し、タグリリース → rulesync 経由で consumer 全 repo とクラウド実行 (Routines / cloud セッション / Actions) に届ける ための判定と手順のスキル。ローカル (`~/.claude/*`, `settings.local.json`) に置いた ハーネスはそのマシンでしか効かず、クラウド実行に届かない — 本スキルはその置き場所 ミスを防ぐ。機密 (トークン・private repo 名・内部 URL) や特定マシン依存の内容を **配布しない**判定も担う。 「このルール他の repo でも使いたい」「rulesync で配布して」「これは汎用だから skills repo に」「クラウド実行でも効くようにして」「この hook / command を共通化 して」「どこに置くべき?」のような要請、session-retro の rule handoff で宛先を 決める時、新しい rule / command / hook / subagent を書いた直後の置き場所判定、 いずれでも必ず起動すること。 範囲外: skill 本体の新規作成・トリガ改善 (skill-builder)、rule や教訓の中身の考案 (session-retro 等の生成元)、単一プロジェクト固有の permissions / settings 変更 (update-config 系)、リリース手順単体の質問 (RELEASING.md)。本スキルが持つのは 「配布判定 → 枠選択 → canonical 収録 → リリース → consumer 反映」の経路のみ。

実装が上流スキル (`design`/`software-design` → `tdd`/`tidy-first`) で GREEN になった後の **出荷専用ターミナルステージ**を、各フェーズを fresh subagent に dispatch するオーケストレータスキル。品質ゲート (`code-review`) → 完了ゲート (`verify-done`) → PR materialize (open PR が無ければ `commit-commands:commit-push-pr`、あれば push) → CI 緑化 (`ci-self-heal`) と自動レビュー対応 (`pr-review-respond`、CodeRabbit/Devin/Copilot/人間、CodeRabbit 修正は `coderabbit:autofix` へ委譲) を、CI 全 pass かつ全コメント終端まで回し、行き詰まったら escalate する。収束後は SHIPPED 前に `pr-monitor` を subagent dispatch し監視設置を確認する。コード修正は behavioral→`tdd` / structural→`tidy-first` の subagent にルーティングし、本スキルはコードを書かずループ制御と収束/escalation 判定だけを main で持つ。「ship して」「実装できたから後は全部やって PR 出して CI もレビュー対応も全部通してマージできる状態にして」「commit-push-pr の検証付き版で」「赤と指摘を全部潰して merge-ready に」のような実装後に出荷まで丸ごと任せる要請で必ず起動すること。commit だけは `commit-commands:commit`、検証ループ不要の commit→push→PR だけは `commit-push-pr`、コードレビューだけは `code-review`、既存 PR のコメント対応だけは `pr-review-respond`、CI 修復だけは `ci-self-heal`、完了確認だけは `verify-done`、実装そのもの (設計/コーディング/未 GREEN/WIP) は上流が担い範囲外。PR は merge せず merge-ready で停止する。

実装が上流スキル (`design`/`software-design` → `tdd`/`tidy-first`) で GREEN になった後の **出荷専用ターミナルステージ**を、各フェーズを fresh subagent に dispatch するオーケストレータスキル。品質ゲート (`code-review`) → 完了ゲート (`verify-done`) → PR materialize (open PR が無ければ `commit-commands:commit-push-pr`、あれば push) → CI 緑化 (`ci-self-heal`) と自動レビュー対応 (`pr-review-respond`、CodeRabbit/Devin/Copilot/人間、CodeRabbit 修正は `coderabbit:autofix` へ委譲) を、CI 全 pass かつ全コメント終端まで回し、行き詰まったら escalate する。収束後は SHIPPED 前に `pr-monitor` を subagent dispatch し監視設置を確認する。コード修正は behavioral→`tdd` / structural→`tidy-first` の subagent にルーティングし、本スキルはコードを書かずループ制御と収束/escalation 判定だけを main で持つ。「ship して」「実装できたから後は全部やって PR 出して CI もレビュー対応も全部通してマージできる状態にして」「commit-push-pr の検証付き版で」「赤と指摘を全部潰して merge-ready に」のような実装後に出荷まで丸ごと任せる要請で必ず起動すること。commit だけは `commit-commands:commit`、検証ループ不要の commit→push→PR だけは `commit-push-pr`、コードレビューだけは `code-review`、既存 PR のコメント対応だけは `pr-review-respond`、CI 修復だけは `ci-self-heal`、完了確認だけは `verify-done`、実装そのもの (設計/コーディング/未 GREEN/WIP) は上流が担い範囲外。PR は merge せず merge-ready で停止する。

実装が上流スキル (`design`/`software-design` → `tdd`/`tidy-first`) で GREEN になった後の **出荷専用ターミナルステージ**を、各フェーズを fresh subagent に dispatch するオーケストレータスキル。品質ゲート (`code-review`) → 完了ゲート (`verify-done`) → PR materialize (open PR が無ければ `commit-commands:commit-push-pr`、あれば push) → CI 緑化 (`ci-self-heal`) と自動レビュー対応 (`pr-review-respond`、CodeRabbit/Devin/Copilot/人間、CodeRabbit 修正は `coderabbit:autofix` へ委譲) を、CI 全 pass かつ全コメント終端まで回し、行き詰まったら escalate する。収束後は SHIPPED 前に `pr-monitor` を subagent dispatch し監視設置を確認する。コード修正は behavioral→`tdd` / structural→`tidy-first` の subagent にルーティングし、本スキルはコードを書かずループ制御と収束/escalation 判定だけを main で持つ。「ship して」「実装できたから後は全部やって PR 出して CI もレビュー対応も全部通してマージできる状態にして」「commit-push-pr の検証付き版で」「赤と指摘を全部潰して merge-ready に」のような実装後に出荷まで丸ごと任せる要請で必ず起動すること。commit だけは `commit-commands:commit`、検証ループ不要の commit→push→PR だけは `commit-push-pr`、コードレビューだけは `code-review`、既存 PR のコメント対応だけは `pr-review-respond`、CI 修復だけは `ci-self-heal`、完了確認だけは `verify-done`、実装そのもの (設計/コーディング/未 GREEN/WIP) は上流が担い範囲外。PR は merge せず merge-ready で停止する。

PR に投稿された自動レビュー (CodeRabbit / Devin) と人間レビュアーのコメントを取得し、各指摘の妥当性を検証したうえで対応するスキル。VALID は修正コミットを当てて該当スレッドに「Fixed in <SHA>」と返信、INVALID_PUSH は根拠付きの pushback コメントを残し resolve しない、VALID_DEFER は issue 化して参照、DUPLICATE は既存対応スレッドを指す。最後に PR へ集約サマリコメントを 1 件投稿し「何を・どう対応した／なぜ対応しなかったか」を 1 箇所で追えるようにする。`gh pr create` 直後・**既存 PR ブランチへ push した直後 (レビュー対応後の再 push を含む)**・「レビュー対応して」「コメント見て対応して」「コードラビット対応」「Devin の指摘片付けて」「PR のコメント全部捌いて」「push したのでスレッド対応して」のような要請、CodeRabbit / Devin / 人間レビュアーが新規コメントを残した時 (監視やイベントでの検知を含む)、PR を merge する前に未解決スレッドを確認したい時、いずれでも必ず起動すること。未解決スレッドが残る PR を離れる前に必ず一度起動する。レビュアー判別はコメント author と本文を読んで行い、bot suffix のような表面的なルールは持たない。本スキルは「読む・直す・返信する・サマリ投稿する」までで、レビュー自体を実行する (CodeRabbit や Devin を呼び出す) ことはしない — 既にレビュー済みの PR に後追いで対応するスキル。GitHub API 呼び出しは同梱の単一エントリ `scripts/prr` (subcommand: `fetch`/`reply`/`resolve`/`summary`/`wait-ci`) に集約しており、`allowed-tools` で consumer 側の追加 permission は不要。CodeRabbit 指摘の修正適用は coderabbit plugin がある環境では `coderabbit:autofix` に委譲し、本スキルは triage・返信・resolve・サマリに徹する。

PR に投稿された自動レビュー (CodeRabbit / Devin) と人間レビュアーのコメントを取得し、各指摘の妥当性を検証したうえで対応するスキル。VALID は修正コミットを当てて該当スレッドに「Fixed in <SHA>」と返信、INVALID_PUSH は根拠付きの pushback コメントを残し resolve しない、VALID_DEFER は issue 化して参照、DUPLICATE は既存対応スレッドを指す。最後に PR へ集約サマリコメントを 1 件投稿し「何を・どう対応した／なぜ対応しなかったか」を 1 箇所で追えるようにする。`gh pr create` 直後・**既存 PR ブランチへ push した直後 (レビュー対応後の再 push を含む)**・「レビュー対応して」「コメント見て対応して」「コードラビット対応」「Devin の指摘片付けて」「PR のコメント全部捌いて」「push したのでスレッド対応して」のような要請、CodeRabbit / Devin / 人間レビュアーが新規コメントを残した時 (監視やイベントでの検知を含む)、PR を merge する前に未解決スレッドを確認したい時、いずれでも必ず起動すること。未解決スレッドが残る PR を離れる前に必ず一度起動する。レビュアー判別はコメント author と本文を読んで行い、bot suffix のような表面的なルールは持たない。本スキルは「読む・直す・返信する・サマリ投稿する」までで、レビュー自体を実行する (CodeRabbit や Devin を呼び出す) ことはしない — 既にレビュー済みの PR に後追いで対応するスキル。GitHub API 呼び出しは同梱の単一エントリ `scripts/prr` (subcommand: `fetch`/`reply`/`resolve`/`summary`/`wait-ci`) に集約しており、`allowed-tools` で consumer 側の追加 permission は不要。CodeRabbit 指摘の修正適用は coderabbit plugin がある環境では `coderabbit:autofix` に委譲し、本スキルは triage・返信・resolve・サマリに徹する。

GitHub issue に `claude:ready` ラベルが付いた 1 件を、排他ロック → 入口ゲート (acceptance criteria 検証) → branch → 実装 → ローカルテスト green → commit → push → **PR 作成まで**ヘッドレスで完遂するワークフロー。`linear-issue-driven-development` の GitHub 移植で、最大の差分は**イベント分割**: CI を watch せず PR 作成で終了し、 CI 修正 (`ci-self-heal`) とレビュー対応 (`pr-review-respond`) は Actions のイベント トリガによる有界な反応として別途走る。acceptance criteria の無い issue は実装せず `ambiguous-issue` でエスカレートする (推測で実装しない)。エスカレーションは `needs-human` + 構造化コメント (loop-escalation:v1)、反復上限は `claude-loop:N` ラベルで PR に永続化する。Routine / Actions (ラベルイベント) からの起動が主経路。 `owner/repo#123` 形式の手動再実行、「この issue やっておいて」「claude:ready の issue を処理して」「issue から PR まで自走して」でも必ず起動すること。範囲外: Linear issue (`linear-issue-driven-development`)、対話的な実装後の出荷 (`shipping`)、 CI 修正単体 (`ci-self-heal`)、レビュー対応単体 (`pr-review-respond`)、conflict 解消 単体 (`pr-conflict-resolver`)、PR の merge (人間ゲート)。実行環境はクラウドを想定し、 素の `git` / `gh` / `jq` だけで動くこと。

GitHub issue に `claude:ready` ラベルが付いた 1 件を、排他ロック → 入口ゲート (acceptance criteria 検証) → branch → 実装 → ローカルテスト green → commit → push → **PR 作成まで**ヘッドレスで完遂するワークフロー。`linear-issue-driven-development` の GitHub 移植で、最大の差分は**イベント分割**: CI を watch せず PR 作成で終了し、 CI 修正 (`ci-self-heal`) とレビュー対応 (`pr-review-respond`) は Actions のイベント トリガによる有界な反応として別途走る。acceptance criteria の無い issue は実装せず `ambiguous-issue` でエスカレートする (推測で実装しない)。エスカレーションは `needs-human` + 構造化コメント (loop-escalation:v1)、反復上限は `claude-loop:N` ラベルで PR に永続化する。Routine / Actions (ラベルイベント) からの起動が主経路。 `owner/repo#123` 形式の手動再実行、「この issue やっておいて」「claude:ready の issue を処理して」「issue から PR まで自走して」でも必ず起動すること。範囲外: Linear issue (`linear-issue-driven-development`)、対話的な実装後の出荷 (`shipping`)、 CI 修正単体 (`ci-self-heal`)、レビュー対応単体 (`pr-review-respond`)、conflict 解消 単体 (`pr-conflict-resolver`)、PR の merge (人間ゲート)。実行環境はクラウドを想定し、 素の `git` / `gh` / `jq` だけで動くこと。

GitHub issue に `claude:ready` ラベルが付いた 1 件を、排他ロック → 入口ゲート (acceptance criteria 検証) → branch → 実装 → ローカルテスト green → commit → push → **PR 作成まで**ヘッドレスで完遂するワークフロー。`linear-issue-driven-development` の GitHub 移植で、最大の差分は**イベント分割**: CI を watch せず PR 作成で終了し、 CI 修正 (`ci-self-heal`) とレビュー対応 (`pr-review-respond`) は Actions のイベント トリガによる有界な反応として別途走る。acceptance criteria の無い issue は実装せず `ambiguous-issue` でエスカレートする (推測で実装しない)。エスカレーションは `needs-human` + 構造化コメント (loop-escalation:v1)、反復上限は `claude-loop:N` ラベルで PR に永続化する。Routine / Actions (ラベルイベント) からの起動が主経路。 `owner/repo#123` 形式の手動再実行、「この issue やっておいて」「claude:ready の issue を処理して」「issue から PR まで自走して」でも必ず起動すること。範囲外: Linear issue (`linear-issue-driven-development`)、対話的な実装後の出荷 (`shipping`)、 CI 修正単体 (`ci-self-heal`)、レビュー対応単体 (`pr-review-respond`)、conflict 解消 単体 (`pr-conflict-resolver`)、PR の merge (人間ゲート)。実行環境はクラウドを想定し、 素の `git` / `gh` / `jq` だけで動くこと。

GitHub PR で発生した merge conflict を自動修正するための手順とベストプラクティス。 PR コメントで `@claude` 経由で呼ばれた conflict 解決タスクや、ローカルでの rebase / merge conflict を解決するときに必ず参照する。チェックアウト → merge → conflict 解決 → lock ファイル再生成 → 検証 → commit で merge を確定 → push までの一連の安全な流れを、 同梱スクリプト (`scripts/*.sh`) の決定的な実行として定義する。

テスト変更を含む diff に対して静的 assertion 監査 (Phase 1) と unit テスト限定の mutation smoke (Phase 2、実コードへの変異注入 + 再実行) を行い、PASS/BLOCK を判定するゲート用スキル。tautology-literal-sharing (critical) / assertion-roulette / overstated-coverage / boundary-gap の 4 チェックを正規表現ベースで実行し、critical が 1 件でもあれば BLOCK として呼び出し元に差し戻す。加えて対象が unit テスト (プロセス内で完結・外部 I/O 無し) の場合のみ `scripts/mutate_and_run.py` で変異注入を行い、survived mutant が 1 件でもあれば BLOCK にする。主経路は `tdd` Step 3.5 (GREEN 確認後・commit 前)・`pr-review-respond` Phase C (VALID 修正のテスト側 diff)・`verify-done` Step 4 (完了宣言直前) の各本文に組み込まれた強制サブステップ呼び出しであり、ユーザからの直接要請にも対応する。「このテスト検出力ある?」「テスト弱くない?」「assertion 監査して」「tautology チェックして」「このテスト実装をなぞってるだけじゃない?」「テストがバグをロックインしてないか見て」「このテスト mutation testing して」のような口語、いずれでも必ず起動すること。テストコードの網羅的レビューは `test-review`、push 後の CI 赤対応は `ci-self-heal`、skill の eval trigger JSON 採点は `skill-builder` Mode B、テストスイート全体の mutation score 算出 (Stryker/mutmut 相当の運用) は、いずれも本スキルの範囲外。

Claude Code skill を新規作成・既存 skill のトリガ精度を測定/改善するためのメタスキル。プロジェクトの skill ディレクトリ（`.claude/skills/<name>/SKILL.md` または top-level `<name>/SKILL.md` の両形式に対応）に新しい skill を scaffold したい時、既存 skill が適切なときに発火しない / 余計な時に発火するのを直したい時、description を eval ベースで最適化したい時、trigger 性能をベースライン測定したい時、Mode C で起動後の本文品質を subagent dispatch で測りたい時、いずれでも必ず起動すること。「skill 作って」「このスキルなんで起動しない」「スキルが暴発する」「skill description 最適化」「skill の eval 作って」「メタスキル」「skill の品質測りたい」のような要請に該当する。プロジェクト規約 (CLAUDE.md / `rules/` / `AGENTS.md` 等) との整合確認も兼ね、特定プロジェクトには依存せず本スキルが置かれたリポジトリと配布先の双方で機能する。プラグインスキル（`plugins/<plugin>/skills/...`）の編集は範囲外。