project-execution

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

When this skill is activated, always start your first response with the 🧢 emoji.

激活此Skill后，首次回复请始终以🧢表情开头。

Project Execution

项目执行

Project execution is the discipline of turning a plan into delivered outcomes while navigating uncertainty, managing cross-team dependencies, and keeping stakeholders aligned. Most projects fail not from bad ideas but from poor execution - untracked risks that materialize, dependencies that slip silently, and stakeholders who learn about problems too late to help. This skill equips an agent to build risk registers, map dependency chains, write crisp status updates, and make sound escalation decisions throughout a project's lifecycle.

项目执行是一门将计划转化为交付成果的学科，同时要应对不确定性、管理跨团队依赖项并保持利益相关者的目标一致。大多数项目失败并非因为想法不佳，而是执行不力——未被跟踪的风险变为现实，依赖项悄然延误，利益相关者得知问题时已来不及提供帮助。此Skill可让Agent在项目全生命周期内构建风险登记册（Risk register）、绘制依赖链、撰写清晰的状态更新，并做出合理的升级决策。

When to use this skill

何时使用此Skill

Trigger this skill when the user:

Needs to create a project plan, timeline, or milestone breakdown
Wants to identify, assess, or mitigate project risks
Asks to map dependencies between teams, services, or deliverables
Needs to write a status update, executive summary, or steering committee report
Wants to build or maintain a RAID log (Risks, Assumptions, Issues, Dependencies)
Asks about critical path analysis or schedule compression
Needs to escalate a blocked or at-risk project
Wants to estimate timelines or evaluate schedule feasibility

Do NOT trigger this skill for:

Pure technical architecture decisions (use system-design or clean-architecture instead)
Agile ceremony design or Scrum process questions (this skill is methodology-agnostic)

当用户有以下需求时触发此Skill：

需要创建项目计划、时间线或里程碑分解
希望识别、评估或缓解项目风险
请求映射团队、服务或交付成果之间的依赖项
需要撰写状态更新、执行摘要或指导委员会报告
希望构建或维护RAID日志（Risks风险、Assumptions假设、Issues问题、Dependencies依赖项）
询问关键路径分析或进度压缩相关问题
需要上报受阻或存在风险的项目
希望估算时间线或评估进度可行性

请勿在以下场景触发此Skill：

纯技术架构决策（请改用system-design或clean-architecture Skill）
敏捷仪式设计或Scrum流程问题（此Skill与方法论无关）

Key principles

核心原则

Risks are first-class artifacts - Every project maintains a living risk register. A risk without an owner, a likelihood rating, and a mitigation plan is just a worry. Quantify risks on a 3x3 matrix (likelihood x impact) and review them weekly, not just at kickoff.
Dependencies are contracts, not hopes - When your timeline depends on another team's deliverable, treat it as a contract. Document the what, the when, the who, and the fallback if it slips. Check dependency health weekly - do not wait for the deadline to discover a slip.
Communicate before they ask - Stakeholders should never learn about problems from a status meeting. Bad news travels up immediately. Status updates are predictable, structured, and honest. Use red/amber/green (RAG) status consistently and never inflate green to avoid a conversation.
Plan for recovery, not perfection - Every plan will deviate. The mark of good execution is how fast you detect deviation and course-correct. Build explicit decision points (go/no-go gates) into the plan, not just milestones.
Scope is the primary lever - When timeline, resources, and quality are constrained, scope is the variable you negotiate. Never silently reduce quality to hit a date. Make trade-offs explicit and get stakeholder sign-off.

