project-docs

プロジェクトドキュメント生成ツール

コードベースを分析して、構造化されたプロジェクトドキュメントを生成します。目指すアーキテクチャではなく、実際のコードを反映したドキュメントを作成します。

使用する場面

• 新しいプロジェクトの初期ドキュメントが必要なとき
• ドキュメントが不足している、または古くなっているとき
• コードベースについて誰かに説明するとき
• リファクタリング後にドキュメントを更新するとき

ワークフロー

1. プロジェクトの種類を検出する

プロジェクトのルートをスキャンし、プロジェクトの種類を判定します。

指標	プロジェクトの種類
wrangler.jsonc / wrangler.toml	Cloudflare Worker
vite.config.ts + src/App.tsx	React SPA
astro.config.mjs	Astro サイト
next.config.js	Next.js アプリ
hono を含む package.json	Hono API
Hono を含む src/index.ts	API サーバー
drizzle.config.ts	データベース層あり
schema.ts または schema/	データベーススキーマあり
pyproject.toml / setup.py	Python プロジェクト
Cargo.toml	Rust プロジェクト

2. 生成するドキュメントを確認する

Which docs should I generate?
1. ARCHITECTURE.md — system overview, stack, directory structure, key flows
2. API_ENDPOINTS.md — routes, methods, params, response shapes, auth
3. DATABASE_SCHEMA.md — tables, relationships, migrations, indexes
4. All of the above

プロジェクトに合ったドキュメントだけを提示してください。静的サイトに API_ENDPOINTS.md を提示しないでください。データベースがない場合は DATABASE_SCHEMA.md を提示しないでください。

3. コードベースをスキャンする

リクエストされた各ドキュメントについて、関連するソースファイルを読み込みます。

ARCHITECTURE.md — スキャン対象：

• package.json / pyproject.toml（技術スタック、依存関係）
• エントリーポイント（src/index.ts、src/main.tsx、src/App.tsx）
• 設定ファイル（wrangler.jsonc、vite.config.ts、tsconfig.json）
• ディレクトリ構成（上位 2 階層）
• 主要なモジュールとそのエクスポート

API_ENDPOINTS.md — スキャン対象：

• ルートファイル（src/routes/、src/api/、または index 内のインライン定義）
• ミドルウェアファイル（認証、CORS、ロギング）
• リクエスト／レスポンスの型または Zod スキーマ
• エラー処理のパターン

DATABASE_SCHEMA.md — スキャン対象：

• Drizzle スキーマファイル（src/db/schema.ts、src/schema/）
• マイグレーションファイル（drizzle/、migrations/）
• 存在する場合は生の SQL ファイル
• 存在する場合はシードファイル

4. ドキュメントを生成する

各ドキュメントを docs/ に書き込みます（ディレクトリが存在しない場合は作成します）。すでにプロジェクトにドキュメントがある場合は、上書きではなく更新を提案してください。

小規模なプロジェクトで docs/ ディレクトリがない場合は、プロジェクトのルートに書き込みます。

ドキュメントのテンプレート

ARCHITECTURE.md

# Architecture

## Overview
[One paragraph: what this project does and how it's structured]

## Stack
| Layer | Technology | Version |
|-------|-----------|---------|
| Runtime | [e.g. Cloudflare Workers] | — |
| Framework | [e.g. Hono] | [version] |
| Database | [e.g. D1 (SQLite)] | — |
| ORM | [e.g. Drizzle] | [version] |
| Frontend | [e.g. React 19] | [version] |
| Styling | [e.g. Tailwind v4] | [version] |

## Directory Structure
[Annotated tree — top 2 levels with purpose comments]

## Key Flows
### [Flow 1: e.g. "User Authentication"]
[Step-by-step: request → middleware → handler → database → response]

### [Flow 2: e.g. "Data Processing Pipeline"]
[Step-by-step through the system]

## Configuration
[Key config files and what they control]

## Deployment
[How to deploy, environment variables needed, build commands]

API_ENDPOINTS.md

# API Endpoints

## Base URL
[e.g. `https://api.example.com` or relative `/api`]

## Authentication
[Method: Bearer token, session cookie, API key, none]
[Where tokens come from, how to obtain]

## Endpoints

### [Group: e.g. Users]

#### `GET /api/users`
- **Auth**: Required
- **Params**: `?page=1&limit=20`
- **Response**: `{ users: User[], total: number }`

#### `POST /api/users`
- **Auth**: Required (admin)
- **Body**: `{ name: string, email: string }`
- **Response**: `{ user: User }` (201)
- **Errors**: 400 (validation), 409 (duplicate email)

[Repeat for each endpoint]

## Error Format
[Standard error response shape]

## Rate Limits
[If applicable]

DATABASE_SCHEMA.md

# Database Schema

## Engine
[e.g. Cloudflare D1 (SQLite), PostgreSQL, MySQL]

## Tables

### `users`
| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| id | TEXT | PK | UUID |
| email | TEXT | UNIQUE, NOT NULL | User email |
| name | TEXT | NOT NULL | Display name |
| created_at | TEXT | NOT NULL, DEFAULT now | ISO timestamp |

### `posts`
[Same format]

## Relationships
[Foreign keys, join patterns, cascading rules]

## Indexes
[Non-primary indexes and why they exist]

## Migrations
- Generate: `npx drizzle-kit generate`
- Apply local: `npx wrangler d1 migrations apply DB --local`
- Apply remote: `npx wrangler d1 migrations apply DB --remote`

## Seed Data
[Reference to seed script if one exists]

品質ルール

1. 計画ではなく、存在するものを記載する — 実際のコードを読み、エンドポイントやテーブルを創作しないでください
2. バージョンを含める — 記憶ではなく、package.json／ロックファイルから抽出してください
3. 実際のレスポンス形状を示す — コード内の TypeScript 型または Zod スキーマからコピーしてください
4. 一覧性を高める — 段落より表を、文章よりコードブロックを使用してください
5. CLAUDE.md と重複させない — アーキテクチャ情報がすでに CLAUDE.md にある場合は、ARCHITECTURE.md に移すか、参照してください
6. 不足箇所を明示する — ドキュメントに記載されていないルートや、目的が不明なテーブルを見つけた場合は、`` で注記してください

既存ドキュメントの更新

すでにドキュメントがある場合：

1. 既存のドキュメントを読む
2. 現在のコードベースとの差分を確認する
3. 変更点（新しいエンドポイント、削除されたテーブル、更新された技術スタック）をユーザーに示す
4. 手書きのメモやセクションを保持して更新する

ユーザーがドキュメントに追加したカスタムコンテンツを、決して黙って上書きしないでください。