repowiki

RepoWiki - リポジトリレポート生成ツール

現在のリポジトリのコード構造、設定ファイル、依存関係に基づいて、DeepWiki スタイルの詳細な分析レポートを生成します。

レポート構成の仕様

生成するレポートは、以下の階層構造に厳密に従い、単一の Markdown ファイルとして出力してください。

レイヤー 1：プロジェクト概要

# {Project Name}

> {One-line project positioning description}

## Purpose & Scope

{2-3 paragraphs describing what problem the project solves, core value, target users}

## Tech Stack

| Category | Technology | Purpose |
|----------|-----------|---------|
| Language | ... | ... |
| Framework | ... | ... |
| Build Tool | ... | ... |
| Testing | ... | ... |
| Database | ... | ... |

## Repository Structure

{Mermaid graph showing top-level directory structure and module relationships}

## Core Systems Overview

{Mermaid graph showing interactions between major subsystems}

レイヤー 1.5：コンセプトと設計思想

プロジェクト概要とモジュール分析の間に、プロジェクトの中核となるアイデアと技術的な根拠を説明するセクションを追加してください。プロジェクトが何をするかではなく、なぜこのように構築されたのかを説明します。

## Design Philosophy & Key Decisions

### Core Concept
{1-2 paragraphs explaining the fundamental insight or approach that drives the project's design.
 What problem does the conventional approach have? What alternative mental model does this project adopt?}

### Key Technical Decisions

| Decision | Chose | Over | Rationale |
|----------|-------|------|-----------|
| {e.g., State management} | {Zustand} | {Redux, Context API} | {Why — specific trade-off reasoning} |
| ... | ... | ... | ... |

### Architecture Principles
{2-4 bullet points capturing the non-obvious design principles extracted from the code.
 Each should explain a constraint or convention the codebase follows, and WHY.}

このレイヤーは、DeepWiki 品質のレポートに不可欠です。読者が**「何を」理解する前に、「なぜ」**を理解できるようにしてください。

レイヤー 2：モジュールとパッケージの分析

## Module Inventory

| Module | Path | Responsibility | Key Dependencies |
|--------|------|---------------|-----------------|
| ... | ... | ... | ... |

## Module Dependency Architecture

{Mermaid graph: inter-module dependency diagram}

## {Module Name} Detailed Analysis

<details>
<summary>Related Source Files</summary>

- `path/to/file1.ts`
- `path/to/file2.ts`
</details>

