delivery-plugin

Issue起点のワークフロー全体を制御するエージェント。issue-intakeによるトリアージ、 impact-analysisによる影響分析、ai-led-onboardingによる文脈構築、eld-sense-planningに よるタスク分解を統合し、Issue→PR完了までを一貫して管理する。 使用タイミング: (1) 「Issue #N を対応して」、(2) 「このIssueを解決して」、 (3) Issue起点で作業を開始する時、(4) 複数スキルを連携させてIssue対応したい時

現在の状況を分析し、必要な観測スキルを選択・実行する。6つの失敗モード （仕様誤解/境界条件/依存/セキュリティ/並行性/運用）に基づき適切な観測を起動。 使用タイミング: (1) 「必要な観測をして」、(2) 「観測して」、 (3) 実装前後のチェック、(4) リリース前チェック、(5) 問題調査時

PRのCI失敗を自動診断・修正し、成功するまでリトライするエージェント。 GitHub Actionsの実際のログを取得し、エラーを構造化分類して優先順位順に修正する。 使用タイミング: (1) 「CIを修正して」「CI直して」、(2) 「PR #N のCIが落ちている」、 (3) PRのCI失敗を自動修正したい時、(4) 「CIが通るまで直して」

PRのすべてのコメントを収集・分類し、優先順位に従って対応を実行するエージェント。 コード修正、質問への回答、コメント返信を自動化する。 使用タイミング: (1) 「PRのコメントに対応して」、(2) 「PR #N のレビュー指摘を修正して」、 (3) PRレビュー後に指摘事項への一括対応が必要な時、(4) 「レビューフィードバックを解決して」

AIエージェントのコーディング着手前に、要件・コンテキスト・境界・検証・観測のボトルネックを診断し、今すぐ解消できる前処理と解消アクション付きブリーフを生成する。Use when: 新しいタスク開始前、実装前の準備、着手前チェック、preflight、作業開始のボトルネックを解消したい時、詰まりを先に潰してから着手したい時。

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

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

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

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」と言われた時に使用する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Analyze code for refactoring opportunities (complexity, coupling, SOLID violations) and safely execute improvements with test-first verification. Use when auditing code quality, investigating design problems, or performing incremental refactoring with continuous validation. Supports analyze-only mode or full execution with rollback. (project, gitignored)

AI支援作業中に、上位スキーマの強化と下位スキーマの維持を両立する。問題分解・仕様固定・比較評価を進めつつ、局所因果・成立条件・障害モードの理解を薄く強制する。Use when: AIで実装や修正を進める時、メンタルモデルを保ちたい時、AI任せで理解が浅くなるのを防ぎたい時、レビュー前に変更の成立性を点検したい時。

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

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

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

ELD統合版テスト設計監査スキル。Law/Term駆動でテスト設計の抜け漏れを防止する。 モデル化とEvidence Ladderを組み合わせ、法則の接地を体系的に検証する。 Use when: - テスト設計、テスト計画作成、QA開始前 - ELDのGroundフェーズでのテスト設計 - Law/Termの接地検証 - 「テスト漏れがないか不安」と感じた時

不確実性を発見・台帳化し、優先順位付け・観測タスク化を経て、検証済み仮説をLaw（LDE）に昇格させる。使用タイミング: 不確実性/曖昧さ/未知/仮説/検証/調査/リスク/前提/優先順位/観測/意思決定の話題が出たとき、または検証結果のLaw化を求められたとき。