draft-project-charter
について
このスキルは、プロジェクトの範囲、ステークホルダー、成功基準を正式に定義する包括的なプロジェクト憲章を作成します。問題提起、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にコピー&ペーストしてスキルをインストールします
ドキュメント
name: draft-project-charter description: > 起草项目章程,定义范围、干系人、成功标准和初始风险登记册。 涵盖问题陈述、RACI 矩阵、里程碑规划和范围边界, 适用于敏捷与传统项目管理方法。适合在启动新项目或计划时使用, 在详细规划开始前正式确定范围或对齐干系人, 或在从探索阶段过渡到主动项目工作时使用。 license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: project-management complexity: basic language: multi tags: project-management, charter, scope, stakeholders, raci, risk-register locale: zh-CN source_locale: en source_commit: 6f65f316 translator: claude-opus-4-6 translation_date: "2026-03-16"
起草项目章程
创建结构化的项目章程,在详细规划开始前确立项目边界、干系人协议和成功标准。生成涵盖范围、RACI 分配、里程碑规划和初始风险登记册的综合文档,适用于敏捷、传统或混合项目管理方法。
适用场景
- 启动新项目或计划
- 在非正式项目启动后正式确定范围
- 在详细规划开始前对齐干系人
- 创建执行过程中范围决策的参考文档
- 从探索/构思阶段过渡到主动项目工作
输入
- 必填:项目名称和简要描述
- 必填:主要干系人或发起人
- 可选:现有文档(提案、简报、邮件)
- 可选:已知约束(预算、截止日期、团队规模)
- 可选:方法论偏好(敏捷、传统、混合)
步骤
第 1 步:收集项目背景并创建章程模板
阅读所有现有文档(提案、邮件、简报)以了解项目背景。识别项目所解决的核心问题或机会。创建章程文件并填入结构化模板,后续步骤将逐步完善内容。
创建名为 PROJECT-CHARTER-[PROJECT-NAME].md 的文件,使用以下模板:
# 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 | | |
使用格式 PC-[PROJECT]-[YYYY]-[NNN] 填写文档 ID(例如 PC-WEBSITE-2026-001)。撰写问题陈述(2-3 句话),描述当前状况、差距和影响。撰写项目目的陈述(1 段话)说明将要实现的内容。
预期结果: 章程文件已创建,文档 ID、问题陈述和目的均已填写。问题陈述具体且描述了可衡量的差距。
失败处理: 如果项目背景不清晰,在章程顶部的 QUESTIONS 部分记录向发起人提出的具体问题。如果现有文档存在冲突,在 OPEN ISSUES 部分注明矛盾之处,并标记以供干系人解决。
第 2 步:定义范围边界
明确列出项目范围内和范围外的内容。写出 3-5 个范围内的可交付成果,并为每项制定具体的验收标准。写出 3-5 个范围外的条目以防止范围蔓延。在可交付成果表格中填入每项可交付成果、其验收标准和目标日期。
预期结果: 范围部分包含均衡的范围内和范围外列表。可交付成果表格包含 3-5 个条目,具有具体、可测试的验收标准。目标日期切实可行且逻辑有序。
失败处理: 如果可交付成果模糊,将每项分解为具有具体输出的子可交付成果。如果缺少验收标准,请问:"我们如何证明此可交付成果已完成?"如果目标日期不可用,标记为 TBD 并标记以供里程碑规划会议跟进。
第 3 步:识别干系人并分配 RACI
列出所有将受项目影响、参与项目或对项目拥有决策权的个人或群体。包含其组织角色。创建 RACI 矩阵,使用以下方式将每位干系人映射到每项可交付成果:
- R(负责人):执行工作
- A(问责人):最终决策权(每项可交付成果只有一个 A)
- C(咨询人):在决策前提供意见
- I(知情人):及时了解进展
确保每项可交付成果只有一个 A,并且至少有一个 R。
预期结果: 干系人表格列出 5-10 人及其角色。RACI 矩阵每列可交付成果只有一个 A。没有可交付成果缺少 R 或有多个 A。发起人是最终审批的问责人 (A)。
失败处理: 如果干系人列表不完整,参照组织结构图和探索阶段的会议参与者进行交叉核对。如果识别出多个问责人 (A),将冲突上报给发起人进行决策权限澄清。如果没有负责人 (R),将可交付成果标记为未分配,并需要资源调配。
第 4 步:定义成功标准和里程碑
使用 SMART 格式(具体、可衡量、可实现、相关、有时限)写出 3-5 个可衡量的成功标准。每项标准应与可量化的衡量指标和目标值相关联。定义 4-6 个代表主要项目阶段或可交付成果完成节点的关键里程碑,包含目标日期和对先前里程碑的依赖关系。
预期结果: 成功标准表格包含 3-5 个条目,具有具体的衡量指标(例如,"系统可用性"衡量为"可用率百分比",目标为"99.5%")。里程碑表格显示合理的项目阶段,目标日期切实可行。依赖关系清晰标注。
失败处理: 如果成功标准模糊(例如"提升质量"),重写为具有基线和目标值的可衡量结果。如果里程碑日期不切实际,从最终截止日期逆向推算,使用预估工期和缓冲时间。如果依赖关系形成循环逻辑,重新组织里程碑顺序或拆分冲突的里程碑。
第 5 步:创建初始风险登记册
识别 5-10 个可能影响项目成功的风险。对每个风险评估可能性(低/中/高)和影响(低/中/高),然后计算严重程度。为每个风险定义具体的缓解策略,并指定负责监控和响应的风险负责人。至少在以下每个类别中包含一个风险:范围、进度、资源、技术和外部。
预期结果: 风险登记册包含 5-10 个条目,涵盖范围、进度、资源、技术和外部风险。每个风险已评估可能性、影响和严重程度。缓解策略具有可操作性和针对性。每个风险已指定负责人。
失败处理: 如果风险列表不完整,审查范围边界、依赖关系、干系人列表和假设条件中的潜在失败点。如果缓解策略过于笼统("密切监控"),请具体说明:监控什么?多久一次?什么情况触发行动?如果没有人接受风险负责人角色,暂时分配给项目负责人并上报给发起人。
验证清单
- 章程文件已创建并包含文档 ID
- 问题陈述具体且可衡量
- 范围包含范围内和范围外条目
- RACI 矩阵涵盖所有可交付成果
- 成功标准可衡量(SMART 格式)
- 至少识别 5 个风险并制定缓解策略
- 里程碑包含目标日期
- 审批部分已包含
常见问题
- 范围无边界:列出范围内条目而不明确范围外条目会导致范围蔓延。始终定义不包含的内容。
- 模糊的成功标准:"提升性能"无法衡量。将每个标准与具有基线和目标的数字绑定。
- 遗漏干系人:被忽略的干系人会在后期出现并扰乱项目。交叉核对组织结构图和先前的项目沟通记录。
- 风险登记册流于形式:列出风险而没有可操作的缓解计划会产生虚假的安全感。每个风险需要具体的应对策略。
- 章程过于详细:章程是指南针,而非地图。保持在 2-4 页以内。详细规划在之后进行。
相关技能
create-work-breakdown-structure— 将章程可交付成果分解为工作包manage-backlog— 将章程范围转化为优先级排列的待办事项列表plan-sprint— 根据章程可交付成果规划第一个冲刺generate-status-report— 报告针对章程里程碑的进展conduct-retrospective— 执行后回顾章程假设条件
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、モバイル環境を切り替える際のセッション状態とコンテキストを管理することで、ワークフローを最適化します。様々な段階で異なるツールを必要とする複雑なプロジェクトにご活用ください。
