ln-646-project-structure-auditor

パス： ファイルパス（references/、../ln-*）は、このスキルディレクトリを基準とした相対パスです。

プロジェクト構造監査

種類： L3 ワーカー

物理的なプロジェクト構造が、意図されたアーキテクチャを反映しているかを監査する L3 ワーカーです。

目的と範囲

• モジュール、ドメイン、レイヤー構成、フレームワークの配置、および雑多なファイルが集まったディレクトリを監査します
• 構造のずれを検出し、アーキテクチャの把握や適用を困難にしている箇所を特定します
• コードレベルの境界チェックを、物理構造の証拠で補完します
• MOVE_MODULE、SPLIT_JUNK_DRAWER、または ALIGN_DOMAIN_STRUCTURE を出力します
• 適合スコア（X/10）を算出します

対象外：

• .gitignore、.dockerignore、一時ファイル、ビルド成果物、プラットフォームの残骸、および大容量バイナリ
• インポートレベルのレイヤー違反
• パッケージのセキュリティ、環境ファイルの衛生状態、またはランタイムのライフサイクルチェック
• ファイルの移動や削除

入力

必ず読み込むこと： references/audit_worker_core_contract.md と references/mcp_tool_preferences.md を読み込みます。 ツールポリシー：ホストの AGENTS.md が対象外となる独立したサブエージェントとして実行される場合があるため、ファイルの読み取り、検索、編集には、まずデフォルトで hex-line MCP を使用します。MCP の動作が不明確な場合に限り、references/mcp_integration_patterns.md を読み込みます。

contextStore には、tech_stack、architecture、codebase_root、output_dir、domain_mode、scan_path が含まれます。

アーキテクチャの要約が構造に関する所見の質を大きく高める場合は、まず hex-graph を使用します。利用可能な場合、ローカルのコード、設定、マニフェストの読み取りには、まず hex-line を使用します。MCP が利用できない、未対応、またはインデックス化されていない場合は、組み込みの Read/Grep/Glob/Bash を使用して続行し、レポートにフォールバックしたことを記載します。

ワークフロー

検出ポリシー：2 層検出（候補のスキャン後、コンテキストで検証）を使用します。検証方法が曖昧な場合に限り、references/two_layer_detection.md を読み込みます。

1. コンテキストを解析 -- ドメインを考慮したスコープまたはコードベースのルートから scan_root を決定します
2. 技術スタックと意図された構造を検出
   • 必ず読み込むこと： references/stack_detection.md を読み込みます
   • アーキテクチャのドキュメントや設定がある場合はそれを優先し、ない場合はソースの配置から推測します
3. 構造チェックを実行（レイヤー 1）
   • フレームワークで想定されるソース配置
   • ドメイン／モジュールのグループ化
   • レイヤーディレクトリの構成
   • 雑多なファイルが集まったディレクトリ
   • 命名と配置の一貫性
4. コンテキストを検証（レイヤー 2）
   • 小規模なプロジェクトでは、完全なドメイン／レイヤーへの分解が不要な場合があります
   • フレームワークの規約は、検出されたフレームワークにのみ適用します
   • アプリ／パッケージ／テストの種類ごとに分割され、文書化されている場合は、混在した構成も許容されます
5. 重大度、場所、アクション、作業量、および推奨事項とともに所見を収集します
6. references/audit_scoring.md を使用してスコアを算出します
7. {output_dir}/ln-646--{identifier}.md にレポートを書き込みます
8. references/audit_summary_contract.md に従って要約を返します

監査ルール

1. フレームワークの配置

内容： ソースファイルがフレームワークや技術スタックの規約に沿わない場所に配置されています

検出： references/structure_rules.md を読み込み、検出された技術スタックに該当するルールのみを適用します。

重大度： 配置によってツールやルーティングに支障がある場合は HIGH、保守性の低下につながる場合は MEDIUM

アクション： MOVE_MODULE

2. ドメインとレイヤーの構成

内容： ドメインやレイヤーのディレクトリが、意図されたアーキテクチャを反映していません

検出：

• 文書化または推測されたドメイン／レイヤーと、物理ディレクトリを比較します
• 期待されるサブ構造が欠けているドメインを探します
• 明確なモジュール構成を持つプロジェクトで、ソースファイルがルートや汎用フォルダーに置かれていないか確認します

重大度： デフォルトは MEDIUM、構造によって重要な所有関係が隠れている場合は HIGH

アクション： ALIGN_DOMAIN_STRUCTURE

3. 雑多なファイルが集まったディレクトリ

内容： 汎用ディレクトリに、関連のないモジュールが蓄積しています

検出： utils、helpers、common、shared、services、lib などのディレクトリを確認し、プロジェクトのしきい値を超えて、関連のない責務が混在していないか調べます。

重大度： 広範囲に責務が混在している場合は MEDIUM、小規模で局所的なずれの場合は LOW

アクション： SPLIT_JUNK_DRAWER

スコアリングアルゴリズム

必ずお読みください： references/audit_scoring.md を読み込んでください。

出力形式

必ずお読みください： references/templates/audit_worker_report_template.md を読み込んでください。

references/audit_summary_contract.md に従って JSON サマリーを書き込んでください。管理モードでは、呼び出し元が runId と summaryArtifactPath の両方を渡します。スタンドアロンモードでは、ワーカーが共通コントラクトに従って、実行ごとのアーティファクトパスを生成します。

{output_dir}/ln-646--{identifier}.md に、category: "Project Structure" と framework_placement、domain_layer_layout、junk_drawers の各チェックを含むレポートを書き込んでください。

summaryArtifactPath がない場合は、スタンドアロンの実行時サマリーを .hex-skills/runtime-artifacts/runs/{run_id}/evaluation-worker/{worker}--{identifier}.json に書き込み、同じサマリーを構造化出力に任意で含めてください。

重要なルール

すでに読み込まれている references/audit_worker_core_contract.md を適用してください。

• 自動修正しない： 報告のみとし、ファイルの移動や削除は行わないでください
• 独自の観点： 物理的なアーキテクチャ構造のみを監査してください。ファイルの衛生状態、無視ファイル、パッケージの健全性、環境の衛生状態、インポートレベルの境界、ランタイムのライフサイクルは監査しないでください。
• 自動検出し、決めつけない： 検出したスタックにのみフレームワークのルールを適用してください
• 必ず根拠を示す： すべての指摘にファイルパスを含めてください
• 対応を必須とする： すべての指摘で MOVE_MODULE、SPLIT_JUNK_DRAWER、ALIGN_DOMAIN_STRUCTURE のいずれかを使用してください

完了条件

すでに読み込まれている references/audit_worker_core_contract.md を適用してください。

• contextStore の解析に成功した
• scan_root を特定した
• 技術スタックと意図された構造を検出した
• フレームワークの配置を確認した
• ドメイン／レイヤーのレイアウトを確認した
• ジャンクドロワーディレクトリを確認した
• レイヤー 2 のコンテキスト検証を適用した
• 重要度、場所、対応、作業量、推奨事項を含めて指摘を収集した
• references/audit_scoring.md に従ってスコアを算出した
• {output_dir}/ln-646--{identifier}.md にレポートを書き込んだ（単一の Write 呼び出しでアトミックに書き込み）
• コントラクトに従ってサマリーを書き込んだ

---

バージョン： 1.0.0 最終更新日： 2026-03-15