code-quality-audit

コード品質監査

一貫したツールとレポートを使用して、Drupal および Next.js プロジェクトの品質監査とセキュリティ監査を実施します。

読み取り方針： 監査、レビュー、セキュリティ、SOLID、DRY の各コマンドは Type B の作業（監査／レビュー／アーキテクチャ分析）に該当するため、エージェントはソースファイルと設定ファイルをすべて読み込む必要があります。これらの作業では、最初に grep を実行しないでください。継承されたメソッド、アノテーション、設定によって紐付けられたクラスは、grep を最初に実行する方法では見つかりません。https://camoa.github.io/dev-guides/development/reading-strategy/ を dev-guides-navigator 経由で参照してください。コードインテリジェンスプラグインがインストールされている場合、LSP ツールは継承や設定による紐付けをセマンティックに解決します。SOLID／DRY／レビューで関係性を確認する場合は、こちらを優先し、利用できない場合はファイルをすべて読み込む方法に切り替えてください。references/code-intelligence.md を参照してください。

クイックコマンド

コマンドを直接実行するには、以下を使用してください。

• /code-quality-tools:setup - 初回セットアップウィザード（ツールのインストールと設定）
• /code-quality-tools:audit - 完全な監査を実行（全 22 項目）
• /code-quality-tools:coverage - テストカバレッジを確認
• /code-quality-tools:security - セキュリティスキャンを実行（Drupal は 10 層、Next.js は 7 層）
• /code-quality-tools:lint - コード規約を確認
• /code-quality-tools:solid - アーキテクチャと SOLID 原則を確認
• /code-quality-tools:dry - コードの重複を検出
• /code-quality-tools:tdd - TDD ワークフローを開始（テストウォッチャーモード）
• /code-quality-tools:review - ルーブリック採点によるコードレビュー（/50 点満点、品質ゲート付き）
• /code-quality-tools:ultrareview - クラウド上の複数エージェントによる詳細レビューを、事前チェック付きで実行（5～10 分、無料枠を超えると有料）
• /code-quality-tools:generate-review-md - Claude Code の管理対象コードレビュー用に v2 REVIEW.md を生成
• /code-quality-tools:architecture-debate - アーキテクチャについて議論（プラグマティスト + ピューリスト + メンテナー）
• /code-quality-tools:security-debate - セキュリティについて議論（ディフェンダー + レッドチーム + コンプライアンス）

会話形式のワークフローについては、このまま読み進めてください……

監視モードのリンティング（スキルスコープ）

このスキルのフロントマターでは、スキルスコープのフックを2つ宣言しています。これらのフックが有効なのは、スキルの読み込み中のみであり、プラグイン全体には適用されません。

イベント	タイミング	内容
FileChanged	リンター設定が変更されたとき — 一般的な形式の正確なファイル名：composer.json、package.json、phpstan.neon*（3種類）、phpcs.xml*（3種類）、psalm.xml*（2種類）、eslint.config.{js,mjs,cjs}、.eslintrc.{js,json,yml,yaml}、tsconfig.json	hooks/lint-changed.sh を実行します — 設定変更時に再度リンティングし、watchPaths に含まれるソースファイルが変更された場合は、そのファイルのみをリンティングします
PermissionDenied	自動モードで Read、Grep、Glob が拒否されたとき	{retry: true} を返します — 監査中に発生した、破壊的操作ではない分類の拒否を再試行します

スコープの適切な管理： これらのフックはスキルが呼び出されたときに登録され、セッションの残りの間は動作し続けます。スキルが非アクティブになっても停止しません。スキルスコープによって制御できるのは呼び出しのゲートであり、停止スイッチではありません。プラグインスコープの FileChanged ハンドラーは、プラグインが有効なすべての会話でセッション開始時から動作し、監査を依頼していないユーザーのファイル変更にも反応します。ここで宣言すれば、誰かが実際にスキルを呼び出すまで何も実行されません。セッション中に監視モードを停止するには、以下の CLAUDE_CODE_QUALITY_WATCH=0 を使用してください。また、ハンドラーの初回成功時に Claude Code に削除させたい場合は、フックハンドラーに once: true を指定してください。once が適用されるのはスキルのフロントマター内だけであり、繰り返し実行することを意図した監視モードのリンティングには適していません。

