project-analyzer

Name: project-analyzer
Author: oimiragieo

github.com/oimiragieo開発44117 回インストール17 週間前に更新

リポジトリ

project-analyzer について

既存コードベースを素早く把握するための自動分析スキルです。プロジェクト種別、フレームワーク、構造、品質上の課題を特定し、受け入れや調査に役立つ改善案を示します。

主な機能

01プロジェクト種別とフレームワークの検出
02ファイル数と言語別統計の作成
03コンポーネントとアーキテクチャパターンの分析
04依存関係と品質指標の確認
05技術的負債の検出と改善案の提示

活用シーン

01コードベースの引き継ぎ時に構造を把握
02依存関係の健全性と品質ツールを確認
03技術的負債の対応優先度を決定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/oimiragieo/agent-studio --skill project-analyzer

インストール後、Claude Code で/project-analyzerを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

commands/

project-analyzer.md

hooks/

post-execute.cjs

pre-execute.cjs

references/

auto-claude-patterns.md

database-patterns.md

research-requirements.md

route-patterns.md

service-patterns.md

rules/

project-analyzer.md

schemas/

input.schema.json

output.schema.json

scripts/

main.cjs

templates/

implementation-template.md

詳細

参考資料（アーカイブ）： SCAFFOLD_SKILLS_ARCHIVE_MAP.md — Auto-Claude-develop の分析／analyzers を用いた ProjectAnalyzer のモノレポ／サービス検出。

Project Analyzer - プロジェクトへの迅速なオンボーディングと理解を実現する、既存コードベースの自動分析ツールです。 - プロジェクトの種類を検出します（フロントエンド、バックエンド、フルスタック、ライブラリ、CLI、モバイル、モノレポ） - マニフェストと構造からフレームワークとライブラリを特定します - ファイル統計と言語の内訳を生成します - コンポーネント間の関係とモジュール構造をマッピングします - アーキテクチャパターン（MVC、レイヤード、マイクロサービスなど）を検出します - 依存関係の健全性と古いパッケージを分析します - コード品質の指標（リンティング、テスト、型安全性）を特定します - 技術的負債とアンチパターンを検出します - 優先順位付けされた改善案を生成します

ステップ 1：プロジェクトルートを特定する

マニフェストファイルを見つけてプロジェクトルートを特定します。

パッケージマネージャーのファイルを検索します：
- package.json（Node.js／JavaScript／TypeScript）
- requirements.txt、pyproject.toml、setup.py（Python）
- go.mod（Go）
- Cargo.toml（Rust）
- pom.xml、build.gradle（Java／Maven／Gradle）
- composer.json（PHP）
プロジェクトルートを特定します：
- 主要なパッケージマネージャーファイルを含むディレクトリ
- モノレポを処理します（複数の package.json ファイル）
- ワークスペース設定を検出します
プロジェクトルートを検証します：
- .git ディレクトリがあるか確認します
- ソースコードのディレクトリが存在することを確認します
- マニフェストファイルを解析できることを確認します

ステップ 2：プロジェクトの種類を検出する

マニフェストファイルとディレクトリ構造に基づいてプロジェクトを分類します。

フロントエンドプロジェクト：
- 指標：React、Vue、Angular、Svelte の依存関係
- ディレクトリ：src/components/、public/、assets/
- フレームワーク：Next.js、Nuxt.js、Gatsby、Vite
バックエンドプロジェクト：
- 指標：Express、FastAPI、Django、Flask、Gin の依存関係
- ディレクトリ：routes/、controllers/、models/、api/
- フレームワーク：Next.js API routes、FastAPI、Express
フルスタックプロジェクト：
- 指標：フロントエンドとバックエンドの両方のフレームワーク
- ディレクトリ：フロントエンドとバックエンドを組み合わせた構造
- フレームワーク：Next.js、Remix、SvelteKit、Nuxt.js
ライブラリ／パッケージプロジェクト：
- 指標：アプリケーション固有のディレクトリがない
- ファイル：index.ts、lib/、dist/、build/
- マニフェスト：package.json の library フィールド
CLI プロジェクト：
- 指標：package.json の bin フィールド
- ファイル：CLI のエントリーポイント、コマンドパーサー
- 依存関係：Commander、Yargs、Inquirer
モバイルプロジェクト：
- 指標：React Native、Flutter、Ionic の依存関係
- ファイル：android/、ios/、mobile/
- フレームワーク：React Native、Expo、Flutter
モノレポプロジェクト：
- 指標：package.json の workspaces、pnpm-workspace.yaml
- 構造：サブディレクトリ内に複数のパッケージ
- ツール：Turborepo、Nx、Lerna
マイクロサービスプロジェクト：
- 指標：複数のサービスディレクトリ
- ファイル：docker-compose.yml、サービス設定ファイル
- 構造：サービスベースの構成

