draft-project-charter
について
このClaudeスキルは、包括的なプロジェクト憲章を作成し、範囲、ステークホルダー、成功基準、初期リスク登録を定義します。問題提起、RACIマトリックス、アジャイルおよび古典的手法の両方に対応したマイルストーン計画など、主要要素を生成します。プロジェクトを正式に立ち上げる、ステークホルダーの合意形成を行う、あるいは発見フェーズから実作業への移行にご活用ください。
クイックインストール
Claude Code
推奨npx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/draft-project-charterこのコマンドをClaude Codeにコピー&ペーストしてスキルをインストールします
ドキュメント
Draft a Project Charter
Make structured project charter. Sets project boundaries, stakeholder agreements, success criteria before detailed planning starts. Produces full doc: scope, RACI assignments, milestone planning, initial risk register. Fits agile, classic, or hybrid methodologies.
When Use
- Kick off new project or initiative
- Formalize scope after informal project start
- Align stakeholders before detailed planning
- Create reference doc for scope decisions during execution
- Transition from discovery/ideation to active project work
Inputs
- Required: Project name + brief description
- Required: Primary stakeholder or sponsor
- Optional: Existing docs (proposals, briefs, emails)
- Optional: Known constraints (budget, deadline, team size)
- Optional: Methodology preference (agile, classic, hybrid)
Steps
Step 1: Gather Context + Create Charter Template
Read existing docs (proposals, emails, briefs) for project background. Identify core problem or opportunity project addresses. Create charter file with structured template, populate in next steps.
Create file PROJECT-CHARTER-[PROJECT-NAME].md with this template:
# Project Charter: [Project Name]
## Document ID: PC-[PROJECT]-[YYYY]-[NNN]
### 1. Problem Statement
[2-3 sentences describing the problem or opportunity this project addresses]
### 2. Project Purpose
[What the project will achieve and why it matters]
### 3. Scope
#### In Scope
- [Deliverable 1]
- [Deliverable 2]
#### Out of Scope
- [Exclusion 1]
- [Exclusion 2]
### 4. Deliverables
| # | Deliverable | Acceptance Criteria | Target Date |
|---|------------|---------------------|-------------|
| 1 | | | |
### 5. Stakeholders & RACI
| Stakeholder | Role | D1 | D2 | D3 |
|-------------|------|----|----|-----|
| | | | | |
*R=Responsible, A=Accountable, C=Consulted, I=Informed*
### 6. Success Criteria
| # | Criterion | Measure | Target |
|---|-----------|---------|--------|
| 1 | | | |
### 7. Milestones
| Milestone | Target Date | Dependencies |
|-----------|-------------|--------------|
| | | |
### 8. Risk Register
| ID | Risk | Likelihood | Impact | Severity | Mitigation | Owner |
|----|------|------------|--------|----------|------------|-------|
| R1 | | | | | | |
*Likelihood/Impact: Low, Medium, High*
*Severity = Likelihood × Impact*
### 9. Assumptions and Constraints
#### Assumptions
- [Key assumption 1]
#### Constraints
- [Key constraint 1]
### 10. Approval
| Role | Name | Date |
|------|------|------|
| Sponsor | | |
| Project Lead | | |
Fill document ID using format PC-[PROJECT]-[YYYY]-[NNN] (e.g., PC-WEBSITE-2026-001). Write problem statement (2-3 sentences): current situation, gap, impact. Write project purpose statement (1 paragraph): what will be achieved.
Got: Charter file created with document ID, problem statement, purpose filled in. Problem statement specific + describes measurable gap.
If fail: Project context unclear? Document specific questions for sponsor in QUESTIONS section at top of charter. Existing docs conflict? Note contradictions in OPEN ISSUES section, flag for stakeholder resolution.
Step 2: Define Scope Boundaries
Make explicit lists: what is + is not in project scope. Write 3-5 in-scope deliverables with specific acceptance criteria each. Write 3-5 out-of-scope items to block scope creep. Populate Deliverables table: each deliverable, acceptance criteria, target date.
Got: Scope section balanced: in-scope + out-of-scope lists. Deliverables table has 3-5 entries, specific testable acceptance criteria. Target dates realistic, sequenced logically.
If fail: Deliverables vague? Break into sub-deliverables with concrete outputs. Acceptance criteria missing? Ask: "How would we demonstrate this deliverable is complete?" Target dates unavailable? Mark TBD, flag for milestone planning session.
Step 3: Identify Stakeholders + Assign RACI
List all people/groups affected by, contributing to, or with decision authority over project. Include org role. Make RACI matrix mapping each stakeholder to each deliverable:
- R (Responsible): Does the work
- A (Accountable): Final decision authority (only one A per deliverable)
- C (Consulted): Gives input before decisions
- I (Informed): Kept updated
Ensure each deliverable has exactly one A + min one R.
Got: Stakeholders table lists 5-10 people with roles. RACI matrix: one A per deliverable column. No deliverable missing R or with multiple As. Sponsor = A for final approval.
If fail: Stakeholder list incomplete? Cross-reference with org chart + meeting attendees from discovery phase. Multiple As identified? Escalate conflict to sponsor for decision authority clarification. No R? Flag deliverable as unassigned, requiring resource allocation.
Step 4: Define Success Criteria + Milestones
Write 3-5 measurable success criteria in SMART format (Specific, Measurable, Achievable, Relevant, Time-bound). Each criterion ties to quantifiable measure + target value. Define 4-6 key milestones for major project stages or deliverable completions. Target dates + dependencies on prior milestones.
Got: Success Criteria table: 3-5 entries with specific measures (e.g., "System uptime" measured as "% availability" with target "99.5%"). Milestones table shows logical project phases with realistic target dates. Dependencies clearly noted.
If fail: Success criteria vague (e.g., "improve quality")? Rewrite as measurable outcomes with baseline + target values. Milestone dates unrealistic? Work backward from final deadline using estimated durations + buffers. Dependencies create circular logic? Restructure milestone sequence or split conflicting milestones.
Step 5: Create Initial Risk Register
Identify 5-10 risks that could impact project success. For each risk: assess likelihood (Low/Medium/High) + impact (Low/Medium/High), calculate severity. Define specific mitigation strategy per risk, assign risk owner for monitoring + response. Include min 1 risk per category: scope, schedule, resource, technical, external.
Got: Risk Register has 5-10 entries covering scope, schedule, resource, technical, external risks. Each risk has likelihood, impact, severity assessed. Mitigation strategies actionable + specific. Each risk has assigned owner.
If fail: Risk list incomplete? Review scope boundaries, dependencies, stakeholder list, assumptions for potential failure points. Mitigation strategies generic ("monitor closely")? Specify: What monitored? How often? What triggers action? No one accepts risk ownership? Assign to project lead temporarily, escalate to sponsor.
Checks
- Charter file created with document ID
- Problem statement specific + measurable
- Scope has both in-scope + out-of-scope items
- RACI matrix covers all deliverables
- Success criteria measurable (SMART)
- Min 5 risks identified with mitigation strategies
- Milestones have target dates
- Approval section included
Pitfalls
- Scope without boundaries: Listing in-scope without explicit out-of-scope → scope creep. Always define what you won't do.
- Vague success criteria: "Improve performance" = unmeasurable. Tie every criterion to a number with baseline + target.
- Missing stakeholders: Overlooked stakeholders surface late, derail project. Cross-reference org charts + prior project comms.
- Risk register as checkbox: Listing risks without actionable mitigation = false confidence. Each risk needs specific response strategy.
- Over-detailed charter: Charter = compass, not map. Keep 2-4 pages. Detailed planning happens later.
See Also
create-work-breakdown-structure— decompose charter deliverables into work packagesmanage-backlog— translate charter scope into prioritized backlogplan-sprint— plan first sprint from charter deliverablesgenerate-status-report— report progress vs charter milestonesconduct-retrospective— review charter assumptions after execution
GitHub リポジトリ
関連スキル
executing-plans
デザインexecuting-plansスキルは、完全な実装計画があり、それを管理されたバッチでレビューチェックポイントを設けながら実行する場合に使用します。このスキルは計画を読み込んで批判的にレビューした後、小さなバッチ(デフォルトは3タスク)でタスクを実行し、各バッチの間に進捗状況を報告してアーキテクトのレビューを受けます。これにより、品質管理チェックポイントが組み込まれた体系的な実装が保証されます。
requesting-code-review
デザインこのスキルは、コードレビュアーサブエージェントを起動し、処理を進める前に要件に対してコード変更を分析します。タスク完了後、主要な機能の実装後、またはmainブランチへのマージ前などに使用すべきです。このレビューは、現在の実装と元の計画を比較することで、問題を早期に発見するのに役立ちます。
connect-mcp-server
デザインこのスキルは、開発者がHTTP、stdio、またはSSEトランスポートを使用してMCPサーバーをClaude Codeに接続するための包括的なガイドを提供します。GitHub、Notion、カスタムAPIなどの外部サービスを統合するためのインストール、設定、認証、セキュリティについて解説しています。MCP統合のセットアップ、外部ツールの設定、またはClaudeのModel Context Protocolを扱う際にご利用ください。
web-cli-teleport
デザインこのスキルは、タスク分析に基づいて開発者がClaude Code WebとCLIインターフェースの選択を支援し、これらの環境間でのシームレスなセッションテレポーテーションを可能にします。Web、CLI、モバイル環境を切り替える際のセッション状態とコンテキストを管理することで、ワークフローを最適化します。様々な段階で異なるツールを必要とする複雑なプロジェクトにご活用ください。