FileChanged のマッチャーはリテラルであり、グロブではありません。 Hooks Reference によると、FileChanged のマッチャー値は | で分割され、リテラルなファイル名として登録されます。グロブではありません。任意のソースファイル（*.php、*.tsx）を監視するには、CwdChanged フックから動的に watchPaths を設定するか、プロジェクトの .claude/settings.json に特定の絶対パスを追加してください。ここでのデフォルトの監視リストはリンター設定の変更を対象としているため、ソースの編集時にもファイルごとに監視したい場合は、設定で対象を広げてください。

セッション中に強制的に無効化する場合：

export CLAUDE_CODE_QUALITY_WATCH=0

再度有効にするには、変数の設定を解除するか、0 以外の値を設定してください。

これが hooks/hooks.json に含まれていない理由： プラグインスコープのフックは呼び出しを必要とせず、プラグインが有効なすべてのセッションで有効になります。そこに属するのは PreCompact のみです。監査が実行されたかどうかにかかわらず適用されるべきだからです。監査を依頼していないユーザーに監視モードのリンティングを実行しないよう、ここで宣言しています。

既知の制限事項

• 敵対的なクローン内でのnpx。 攻撃者が管理するpackage.jsonリポジトリでスキルを読み込み、設定ファイルを編集すると、ウォッチモードのディスパッチャーがそのツリーからnpx --no-install eslintを実行します。トロイの木馬化されたnode_modules/.bin/eslintが実行されるおそれがあります。対策：lint-changed.shの封じ込めガードはcwd外のパスを拒否しますが、リンター自体をサンドボックス化することはできません。信頼できないチェックアウトでは、このスキルを読み込まないでください。
• PermissionDeniedの再試行は、Read|Grep|Globに対して無条件に実行されます。 マッチャーは利用可能な中で最も厳密な仕組みです。「監査ツールの呼び出し中のみ」といった、より細かなフィルターはありません。スキルの読み込み中に、無関係な読み取り専用操作の拒否に対しても通知されることは許容しています。
• --jsonの出力はモデルが生成します。 スキーマには必須の形式とJSONエスケープ（references/json-schemas.mdのinvariant 4）が記載されていますが、契約の遵守はモデルに委ねられています。ドキュメントを信頼する前に、利用側でjq .を実行してください。
• FileChangedマッチャーはファイル名をリテラルで照合します。 リストにないバリエーション（例：phpstan.local.neonやカスタム名）では実行されません。より広範囲にソースファイルを監視する必要がある場合は、CwdChangedフックからwatchPathsを動的に設定してください。

注 — Claude Code組み込みの/simplify： Claude Codeには、1回で素早くコードレビューを行う組み込みの/simplifyスキルが付属しています。/code-quality-tools:reviewは異なり、自動ツール（PHPStan/ESLint）を実行し、10項目の評価カテゴリを/50の尺度で採点し、品質ゲート（PASSは35以上／FAIL）を適用して、保存されるレポートを作成します。手早くその場でフィードバックを得るには/simplifyを、構造化され、採点され、記録に残る評価が必要な場合は/code-quality-tools:reviewを使ってください。

