Delivery Plugin

.envファイルのシークレットを1Password CLIで管理する（平文.envの保存・Git流出対策。AIからの秘匿は対象外）。migrate/run/sync/addをサポート。

言語横断で過剰抽象化や AI 生成コードの構造重複を安全にリファクタリングする。duplicated contract、pass-through layer、mirror mapper、split async path、half-migration を見つけ、最小の一貫した end-state に収束させる。TS/JS、Dart/Flutter、Elixir/Phoenix は専用 profile あり。「リファクタリングして」「AI生成コードを整理して」「重複型を統合して」「wrapperを潰して」で使用。

Issueの初期トリアージスキル。Issueを受け取り、標準化された分析結果（分類・深刻度・影響スコープ・不確実性・次アクション参照）を生成する。GitHub/Jira/Linear等のトラッカーからissue_payload形式で受け取る。トリガー条件: 「Issue #N を分析して」「このIssueの深刻度は？」「このバグはCritical？」、「Issue本文を初期トリアージして」「Issueを取り込んで」、新しいIssueを受け取り、最初の分類・判断が必要な時。注意: 根本原因の断定、修正案の確定、優先度の最終決定は行わない（材料提供まで）。

PR作成時に生成AIがPR本文にオンボーディングを記述するスキル。変更の契約を、レビューア・将来の自分・障害対応者に渡す。理解の再現性・反証可能性・運用可能性を同時に成立させる。トリガー条件: PRを作成する時（「PRを作成して」「プルリクを書いて」）、PR本文を充実させたい時（「PR説明を書いて」「PRオンボーディングして」）、変更の影響を整理したい時（「この変更の影響範囲を整理して」）、レビューの準備をする時（「レビュー用に変更をまとめて」）。

GitHub Projectの管理スキル。ghコマンドを使用してプロジェクトの確認、アイテム追加・状態変更、フィールド更新を行う。トリガー条件: 「Projectを確認して」「プロジェクトのアイテム一覧」「Project #N を見せて」、「IssueをProjectに追加」「PRをProjectに紐付け」、「ステータスをDoneに変更」「フィールドを更新」、「カンバンを操作」「タスクの進捗を更新」。

コード変更の影響範囲分析スキル。変更が引き起こし得る影響を影響面（code/interface/data/external/config/runtime/security/observability）ごとに整理し、「どこをレビューし、何をテストし、何を観測すべきか」を根拠つきで提示する。トリガー条件: 「影響範囲を分析して」「この変更の影響は？」「どこまで波及する？」、PRレビュー依頼時、リファクタ/仕様変更時、障害対応で「原因箇所の周辺影響」を確認したい時。注意: 変更の是非の最終判断は行わない。実行時にしか分からない挙動は推定と不確実性を提示する。

PRのCI失敗を自動診断・修正し、成功するまでリトライするスキル。GitHub Actionsの実際のログを取得し、エラーを構造化分類して優先順位順に修正する。トリガー条件: 「CIを修正して」「CI直して」、「PR #N のCIが落ちている」、PRのCI失敗を自動修正したい時、「CIが通るまで直して」、「/pr-ci-responder」。

コード走査中に発見したスコープ外の課題をIssue候補として構造化し、ユーザー承認後にGitHub Issueを起票する。「Issue候補を探して」「スコープ外の問題を報告して」「issue-discovererで走査して」とトリガー。

仕様誤解を早期発見する観測。仕様の曖昧さ、仮定の明文化、受入条件のテスト化を行う。Use when: 新機能設計前、要件レビュー、仕様が曖昧、何を作るべきか不明、受入条件を決めたい、PRで仕様との乖離をチェックしたい時、生成コードの受入判断時。

生成AIが人間に対して行う作業開始時オンボーディング。AIが"説明係"ではなく"進行役"として、探索→仮説→検証→要約→未確定の明示を回し、人間が最小スキーマ（因果・境界・不変条件・壊れ方・観測）を短時間で再構築できる状態に導く。トリガー条件: 新しいタスクやコード変更に着手する前（「この機能を修正して」「このバグを直して」）、未知のコードベースを理解する必要がある時、「オンボーディングして」「作業開始の準備をして」「コードを理解したい」、複雑なタスクを始める前の文脈理解が必要な時、「作戦ブリーフを作成して」「安全に始められるようにして」、AIエージェント自身の着手前チェック（preflight、要件・境界・検証・観測のボトルネック解消、ready/partial/blocked判定）が必要な時。

Generate or improve .coderabbit.yaml by analyzing project structure, languages, and conventions. Optimizes path_instructions, path_filters, tools, and knowledge_base. Triggers on "CodeRabbitを設定して", ".coderabbit.yamlを作って", "CodeRabbit設定を改善して", "レビュー設定を最適化して", or "/coderabbit-config".

コード変更に対して永続的なコメント（Why・制約・境界条件）を自動付与する。差分の依存グラフを解析し、2パス処理（意図マップ構築→役割別コメント生成）でレビュアーと将来の開発者の理解を助ける。「コメントを付けて」「アノテーションして」「レビューしやすくして」「comment annotation」と言われた時に使用する。