风险是首要管理对象 - 每个项目都需维护一个动态的风险登记册（Risk register）。没有负责人、可能性评级和缓解计划的风险只是一种担忧。使用3x3矩阵（可能性×影响）量化风险，并且每周回顾，而不仅仅是在项目启动时。
依赖项是契约而非期望 - 当你的时间线依赖于其他团队的交付成果时，要将其视为契约。记录交付内容、时间、负责人以及延误时的备选方案。每周检查依赖项的健康状况——不要等到截止日期才发现延误。
主动沟通，而非被动回应 - 绝不能让利益相关者从状态会议上才得知问题。坏消息应立即上报。状态更新需可预测、结构化且诚实。持续使用红/黄/绿（RAG）状态标记，切勿为了避免沟通而虚报绿色状态。
规划恢复方案，而非追求完美 - 所有计划都会偏离轨道。良好执行的标志是你发现偏差并纠正路线的速度。在计划中设置明确的决策点（继续/终止闸门），而不仅仅是里程碑。
范围是首要调节杠杆 - 当时间线、资源和质量受限，范围是你可以协商的变量。切勿为了赶日期而悄悄降低质量。明确权衡取舍并获得利益相关者的签字确认。

Core concepts

核心概念

RAID Log - The central tracking artifact for any project. Risks are things that might happen. Assumptions are things you believe to be true but have not verified. Issues are risks that have materialized - they are active problems. Dependencies are external deliverables your project requires.

Critical Path - The longest sequence of dependent tasks that determines the minimum project duration. Any delay on the critical path delays the entire project. Non-critical tasks have float (slack time). Focus risk mitigation and dependency tracking efforts on critical-path items first.

RAG Status - Red/Amber/Green health indicator used in status reporting. Green means on track with no significant risks. Amber means at risk - there are issues that could cause a miss without intervention. Red means off track - the current plan will not meet its commitments without a scope, timeline, or resource change. Define these thresholds explicitly at project start.

Stakeholder Map - A matrix classifying stakeholders by influence and interest. High-influence/high-interest stakeholders get direct, frequent updates. Low-influence/low-interest stakeholders get broadcast updates. Misclassifying a stakeholder's quadrant is a common source of project friction.

RAID日志 - 任何项目的核心跟踪工具。Risks（风险）是可能发生的事情；Assumptions（假设）是你认为真实但未验证的事情；Issues（问题）是已发生的风险——即当前存在的问题；Dependencies（依赖项）是项目所需的外部交付成果。

关键路径 - 决定项目最短周期的最长依赖任务序列。关键路径上的任何延误都会导致整个项目延误。非关键任务有浮动时间（松弛时间）。优先将风险缓解和依赖项跟踪的精力放在关键路径的事项上。

RAG状态 - 状态报告中使用的红/黄/绿健康指标。绿色表示按计划推进，无重大风险；黄色表示存在风险——若不干预，可能会导致目标无法达成；红色表示偏离轨道——若不调整范围、时间线或资源，当前计划无法兑现承诺。需在项目启动时明确定义这些阈值。

利益相关者图谱 - 按影响力和关注度对利益相关者进行分类的矩阵。高影响力/高关注度的利益相关者需获得直接、频繁的更新；低影响力/低关注度的利益相关者只需接收广播式更新。错误分类利益相关者的象限是项目摩擦的常见来源。

Common tasks

常见任务

Build a risk register

构建风险登记册

Create a structured table with these columns: Risk ID, Description, Likelihood (Low/Medium/High), Impact (Low/Medium/High), Risk Score (L x I), Owner, Mitigation Plan, Status (Open/Mitigated/Occurred), Last Reviewed. Seed the register during planning by running a pre-mortem exercise - ask "It is 3 months from now and this project has failed. What went wrong?" Categorize risks into Technical, Resource, Dependency, Scope, and External buckets.

Risk ID	Description	L	I	Score	Owner	Mitigation	Status
R-001	Auth service migration delays our API launch	H	H	9	@alice	Build adapter layer to decouple; weekly sync with auth team	Open
R-002	Key engineer on PTO during final sprint	M	M	4	@bob	Cross-train second engineer by week 3	Open
R-003	Third-party API rate limits hit during load test	L	H	3	@carol	Request limit increase by week 2; implement circuit breaker	Open