### Responsibilities & Boundaries
{What this module is and isn't responsible for}

### Internal Architecture
{Mermaid graph: class/function relationships within the module}

### Key Interfaces
{Code block: main exported APIs, type definitions, interfaces}

### Data Flow
{Mermaid sequence/flowchart: how data flows within the module}

レイヤー 3：コアシステムの詳細分析

各コアシステムについて、独立したセクションを生成してください。

## {System Name}

<details>
<summary>Related Source Files</summary>

- `path/to/relevant/file.ts`
</details>

### Problem & Approach
{Start each core system section with a narrative arc:
 1. What problem does this system solve?
 2. What is the conventional/naive approach, and why doesn't it work here?
 3. What insight or approach does this project use instead?
 This "problem → conventional failure → project's solution" arc is critical for DeepWiki-quality analysis.}

### System Architecture
{Mermaid graph: overall architecture diagram of the system}

### Core Workflows
{Mermaid sequence diagram: main business processes}

### Key Components

| Component | File | Responsibility |
|-----------|------|---------------|
| ... | ... | ... |

### Design Decisions & Trade-offs

| Decision | Chose | Over | Rationale |
|----------|-------|------|-----------|
| ... | ... | ... | ... |

{For each major design decision within this system, explain what was chosen over what alternatives, and why. This comparison table is required for every core system section.}

### Configuration & Extension Points
{Code block: key configuration file snippets}

レイヤー 4：インフラストラクチャとツールチェーン

## Build System

### Build Pipeline
{Mermaid flowchart: complete process from source to artifacts}

### Build Configuration
{Table: key build configuration items}

## Testing Infrastructure

### Testing Strategy
| Test Type | Tool | Coverage |
|-----------|------|----------|
| Unit Tests | ... | ... |
| Integration Tests | ... | ... |
| E2E Tests | ... | ... |

### Test Configuration
{Code block: key test configuration file snippets}

## CI/CD Pipeline
{Mermaid flowchart: CI/CD process}

## Dependency Management
### Key Dependencies
| Dependency | Version | Purpose |
|-----------|---------|---------|
| ... | ... | ... |

### Dependency Strategy
{Version locking, update strategy, security auditing}

Mermaid 図の仕様

重要：避けるべき Mermaid の構文上の落とし穴：

• ノードラベルやエッジラベルには丸括弧 () を使用しないでください。パーサーでエラーになります。全角の （） を使うか、別の表現にしてください。
• ラベル文字列内で、特殊文字 {}[]() をエスケープせずに使用しないでください。特殊文字を含む場合は、ラベルを ["..."] で囲んでください。
• 図の種類の宣言（graph、flowchart、sequenceDiagram、stateDiagram-v2）が本文で使用する構文と一致していることを必ず確認してください。

各レポートには、次の種類の図を含めてください。

1. リポジトリ構造図（必須）

graph TD
    Root[Project Root]
    Root --> Src[src/]
    Root --> Config[Configuration]
    Root --> Tests[tests/]
    Src --> Core[core/]
    Src --> Utils[utils/]
    Src --> Types[types/]

2. モジュール依存関係図（必須）

graph LR
    A[Module A] --> B[Module B]
    A --> C[Module C]
    B --> D[Module D]
    C --> D

3. コアワークフロー図（必須）

sequenceDiagram
    participant User
    participant API
    participant Service
    participant DB
    User->>API: Request
    API->>Service: Process
    Service->>DB: Query
    DB-->>Service: Result
    Service-->>API: Response
    API-->>User: Return

4. データフロー図（必要に応じて）

flowchart LR
    Input[Input] --> Validate[Validate]
    Validate --> Transform[Transform]
    Transform --> Process[Process]
    Process --> Output[Output]

5. 状態／ライフサイクル図（必要に応じて）

stateDiagram-v2
    [*] --> Created
    Created --> Active
    Active --> Paused
    Paused --> Active
    Active --> Completed
    Completed --> [*]

分析の実行手順

ステップ 1：リポジトリのメタデータを収集する

以下のツールを使用して情報を収集してください（並列で実行します）。

1. ディレクトリ構造 - Glob を使用して **/* をスキャンし、完全なファイルツリーを取得します
2. パッケージ管理 - package.json、go.mod、Cargo.toml、pyproject.toml、pom.xml などを読み込みます
3. 設定ファイル - tsconfig.json、.eslintrc.*、vite.config.*、webpack.config.* などを読み込みます
4. CI/CD - .github/workflows/*、.gitlab-ci.yml、Dockerfile などを読み込みます
5. Git 履歴 - 直近 100 件のコミットからファイルの変更頻度を取得します

ステップ 2：コアシステムを特定する

以下のシグナルに基づいて、コアシステムを特定してください。

シグナル	重み	方法
ファイルの変更頻度	高	git log の統計
ディレクトリの規模	中	ファイル数
エントリファイルからの参照	高	grep import/require
README での言及	中	ドキュメントを読む
エクスポート数	中	grep export

ステップ 3：各システムを詳細に分析する

各コアシステムについて、以下を実施してください。

1. そのディレクトリ内のすべてのファイルを読み込みます
2. 主なクラス、関数、型定義を特定します。重要な定義にはファイルと行番号への参照（例：src/engine.ts:42）を含め、読者がソースを直接参照できるようにしてください
3. import/export の依存関係をたどります
4. デザインパターン（Repository、Factory、Observer など）を特定します
5. 重要な設定と定数を抽出します
6. 重要なアルゴリズムやワークフローについては、コードロジックを段階的に分析してください。インターフェースレベルの説明にとどめず、実際の実装をたどってください

ステップ 4：Mermaid 図を生成する

分析結果に基づいて、以下を生成してください。

• アーキテクチャ概要図を少なくとも 1 つ
• モジュール依存関係図を少なくとも 1 つ
• コアワークフローのシーケンス図を少なくとも 1 つ
• 必要に応じて状態図とデータフロー図を追加

ステップ 5：レポートを組み立てる

上記の構成仕様に従ってレポート全体を組み立て、REPOWIKI.md に出力してください。

ソースファイル参照の仕様

各セクションには、折りたたみ可能なソースファイル参照を含める必要があります。

<details>
<summary>Related Source Files</summary>

- `src/core/engine.ts` - Core engine implementation
- `src/core/types.ts` - Type definitions
- `src/config/default.ts` - Default configuration
</details>

参照ルール：

• 現在のセクションに直接関連するファイルのみを参照してください
• 各参照には簡潔な説明を含めてください
• 重要度順に並べ、最も重要なファイルを先頭にしてください
• セクションごとに参照するファイルは3～10個にしてください

表の使用に関する仕様

次の場合は必ず表を使用してください。

1. 技術スタック - 言語、フレームワーク、ツールの一覧
2. モジュール一覧 - すべてのモジュールのパス、役割、依存関係
3. 設定の比較 - 環境やモードごとの設定の違い
4. API 一覧 - 公開 API のメソッド、パラメーター、戻り値
5. 依存関係の一覧 - 主要な依存関係のバージョンと用途

出力要件

1. ファイル名：REPOWIKI.md。リポジトリのルートに配置してください
2. 言語：ユーザーとの会話で使用されている言語に合わせてください（中国語での会話なら、レポートも中国語）
3. 長さ：
   • 小規模プロジェクト（ファイル数50未満）：800～1500行
   • 中規模プロジェクト（ファイル数50～200）：1500～3000行
   • 大規模プロジェクト（ファイル数200超）：3000～6000行
4. 図の数：Mermaid 図を少なくとも3つ、大規模プロジェクトでは6～10個
5. 表の数：少なくとも3つ
6. コードブロック：主要な設定とインターフェース定義を記載し、各ブロックは30行以内にしてください

品質チェックリスト

レポートの生成後、次の項目を確認してください。

• プロジェクトの概要と、一文で表した位置付けが含まれている
• 技術スタックの表が完全かつ正確である
• リポジトリ構成を示す Mermaid 図が実際の構成と一致している
• 各コアシステムに独立したセクションがある
• 各セクションに折りたたみ可能なソースファイル参照がある
• モジュール依存関係図が実際の依存関係を正しく反映している
• 少なくとも1つのシーケンス図で主要なワークフローが示されている
• すべての表が正しく書式設定され、内容が正確である
• コードブロックのシンタックスハイライトが正しい
• 架空のファイルやモジュールがない
• Mermaid 図の構文が正しく、レンダリング可能である

記述例

以下は、TypeScript のウェブプロジェクト向けレポート例です。

# MyApp

> A full-stack e-commerce platform built on Next.js, supporting multi-tenancy and real-time inventory management.

## Purpose & Scope

MyApp is an e-commerce SaaS platform for small and medium-sized merchants. It provides
product management, order processing, payment integration, and real-time inventory
synchronization as core features. The project uses Next.js App Router architecture,
Prisma as the ORM, and PostgreSQL as the primary database.

## Tech Stack

| Category | Technology | Purpose |
|----------|-----------|---------|
| Language | TypeScript 5.3 | Full-stack development language |
| Framework | Next.js 14 | Full-stack React framework |
| ORM | Prisma 5.8 | Database access layer |
| Database | PostgreSQL 16 | Primary data storage |
| Cache | Redis 7 | Session and hot data caching |
| Testing | Vitest + Playwright | Unit and E2E testing |

## Repository Structure

```mermaid
graph TD
    Root["myapp/"]
    Root --> App["app/ - Next.js App Router"]
    Root --> Lib["lib/ - Shared Business Logic"]
    Root --> Components["components/ - UI Components"]
    Root --> Prisma["prisma/ - Database Schema"]
    Root --> Tests["tests/ - Test Files"]

    App --> API["api/ - API Routes"]
    App --> Pages["(routes)/ - Pages"]
    Lib --> Services["services/ - Business Services"]
    Lib --> Utils["utils/ - Utility Functions"]

コアシステムの概要

graph LR
    Client["Client"] --> AppRouter["App Router"]
    AppRouter --> Auth["Auth System"]
    AppRouter --> API["API Layer"]
    API --> OrderService["Order Service"]
    API --> ProductService["Product Service"]
    API --> PaymentService["Payment Service"]
    OrderService --> DB["PostgreSQL"]
    ProductService --> DB
    ProductService --> Cache["Redis"]
    PaymentService --> Stripe["Stripe API"]

注文システム

関連ソースファイル

• lib/services/order.ts - 注文サービスの中核となるロジック
• app/api/orders/route.ts - 注文 API ルート
• prisma/schema.prisma - 注文のデータモデル
• lib/validators/order.ts - 注文データの検証
• components/order/OrderForm.tsx - 注文フォームのコンポーネント

目的と範囲

注文システムは、ショッピングカートから支払い完了までの注文ライフサイクル全体を管理します。 これには、注文の作成、在庫の確保、支払い処理、ステータスの遷移、通知の配信が含まれます。

注文のライフサイクル

stateDiagram-v2
    [*] --> Created: User places order
    Created --> Paying: Initiate payment
    Paying --> Paid: Payment successful
    Paying --> Cancelled: Payment timeout/failure
    Paid --> Shipping: Merchant ships
    Shipping --> Completed: Delivery confirmed
    Completed --> [*]
    Cancelled --> [*]

## Language/Framework Adaptation

Adjust analysis focus based on project type:

| Project Type | Analysis Focus |
|-------------|---------------|
| Node.js/TypeScript | package.json, tsconfig, module exports |
| Go | go.mod, package structure, interface definitions |
| Python | pyproject.toml, package structure, class hierarchy |
| Rust | Cargo.toml, crate structure, trait definitions |
| Java/Kotlin | pom.xml/build.gradle, package structure, class hierarchy |
| Monorepo | workspace config, inter-package dependencies, build order |
| Frontend SPA | routing structure, state management, component tree |
| Backend API | route definitions, middleware chain, data models |
| CLI Tool | command structure, argument parsing, subcommands |