project-planning
プロジェクトの概要説明から、プロジェクト計画書(PVS、ADR、技術仕様書、ロードマップ)の初期版を自動生成し、新規プロジェクト開始時や計画段階で役立つドキュメント作成を支援するSkill。
📜 元の英語説明(参考)
Generate initial project planning documents (PVS, ADR, Tech Spec, Roadmap) from a project concept description. Use when starting a new project, when docs/planning/ contains placeholder files, or when user requests project planning document generation.
🇯🇵 日本人クリエイター向け解説
プロジェクトの概要説明から、プロジェクト計画書(PVS、ADR、技術仕様書、ロードマップ)の初期版を自動生成し、新規プロジェクト開始時や計画段階で役立つドキュメント作成を支援するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o project-planning.zip https://jpskill.com/download/17656.zip && unzip -o project-planning.zip && rm project-planning.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/17656.zip -OutFile "$d\project-planning.zip"; Expand-Archive "$d\project-planning.zip" -DestinationPath $d -Force; ri "$d\project-planning.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
project-planning.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
project-planningフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 2
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
プロジェクト計画スキル
AI支援開発を導くための4つの重要な計画ドキュメントを生成します。これらのドキュメントは、コーディングセッション全体でコンテキストの一貫性を維持し、アーキテクチャのドリフトを防ぎます。
このスキルを使用するタイミング
- ユーザーがプロジェクトのコンセプトを説明し、計画ドキュメントを要求した場合
docs/planning/内のファイルが「生成待ち」ステータスを示している場合- ユーザーがプロジェクトの説明とともに
/planコマンドを呼び出した場合 - アーキテクチャ上の決定を必要とする新しい機能の開発を開始する場合
出力ドキュメント
| ドキュメント | 場所 | 目的 |
|---|---|---|
| プロジェクトビジョンとスコープ | docs/planning/project-vision.md |
何と理由 - 問題、解決策、スコープ |
| 技術仕様 | docs/planning/tech-spec.md |
方法 - アーキテクチャ、データモデル、API |
| 開発ロードマップ | docs/planning/roadmap.md |
いつ - 段階的な実装計画 |
| アーキテクチャ決定記録 | docs/planning/adr/adr-001-*.md |
根拠に基づいた主要な技術的決定 |
生成プロセス
ステップ 1: プロジェクトのコンテキストを収集する
生成する前に、以下を収集します。
- ユーザー入力からのプロジェクトの説明
pyproject.tomlおよび既存のコードからの技術的な制約- プロジェクト構造に反映されたCookiecutterの選択
ステップ 2: ドキュメントを順番に生成する
後のドキュメントが前のドキュメントを参照するため、ドキュメントを順番に生成します。
- プロジェクトビジョンとスコープ - 何を構築し、なぜ構築するのかを確立します
- アーキテクチャ決定記録 - PVSに基づいた主要な技術的選択
- 技術実装仕様 - ADRに基づいた詳細なハウツー
- 開発ロードマップ - 上記すべてに基づいた実装計画
ステップ 3: コンセンサスによる専門家レビュー
各ドキュメントを生成した後、zen-mcp-serverコンセンサスツールを使用して専門家レビューを取得します。
Use mcp__zen__consensus with gemini-3-pro-preview to review:
"Review this [document type] for sufficiency to begin development.
Evaluate:
1. SPECIFICITY: Are requirements concrete enough to implement?
2. COMPLETENESS: Are all critical sections filled with project-specific content?
3. FEASIBILITY: Are timelines and technical choices realistic?
4. CLARITY: Can a developer understand what to build from this?
5. GAPS: What critical information is missing?
Respond with:
- READY: Document is sufficient to begin work
- NEEDS REVISION: [List specific improvements required]
Document content:
[paste document content]"
各ドキュメントを順番にレビューします:
- PVS → ADRを生成する前にREADYである必要があります
- ADR → 技術仕様を生成する前にREADYである必要があります
- 技術仕様 → ロードマップを生成する前にREADYである必要があります
- ロードマップ → 完了する前にREADYである必要があります
ドキュメントがNEEDS REVISIONの場合、フィードバックを組み込み、続行する前に再度レビューします。
ステップ 4: 検証と相互参照
すべてのドキュメントがレビューに合格した後:
- ドキュメントが互いに正しく参照していることを確認します
- 技術的な選択がドキュメント全体で一貫していることを確認します
- ユーザーの検証が必要な仮定にフラグを立てます
- 利用可能な場合は、検証スクリプトを実行します
ドキュメント生成のガイドライン
すべてのドキュメント
- 具体的にする: 具体的なテクノロジー、バージョン、および測定可能な基準を使用します
- ボイラープレートを使用しない: すべてのセクションにプロジェクト固有の情報が含まれている必要があります
- 1000語未満: 濃縮された情報、最小限の文章
- Markdown形式: 構造にはヘッダー、箇条書き、テーブルを使用します
- TL;DRを含める: 各ドキュメントの先頭に2〜3文の要約を記述します
プロジェクトビジョンとスコープ (PVS)
テンプレートを使用します: templates/pvs-template.md
以下に焦点を当てます:
- 解決される問題とユーザーへの影響
- コア機能 (MVPの場合は最大3〜5個)
- 明示的なスコープ境界 (in vs out)
- 測定可能な成功指標
アーキテクチャ決定記録 (ADR)
テンプレートを使用します: templates/adr-template.md
以下についてADRを作成します:
- データベース/ストレージの選択
- 認証戦略
- API設計アプローチ
- 主要なフレームワークの決定
- 元に戻すのにコストがかかる選択
形式: adr-001-{decision-slug}.md
技術実装仕様
テンプレートを使用します: templates/tech-spec-template.md
以下を含めます:
- バージョンを含む完全な技術スタック
- コンポーネントアーキテクチャ図 (ASCII)
- スキーマを含むデータモデル
- APIエンドポイント仕様
- セキュリティ要件
- エラー処理アプローチ
開発ロードマップ
テンプレートを使用します: templates/roadmap-template.md
以下のように構成します:
- フェーズ 0: 基盤 (環境、CI/CD)
- フェーズ 1: MVPコア (必須機能)
- フェーズ 2: 拡張 (追加機能)
- フェーズ 3: 仕上げ (テスト、ドキュメント)
各フェーズには以下が必要です:
- 明確な成果物
- 成功基準 (テスト可能)
- 推定期間
- 依存関係
プロジェクトコンテキストからの事前入力
生成時に、既知の情報を組み込みます:
# From pyproject.toml / cookiecutter context
python_version = "3.12"
project_name = "Fragrance Rater"
project_slug = "fragrance_rater"
cli_framework = "Click"
containerization = "Docker"
品質チェックリスト
生成を完了する前に:
- [ ] 4つのドキュメントすべてが
docs/planning/に作成されている - [ ] 各ドキュメントにTL;DRセクションがある
- [ ] "[TODO]" または "[TBD]" のプレースホルダーが残っていない
- [ ] ドキュメントが相互参照している
- [ ] 技術的な選択が一貫している
- [ ] 成功基準が測定可能である
- [ ] スコープ境界が明確である
- [ ] 少なくとも1つのADRが作成されている
テンプレートリファレンス
テンプレートは templates/ ディレクトリにあります:
pvs-template.md- プロジェクトビジョンとスコープの構造adr-template.md- アーキテクチャ決定記録の構造tech-spec-template.md- 技術仕様の構造roadmap-template.md- 開発ロードマップの構造
詳細なガイダンス
各ドキュメントタイプの包括的なドキュメントについては、reference/ ディレクトリを参照してください:
reference/document-guide.md- すべてのドキュメントタイプの完全なガイダンスreference/prompting-patterns.md- 開発中にドキュメントを使用する方法
生成後
ユーザーに以下を指示します:
- 各ドキュメントの正確性を確認する
[ ]でマークされた仮定を検証する- 必要に応じてロードマップのタイムラインを調整する
- ドキュメントをバージョン管理にコミットする
- 今後の開発セッションでドキュメントを参照する
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Project Planning Skill
Generate four essential planning documents to guide AI-assisted development. These documents maintain context coherence across coding sessions and prevent architectural drift.
When to Use This Skill
- User describes a project concept and asks for planning documents
- Files in
docs/planning/show "Awaiting Generation" status - User invokes
/plancommand with project description - Starting development on a new feature requiring architectural decisions
Output Documents
| Document | Location | Purpose |
|---|---|---|
| Project Vision & Scope | docs/planning/project-vision.md |
What & Why - problem, solution, scope |
| Technical Spec | docs/planning/tech-spec.md |
How - architecture, data model, APIs |
| Development Roadmap | docs/planning/roadmap.md |
When - phased implementation plan |
| Architecture Decision Record | docs/planning/adr/adr-001-*.md |
Key technical decisions with rationale |
Generation Process
Step 1: Gather Project Context
Before generating, collect:
- Project description from user input
- Technical constraints from
pyproject.tomland existing code - Cookiecutter choices reflected in project structure
Step 2: Generate Documents in Order
Generate documents sequentially, as later documents reference earlier ones:
- Project Vision & Scope - Establishes what we're building and why
- Architecture Decision Record - Key technical choices based on PVS
- Technical Implementation Spec - Detailed how-to based on ADRs
- Development Roadmap - Implementation plan based on all above
Step 3: Expert Review via Consensus
After generating each document, use the zen-mcp-server consensus tool to get expert review:
Use mcp__zen__consensus with gemini-3-pro-preview to review:
"Review this [document type] for sufficiency to begin development.
Evaluate:
1. SPECIFICITY: Are requirements concrete enough to implement?
2. COMPLETENESS: Are all critical sections filled with project-specific content?
3. FEASIBILITY: Are timelines and technical choices realistic?
4. CLARITY: Can a developer understand what to build from this?
5. GAPS: What critical information is missing?
Respond with:
- READY: Document is sufficient to begin work
- NEEDS REVISION: [List specific improvements required]
Document content:
[paste document content]"
Review each document in order:
- PVS → Must be READY before generating ADR
- ADR → Must be READY before generating Tech Spec
- Tech Spec → Must be READY before generating Roadmap
- Roadmap → Must be READY before completing
If any document NEEDS REVISION, incorporate feedback and re-review before proceeding.
Step 4: Validate and Cross-Reference
After all documents pass review:
- Ensure documents reference each other correctly
- Verify technical choices are consistent across documents
- Flag any assumptions needing user validation
- Run validation script if available
Document Generation Guidelines
All Documents
- Be specific: Use concrete technologies, versions, and measurable criteria
- No boilerplate: Every section must contain project-specific information
- Under 1000 words: Dense information, minimal prose
- Markdown format: Use headers, bullets, tables for structure
- Include TL;DR: 2-3 sentence summary at top of each document
Project Vision & Scope (PVS)
Use template: templates/pvs-template.md
Focus on:
- Problem being solved and user impact
- Core capabilities (3-5 max for MVP)
- Explicit scope boundaries (in vs out)
- Measurable success metrics
Architecture Decision Record (ADR)
Use template: templates/adr-template.md
Create ADR for:
- Database/storage choice
- Authentication strategy
- API design approach
- Key framework decisions
- Any choice expensive to reverse
Format: adr-001-{decision-slug}.md
Technical Implementation Spec
Use template: templates/tech-spec-template.md
Include:
- Complete tech stack with versions
- Component architecture diagram (ASCII)
- Data model with schemas
- API endpoints specification
- Security requirements
- Error handling approach
Development Roadmap
Use template: templates/roadmap-template.md
Structure as:
- Phase 0: Foundation (environment, CI/CD)
- Phase 1: MVP Core (essential features)
- Phase 2: Enhancement (additional features)
- Phase 3: Polish (testing, documentation)
Each phase needs:
- Clear deliverables
- Success criteria (testable)
- Estimated duration
- Dependencies
Pre-Filling from Project Context
When generating, incorporate known information:
# From pyproject.toml / cookiecutter context
python_version = "3.12"
project_name = "Fragrance Rater"
project_slug = "fragrance_rater"
cli_framework = "Click"
containerization = "Docker"
Quality Checklist
Before completing generation:
- [ ] All four documents created in
docs/planning/ - [ ] Each document has TL;DR section
- [ ] No "[TODO]" or "[TBD]" placeholders remain
- [ ] Documents cross-reference each other
- [ ] Technical choices are consistent
- [ ] Success criteria are measurable
- [ ] Scope boundaries are explicit
- [ ] At least one ADR created
Templates Reference
Templates are in templates/ directory:
pvs-template.md- Project Vision & Scope structureadr-template.md- Architecture Decision Record structuretech-spec-template.md- Technical Spec structureroadmap-template.md- Development Roadmap structure
Detailed Guidance
For comprehensive documentation on each document type, see reference/ directory:
reference/document-guide.md- Full guidance for all document typesreference/prompting-patterns.md- How to use documents during development
After Generation
Instruct user to:
- Review each document for accuracy
- Validate assumptions marked with
[ ] - Adjust timelines in roadmap if needed
- Commit documents to version control
- Reference documents in future development sessions
Example Usage
When user says: "I want to build a CLI tool for managing personal finances..."
Generation Flow with Consensus Review
-
Generate PVS
- Read
templates/pvs-template.md - Generate
docs/planning/project-vision.mdwith finance CLI specifics - Review:
mcp__zen__consensuswith gemini-3-pro-preview → READY or revise
- Read
-
Generate ADR
- Read
templates/adr-template.md - Generate
docs/planning/adr/adr-001-database-choice.mdfor SQLite decision - Review:
mcp__zen__consensuswith gemini-3-pro-preview → READY or revise
- Read
-
Generate Tech Spec
- Read
templates/tech-spec-template.md - Generate
docs/planning/tech-spec.mdwith Python/Click/SQLite stack - Review:
mcp__zen__consensuswith gemini-3-pro-preview → READY or revise
- Read
-
Generate Roadmap
- Read
templates/roadmap-template.md - Generate
docs/planning/roadmap.mdwith phased implementation - Review:
mcp__zen__consensuswith gemini-3-pro-preview → READY or revise
- Read
-
Final Validation
- Run
scripts/validate-planning-docs.py - Summarize what was created and review outcomes
- List next steps for beginning development
- Run
Consensus Review Prompt Template
mcp__zen__consensus with gemini-3-pro-preview:
Review this Project Vision & Scope document for Fragrance Rater.
EVALUATION CRITERIA:
1. SPECIFICITY - Can a developer implement from these requirements?
2. COMPLETENESS - All sections filled with project-specific content?
3. FEASIBILITY - Realistic scope for the described constraints?
4. CLARITY - Unambiguous success criteria and scope boundaries?
5. GAPS - Any critical missing information?
RESPOND:
- READY: Sufficient to proceed to next document
- NEEDS REVISION: [Specific improvements with examples]
DOCUMENT:
[Full document content here]
MCP Server Requirement
This skill requires the zen-mcp-server for consensus review. If not available, skip Step 3 and proceed with manual review.
Configuration: Ensure mcp__zen__consensus tool is accessible.
同梱ファイル
※ ZIPに含まれるファイル一覧。`SKILL.md` 本体に加え、参考資料・サンプル・スクリプトが入っている場合があります。
- 📄 SKILL.md (8,392 bytes)
- 📎 scripts/validate-planning-docs.py (7,880 bytes)