创建包含以下列的结构化表格：Risk ID（风险ID）、Description（描述）、Likelihood（可能性：低/中/高）、Impact（影响：低/中/高）、Risk Score（风险得分：可能性×影响）、Owner（负责人）、Mitigation Plan（缓解计划）、Status（状态：未处理/已缓解/已发生）、Last Reviewed（最后回顾时间）。在规划阶段通过预演失败（pre-mortem）练习来初始化登记册——提问：“假设3个月后这个项目彻底失败了，原因是什么？”将风险分为技术、资源、依赖项、范围和外部类别。

Risk ID	Description	L	I	Score	Owner	Mitigation	Status
R-001	Auth service migration delays our API launch	H	H	9	@alice	Build adapter layer to decouple; weekly sync with auth team	Open
R-002	Key engineer on PTO during final sprint	M	M	4	@bob	Cross-train second engineer by week 3	Open
R-003	Third-party API rate limits hit during load test	L	H	3	@carol	Request limit increase by week 2; implement circuit breaker	Open

Map project dependencies

映射项目依赖项

Create a dependency graph with four attributes per dependency: Source (who needs it), Target (who provides it), Deliverable (what exactly), Due Date, and Fallback Plan. Visualize as a table or directed list. Flag any dependency where the target team has not acknowledged the commitment - these are "unconfirmed dependencies" and carry the highest risk.

Dependency Chain:
  [Design Team] --wireframes (Mar 20)--> [Frontend Team] --UI components (Apr 5)--> [QA Team]
  [Auth Team] --OAuth SDK v3 (Mar 25)--> [Backend Team] --API endpoints (Apr 10)--> [QA Team]
  [Data Team] --schema migration (Mar 15)--> [Backend Team]

Unconfirmed: Auth Team has not acknowledged Mar 25 date - ESCALATE

为每个依赖项创建包含四个属性的依赖关系图：Source（需求方）、Target（提供方）、Deliverable（具体内容）、Due Date（截止日期）和Fallback Plan（备选方案）。可通过表格或有向列表可视化。标记所有目标团队未确认承诺的依赖项——这些是“未确认依赖项”，风险最高。

Dependency Chain:
  [Design Team] --wireframes (Mar 20)--> [Frontend Team] --UI components (Apr 5)--> [QA Team]
  [Auth Team] --OAuth SDK v3 (Mar 25)--> [Backend Team] --API endpoints (Apr 10)--> [QA Team]
  [Data Team] --schema migration (Mar 15)--> [Backend Team]

Unconfirmed: Auth Team has not acknowledged Mar 25 date - ESCALATE

Write a weekly status update

撰写每周状态更新

Follow this template for consistent, scannable status updates:

undefined

遵循以下模板，撰写一致且易读的状态更新：

undefined

Project: [Name] - Week of [Date]

Overall Status: [GREEN/AMBER/RED]

Progress this week

[Completed item 1]
[Completed item 2]

[Completed item 1]
[Completed item 2]

Planned next week

[Planned item 1]
[Planned item 2]

[Planned item 1]
[Planned item 2]

Risks & blockers

[AMBER] [Risk description] - Mitigation: [action] - Owner: [name]
[RED] [Blocker description] - Need: [what you need] - From: [who]

[AMBER] [Risk description] - Mitigation: [action] - Owner: [name]
[RED] [Blocker description] - Need: [what you need] - From: [who]

Key decisions needed

[Decision 1] - Deadline: [date] - Decision maker: [name]

[Decision 1] - Deadline: [date] - Decision maker: [name]

Metrics

Milestone progress: [X/Y] complete
Days to next milestone: [N]
Open risks: [N] (H:[n] M:[n] L:[n])

undefined

Milestone progress: [X/Y] complete
Days to next milestone: [N]
Open risks: [N] (H:[n] M:[n] L:[n])

undefined

Conduct a pre-mortem

开展预演失败（Pre-mortem）