### ステップ 3：フレームワークの検出

マニフェストファイルとインポートからフレームワークを特定します。

package.json の依存関係を読み取る（Node.js）：
- dependencies と devDependencies を解析する
- フレームワークのバージョンを検出する
- 種類（フレームワーク、UI ライブラリ、テストなど）ごとに分類する
requirements.txt を読み取る（Python）：
- Python の依存関係を解析する
- FastAPI、Django、Flask を検出する
- バージョン制約を特定する
インポートを分析する（任意の詳細スキャン）：
- ソースファイルをスキャンして import 文を探す
- 使用されている依存関係と宣言されている依存関係を検出する
- フレームワーク固有のパターンを特定する
フレームワークのカテゴリ：
- フレームワーク：React、Next.js、FastAPI、Express
- UI ライブラリ：Material-UI、Ant Design、Chakra UI
- 状態管理：Redux、Zustand、Pinia
- テスト：Jest、Vitest、Cypress、Playwright
- ビルドツール：Vite、Webpack、Rollup、esbuild
- データベース：Prisma、TypeORM、SQLAlchemy
- ORM：Prisma、Sequelize、Mongoose
- API：tRPC、GraphQL、REST
- 認証：NextAuth、Auth0、Clerk
- ロギング：Winston、Pino、Bunyan
- モニタリング：Sentry、Datadog、New Relic
信頼度スコア：
- 1.0：依存関係に記載されたフレームワーク
- 0.8：インポートから検出されたフレームワーク
- 0.6：構造から推定されたフレームワーク

ステップ 4：ファイル統計

プロジェクトの定量的な統計情報を生成します。

種類ごとにファイル数を数える：
- 一般的な拡張子に glob パターンを使用する
- 除外対象：node_modules/、.git/、dist/、build/
- 言語／ファイルの種類ごとに分類する
コード行数を数える：
- ソースファイルを読み取り、行数を数える
- 空行とコメントを除外する（任意）
- 言語ごとに合計 LOC を計算する
最大のファイルを特定する：
- ファイルサイズ（行数）を記録する
- 行数の多い上位 10 ファイルを報告する
- 1000 行を超えるファイルにフラグを立てる（マイクロサービスの原則に違反）
平均値を計算する：
- ファイルサイズ（行数）の平均
- ディレクトリ階層の平均深度
- ディレクトリあたりのファイル数
言語の検出：
- 拡張子を言語に対応付ける：
  - .ts、.tsx → TypeScript
  - .js、.jsx → JavaScript
  - .py → Python
  - .go → Go
  - .rs → Rust
  - .java → Java
  - .md → Markdown
  - .json → JSON
  - .yaml、.yml → YAML

ステップ 5：構造分析

プロジェクトの構造とアーキテクチャを分析します。

ルートディレクトリを特定する：
- ディレクトリを目的別に分類する：
  - ソース：src/、app/、lib/
  - テスト：test/、__tests__/、cypress/
  - 設定：config/、.config/
  - ドキュメント：docs/、documentation/
  - ビルド：dist/、build/、out/
  - スクリプト：scripts/、bin/
  - アセット：assets/、static/、public/
エントリーポイントを検出する：
- メインエントリー：index.ts、main.py、app.py
- アプリのエントリー：app.ts、server.ts、app/page.tsx
- ハンドラー：handler.ts、lambda.ts
- CLI：cli.ts、bin/
アーキテクチャパターンを検出する：
- MVC：models/、views/、controllers/
- レイヤード：presentation/、business/、data/
- ヘキサゴナル：domain/、application/、infrastructure/
- マイクロサービス：複数のサービスディレクトリ
- モジュール型：機能ベースの構成
- フラット：すべてのファイルが src/ にある
モジュールシステムを検出する：
- "type": "module"（ESM）があるか package.json を確認する
- import／export（ESM）と require（CommonJS）をスキャンする
- 混在するモジュールシステムを特定する

ステップ 6：依存関係の分析

依存関係の健全性を分析します。