注 — security-guidanceプラグインとネイティブの/security-review： このスキルのセキュリティフロー（/code-quality-tools:security、各種ディベート）は、コードベース全体／CI SASTのレイヤーです。フレームワークを認識する複数のツールで、ツリー全体をスキャンします。これらは、Claude Codeの多層防御モデルにおける2つのネイティブレイヤーより下位に位置します。公式のsecurity-guidanceプラグインは、Claudeが自身の編集内容を書き込む際にレビューします（編集ごと／ターン終了時／コミット時に自動実行され、コマンドは不要です。/code-quality-tools:setupから利用できます）。ネイティブの/security-reviewは、必要に応じて差分に限定した汎用スキャンを1回実行します。また、Claude Securityプラグインは、リポジトリ全体（または依頼に応じて差分）を複数のエージェントで詳細にスキャンし、SARIFを出力して、自動適用は決して行わないパッチを提案します。そのドキュメントでは、既存のスキャナーを置き換えるのではなく、別個のCI段階として維持するよう記載されており、検出結果は実行ごとに一定ではありません。これらのレイヤーは、ツリー全体のスキャンに到達する問題を減らしますが、スキャンに取って代わるものではありません。/security-reviewでは、Drupal/Next.jsのリポジトリ全体を対象としたSAST、汚染解析、依存関係のCVE検出、複数エージェントによるOWASPディベートは実行できません。ネイティブレビューでは対応できない、フレームワーク固有のコードベース全体のカバレッジを得るには、このスキルのセキュリティ監査を実行してください。

使用する場面

Drupalプロジェクト：

• 「品質ツールをセットアップ」／「PHPStanをインストール」
• 「コード監査を実行」／「コード品質をチェック」
• 「カバレッジを確認」／「カバレッジはどのくらい？」
• 「SOLID原則への違反を検出」／「複雑度をチェック」
• 「重複をチェック」／「DRYチェック」
• 「コードをリント」／「コーディング規約をチェック」
• 「非推奨箇所を修正」／「Rectorを実行」
• 「TDDを開始」／「RED-GREEN-REFACTOR」
• 「セキュリティをチェック」／「脆弱性を検出」／「OWASP監査」

Next.jsプロジェクト：

• 「品質ツールをセットアップ」／「ESLintをインストール」
• 「コード監査を実行」／「コード品質をチェック」
• 「カバレッジを確認」／「Jestのカバレッジを実行」
• 「SOLID原則への違反を検出」／「複雑度をチェック」／「循環依存をチェック」
• 「コードをリント」／「ESLintを実行」
• 「重複をチェック」／「DRYチェック」
• 「TDDを開始」／「Jestのウォッチモード」
• 「セキュリティをチェック」／「脆弱性を検出」／「OWASP監査」

クイックリファレンス

以下および references/ 内のスクリプトパスは、このプラグイン内のファイルを示しており、監査対象のプロジェクトからコマンドを実行するディレクトリとは異なります。スクリプトを実行するには、次のようにします。

bash "${CLAUDE_PLUGIN_ROOT}/skills/code-quality-audit/<path from the table>"

作業ディレクトリは監査対象のプロジェクトにしたままにしてください。各スクリプトは自身の cwd をスキャンするため、プラグイン内に cd すると、プラグインが監査対象になります。${CLAUDE_PLUGIN_ROOT} は Claude Code によって置換される、プラグインのインストール先ディレクトリです。セッション外では、このプラグインのチェックアウト先に置き換えてください。

Drupal スクリプト

タスク	スクリプト	詳細
ツールをセットアップ	scripts/core/install-tools.sh	Drupal のセットアップを参照
全体監査	scripts/core/full-audit.sh	全体監査を参照
カバレッジ	scripts/drupal/coverage-report.sh	カバレッジチェックを参照
SOLID チェック	scripts/drupal/solid-check.sh	SOLID チェックを参照
DRY チェック	scripts/drupal/dry-check.sh	DRY チェックを参照
Lint チェック	scripts/drupal/lint-check.sh	Lint チェックを参照
非推奨項目を修正	scripts/drupal/rector-fix.sh	Rector による修正を参照
TDD サイクル	scripts/drupal/tdd-workflow.sh	TDD ワークフローを参照
セキュリティ監査	scripts/drupal/security-check.sh	セキュリティ監査を参照（10 層）

Next.js スクリプト

