bmad-document-project

BMAD Document Project

BROWNFIELD のエントリーポイントです。 プロジェクトにすでにコードがある場合、計画スキルにはスタックや規約についての推測ではなく、確かな実態が必要です。このスキルはコードベースを体系的に読み取り専用でスキャンし、project-documentation.md を出力します。これは、後続のすべての BMAD 計画スキルが読み込む、現在の状態を示す信頼できるスナップショットです。

コードの作成、変更、実行は一切行いません。 使用できるツールは Read、Glob、Grep、Write（出力ドキュメントのみ）、および TodoWrite（スキャンの進捗管理用）です。

---

出力

bmad-output/project-documentation.md
（またはユーザーが設定した出力フォルダー。必ずその設定に従ってください）

bmad-output/project-context.md が存在する場合は読み込み、そこにすでに記録されている制約を、ゼロから再確認するのではなく統合してください。

---

3 つの意図

どの意図か不明な場合は確認してください。既存のドキュメントを黙って再生成してはいけません。

作成 — 初回スキャン

TodoWrite を使って、以下の 6 つのスキャンパスの進捗を管理してください。最終ドキュメントを書き出す前に、すべてのパスを完了してください。

パス 1 — リポジトリーの骨格

Glob: **/* (depth ≤ 3, exclude node_modules, .git, dist, build, __pycache__, .venv)
Glob: *.md, *.txt, *.rst at root and docs/

記録する内容：ディレクトリツリーの構成、モノレポの目印（packages/、apps/、libs/）の有無、トップレベルの設定ファイル、ドキュメントのルート。

パス 2 — スタックとツールチェーン

以下のうち存在するファイルを読み込みます（ファイルがなくても失敗扱いにしないでください）。

ファイル	抽出する内容
package.json / package-lock.json	ランタイムと開発用の依存関係、スクリプト
pyproject.toml / requirements*.txt / Pipfile	Python スタック
go.mod	Go モジュールと依存関係
Cargo.toml	Rust クレート
pom.xml / build.gradle	JVM スタック
Gemfile	Ruby スタック
composer.json	PHP スタック
*.csproj / *.sln	.NET スタック
Dockerfile / docker-compose*.yml	コンテナー戦略
.github/workflows/*.yml / *.gitlab-ci.yml / Jenkinsfile	CI/CD の一連の流れ
*.tf / *.bicep / *.yaml（infra/ 内）	IaC / クラウドプロバイダー

記録する内容：主要言語、フレームワーク、主要ライブラリー、ランタイムのバージョン指定、テストフレームワーク（記録のみ — 実行しないでください）、ビルドツール、パッケージマネージャー。

パス 3 — エントリーポイントと主要なフロー

Grep: "main\|entrypoint\|app\.listen\|createServer\|handler\|router\|routes"
Grep: "export default\|module\.exports\|@app\.route\|@Controller\|@RestController"

見つかったトップレベルのエントリーファイルを読み込みます（最大 5～8 ファイル。概要を把握する程度にとどめ、網羅的に読み込まないでください）。

記録する内容：アプリの起動方法、主要なルーティング層、認証／ミドルウェアのチェーン（名前のみ）、検出されたバックグラウンドワーカーまたはキュー。

パス 4 — モジュール／ドメインの構造

src/、app/、lib/、または同等のディレクトリ直下 1 階層にあるディレクトリ名と index.* / __init__.* ファイルを読み込みます。

Glob: src/**/index.{ts,js,py,go,rb}
Glob: app/**/__init__.py

記録する内容：モジュール名と推定される責務、レイヤーの境界（コントローラー／サービス／リポジトリー／モデル／ユーティリティ）、共通ユーティリティ。

パス 5 — 規約とパターン

レイヤーごとに代表的なファイルを 3～5 個サンプルとして確認します（ファイル名やパスの深さから判断できる場合は、最近変更されたものを優先してください）。

Grep: "class \|interface \|type \|enum " — naming style
Grep: "async \|await \|Promise\|goroutine\|concurrent" — concurrency pattern
Grep: "import \|require\|from " — module resolution style
Grep: "console\.log\|logger\.\|log\." — logging approach
Grep: "\.env\|process\.env\|os\.environ\|config\." — config/secrets pattern