依存関係の数を数える：
- 本番用依存関係
- 開発用依存関係
- 依存関係の合計数
古いパッケージを確認する（任意）：
- npm outdated または同等のコマンドを実行する
- 出力を解析して古いパッケージを特定する
- メジャーバージョンの更新（互換性を損なう変更）を特定する
セキュリティスキャン（任意）：
- npm audit または同等のコマンドを実行する
- 重大度ごとに脆弱性を特定する
- 重大なセキュリティ問題にフラグを立てる

ステップ 7：コード品質の指標

コード品質ツールを検出します。

リンティング設定：
- 検出対象：.eslintrc.json、eslint.config.js、ruff.toml
- ツール：ESLint、Ruff、Flake8、Pylint
- 設定されている場合はリンターを実行します（任意）
フォーマット設定：
- 検出対象：.prettierrc、pyproject.toml（Black/Ruff）
- ツール：Prettier、Black、Ruff
テストフレームワーク：
- 検出対象：Jest、Vitest、Pytest、Cypress
- テストファイルの数をカウントします
- カバレッジ設定を確認します
型安全性：
- TypeScript を検出：tsconfig.json
- strict モードを確認：「"strict": true」
- Python の型付けツールを検出：mypy、pyright

ステップ 8：パターンの検出

一般的なパターンとアンチパターンを特定します。

優れたプラクティス：
- モジュール化されたコンポーネント構成
- 包括的なテストカバレッジ
- TypeScript の strict モードが有効
- CI/CD 設定が存在する
アンチパターン：
- 大きなファイル（1000 行超）
- テストがない
- 古くなった依存関係
- リンティング設定がない
中立的なパターン：
- 特定のアーキテクチャの選択
- フレームワーク固有のパターン

ステップ 9：技術的負債の分析

技術的負債のスコアを算出します。

負債の指標：
- 古くなった依存関係：古くなったパッケージの数
- テストの不足：テストファイルの割合が低い
- デッドコード：使用されていないインポート／エクスポート（任意）
- 複雑さ：大きなファイル、深いネスト
- ドキュメント：README やドキュメントがない
- セキュリティ：既知の脆弱性
- パフォーマンス：バンドルサイズ、読み込み時間
負債スコア（0～100）：
- 0～20：非常に良好
- 21～40：良好。軽微な問題あり
- 41～60：中程度の負債。対応が必要
- 61～80：負債が大きい。リファクタリングを推奨
- 81～100：深刻な負債。大規模な刷新が必要
修正に必要な労力：
- ごくわずか：1 時間未満
- 軽微：1～4 時間
- 中程度：1～3 日
- 大規模：1～2 週間
- 非常に大規模：2 週間超

ステップ 10：推奨事項の生成

優先順位を付けた改善の推奨事項を作成します。

推奨事項の分類：
- セキュリティ：重大な脆弱性、古くなった認証
- パフォーマンス：バンドルの最適化、遅延読み込み
- 保守性：大きなファイルのリファクタリング、テストの追加
- テスト：カバレッジの向上、E2E テストの追加
- ドキュメント：README、API ドキュメントの追加
- アーキテクチャ：モジュール性、関心の分離の改善
- 依存関係：パッケージの更新、未使用パッケージの削除
影響度による優先順位付け：
- P0：重大なセキュリティ問題、本番環境を妨げる問題
- P1：影響が大きく、信頼性に関わる問題
- P2：影響が中程度で、品質を向上させる問題
- P3：影響が小さく、あると望ましい改善
労力と影響の見積もり：
- 労力：ごくわずか、軽微、中程度、大規模、非常に大規模
- 影響：低、中、高、重大

ステップ 11：出力の検証

分析出力をスキーマに照らして検証します。

スキーマ検証：
- project-analysis.schema.json に照らして検証します
- 必須フィールドがすべて存在することを確認します
- データ型と形式を確認します
出力メタデータ：
- アナライザーのバージョン
- 分析時間（ms）
- 分析したファイル数
- スキップしたファイル数
- 発生したエラー

</execution_process>

**パフォーマンス要件**：

目標：一般的なプロジェクト（ファイル数 10k 未満）で 30 秒未満
最適化：
- 大きなディレクトリをスキップします：node_modules/、.git/、dist/
- ファイルを並列処理します
- 増分分析用に結果をキャッシュします
- ディープスキャンを必須ファイルに限定します
- ファイル数が多い場合はストリーミングを使用します

**Conductor との統合**： - プロジェクトの自動検出を提供します - 手動でのコンテキスト収集を不要にします - ブラウンフィールドのオンボーディングを 80% 高速化します - プロジェクトのコンテキストをチャットインターフェースに渡します

