Ddd review

Skill dskst/ddd-skills/skills/ddd-review

コードの変更差分・PR・指定ファイルを DDD 観点でレビューするワークフローを実行する。次のような依頼があったときに使う:「DDD観点でレビューする」「DDDレビューをする」「この変更をDDDの観点で見る」「PRをDDDでレビューする」「コミット前にDDDチェックをする」「ドメインモデルの変更をレビューする」「diffをDDD観点で確認する」。または、DDDレビュー、DDD観点のコードレビュー、ドメインモデルのレビューに言及する場合にも使う。From its SKILL.md

Install

npx -y skills add dskst/ddd-skills --skill ddd-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

7.1 KB, as published. Nobody here has run it

DDDレビュー

コードの変更差分・PR・指定ファイルを DDD 観点でレビューするワークフローを実行する。

位置づけ: 本スキルは差分中心の軽量なレビューワークフローである。コードベース全体の網羅的な分析が必要な場合は、専門エージェント（ddd-reviewer / anti-pattern-detector / architecture-checker / evolvability-assessor）へ委譲する。

ワークフロー

1. レビュー範囲の決定

引数と作業状態から対象を決める:

レビュー対象は何か？
├─ 引数でファイル・ディレクトリが指定されている → そのファイル群
├─ 引数でPR番号・ブランチが指定されている       → gh pr diff / git diff <branch>
├─ 引数なし・未コミットの変更がある             → git diff（staged + unstaged）
├─ 引数なし・作業ツリーがクリーン               → 直近コミット（git show HEAD）
└─ 「全体をレビュー」と明示された               → エージェントへ委譲（後述）

差分だけでは文脈が不足するため、変更されたクラスの全体と、その呼び出し元・呼び出し先を必ず読んでから判定する。

2. 観点別チェック

差分に対して以下の5観点を順に検証する。各観点の詳細な判断基準は対応するスキルにある。

観点A: ユビキタス言語（ubiquitous-language）

新しい名前（クラス・メソッド・変数）はドメイン用語と一致しているか
用語集（glossary）があるプロジェクトでは、用語集との整合が取れているか
CRUD 語彙（create/update/set/get/data/info）でビジネス操作を命名していないか
同じ概念に複数の名前、別の概念に同じ名前を使っていないか

観点B: レイヤー責務（domain-classifier）

追加されたロジックは正しい層に配置されているか（判定ツリーを適用する）
ドメイン層に ORM・フレームワーク・外部クライアントの import が増えていないか
コントローラ/ハンドラがリポジトリを直接呼んでいないか
ビジネスルールがユースケース層に書かれていないか

観点C: 戦術パターン（entity-design / value-object / domain-service / repository-design / exception-design）

エンティティ: 公開セッター追加・貧血化の兆候はないか。状態変更はビジネスメソッド経由か
Value Object: プリミティブ型のままのドメイン値はないか。不変性・自己検証は保たれているか
ドメインサービス: エンティティに置けるロジックを吸い上げていないか（最後の手段の原則）
リポジトリ: 集約ルート単位か。クエリの肥大化はないか
例外: ドメイン例外として表現すべきエラーを汎用例外で投げていないか

観点D: 集約と整合性（aggregate-design / domain-event）

1トランザクションで複数の集約を更新していないか
集約間の参照が ID ではなくオブジェクト参照になっていないか
不変条件の検証を迂回する経路が増えていないか
ドメインイベントの命名は過去形でビジネス的に意味があるか

観点E: アンチパターンの兆候

差分に anti-pattern-detector の8パターン（Anemic Domain Model、Repository per Entity、Leaking Infrastructure、God Aggregate、Skipping Ports、CRUD Thinking、Premature CQRS、Cross-Aggregate Transaction）の兆候がないかを確認する。兆候があれば該当箇所のみ精査し、広がりが疑われる場合はエージェント起動を提案する。

3. エージェントへの委譲

以下の場合は差分レビューに留めず、専門エージェントを起動する:

状況	起動するエージェント
コードベース全体の DDD 準拠度を評価したい	ddd-reviewer
アンチパターンの全体スキャンが必要	anti-pattern-detector
レイヤー構造・依存方向の検証が必要	architecture-checker
変更容易性・テスタビリティの評価が必要	evolvability-assessor

差分レビューで重大な問題（Critical）を複数検出した場合も、影響範囲の特定のためにエージェントの起動を提案する。

出力フォーマット

所見（問題ごと）

[CRITICAL|WARNING|INFO] {file_path}:{line_number}
  観点: {A-Eのいずれか}
  問題: {何が問題か}
  原則: {違反しているDDD原則}
  修正案: {具体的な修正方法。可能なら修正前/修正後のコードを添える}

重大度の基準:

CRITICAL: 不変条件の破壊、集約をまたぐトランザクション、インフラの漏れなど、放置するとドメインモデルの信頼性が崩れるもの
WARNING: 貧血化の兆候、CRUD 命名、配置の誤りなど、蓄積すると設計が劣化するもの
INFO: 改善提案、より DDD らしい表現の提示

サマリー

## DDDレビュー結果

対象: {差分の範囲}

| 観点 | 結果 | 所見数 |
|------|------|--------|
| A. ユビキタス言語 | ✅ / ⚠️ / ❌ | N |
| B. レイヤー責務 | ✅ / ⚠️ / ❌ | N |
| C. 戦術パターン | ✅ / ⚠️ / ❌ | N |
| D. 集約と整合性 | ✅ / ⚠️ / ❌ | N |
| E. アンチパターン | ✅ / ⚠️ / ❌ | N |

### 必ず修正（Critical）
### 修正を推奨（Warning）
### 良い変更（維持すべき点）
### 次のアクション
{修正に使える関連スキル（例: 貧血化 → ddd-refactoring）を案内する}

レビューの品質基準

証拠（ファイルパス・行番号・コード）なしに指摘しない
差分に含まれない既存コードの問題は、変更と関係する場合のみ言及する
意図的なトレードオフ（コメントや ADR で説明されているもの）は違反と区別する
問題の指摘には必ず修正案を添え、修正に使える関連スキルを案内する
良いプラクティスも明示的に評価する

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.