記録する内容：命名規約（ファイル、クラス、関数の大文字・小文字のスタイル）、エラー処理のスタイル、ロギングの方法、設定／シークレットの管理方法、テストファイルの配置規約（名前のみ — 実行しないでください）。

パス 6 — 統合ポイント

Grep: "http[s]\?://\|fetch(\|axios\.\|requests\.\|http\.Get\|RestTemplate"
Grep: "database\|db\.\|pool\.\|prisma\.\|mongoose\.\|sqlx\.\|gorm\."
Grep: "redis\|kafka\|rabbitmq\|sqs\|pubsub\|queue\|event"
Grep: "s3\.\|storage\.\|blob\.\|bucket"

記録する内容：呼び出される外部 HTTP API（ドメイン／サービス名。シークレットは含めない）、データベースの種類と ORM／ドライバー、メッセージキューまたはイベントバス、オブジェクトストレージ、サードパーティーサービス（決済、メール、認証プロバイダー — 名前のみ）。

ドキュメントの作成

${CLAUDE_PLUGIN_ROOT}/skills/bmad-document-project/templates/project-documentation.template.md
→ bmad-output/project-documentation.md

Write ツールを使用してください。内容を捏造するのではなく、情報のないセクションには `` コメントを残してください。網羅性より正確性を優先してください。

---

更新 — 変更箇所の再スキャン

1. 既存の project-documentation.md を読み込みます。
2. 変更された箇所（新しいモジュール？ 新しい依存関係？ リファクタリング？）をユーザーに確認します。
3. 変更箇所に関連する上記のパスのみを再実行します。
4. 変更されたセクションを正確に書き換えて、ドキュメントを最小限の範囲で編集します。
5. ドキュメントの末尾に日付入りの更新メモを追記します。

一部だけが変更された場合、ドキュメント全体をゼロから再生成してはいけません。

---

検証 — 網羅性を確認する

既存の project-documentation.md を読み、以下を確認します。

• 6 つすべてのスキャン領域に内容がある（空欄でも、すべて「検出されませんでした」でもない）
• 技術スタックのセクションに、主要な言語、フレームワーク、主要な依存関係が記載されている
• エントリーポイントのセクションに、少なくとも 1 つのブートストラップ／起動ファイルが記載されている
• モジュール構造に、判別可能なドメイン名が記載されている
• 規約のセクションで、命名スタイルとエラー処理が扱われている
• 統合ポイントに外部依存関係が列挙されている（または「なし」と明記されている）
• 架空のファイルパスがない（Glob で 1、2 件を照合する）

合否チェックリストを報告します。黙って編集するのではなく、不足分を補うことを提案します。

---

スコープの境界

このスキルは、単一の出力ドキュメントを除き読み取り専用です。以下の操作は行いません。

• ソースファイルを変更しません。
• テスト、ビルドスクリプト、リンター、カバレッジツールを実行しません。
• アプリケーションコード、マイグレーションファイル、フィクスチャを生成しません。
• 機能を実装したり、差分をレビューしたりしません。

スキャンで修正すべき点が見つかった場合は、修正せず、ドキュメントに計画上のメモとして記録します。

---

引き継ぎ

project-documentation.md が作成されると、既存コードベースの情報として、以下の入力資料になります。

• bmad-init — 検出された技術スタックと制約を project-context.md に反映します。
• bmad-prd — 既存の機能と統合上の制約を示す根拠になります。
• bmad-architecture — ゼロから設計するのではなく、発展させるための基準アーキテクチャになります。
• bmad-tech-spec（Quick Flow）— 焦点を絞った仕様書を作成するための具体的な出発点になります。

ドキュメントの準備ができたら、推奨する次のステップを示します。

---

ペルソナに関する注記

この分析の役割は、BMAD Method における Mary（ビジネスアナリスト）に沿ったものです。何を変えるべきかを提案する前に、現状を把握します。このドキュメントは彼女の現場メモであり、正確で、出典に基づき、推測を含みません。

---

---

BMAD Planning & Orchestrator プラグインの一部 — BMAD Code Organization による BMAD Method 用の Claude Code ハーネス（https://github.com/bmad-code-org/BMAD-METHOD）。`bmad-document-project` の理念を実装しています。手法に関する功績はすべて BMAD Code Organization に帰属します。