他のスキルとの統合：

rule-selector：検出されたフレームワークに基づいてルールを自動選択します
repo-rag：アーキテクチャパターンをセマンティック検索します
dependency-analyzer：依存関係を詳細に分析します

<best_practices>

段階的な開示：マニフェスト分析から始め、必要に応じてディープスキャンを追加します
パフォーマンスを最優先：大規模プロジェクトでは負荷の高い処理をスキップします
適切なエラー処理：ファイルの欠落や解析エラーに対処します
出力を検証：常にスキーマに照らして検証します
結果をキャッシュ：分析出力を保存して再利用します
増分更新：変更されたファイルのみを再分析します </best_practices>

**プログラムからの使用**：

# Analyze current project
node .claude/tools/analysis/project-analyzer/analyzer.mjs

# Analyze specific directory
node .claude/tools/analysis/project-analyzer/analyzer.mjs /path/to/project

# Output to file
node .claude/tools/analysis/project-analyzer/analyzer.mjs --output .claude/context/artifacts/project-analysis.json

エージェントの呼び出し：

# Analyze current project
Analyze this project

# Generate comprehensive analysis
Perform full project analysis and save to artifacts

# Quick analysis (manifest only)
Quick project type detection

</usage_example>

<formatting_example> 出力例（.claude/context/artifacts/project-analysis.json）：

{
  "analysis_id": "analysis-llm-rules-20250115",
  "project_type": "fullstack",
  "analyzed_at": "2025-01-15T10:30:00.000Z",
  "project_root": "C:\\dev\\projects\\LLM-RULES",
  "stats": {
    "total_files": 1243,
    "total_lines": 125430,
    "languages": {
      "JavaScript": 45230,
      "TypeScript": 38120,
      "Markdown": 25680,
      "JSON": 12400,
      "YAML": 4000
    },
    "file_types": {
      ".js": 234,
      ".mjs": 156,
      ".ts": 89,
      ".md": 312,
      ".json": 145
    },
    "directories": 87,
    "avg_file_size_lines": 101,
    "largest_files": [
      {
        "path": ".claude/tools/enforcement-gate.mjs",
        "lines": 1520
      }
    ]
  },
  "frameworks": [
    {
      "name": "nextjs",
      "version": "14.0.0",
      "category": "framework",
      "confidence": 1.0,
      "source": "package.json"
    },
    {
      "name": "react",
      "version": "18.2.0",
      "category": "framework",
      "confidence": 1.0,
      "source": "package.json"
    }
  ],
  "structure": {
    "root_directories": [
      {
        "name": ".claude",
        "purpose": "config",
        "file_count": 543
      },
      {
        "name": "conductor-main",
        "purpose": "source",
        "file_count": 234
      }
    ],
    "entry_points": [
      {
        "path": "conductor-main/src/index.ts",
        "type": "main"
      }
    ],
    "architecture_pattern": "modular",
    "module_system": "esm"
  },
  "dependencies": {
    "production": 45,
    "development": 23
  },
  "code_quality": {
    "linting": {
      "configured": true,
      "tool": "eslint"
    },
    "formatting": {
      "configured": true,
      "tool": "prettier"
    },
    "testing": {
      "framework": "vitest",
      "test_files": 89,
      "coverage_configured": true
    },
    "type_safety": {
      "typescript": true,
      "strict_mode": true
    }
  },
  "tech_debt": {
    "score": 35,
    "indicators": [
      {
        "category": "complexity",
        "severity": "medium",
        "description": "3 files exceed 1000 lines",
        "remediation_effort": "moderate"
      }
    ]
  },
  "recommendations": [
    {
      "priority": "P1",
      "category": "maintainability",
      "title": "Refactor large files",
      "description": "Break down files > 1000 lines into smaller modules",
      "effort": "moderate",
      "impact": "high"
    }
  ],
  "metadata": {
    "analyzer_version": "1.0.0",
    "analysis_duration_ms": 2340,
    "files_analyzed": 1243,
    "files_skipped": 3420,
    "errors": []
  }
}

</formatting_example>

スマートなカテゴリ分類スコアリング（Skill_Seekers smart_categorize に着想）

ファイル、ディレクトリ、コンポーネントをカテゴリに分類する際は、誤検出を防ぐため、単純な文字列一致ではなく、重み付けしたキーワードスコアリングを使用します。