タスク	スクリプト	詳細
ツールをセットアップ	scripts/core/install-tools.sh	Next.js のセットアップを参照
全体監査	scripts/core/full-audit.sh	全体監査を参照
カバレッジ	scripts/nextjs/coverage-report.sh	カバレッジチェックを参照
SOLID チェック	scripts/nextjs/solid-check.sh	SOLID チェックを参照
Lint チェック	scripts/nextjs/lint-check.sh	Lint チェックを参照
DRY チェック	scripts/nextjs/dry-check.sh	DRY チェックを参照
TDD サイクル	scripts/nextjs/tdd-workflow.sh	TDD ワークフローを参照
セキュリティ監査	scripts/nextjs/security-check.sh	セキュリティ監査を参照（7 層）

操作を始める前に

Drupal:

1. Drupal のルートを特定します。web/core/lib/Drupal.php または docroot/core/lib/Drupal.php を確認してください
2. DDEV を確認します。ddev describe

Next.js:

1. npm を確認します。npm --version

レポートディレクトリ — 作成しないでください

mkdir -p .reports は絶対に実行しないでください。また、監査対象のリポジトリの .gitignore に .reports/ を追加しないでください。 レポートには監査対象ソースの行が引用され、シークレットスキャナーが一致したファイル名も記載されます。そのため、ブランチに含めて配布すべきものではありません。リポジトリ内の .reports は、レポートの保存先ではなくなりました。

scripts/ 内の各スクリプトは、scripts/core/report-dir.sh を読み込んでレポートディレクトリを解決し、そのディレクトリを作成して、起動時に Report directory: <path> と表示します。パスを推測せず、その行を確認してください。解決順序は次のとおりです。明示的に設定された REPORT_DIR、それ以外の場合は、この作業ディレクトリに登録されている ai-dev-assistant プロジェクトフォルダー内の <project>/audits/<date>/、それ以外の場合は、リポジトリの外にある ${XDG_STATE_HOME:-$HOME/.local/state}/code-quality-tools/<project>/<timestamp>/ です。.reports/ は REPORT_DIR_IN_REPO=1 を指定した場合にのみ使用でき、作成時に gitignore に登録されます。 パスを自分で知る必要がある場合（レポートを読み返すときや、ユーザーに確認場所を伝えるときなど）は、ディレクトリ名を書き留める代わりに、同じファイルに問い合わせてください。

bash "${CLAUDE_PLUGIN_ROOT}/skills/code-quality-audit/scripts/core/report-dir.sh" --print    # where the next run writes; creates nothing
bash "${CLAUDE_PLUGIN_ROOT}/skills/code-quality-audit/scripts/core/report-dir.sh" --ensure   # same path, created with mode 0700; use before writing
bash "${CLAUDE_PLUGIN_ROOT}/skills/code-quality-audit/scripts/core/report-dir.sh" --latest   # where the last run wrote; exits 1 if none yet

--latest が 0 以外の場合、ここでは監査が実行されていないという意味であり、監査に問題がなかったという意味ではありません。その旨を伝え、監査の実行を提案してください。

サンドボックスのユーザーへ： 組み込みの サンドボックス化された Bash ツール（/sandbox）が有効な場合、リンター（PHPStan、ESLint、Semgrep、Trivy、Gitleaks）を呼び出す bash スクリプトでは、バイナリのパスをホワイトリストに登録する必要があります。ツールのバイナリを allowedPaths に追加してください（例：vendor/bin/phpstan、/usr/local/bin/semgrep）。DDEV を介したコマンドはコンテナ内で実行されるため、影響を受けません。

サンドボックス内では git フックのインストールに失敗し、しかもエラーが不明瞭です。 サンドボックスはすべての Bash コマンドとその子プロセスに対してオペレーティングシステムによって強制され、.git 内の hooks と config は保護されたパスです。これを解除する方法はありません。allowWrite エントリーや、パスを対象とする Edit 許可ルールでも解除できず、sandbox.filesystem.disabled だけが無効化できますが、その場合は保護されたパスすべてが一括で対象となり、個別には無効化できません。そのため、Drupal での GrumPHP の vendor/bin/grumphp git:init や Next.js での Husky を使う /code-quality-tools:setup の git フック手順は、インストーラー自身が子プロセスとして .git/hooks/ に書き込むため、サンドボックス化されたセッションでは書き込みできません。Linux と WSL2 では、hooks を名指しするエラーではなく、unable to unlink old ... Read-only file system が表示されることが予想されます。サンドボックス外でフックをインストールするか、スキップしてください。