Before execution begins, run a structured pre-mortem session. Prompt the team (or simulate as an agent) with: "Assume this project has failed spectacularly. List every reason why." Group responses into categories (Technical, People, Process, External). Convert the top findings into risk register entries with owners and mitigations. A pre-mortem surfaces risks that optimism bias hides during normal planning.

在项目执行开始前，开展结构化的预演失败会议。引导团队（或由Agent模拟）思考：“假设这个项目彻底失败了，列出所有可能的原因。”将回复分类为技术、人员、流程、外部类别。将最重要的发现转化为风险登记册中的条目，并指定负责人和缓解措施。预演失败能揭示常规规划中因乐观偏见而被隐藏的风险。

Create a stakeholder communication plan

创建利益相关者沟通计划

Map each stakeholder to a communication cadence:

Stakeholder	Role	Influence	Interest	Update Frequency	Channel	Content Level
VP Engineering	Sponsor	High	High	Weekly + ad-hoc	1:1 + email	Executive summary
Product Manager	Partner	High	High	Twice weekly	Slack + standup	Detailed
Platform Team	Dependency	Medium	Medium	Weekly	Email	Dependency status only
Design Team	Contributor	Low	High	As needed	Slack	Task-level

为每个利益相关者匹配对应的沟通节奏：

Stakeholder	Role	Influence	Interest	Update Frequency	Channel	Content Level
VP Engineering	Sponsor	High	High	Weekly + ad-hoc	1:1 + email	Executive summary
Product Manager	Partner	High	High	Twice weekly	Slack + standup	Detailed
Platform Team	Dependency	Medium	Medium	Weekly	Email	Dependency status only
Design Team	Contributor	Low	High	As needed	Slack	Task-level

Perform critical path analysis

执行关键路径分析

List all tasks with their durations and dependencies. Identify the longest path through the dependency graph - this is your critical path and minimum project duration. Calculate float for non-critical tasks. When the critical path is too long, apply schedule compression: fast-tracking (parallelizing sequential tasks that can overlap) or crashing (adding resources to critical-path tasks with the lowest incremental cost).

列出所有任务及其持续时间和依赖项。找出依赖关系图中最长的路径——这就是你的关键路径和项目最短周期。计算非关键任务的浮动时间。当关键路径过长时，应用进度压缩：快速跟进（并行化可重叠的顺序任务）或赶工（为关键路径上增量成本最低的任务增加资源）。

Write an escalation

撰写上报材料

When a project turns red, escalate with this structure: (1) State the problem in one sentence, (2) Quantify the impact (days of delay, revenue at risk, users affected), (3) List options with trade-offs (never escalate without options), (4) State your recommendation, (5) Name the decision needed and by when. Never surprise leadership - pre-wire key stakeholders before the formal escalation.

当项目变为红色状态时，按照以下结构上报：(1) 用一句话说明问题；(2) 量化影响（延误天数、面临风险的收入、受影响的用户数）；(3) 列出带有权衡的选项（绝不能无选项就上报）；(4) 说明你的推荐方案；(5) 明确需要做出的决策和截止时间。切勿让领导层感到意外——在正式上报前，先与关键利益相关者沟通。

Run a go/no-go gate review

开展继续/终止闸门评审

At each major milestone, run a structured gate review. Check: Are all entry criteria met? Are all critical-path dependencies delivered? Are open risks within acceptable thresholds? Is the team confident in the next phase estimate? Document the decision (Go, Conditional Go with actions, or No-Go with remediation plan) and circulate to all stakeholders within 24 hours.

在每个主要里程碑处，开展结构化的闸门评审。检查：是否满足所有进入标准？关键路径上的所有依赖项是否已交付？未处理的风险是否在可接受的阈值内？团队是否对下一阶段的估算有信心？记录决策（继续、有条件继续并附带行动、或终止并附带补救计划），并在24小时内分发给所有利益相关者。

Anti-patterns / common mistakes

反模式/常见错误