シグナルの出所	スコアの重み	例
ファイルパス／URL	3 点	`/api/routes/` は「API」カテゴリに一致します
ファイル名／クラス名	2 点	`AuthService.ts` は「認証」に一致します
ファイルの内容／インポート	1 点	`import express` は「バックエンド」に一致します

しきい値：カテゴリを割り当てるには、合計 2 点以上が必要です。しきい値を超えるスコアのカテゴリがない場合は、「その他」に分類します。これにより、単一の弱いシグナルによってコンポーネントが誤分類されるのを防ぎます。

カテゴリのキーワード（プロジェクトの種類に応じて拡張してください）：

API：route、endpoint、controller、handler、middleware、api、rest、graphql
認証：auth、login、session、jwt、oauth、token、credential、permission
データベース：model、schema、migration、seed、repository、entity、query
テスト：test、spec、fixture、mock、stub、e2e、integration
設定：config、env、setting、constant、option、feature-flag
UI：component、view、page、layout、template、style、theme

3 ストリーム分析（Skill_Seekers unified_codebase_analyzer に着想）

プロジェクトを包括的に理解するため、次の 3 つの並行ストリームを分析します。

ストリーム 1 — コード分析：AST パターン、フレームワークの検出、依存関係グラフ、アーキテクチャの分類。これは既存のコアワークフローです（ステップ 1〜11）。

ストリーム 2 — ドキュメント：README の品質、API ドキュメントの有無、インラインドキュメントの網羅率、変更履歴の保守状況、コントリビューションガイド。スコア：種類ごとに重み付けした docFiles / totalFiles。

ストリーム 3 — コミュニティ／運用：Git の活動状況（コミット頻度、コントリビューター数）、CI/CD の設定、Issue テンプレート、PR テンプレート、リリースワークフロー、Docker／コンテナのセットアップ。

3 つのストリームをすべて、出力 JSON の analysis.streams にまとめます。

{
  "streams": {
    "code": { "score": 0.85, "findings": [...] },
    "documentation": { "score": 0.60, "findings": [...] },
    "operations": { "score": 0.75, "findings": [...] }
  },
  "compositeHealth": 0.73
}

デザインパターンの認識（Skill_Seekers C3.1 PatternRecognizer に着想）

信頼度をスコアリングして、一般的なデザインパターンを検出します。

パターン	検出シグナル	信頼度のしきい値
Singleton	プライベートコンストラクター＋ static インスタンス	0.80
Factory	インターフェース型を返す `create*` メソッド	0.70
Observer	`subscribe`／`on`／`emit`／`addEventListener`	0.70
Strategy	インターフェース＋複数の実装	0.60
Decorator	同じインターフェースを持つラッパークラス	0.60
Repository	データアクセス層の抽象化	0.70
Middleware	リクエストパイプライン内の責任連鎖	0.70

検出したパターンは、場所、信頼度、根拠とともに分析 JSON に出力します。

{
  "patterns": [
    {
      "type": "Factory",
      "category": "Creational",
      "confidence": 0.85,
      "location": "src/services/UserFactory.ts",
      "evidence": ["createUser method", "returns IUser interface"]
    }
  ]
}

参考資料

Auto-Claude 分析フレームワークから抽出した追加の検出パターンについては、次を参照してください。

references/auto-claude-patterns.md - モノレポの指標、SERVICE_INDICATORS、SERVICE_ROOT_FILES、インフラストラクチャの検出、規約の検出
references/service-patterns.md - サービスタイプの検出（フロントエンド、バックエンド、ライブラリ）、フレームワーク固有のパターン、エントリーポイントの検出
references/database-patterns.md - データベース設定ファイルのパターン、ORM の検出（Prisma、SQLAlchemy、TypeORM、Drizzle、Mongoose）、接続文字列のパターン
references/route-patterns.md - Express、FastAPI、Flask、Django、Next.js、Go、Rust の API ルート検出パターン

これらの参考資料には、ブラウンフィールドのコードベース分析に使える包括的な正規表現パターンと検出ロジックが記載されています。

メモリプロトコル（必須）

開始前： .claude/context/memory/learnings.md を読みます。

完了後：

新しいパターン → .claude/context/memory/learnings.md
見つかった問題 → .claude/context/memory/issues.md
行った判断 → .claude/context/memory/decisions.md

中断されることを前提としてください。メモリに記録されていないことは、実施されていないのと同じです。

Markdown 対応

ログインしてコメント

基本情報

作者: oimiragieo
リポジトリ: oimiragieo/agent-studio
カテゴリ: 開発
インストール数: 117
GitHub スター: 44

問題を報告