信頼できないツリーを監査する前に、認証情報を保護してください。 sandbox.credentials はサンドボックス化された Bash コマンドに適用されます。このスキルのゲートでは、ここで composer audit、npm audit、semgrep が実行されます。deny は認証情報ファイルへのアクセスをブロックするか、環境変数を完全に削除します。mask（変数は v2.1.199 以降、ファイルは v2.1.221 以降）はセッションごとのセンチネルに置き換え、サンドボックスのプロキシが許可されたホストに対して実際の値を差し戻せるようにします。そのため認証は引き続き機能し、コマンドやログに秘密情報が渡ることもありません。これは、上記の「既知の制限事項」に記載されている悪意あるクローンのリスクへの対策として重要です。

無人セッションでは、このプラグインのフックが確認なしで実行されます。 Claude Code のフォルダー信頼ダイアログが表示されるのは対話型セッションのみです。claude -p の実行や SDK セッションでは表示されず、設定ファイル内のフックは常に使用されます。このプラグインには、プラグインスコープの PreCompact フックと、スキルスコープの FileChanged および PermissionDenied フックが含まれているため、このモードでは誰にも確認を求めずに、見慣れないクローンに対して 3 つすべてが実行されます。

Bash サンドボックスが制限するのは Bash のみです。組み込みのファイルツール、MCP サーバー、フックはホスト上で制限なく実行されます。この点が重要なのは、ウォッチモードのディスパッチャーが FileChanged フック（lint-changed.sh）として実行されるためです。そのため、上記の「既知の制限事項」に記載されている npx によるトロイの木馬のリスクは、Bash サンドボックスの境界の外側にあります。Docker を使わずに、フック（およびファイルツールと MCP）を 1 つの OS 境界内に閉じ込めるには、Claude Code プロセス全体を サンドボックスランタイム（@anthropic-ai/sandbox-runtime、ベータ版の研究プレビュー）の下で実行してください。~/.srt-settings.json（デフォルトではすべての書き込みとネットワークを拒否します）を設定して、プロジェクトディレクトリ、~/.claude／~/.claude.json、api.anthropic.com を許可し、その後 npx @anthropic-ai/sandbox-runtime claude で起動します。推奨： 信頼できないチェックアウトの監査は、サンドボックスランタイムの下で実行してください（または、カーネルレベルで分離するには、専用 VM／Claude Code on the web を使用してください）。分離方法の比較については、サンドボックス環境ガイド（/en/sandbox-environments）をご覧ください。

何をいつ実行するか

詳しいガイダンスについては、decision-guides/quality-audit-checklist.md をご覧ください。

コンテキスト	実行するもの	時間
コミット前	quality:cs のみ	約 5 秒
プッシュ前	PHPStan + 単体／カーネルテスト	約 2 分
マージ前	完全監査	約 10 分
毎週	完全監査 + HTML レポート	約 15 分

適応型監査深度（${CLAUDE_EFFORT}）

このスキルで監査を実施する場合は、セッションの作業レベルに応じて深度を調整します。${CLAUDE_EFFORT} の置換値は現在のレベルに解決されます。

${CLAUDE_EFFORT}	監査深度
low	高速なリントのみ — コーディング規約のチェックを実施し、セキュリティ、SOLID、DRY、カバレッジはスキップします
medium	リント + カバレッジ + SOLID + DRY — 詳細なセキュリティチェックはスキップします
high	完全な監査 — 22 項目すべての処理を実施します（実質的なデフォルト）
xhigh / max	完全な監査の後、セキュリティに関する検出結果を3エージェントでレビューする /code-quality-tools:security-debate の実行を提案します

