プロジェクトドキュメントジェネレーター
コードベースを分析して構造化されたプロジェクトドキュメントを生成します。実際のコードを反映したドキュメントを作成し、理想的なアーキテクチャではありません。
使用すべき状況
- 新しいプロジェクトに初期ドキュメントが必要な場合
- ドキュメントが欠落しているか古くなっている場合
- コードベースに新しいメンバーをオンボーディングする場合
- リファクタリング後にドキュメントを更新する場合
ワークフロー
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 内の hono | Hono API |
src/index.ts 内の Hono | APIサーバー |
drizzle.config.ts | データベースレイヤーあり |
schema.ts または 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/、またはindex内のインライン) - ミドルウェアファイル (認証、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`
## シードデータ
[シードスクリプトが存在する場合はその参照]
品質ルール
- 計画されたものではなく、存在するものを文書化する — 実際のコードを読み、エンドポイントやテーブルを発明しない
- バージョンを含める — package.json/lockファイルから抽出し、記憶に頼らない
- 実際のレスポンス形状を示す — コード内のTypeScript型またはZodスキーマからコピーする
- スキャンしやすく保つ — 段落よりも表、散文よりもコードブロック
- CLAUDE.mdを複製しない — アーキテクチャ情報がすでにCLAUDE.mdにある場合は、ARCHITECTURE.mdに移動するか参照する
- ギャップをマークする — 目的が不明確な文書化されていないルートやテーブルを見つけた場合は、
<!-- TODO: 目的を文書化 -->でメモする
既存ドキュメントの更新
ドキュメントが既に存在する場合:
- 既存のドキュメントを読む
- 現在のコードベースと差分を取る
- 変更内容をユーザーに表示する（新しいエンドポイント、削除されたテーブル、更新されたスタック）
- 手書きのメモやセクションを保持したまま更新を適用する
ユーザーがドキュメントに追加したカスタムコンテンツを黙って上書きしないでください。