Mistake	Why it's wrong	What to do instead
Tracking risks only at kickoff	Risks evolve weekly. A static register gives false confidence.	Review and update the risk register every week. Add new risks as they emerge.
Treating all dependencies equally	Not all dependencies are on the critical path. Spreading attention equally means critical ones get insufficient focus.	Prioritize dependency tracking by critical-path impact.
Reporting green until suddenly red	Skipping amber destroys trust. Stakeholders cannot help if they do not see the warning signs.	Use amber honestly. An amber status with a mitigation plan builds more confidence than false green.
Escalating without options	Dumping a problem on leadership without solutions signals lack of ownership.	Always present 2-3 options with trade-offs and your recommendation.
Silent scope changes	Absorbing scope increases without adjusting timeline or resources leads to burnout and quality drops.	Make every scope change visible. Log it, assess impact, get sign-off.
Single-threaded dependencies	One person as the sole contact for a critical dependency is a single point of failure.	Ensure every critical dependency has a backup contact and a documented handoff plan.

错误行为	危害	正确做法
仅在项目启动时跟踪风险	风险每周都会演变。静态的登记册会带来虚假的信心。	每周回顾并更新风险登记册。出现新风险时及时添加。
同等对待所有依赖项	并非所有依赖项都在关键路径上。平均分配精力会导致关键依赖项得不到足够关注。	根据关键路径影响优先级跟踪依赖项。
一直报绿色直到突然变红	跳过黄色状态会破坏信任。利益相关者看不到预警信号就无法提供帮助。	诚实地使用黄色状态。带有缓解计划的黄色状态比虚假的绿色状态更能建立信心。
无解决方案就上报	把问题丢给领导层而不提供解决方案，表明缺乏责任感。	始终提供2-3个带有权衡的选项和你的推荐方案。
悄悄变更范围	不调整时间线或资源就接受范围扩大，会导致团队 burnout 和质量下降。	让所有范围变更透明化。记录变更、评估影响并获得签字确认。
单线程依赖项	关键依赖项仅由一人对接，会造成单点故障。	确保每个关键依赖项都有备用对接人和书面的交接计划。

References

参考资料

For detailed guidance on specific sub-domains, read the relevant file from the

references/

folder:

```
references/risk-management.md
```
- Deep dive on risk identification techniques, quantitative risk analysis, and mitigation strategy patterns
```
references/dependency-tracking.md
```
- Dependency mapping methods, cross-team coordination protocols, and escalation triggers
```
references/stakeholder-communication.md
```
- Communication templates, stakeholder mapping frameworks, and difficult conversation playbooks

Only load a references file if the current task requires it - they are long and will consume context.

如需特定子领域的详细指导，请阅读

references/

文件夹中的相关文件：

```
references/risk-management.md
```
- 深入探讨风险识别技术、定量风险分析和缓解策略模式
```
references/dependency-tracking.md
```
- 依赖项映射方法、跨团队协调协议和上报触发条件
```
references/stakeholder-communication.md
```
- 沟通模板、利益相关者图谱框架和艰难对话脚本

仅在当前任务需要时加载参考文件——这些文件篇幅较长，会占用上下文资源。

project-execution

Original

Translation

Project Execution

项目执行

When to use this skill

何时使用此Skill

Key principles

核心原则

Core concepts

核心概念

Common tasks

常见任务

Build a risk register

构建风险登记册

Map project dependencies

映射项目依赖项

Write a weekly status update

撰写每周状态更新

Project: [Name] - Week of [Date]

Project: [Name] - Week of [Date]

Progress this week

Progress this week

Planned next week

Planned next week

Risks & blockers

Risks & blockers

Key decisions needed

Key decisions needed

Metrics

Metrics

Conduct a pre-mortem

开展预演失败（Pre-mortem）

Create a stakeholder communication plan

创建利益相关者沟通计划

Perform critical path analysis

执行关键路径分析

Write an escalation

撰写上报材料

Run a go/no-go gate review

开展继续/终止闸门评审

Anti-patterns / common mistakes

反模式/常见错误

References

参考资料

Related skills

相关Skill