値が設定されていない場合や認識できない場合は、high（完全な監査）として扱います。レベルを読み取れないことを理由に、カバレッジやセキュリティを黙ってスキップしてはいけません。

これはパイロット版（v3.5.0）です。適応型の深度が監査フローに組み込まれているのはその部分のみです。FileChanged ウォッチモードのディスパッチャーとコマンドごとの作業レベルのゲートは、意図的にまだ作業レベルに対応していません。このパイロット版を実際の使用環境で観察した後に見直す予定です。

対象範囲の指定

プロジェクト全体ではなく、特定のモジュールやコンポーネントを監査するには：

**対象範囲の指定**で、次の3つの方法を確認してください：

1. ディレクトリを変更する（推奨）- cd web/modules/custom/my_module
2. 環境変数を使用する - DRUPAL_MODULES_PATH=path/to/module
3. 全体をスキャンする（デフォルト）- プロジェクトのルートから実行します

インテリジェント検出：Claude が現在のディレクトリとユーザーの意図を検出します。

シークレットスキャンの対象範囲（CQT_SECRET_SCAN）

「gitleaks を実行する」ことは対象範囲の選択であり、単一の操作ではありません。セキュリティゲートではその選択が明示されます。デフォルトは作業ツリーで、実行時にはその旨を示す [SCOPE] 行が出力されます。security-report.json にも同じ値が記録されるため、レポートを見れば作業ツリーのスキャンか、全履歴のスキャンかを判別できます。ツリーのスキャン後に Gitleaks: 0 findings と表示されても、クリーンなのはチェックアウトであり、リポジトリではありません。

全履歴のスキャンはコストが高いため、明示的に選択する必要があります。また、所要時間は推測ではなく実測に基づいています。このスキャンの元となったリポジトリ（2,368 件のコミット、253,505 個のパック済みオブジェクト、224.84 MiB の履歴があり、Composer への移行前に core/vendor/contrib がすべてコミット済み）では、全履歴のスキャンが数百パーセントの CPU 使用率で何分も実行され、10 分で強制終了されました。実行する場合は意図的に設定し、予算を確保してください。

変数	値	コストと効果
CQT_SECRET_SCAN	tree（デフォルト）、diff、history	tree = gitleaks dir。作業ツリーを対象とし、数秒で完了します。diff = 範囲が限定されたコミット範囲。範囲に比例したコストで、CI での利用に適しています。history = すべての ref から到達可能な全コミット。コミット後に削除されたシークレットを見つけられる唯一のスキャンであり、実際に高いコストがかかる唯一のスキャンです。
CQT_SECRET_SCAN_BASE	git ref	diff のベースです。未設定の場合、解決可能な最初の upstream ref から導出されます。解決できる ref がない場合は、スキャン範囲を暗黙にすべてへ拡大せず、スキャンを拒否してスキップとして記録します。
CQT_SECRET_SCAN_LOG_OPTS	文字列	history または diff のスキャンで gitleaks --log-opts に渡されます。**引用符は使用しないでください。**gitleaks はこの値を単語ごとに分割してから git log に渡すため、引用符の効力は失われます。引用符で囲んだパス指定ではスキャン対象が 0 バイトとなり、何も検出されずに終了コード 0 で終了します。引用符を含む値は拒否されます。範囲指定と、引用符を使わないパス指定は使用できます。
CQT_SECRET_SCAN_ALLOWLIST	vendored	templates/gitleaks-vendored-allowlist.toml を適用します。検出結果を抑制するため、明示的に選択する必要があります。実行時には、適用中の設定ファイル名を示す [FILTER] 行が出力されます。レポートを読みやすくしますが、すべての blob が引き続き読み込まれるため、全履歴のスキャンは速くなりません。
CQT_SECRET_SCAN_ALLOWLIST_FILE	パス	同梱の設定ファイルの代わりに、この gitleaks 設定を使用します。
CQT_SECRET_SCAN_TIMEOUT	秒数（デフォルトは 300）	timeout(1) を使って適用される、各スキャンの実行時間の上限です。gitleaks 独自の --timeout は使用しません。gitleaks に独自のタイムアウトを指定すると、形式上は正しい空のレポートが書き出され、終了コード 1 で終了します。これはクリーンなツリーの場合と区別できません。timeout(1) は終了コード 124 で終了し、何も書き出しません。timeout(1) がないマシンでは上限は適用されず、範囲を示す行には、適用される上限の代わりにその旨が表示されます。

