| name | generate-project-docs |
| description | 開発規模の大きい機能開発向けに、既存コードベースを事前調査したうえでプロジェクト仕様ドキュメントを生成します。docs/projects/YYYYMMDD-要件名/ 配下に 01_要件定義書.md、02_概要設計書.md、03_WBS.md を作成します。git管理対象のため機密情報は含めません。「プロジェクトドキュメント作成」「新規開発の仕様書を作って」「大規模開発のドキュメント生成」などで呼び出されます。 |
プロジェクト仕様ドキュメント生成スキル（大規模機能開発向け）
概要
このスキルは、開発規模の大きい機能開発のためのプロジェクト仕様ドキュメントを docs/projects/{YYYYMMDD}-{要件名}/ 配下に生成します。
generate-working-docs が WBS の 1 タスク単位の作業ドキュメントを対象とするのに対し、本スキルはその上位レイヤーである要件・設計・WBS 全体を対象とします。
本スキルの特徴
1. 既存コードベースの事前調査を必須化
大規模開発のドキュメントを作成する際、既存実装を把握しないまま書き出すと矛盾が発生し手戻りになります。本スキルは必ず生成前に Explore エージェントで既存コードベースを調査し、以下を明確化します：
- 既に実装済みの機能 — 今回の要件で利用・継承できるもの
- 拡張対象の既存機能 — 今回の開発で改修するもの
- 新規実装が必要な部分 — 既存コードに存在しないもの
2. git 管理前提の機密情報ガード
生成先 docs/projects/ は git 管理対象です。以下の情報は記載しません：
- APIキー・トークン・パスワード・接続文字列
- 社内固有のURL・IPアドレス・ホスト名
- 個人情報（メールアドレス・氏名・アカウントID等）
- 取引先名・未公開の事業情報
生成前にユーザー入力から検出した場合は警告し、生成後にも自己チェック（grep パターンマッチ）を行います。
生成ファイル
| ファイル | 内容 |
|---|
01_要件定義書.md | 機能・非機能要件、背景、ユースケース、スコープ |
02_概要設計書.md | アーキテクチャ、コンポーネント設計、データフロー、既存コードとの関係 |
03_WBS.md | 作業分解・フェーズ別スケジュール・依存関係 |
実行手順
ステップ1: 要件ヒアリング
ユーザーに以下を確認します：
- 要件名: 日本語可（例:
macOSウィンドウタブ統合）。docs/local/ 既存フォルダ名に合わせてハイフン区切り。
- 機能の目的・背景: なぜ必要か、誰のためか
- スコープの大まかな輪郭: 含める／含めない機能
ステップ2: 既存コードベースの調査（必須）
Explore エージェントを起動し、以下の観点で調査します：
Agent({
description: "既存実装調査",
subagent_type: "Explore",
prompt: "{要件名}に関連する既存実装を調査。以下を洗い出す：
1. 既に実装済みで、今回の要件で再利用できる機能・モジュール（ファイルパス・主要関数）
2. 今回の要件で改修が必要な既存機能（現状の実装箇所・改修ポイント）
3. 今回の要件で新規実装が必要な領域（既存コードに存在しない機能）
調査対象: src/, src-tauri/src/, docs/steering/, docs/local/
報告は簡潔に（200 語程度）。"
})
ステップ3: 調査サマリの提示と認識合わせ
Explore の結果をもとに、以下の形式でユーザーに提示します：
## 既存コードベース調査結果
### 既存実装（再利用可能）
- `src/components/xxx.tsx` — 〇〇機能として実装済み
### 改修対象
- `src-tauri/src/commands/yyy.rs` — 今回の要件で拡張
### 新規実装
- zzz コンポーネント — 既存に存在しない
この認識で進めてよいですか？
ユーザー承認後に次のステップへ進みます。認識齟齬があればヒアリングを繰り返します。
ステップ4: ディレクトリ作成
mkdir -p docs/projects/{YYYYMMDD}-{要件名}
ステップ5: ドキュメント生成
3ファイルをテンプレート（templates.md）に沿って生成します。テンプレートの穴埋めではなく、調査結果とヒアリング内容を踏まえて実際の内容を記載してください。
参照すべき永続化ドキュメント：
docs/steering/01_product_requirements.md — プロダクト全体の要件docs/steering/02_functional_design.md — 既存の画面・機能設計docs/steering/03_architecture_specifications.md — 技術スタック・アーキテクチャdocs/steering/04_repository_structure.md — ディレクトリ構造・命名規則docs/steering/05_development_guidelines.md — コーディング規約・ブランチ戦略docs/steering/06_ubiquitous_language.md — プロジェクト用語
各ドキュメントには**「既存コードベースとの関係」セクション**を必ず含め、ステップ2の調査結果を反映します。
ステップ6: 機密情報の自己チェック
生成後、以下のパターンで生成ファイルを Grep し、該当があればユーザーに報告します：
(?i)(api[_-]?key|token|password|secret|credential)- メールアドレス形式:
[\w.+-]+@[\w-]+\.[\w.-]+
- IPアドレス形式（プライベート/パブリック問わず）:
\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}
- 社内ドメイン的なパターン:
\.internal, \.corp, \.local
検出時は該当箇所を提示し、削除・マスクの判断をユーザーに仰ぎます。
ステップ7: 完了報告
生成したディレクトリとファイル一覧、および機密情報チェック結果をユーザーに報告します。コミットはユーザー承認後（CLAUDE.md の作業ルール参照）。
使用例
詳細は examples.md を参照してください。
関連
generate-working-docs — WBS の 1 タスク単位の作業ドキュメント生成CLAUDE.md — 作業ルール（コミットタイミング等）docs/steering/ — 永続化ドキュメント群docs/local/ — 過去の類似ドキュメント（参考用、機密情報を含む可能性あり）
