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

コードベース分析によって構造化されたプロジェクトドキュメントを生成します。実際のコードを反映したドキュメントを作成し、理想的なアーキテクチャではなく現状を記録します。

使用時機

• 新規プロジェクトが初期ドキュメントを必要としている
• ドキュメントが不足しているか古い
• 誰かをコードベースにオンボーディングする
• リファクタリング後のドキュメント更新

ワークフロー

1. プロジェクトタイプの検出

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

インジケーター	プロジェクトタイプ
wrangler.jsonc / wrangler.toml	Cloudflare Worker
vite.config.ts + src/App.tsx	React SPA
astro.config.mjs	Astro サイト
next.config.js	Next.js アプリ
package.json with hono	Hono API
src/index.ts with Hono	API サーバー
drizzle.config.ts	データベースレイヤーあり
schema.ts or schema/	データベーススキーマあり
pyproject.toml / setup.py	Python プロジェクト
Cargo.toml	Rust プロジェクト

2. 生成内容の確認

どのドキュメントを生成しますか?
1. ARCHITECTURE.md — システム概要、スタック、ディレクトリ構造、主要フロー
2. API_ENDPOINTS.md — ルート、メソッド、パラメーター、レスポンス形式、認証
3. DATABASE_SCHEMA.md — テーブル、リレーションシップ、マイグレーション、インデックス
4. すべて

プロジェクトに該当するドキュメントのみを提案してください。静的サイトに 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/、またはインデックス内)
• ミドルウェアファイル (認証、CORS、ログ)
• リクエスト/レスポンスタイプまたは Zod スキーマ
• エラーハンドリングパターン

DATABASE_SCHEMA.md — スキャン対象:

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

4. ドキュメント生成

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

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

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

ARCHITECTURE.md

# アーキテクチャ

## 概要
[1 段落: このプロジェクトが何をしているか、どのように構造化されているか]

## スタック
| レイヤー | テクノロジー | バージョン |
|-------|-----------|---------|
| ランタイム | [例: Cloudflare Workers] | — |
| フレームワーク | [例: Hono] | [バージョン] |
| データベース | [例: D1 (SQLite)] | — |
| ORM | [例: Drizzle] | [バージョン] |
| フロントエンド | [例: React 19] | [バージョン] |
| スタイリング | [例: Tailwind v4] | [バージョン] |

## ディレクトリ構造
[注釈付きツリー — 上位 2 レベルと目的コメント]

## 主要フロー
### [フロー 1: 例 「ユーザー認証」]
[ステップバイステップ: リクエスト → ミドルウェア → ハンドラー → データベース → レスポンス]

### [フロー 2: 例 「データ処理パイプライン」]
[システム全体のステップバイステップ]

## 設定
[主要な設定ファイルと制御対象]

## デプロイメント
[デプロイ方法、必要な環境変数、ビルドコマンド]

API_ENDPOINTS.md

# API エンドポイント

## ベース URL
[例: `https://api.example.com` または相対パス `/api`]

## 認証
[メソッド: Bearer トークン、セッションクッキー、API キー、なし]
[トークンの取得元、取得方法]

## エンドポイント

### [グループ: 例 「ユーザー」]

#### `GET /api/users`
- **認証**: 必須
- **パラメーター**: `?page=1&limit=20`
- **レスポンス**: `{ users: User[], total: number }`

#### `POST /api/users`
- **認証**: 必須 (管理者)
- **ボディ**: `{ name: string, email: string }`
- **レスポンス**: `{ user: User }` (201)
- **エラー**: 400 (バリデーション), 409 (メール重複)

[各エンドポイントごとに繰り返し]

## エラー形式
[標準エラーレスポンス形式]

## レート制限
[該当する場合]

DATABASE_SCHEMA.md

# データベーススキーマ

## エンジン
[例: Cloudflare D1 (SQLite)、PostgreSQL、MySQL]

## テーブル

### `users`
| カラム | 型 | 制約 | 説明 |
|--------|------|-------------|-------------|
| id | TEXT | PK | UUID |
| email | TEXT | UNIQUE, NOT NULL | ユーザーメール |
| name | TEXT | NOT NULL | 表示名 |
| created_at | TEXT | NOT NULL, DEFAULT now | ISO タイムスタンプ |

### `posts`
[同じ形式]

## リレーションシップ
[外部キー、結合パターン、カスケード規則]

## インデックス
[非主キーインデックスと存在理由]

## マイグレーション
- 生成: `npx drizzle-kit generate`
- ローカル適用: `npx wrangler d1 migrations apply DB --local`
- リモート適用: `npx wrangler d1 migrations apply DB --remote`

## シードデータ
[シードスクリプトへの参照 (存在する場合)]

クオリティルール

1. 計画されているもでなく、存在するものを文書化する — 実際のコードを読み、エンドポイントやテーブルを想像で作らない
2. バージョンを含める — package.json/ロックファイルから抽出し、記憶に頼らない
3. 実際のレスポンス形式を表示する — コード内の TypeScript タイプまたは Zod スキーマからコピーする
4. スキャン可能に保つ — 散文より表、プロセのより コードブロック
5. CLAUDE.md の複製を避ける — アーキテクチャ情報が既に CLAUDE.md にある場合、ARCHITECTURE.md に移動するか参照する
6. ギャップにフラグを立てる — ドキュメント化されていないルートや目的が不明なテーブルが見つかった場合、<!-- TODO: document purpose --> で注記してください

既存ドキュメントの更新

ドキュメントが既に存在する場合:

1. 既存のドキュメントを読む
2. 現在のコードベースとの差分を取得
3. ユーザーに何が変わったかを表示 (新しいエンドポイント、削除されたテーブル、更新されたスタック)
4. ユーザーが追加したカスタムコンテンツまたはセクションを保持して更新を適用する

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