# What a PR build should run: only what this branch added.
CQT_SECRET_SCAN=diff CQT_SECRET_SCAN_BASE=origin/main bash scripts/drupal/security-check.sh

# The pass that finds a credential that was committed and later gitignored.
CQT_SECRET_SCAN=history CQT_SECRET_SCAN_TIMEOUT=1800 \
  CQT_SECRET_SCAN_ALLOWLIST=vendored bash scripts/drupal/security-check.sh

実測した --log-opts の失敗モードを含む完全な表は、Drupal / Next.js を参照してください。

---

運用

整理しやすくするため、詳細な運用手順はすべてリファレンスファイルに移動しました。

Drupal の運用

セットアップと設定

• 操作 1： ツールのセットアップ - PHPStan、PHPMD、PHPCPD、Coder をインストールします
• 操作 6： モジュール固有の監査 - 監査対象を 1 つのモジュールに絞ります
• 操作 7： Composer スクリプトの追加 - 品質チェック用スクリプトを設定します
• 操作 8： CI との統合 - GitHub Actions をセットアップします

品質監査

• 操作 2： 完全監査 - すべての品質チェックを実行
• 操作 3： カバレッジチェック - テストカバレッジを測定
• 操作 4： SOLID チェック - 原則違反を検出
• 操作 5： DRY チェック - コードの重複を検出
• 操作 11： Lint チェック - コーディング規約
• 操作 12： Rector による修正 - 非推奨機能を自動修正

開発ワークフロー

• 操作 10： TDD ワークフロー - RED-GREEN-REFACTOR サイクル

セキュリティ

• 操作 20： セキュリティ監査 — 10 層のセキュリティチェック
  • Drush pm:security、Composer audit
  • yousha/php-security-linter、Psalm の taint 分析
  • Drupal 独自のパターン、Security Review モジュール
  • Semgrep SAST、Trivy スキャナー、Gitleaks
  • Roave Security Advisories

Next.js の操作

セットアップと設定

• 操作 13： ツールのセットアップ - ESLint、Jest、セキュリティツールをインストール

品質監査

• 操作 14： 完全監査 - すべての品質チェックを実行
• 操作 15： Lint チェック - ESLint + TypeScript
• 操作 16： カバレッジチェック - Jest のカバレッジ
• 操作 17： DRY チェック - 重複を検出
• 操作 19： SOLID チェック - 循環依存、複雑さ

開発ワークフロー

• 操作 18： TDD ワークフロー - Jest を使った RED-GREEN-REFACTOR

セキュリティ

• 操作 21： セキュリティ監査 — 7 層のセキュリティチェック
  • npm audit、ESLint のセキュリティプラグイン
  • Semgrep SAST、Trivy スキャナー、Gitleaks
  • React/Next.js 独自のパターン（XSS、eval、ナビゲーション）
  • Socket CLI

オプション：DAST（動的テスト）

ステージング環境向けの本番前セキュリティテスト

• 操作 22： DAST ツール — 動的セキュリティテスト
  • OWASP ZAP（フル機能の DAST スキャナー）
  • Nuclei（テンプレートベースの CVE スキャン）
  • アプリケーションの実行が必要です
  • リリース前にステージング／本番前環境で使用します

---

レポートの保存

すべてのレポートは schemas/audit-report.schema.json に準拠する必要があります：