LLM生成システムの検証設計スキル。assay-kitフレームワークを活用し、LLM特有の失敗モード（幻覚、例への過学習、部分的処理）を考慮した総合的なテストケース設計を支援する。使用タイミング: LLMベースのワークフロー/エージェントの評価設計時、ゴールデンデータセット（golden-dataset.yaml）の設計・拡張時、既存テストが特定パターンに過学習していないか検証時、LLM出力の品質スコアラー設計時、「なぜこのテストケースが必要か」の根拠を示す時。

Harness Engineering environmentを設計・scaffold・validateする。AI/agent eval と integration/regression harness の共通基盤を作り、cases・fixtures・reporting・CI・devcontainer を整える。Use when 「Harness環境を作って」「評価ハーネスを整備して」「回帰検証環境を構築して」 or 「benchmark/eval harness を仕込んで」と言われた時。

現在の作業ブランチへ既定でmainを取り込み、必要ならコンフリクト解消まで進める。mainの取り込み、最新mainの反映、merge main、コンフリクト解消、resolve merge conflicts を依頼された時に使用する。

PRコメント（レビュー/インライン/CodeRabbit outside diff range含む）を収集・分類し、優先順位に従って対応・返信を実行する

境界条件・エッジケースの観測。null/空/0/最大値/最小値/オーバーフロー/タイムゾーン等を網羅的にテスト。Use when: テスト設計、バリデーション実装、パーサー実装、日付/金額処理、例は通るが端で壊れる疑い、バグ修正後の再発防止。

Perform critical code review with 6-phase pipeline (context gathering, static analysis, LLM review with verification, automated fix flow). Use when reviewing code changes, pull requests, specific files, or branch diffs. Triggers on "review this code", "critical review", "code review for PR

セキュリティ観測。認可漏れ、インジェクション、機密漏えい、暗号誤用、依存脆弱性を検出。Use when: 認証/認可実装、外部入力処理、依存更新、コミット前チェック、セキュリティレビューして、脅威分析が必要な時。

依存関係の取り違えを検出する観測。lockfile固定、クリーンビルド、統合スモークで再現性を担保。Use when: 依存追加/更新、CI設定、ローカルでは動く問題、新環境セットアップ、バージョン差異の疑い。

ユニットテストとPBT（Property-Based Testing）を組み合わせた体系的テスト設計スキル。「脳を使う場所」を原因推理から「プロパティとジェネレータの設計」へ移動させる。4つの成果物（ユニットテスト、プロパティカタログ、ジェネレータ群、反例コーパス）を固定し、意地悪レベル（L0-L8）を段階的に上げながら、反例を資産化して回帰テストに回収する。トリガー条件: 「体系的にテスト設計して」「テストを設計して」、「PBTでテスト設計して」「プロパティベーステストを書いて」、「ユニットテストを設計して」「テストケースを作成して」、「テストをもっと意地悪にして」「境界値を網羅して」、「ジェネレータを設計して」「反例を資産化して」、「テストの穴を探して」「プロパティカタログを作成して」、ELD v5のfailure-path Claimをtest/integration Evidenceで接地する時。

不確実性を発見・台帳化し、優先順位付け・観測タスク化を経て、検証結果をDecision proposalと必要に応じたproposed Lawへ整理する。使用タイミング: 不確実性/曖昧さ/未知/仮説/検証/調査/リスク/前提/優先順位/観測/意思決定の話題が出たとき。観測結果をaccepted Lawへ自動昇格しない。

コードのAI可読性を分析し、生成AIがバグ修正や変更を行う際に苦戦する原因となる問題を特定するスキル。以下の場合に使用する：(1)「AIが修正しやすいコードか分析して」「AI可読性を診断して」と依頼された時 (2) バグ修正や変更作業が難航している原因を調査したい時 (3) コードベースのAIフレンドリー度を評価したい時 (4) リファクタリング優先度を決めたい時。分析観点：コンテキストウィンドウ問題、命名・表現問題、構造・設計問題、テスト・検証問題、ドキュメント問題、LLM特有の苦手パターン

並行性の観測。データレース、デッドロック、タイミング依存バグを検出。Use when: async/await実装、スレッド/goroutine使用、共有状態操作、本番でだけ起きる問題、たまに落ちるテスト調査。

観測の最小セットを適用。6つの失敗モード（仕様誤解/境界条件/依存/セキュリティ/並行性/運用）を継続可能なコストで網羅。Use when: プロジェクト開始、リリース前チェック、品質改善振り返り、観測が足りているか確認したい。

運用観測性の確保。ログ、メトリクス、ヘルスチェック、設定検証でバグを扱う能力を担保。Use when: デプロイ前チェック、障害調査が困難、原因不明、ログ設計、メトリクス設計、設定管理実装。

Issueワークフロー統括スキル。Issue受領から実装・検証・PRレビュー完了までを、分類に応じたテンプレートで統括し、フェーズ成果物を構造化して引き継ぎながら進行する。トリガー条件: 「Issue #N を修正して」「#N を直してPRまで」「/fix-issue 123」「/orchestrate-issue 123」Issue修正の全体統括が必要な時。注意: 実装そのもの、コード生成、レビュー判断の最終決裁は行わない（該当スキルへ委譲し、統括は状態と根拠の整合性を担保する）