security-scan-db

GitHub Flow のブランチ戦略・Conventional Commits（日本語）・PR / Issue の書式・AI ツール痕跡の禁止など Git 運用規約。Git 系エージェント（branch-master / commit-helper / pr-author /…

変更コード（または指定ファイル）を、クリーンアーキテクチャ・プロジェクト規約・正確性・セキュリティの観点で総合レビューする。差分の領域（サーバ / フロント / DB）に応じて review-server / review-frontend / security-scan-* へ振り分け、結果を統合して返す。

4 層クリーンアーキテクチャ（domain / application / infrastructure / presentation）の依存方向・層ごとの責務・DI・Clock port・エラーハンドリングの原則。言語 / フレームワーク非依存の共通基準で、設計・実装・レビュー系エージェントが前提として読む。

SDD（仕様駆動開発）の工程・成果物・エージェント分担と、成果ドキュメントを `.docs/specs/<日時>-<機能>/` へ集約する規約。プラグインの各エージェントが前提として読む背景知識。

プロジェクトの .claude/rules（paths 付きのスタック制約）・.claude/docs・固有エージェント / スキル・CLAUDE.md を追加・修正するとき、または sdd-harness プラグイン本体を改修するときに使う。ハーネス整備のメタ作業。

精緻化された要件から、クリーンアーキテクチャ 4 層 + UI の構成・データモデル・サーバ入口 / コンポーネント設計・影響範囲・実装タスク分解を設計（壁打ち）するときに使う。設計書（.docs/specs/<...>/design.md）は出力するがソースコードは変更しない。

ヒアリング済みの要件メモを、機能 / 非機能要件・受け入れ条件・ドメイン概念・権限マッピング・スタック制約へ精緻化し、設計に渡せる仕様にするときに使う。ソースコードは変更しない。

新機能の要件が曖昧なときに、要件定義の前段として壁打ちし、抜け漏れを洗い出す構造化された質問を作り、回答を要件メモ（.docs/specs/<...>/requirements.md）にまとめるときに使う。ソースコードは変更しない。

設計（design.md）に基づき新機能を domain → application → infrastructure → presentation → frontend → テスト の順で一気通貫に実装するときに使う。

規約に沿ったブランチの作成・切り替え・整理を行うときに使う。新規作業の開始時や既定ブランチ（main）上で作業しそうなときに。

DB のデータモデルを設計する段階（エンティティ抽出・リレーション・正規化・インデックス・制約・監査カラム）で使う。設計書は .docs/specs/<...>/db-design.md。実装は db-engineer に渡す。

ORM スキーマ定義の変更・マイグレーション・クライアント生成・モデル↔エンティティ mapper・リポジトリ実装（ORM 部分）を行うときに使う。