{
  "meta": {
    "project_type": "drupal|nextjs|monorepo",
    "timestamp": "2025-12-19T12:00:00Z",
    "thresholds": { "coverage_minimum": 70, "duplication_max": 5 }
  },
  "summary": {
    "overall_score": "pass|warning|fail|unknown",
    "coverage_score": "pass|warning|fail",
    "solid_score": "pass|warning|fail",
    "dry_score": "pass|warning|fail",
    "security_score": "pass|warning|fail|skipped"
  },
  "coverage": { "line_coverage": 75.5, "files_analyzed": 45 },
  "solid": { "violations": [] },
  "dry": { "duplication_percentage": 3.2, "clones": [] },
  "security": { "critical": 0, "high": 0, "medium": 3, "low": 5, "issues": [] },
  "recommendations": []
}

---

参考資料

基本ガイダンス

• references/tdd-workflow.md - RED-GREEN-REFACTOR のパターン、テストの命名、サイクルの目標
• references/coverage-metrics.md - コードの種類ごとのカバレッジ目標、PCOV と Xdebug の比較
• references/dry-detection.md - Rule of Three、重複が許容される場合
• references/solid-detection.md - SOLID の検出パターンと修正方法
• references/composer-scripts.md - すぐに使える Composer スクリプト
• references/scope-targeting.md - 特定のモジュール／コンポーネントを対象にする方法
• references/post-batch-aggregation.md - オプションの PostToolBatch 集約パターン（Claude Code 2.1.118 以降）。デフォルトでは同梱されません
• references/code-intelligence.md - より詳細な SOLID／DRY／レビュー分析のためのオプションの LSP ツールによるコードインテリジェンス（推奨ですが必須ではありません）
• references/setup-hook-pattern.md - claude --init -p で CI ツールを一度だけブートストラップするオプションの Setup フックパターン。デフォルトでは同梱されません

運用

• references/operations/drupal-setup.md - Drupal のセットアップ運用
• references/operations/drupal-audits.md - Drupal の品質監査運用
• references/operations/drupal-security.md - Drupal のセキュリティ（10 層、v2.0.0）
• references/operations/drupal-tdd.md - Drupal の TDD ワークフロー
• references/operations/nextjs-setup.md - Next.js のセットアップ運用
• references/operations/nextjs-audits.md - Next.js の品質監査運用
• references/operations/nextjs-security.md - Next.js のセキュリティ（7 層、v2.0.0）
• references/operations/nextjs-tdd.md - Next.js の TDD ワークフロー

オンラインの開発ガイド（Drupal ドメイン）

ツールコマンド以外の、Drupal 固有のパターンについて詳しく知るには、ガイドのインデックスを取得してください。

インデックス： https://camoa.github.io/dev-guides/llms.txt

関連する可能性が高いトピック：solid-principles、dry-principles、security、testing、tdd、js-development、github-actions

使用方法：WebFetch でインデックスを取得して利用可能なトピックを確認し、違反の説明、修正案の提示、またはアーキテクチャの背景情報の提供にあたって、該当するトピックのページを取得してください。

判断ガイド

• decision-guides/test-type-selection.md - Unit、Kernel、Functional の判断ツリー
• decision-guides/quality-audit-checklist.md - 何をいつ実行するか（コミット前とマージ前）

テンプレート

Drupal

• templates/drupal/phpstan.neon - PHPStan 2.x の設定（拡張機能を自動ロード）
• templates/drupal/phpmd.xml - Drupal 用 PHPMD ルールセット
• templates/drupal/phpunit.xml - テストスイートを含む PHPUnit の設定
• templates/ci/github-drupal.yml - セキュリティツールを含む GitHub Actions ワークフロー

Next.js

• templates/nextjs/eslint.config.js - TypeScript とセキュリティに対応した ESLint v9 のフラット設定
• templates/nextjs/jest.config.js - カバレッジしきい値を設定した Jest の設定
• templates/nextjs/jest.setup.js - Testing Library を使用した Jest のセットアップ
• templates/nextjs/.prettierrc - Tailwind プラグインを使用した Prettier の設定

バージョン履歴については CHANGELOG.md を参照してください。