DDDの集約(Aggregate)設計ルールに基づくコードレビュー・設計支援・リファクタリングを行う。 Evans Rules、Vernon's 4 Rules、Design by Contractに基づき、集約の境界定義、不変条件の検証、 不変(Immutable)設計、ID参照、結果整合性、ドメインイベント連携を包括的にガイドする。 以下のいずれかに該当する場合は必ずこのスキルを使用すること: - 集約(Aggregate)の新規設計・実装・リファクタリング(どの言語でも) - 既存の集約やエンティティクラスのDDD観点でのコードレビュー - 集約の境界決定(「AとBは同じ集約にすべきか?」「この集約は大きすぎるか?」) - 集約内の不変条件・整合性境界の設計 - 集約間の連携方式の判断(ドメインイベント、結果整合性、Sagaパターン) - 可変(Mutable)な集約コードを不変(Immutable)設計にリファクタリングする - publicフィールド、直接参照、push/appendなどカプセル化違反の検出・修正 キーワード例:集約、Aggregate、aggregate boundary、集約ルート、AggregateRoot、 エンティティ設計、DDD実装、Vernon Rules、Evans Rules、集約の分割、真の不変条件
pr-green
Pull Request をグリーンにするスキル。CI チェックの失敗解消と、PR に紐づく Issue の 修正・クローズを一括で実行する。
GitHub Actions の CI ログ分析、ローカル CI (`./scripts/ci-check.sh`)の実行、エラーの根本原因特定と修正、PR コメントや リンクされた Issue の解消を含む。解消した Issue は確認後にクローズする。
ループモード(`/loop 5 /pr-green`)にも対応し、自律的に CI 監視・修正・プッシュを繰り返す。
トリガー:「PR をグリーンにして」「CI を通して」「CI エラーを直して」 「PR の issue を解消して」「PR を修正して」「CI が落ちている」「テストが失敗している」 「PR のレビュー指摘を直して」「PR を mergeable にして」 といった PR 修正・CI 解消関連リクエストで起動。
PR 番号が指定されなくても、 現在のブランチから自動検出して対応する。
含まれるファイル(1)
- SKILL.md6.4 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
PR Green スキル
PR の CI チェック失敗と紐づく Issue を解消し、PR をマージ可能な状態にする。
動作モード
| モード | 起動方法 | 振る舞い |
|---|---|---|
| 対話モード | /pr-green or 「CI を直して」 | 状況報告→ユーザー確認→修正→確認→プッシュ |
| ループモード | /loop 5 /pr-green | 自律的に監視・修正・コミット・プッシュ。問題なければ即終了 |
/loop 経由で呼ばれた場合はループモードとして動作する。判断がつかない場合は対話モードとする。
モード別の振る舞いの違い
| 判断ポイント | 対話モード | ループモード |
|---|---|---|
| 状況サマリー | 詳細に表示し確認を取る | 問題がある場合のみ簡潔に表示 |
| 修正前の確認 | ユーザーに方針確認 | 確認なしで修正を開始 |
| コミット・プッシュ | ユーザー確認後 | 自動 |
| Issue クローズ | 一覧提示→承認後クローズ | 自動クローズ(コメント付き) |
| 問題なしの場合 | 「すべてグリーンです」と報告 | 何も出力せず即終了 |
| 結果報告 | 詳細な修正レポート | 修正した場合のみ簡潔に報告 |
| 判断困難な問題 | ユーザーに相談 | スキップして報告 |
ワークフロー
ステップ 0: PR の特定
引数で PR 番号が指定されていればそれを使う。指定がなければ現在のブランチから自動検出する。
gh pr view --json number,title,state,statusCheckRollup,url,headRefName
PR が見つからない場合は報告して終了する。
ステップ 1: 状況の把握
1a. CI チェックの状態確認
gh pr checks <number>
# 失敗した CI の詳細ログ(run-id は checks 結果から特定)
gh run view <run-id> --log-failed
1b. PR に紐づく Issue の確認
PR レビューコメント(CodeRabbit 等のボットレビュー含む):
gh api repos/{owner}/{repo}/pulls/<number>/reviews --jq '.[] | select(.state != "APPROVED") | {user: .user.login, state: .state, body: .body}'
gh api repos/{owner}/{repo}/pulls/<number>/comments --jq '.[] | {user: .user.login, body: .body, path: .path, line: .line, created_at: .created_at}'
PR にリンクされた Issue:
gh pr view <number> --json closingIssuesReferences --jq '.closingIssuesReferences[] | {number, title}'
1c. 早期終了判定(ループモード)
以下の条件をすべて満たす場合は何もせず即終了する:
- CI チェックがすべて成功(PASS)または実行中(PENDING)
- 未対応のレビューコメントがない
- リンクされた Issue がすべてクローズ済み
CI が実行中(PENDING)の場合も即終了 — 次のループ周回で結果を確認する。
1d. 状況サマリー(対話モードのみ)
対話モードでは状況サマリーを表示し、対応方針の確認を取る。
ステップ 2: CI エラーの解消
CI エラーを分類し、優先度順に対応する。
| 優先度 | エラー種別 | 再現コマンド |
|---|---|---|
| 1 | コンパイルエラー | エラーメッセージから直接特定 |
| 2 | lint / fmt | ./scripts/ci-check.sh ai lint, ./scripts/ci-check.sh ai dylint |
| 3 | テスト失敗 | ./scripts/ci-check.sh ai unit-test, ./scripts/ci-check.sh ai integration-test |
| 4 | clippy | ./scripts/ci-check.sh ai clippy |
| 5 | doc テスト | ./scripts/ci-check.sh ai doc |
各エラーに対して:再現→分析→修正→同じコマンドで検証。
ステップ 3: PR の Issue 解消
3a. レビューコメントへの対応
指摘箇所のコードを読み、指摘に沿って修正する。
3b. リンクされた Issue への対応
Issue 本文から対象コード・問題・期待動作を抽出し、修正・検証する。
3c. 解消済み Issue のクローズ
gh issue close <number> --comment "$(cat <<'EOF'
## 解決確認
- PR: #<pr-number>
- 修正内容: <具体的な修正の説明>
- 確認方法: <テスト結果やコード確認の根拠>
本 PR の修正により解消されたためクローズします。
EOF
)"
対話モードではクローズ前にユーザー承認を取る。ループモードでは自動クローズする。
ステップ 4: コミット・ローカル検証・プッシュ
修正した箇所に関連するチェックのみローカルで再実行する。 フルチェックはローカルでは実行しない — CI に任せる。
対話モードではコミット・プッシュ前にユーザー確認を取る。ループモードでは自動で行う。
プッシュ後の CI 結果は、次のループ周回(ループモード)または gh pr checks --watch(対話モード)で確認する。
ステップ 5: 結果報告
対話モード: 修正内容・Issue 対応・残存事項の詳細レポート。
ループモード: 修正があった場合のみ簡潔に1行報告。修正なし(早期終了)の場合は出力なし。
完了条件
- CIエラーがないこと
- PRについたコメント/issueが解決できていること
- ボーイスカウトルールを適用すること
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
集約とトランザクション境界の関係を明確化し、複数集約を単一トランザクションに含めるアンチパターンを 検出・是正する。集約は強い整合性境界であり、ユースケースで複数集約を更新する場合は結果整合性を 使うべきという原則を適用する。コードレビュー、ユースケース設計、リファクタリング時に トランザクション境界の問題を検出する場合に使用。 対象言語: 言語非依存(Java, Kotlin, Scala, TypeScript, Go, Rust, Python等すべて)。 トリガー:「複数集約を同じトランザクションで更新している」「ユースケースに@Transactionalがある」 「集約間の整合性をどう取るか」「Sagaパターンを使うべきか」「トランザクション境界の設計」 「1トランザクション1集約」「結果整合性の実装」「集約をまたぐトランザクション」 といったトランザクション境界関連リクエストで起動。
後方互換性がゴミコードを量産する構造を検出し、互換性を「契約と撤去計画」として管理する ガバナンスを支援するスキル。公開API境界の明確化、非推奨化サイクル(deprecation cycle)の 制度化、互換層の局所化(Adapter/Strangler Fig)、契約テスト(CDC)による互換性検証、 AI生成コードの互換性ゲート設計を含む。コードレビュー、API設計、リファクタリング、 レガシー移行時に互換性起因の技術的負債を防ぐために使用。 対象言語: 言語非依存(Java, TypeScript, Go, Python, Rust等すべて)。 トリガー:「後方互換性を保ちたい」「非推奨APIをどうする」「互換層が増えてきた」 「レガシー移行の戦略」「API設計レビュー」「互換性のためのコードが多い」 「deprecation policyを作りたい」「破壊的変更の管理」といった互換性管理関連リクエストで起動。
getterの濫用を防ぐための命名規約スキル。ドメインモデルでgetterが必要な場合(永続化、JSON変換など)に `breachEncapsulationOf` プレフィックスを付与することで、カプセル化を破っていることを明示する。 これにより、Tell Don't Ask原則の違反を未然に防ぎ、getterの意図しない使用を抑制する。 コードレビュー、新規実装、リファクタリング時にgetter設計が必要な場合に使用。 対象言語: Java, Kotlin, Scala, TypeScript, Python, Go, Rust。 トリガー:「getterの命名規約」「カプセル化を破るgetter」「永続化用のgetter」 「breachEncapsulation」「getterを作りたいが濫用を防ぎたい」といったgetter命名関連リクエストで起動。
クリーンアーキテクチャを採用しているプロジェクト向けの設計・レビュー支援。4層構造(ドメイン層、 ユースケース層、インターフェースアダプタ層、インフラストラクチャ層)に基づく。特にインフラ層は 横断的関心事(ロギング、設定管理)のみ、永続化やRPCはインターフェースアダプタ層に配置すべき という原則を適用する。トリガー:「クリーンアーキテクチャで」「クリーンアーキテクチャに従って」 「クリーンアーキテクチャのレビュー」など、クリーンアーキテクチャを明示的に指定した場合のみ起動。 一般的な「設計レビュー」「アーキテクチャ相談」では起動しない。
CQRS/ESが集約の境界定義とモデリングに与える影響を解説する。CQRSを導入すると集約は コマンド実行に必要な最小限の状態のみ保持すればよくなり、読み取り責務はリードモデルに 委譲できる。大きすぎる集約の軽量化、集約境界の再定義、イベントによる状態管理を支援する。 集約設計、CQRS導入時のモデリング見直し、パフォーマンス問題の解決時に使用。 対象言語: 言語非依存。 トリガー:「CQRSで集約が変わる」「集約が大きすぎる」「集約にメッセージ1000件」 「集約の更新が重い」「CQRS導入で集約を見直す」「集約を軽量化したい」 「集約にクエリ用データが混ざっている」「集約の境界を再定義」 といったCQRS/モデリング関連リクエストで起動。