commit 6e4b11f65cd99d8687f5b45f3a7eafda7f1a05e2
Author: wehub-skill-sync <skill-sync@wehub.local>
Date:   Mon Jul 13 21:37:06 2026 +0800

    chore: import zh skill managing-timelines

diff --git a/README.wehub.md b/README.wehub.md
new file mode 100644
index 0000000..15cec2c
--- /dev/null
+++ b/README.wehub.md
@@ -0,0 +1,9 @@
+# WeHub 来源说明
+
+- Skill 名称：`managing-timelines`
+- 中文类目：Sprint 与时间线规划
+- 上游仓库：`refoundai__lenny-skills`
+- 上游路径：`skills/managing-timelines/SKILL.md`
+- 上游链接：https://github.com/refoundai/lenny-skills/blob/HEAD/skills/managing-timelines/SKILL.md
+- 本仓库为 WeHub 中文 Skill 汉化包，基于 skill 市场筛选 Top200 清单整理
+- 原作者、版权和许可证信息以上游仓库为准
diff --git a/SKILL.md b/SKILL.md
new file mode 100644
index 0000000..33d46af
--- /dev/null
+++ b/SKILL.md
@@ -0,0 +1,77 @@
+---
+name: managing-timelines
+description: 帮助用户设定并达成切实可行的截止日期。当用户正在规划项目时间线、难以按时完成、面临利益相关者的时间压力或希望提高估算准确度时使用。
+---
+
+# 管理时间线
+
+利用来自 13 位产品负责人的方法，帮助用户设定并达成切实可行的项目时间线。
+
+## 如何提供帮助
+
+当用户寻求时间线方面的帮助时：
+
+1. **了解上下文** —— 询问截止日期的性质（外部承诺、内部目标、人为设定的里程碑）、工作所处的阶段，以及时间压力的来源
+2. **诊断问题** —— 判断这是估算问题、范围问题、注意力分散问题，还是利益相关者不切实际的期望
+3. **应用合适的框架** —— 根据具体情况，帮助用户采用基于阶段的承诺、山形图或尽早交付策略
+4. **培养健康习惯** —— 引导用户养成可持续的时间线管理实践，而非一次性补救
+
+## 核心原则
+
+### 把真正的截止日期当作 P0 来对待——其他一切都不重要
+Nan Yu：「让截止日期真正起效的唯一方法，就是把它当作 P0 级别的问题来严肃对待，相比之下其他所有事情都必须变得不重要。」不要设立过多的截止日期。将其保留给关键的外部事件，一旦设定，就保护团队免受所有其他干扰。
+
+### 对阶段做出承诺，而非遥远的交付日期
+Annie Pearl：「我们已经转向承诺那些在我们掌控范围内的日期。我们可以承诺一个探索阶段的工作……而不是对一个六个月后、尚未充分探索的项目做出承诺。」将工作拆分为探索、方案设计、构建和上线四个阶段。只有在方案设计完成后，才提供工程交付日期。
+
+### 尽早交付，用剩余时间迭代
+Nan Yu：「我们几乎不做估算。我们做的是尽早交付。如果在时间的 10% 内你已经有了一个可用的东西，你就可以用剩下的时间决定是继续迭代还是打磨完善。」专注于尽快达到一个「可行或不可行」的可交付状态，而不是把大量精力放在前期估算上。
+
+### 使用山形图跟踪不确定性
+Jason Fried：「项目更像一座山。左边意味着你还在摸索阶段。一旦工作到达山顶，之后就是下坡路了——纯粹的执行。」将工作可视化为一座山：左侧是探索阶段，右侧是执行阶段。卡在上坡路上的事项是错过截止日期的高风险因素。
+
+### 人为制造截止日期以创造动力
+Laura Modi：「你的工作不仅仅是让人们靠惯性前进。你的工作是创造动力。有时这需要人为制造。」设定任意的截止日期和上线时间来推动进展。使用里程碑来防止过度追求完美。
+
+### 质疑估算中隐藏的裕量
+Dylan Field：「如果时间线可能没有经过充分的、从基本原理出发的推敲，并且存在善意添加的裕量，你就必须理解各项任务实际需要多长时间的基本假设。」多问「为什么」来发现隐藏的限制条件或不必要的裕量。从基本原理出发审视各项假设。
+
+### 考虑规划谬误
+Nir Eyal：「人们完成一项任务实际所需的时间，通常比他们估算的长三倍。当你只工作了五分钟，就收到一封邮件和一个通知时，你实际上从未真正追踪过花费的时间。」通过你是否在不受干扰的情况下完成了自己承诺的事情来衡量生产力。使用时间盒来建立关于实际耗时的反馈循环。
+
+### 不要请求延期
+Seth Godin：「专业人士不会请求延期，因为专业人士明白，意料之外的事情总会发生。」将截止日期和预算视为硬约束。在计划中预留缓冲空间以应对意外情况，而无需延期。
+
+### 每周使用 RAG 状态进行评审
+Brian Chesky：「我有一位首席项目经理，他会把所有项目标记为绿色、黄色或红色。我每周评审工作进展，如果某件事没有推进，我会叫停会议，问『为什么这件事没有推进？』」提升项目管理的地位。使用简单的 RAG 状态和每周评审，尽早发现问题并扫清障碍。
+
+### 预期 AI 时间线是不均衡的
+Aparna Chennapragada：「首次演示的时间大大缩短，但完全部署所需的时间会更长。这是一种不均衡的节奏。」为原型构建的短内循环做好规划，但要为规模化部署的外循环分配充足的时间。管理好关于演示产品与可交付产品之间差距的预期。
+
+## 可用于帮助用户的问题
+
+- 「这是一个外部承诺还是内部目标？如果错过了会有什么后果？」
+- 「当前工作处于哪个阶段——探索、方案设计还是构建？」
+- 「你们是否已经交付了一个『可用版本』，还是团队仍在摸索中？」
+- 「这个估算中裕量在哪里？背后隐含了哪些假设？」
+- 「你的实际时间有多少花在了专注工作上，又有多少花在了会议和干扰上？」
+- 「是否有太多『P0 级别的截止日期』在争夺注意力？」
+
+## 需要指出的常见错误
+
+- **在探索完成之前就承诺日期** —— 你无法估算尚未确定范围的事情。对阶段做出承诺，而非遥远的交付日期
+- **优先级过高的截止日期太多** —— 如果每件事都是 P0，那就没有真正的 P0 了。把真正的截止日期留给关键的外部事件
+- **把大量精力放在前期估算上，而不是尽早交付** —— 快速得到一个可用版本，然后用剩余时间迭代
+- **忽视规划谬误** —— 由于干扰，实际耗时通常是估算的三倍。使用时间盒，并度量实际专注工作时间
+- **请求延期** —— 专业人士会为意外情况做好规划。预留缓冲空间，而不是延长时间线
+
+## 深入阅读
+
+关于 13 位嘉宾的 14 条洞见，请参见 `references/guest-insights.md`
+
+## 相关技能
+
+- 范围界定与裁剪
+- 路线图优先级排序
+- 高效会议
+- 不确定性下的规划
diff --git a/references/guest-insights.md b/references/guest-insights.md
new file mode 100644
index 0000000..a0fa240
--- /dev/null
+++ b/references/guest-insights.md
@@ -0,0 +1,203 @@
+# 管理时间线 —— 嘉宾洞见合集
+
+*13 位嘉宾，14 条引述*
+
+---
+
+## Ada Chen Rekhi
+*Ada Chen Rekhi*
+
+> "也许在前一天晚上就想好，你一天中最想完成的那一件事，然后在最早的机会，试着给自己五分钟先做这件事。"
+
+**洞见：** 通过承诺在当天早些时候只花五分钟完成你最重要的任务，来克服"高效拖延"。
+
+**战术建议：**
+- 在前一天晚上确定你的"那一件事"。
+- 运用"五分钟法则"来降低启动困难任务的心理门槛。
+
+*时间戳：01:15:43*
+
+
+## Annie Pearl
+*Annie Pearl*
+
+> "过去一年我们做的一件事，就是真正转向一种模型——只谈论我们能够掌控的日期，并对此做出承诺和保证。所以，如果你思考产品开发的生命周期，我们可以承诺一次探索工作……我们在对眼前的工作做承诺方面已经好多了，而不是去承诺一个六个月后、连充分探索都还没做的项目。"
+
+**洞见：** 只对当前阶段的工作（探索或方案设计）承诺日期，而不是为尚未确定范围的项目承诺长远的交付日期。
+
+**战术建议：**
+- 将生命周期拆分为探索、方案设计、构建和发布四个阶段。
+- 只有在方案设计阶段完成且估算准确之后，才提供工程交付日期。
+
+*时间戳：00:36:30*
+
+
+## Aparna Chennapragada
+*Aparna Chennapragada*
+
+> "我所看到的是，首次演示的时间大大缩短了，但全面部署所需的时间却更长了。所以我认为节奏会是不均匀的。过去的情况更像是，你接手这件事，花几周时间，然后就可以迭代等等。但那个原型设计和迭代的内循环，甚至通过 AI 对话来做用户研究，所有这些都变短了。但我认为，规模化的门槛因此变得更高了。"
+
+**洞见：** AI 开发会带来一种不均匀的节奏——初始原型可以快速完成，但达到生产级的规模和可靠性所需的时间，远比传统软件要长。
+
+**战术建议：**
+- 为原型设计和探索的"内循环"规划更短的时间。
+- 为规模化和部署的"外循环"分配充足的时间。
+- 管理相关方对成功演示与可交付产品之间差距的预期。
+
+*时间戳：00:24:04*
+
+
+## Brian Chesky
+*Brian Chesky*
+
+> "我有一位首席项目经理，他会给所有项目打分。要么是绿色、黄色，要么是红色，意思是它们能否按时交付……我每周都会审查工作进度。之所以没有那么多官僚流程……是因为我会审查工作，如果某件事没有进展，我就会停下会议，问：'为什么这件事没有进展？'"
+
+**洞见：** 通过高地位的项目管理和频繁的高管审查来维持交付速度并识别瓶颈。
+
+**战术建议：**
+- 将项目管理提升到一个高地位的角色。
+- 使用简单的 RAG（红、黄、绿）状态来跟踪项目进度。
+- 每周审查工作，以识别并帮助个体工程师扫清障碍。
+
+*时间戳：00:27:11*
+
+
+## Dylan Field
+*Dylan Field 2.0*
+
+> "如果时间线可能没有从第一性原理出发经过充分推敲，并且可能存在不同人善意添加的水分，那么你必须完全理解：好，哪些是对实际需要多长时间的假设，哪些是水分？然后真正和团队一起解决这个问题。"
+
+**洞见：** 通过深入挖掘时间估算背后的假设并识别不必要的"水分"来挑战这些估算。
+
+**战术建议：**
+- 多问"为什么"来发现隐藏的约束或估算中不必要的水分。
+- 和团队一起从第一性原理出发推演时间线假设。
+
+*时间戳：00:10:27*
+
+
+## Eli Schwartz
+*Eli Schwartz*
+
+> "当你开展 SEO 工作时——我会不断回到这一点——它是一个产品。所以你在打造一个产品，你在创建里程碑……如果你开始错过所有这些里程碑……你可以非常具体地指出那些被错过的里程碑。"
+
+**洞见：** SEO 项目应该用产品里程碑来管理，以确保问责制，并在最终结果显现之前跟踪进展。
+
+**战术建议：**
+- 为创意构思、PRD 创建、工程冲刺和上线发布设定月度里程碑。
+- 使用"已索引页面数"作为早期里程碑，以验证技术构建是否正常运作。
+
+*时间戳：00:52:28*
+
+
+## Jackson Shuttleworth
+*Jackson Shuttleworth*
+
+> "我们有大量的 Jira 自动化……确保你有非常好的流程来管理如何运行这么多实验……我们会提前几个月做规划，当我们思考这些功能迭代——即使是小的功能迭代——因为当你失去周期，没有推动某个功能时，那本质上就是机会的损失。"
+
+**洞见：** 高速度的实验需要严谨的流程和自动化的项目管理，以避免"周期损失"。
+
+**战术建议：**
+- 使用 Jira 自动化来管理实验管道。
+- 提前数月规划设计和工程的带宽，确保持续迭代。
+
+*时间戳：01:08:41*
+
+
+## Jason Fried
+*Jason Fried*
+
+> "我们在 Basecamp 里有一个叫山丘图的东西。山丘上的东西，那才是真正的工作……项目更像一座山丘，而不是一条直线。如果你在山丘的左侧，意味着你还在努力把这件事推上山，还在试图弄清楚该怎么做。但一旦工作到达山顶，剩下的就是下山的路了，那就是纯粹的执行，我们知道如何把它搞定。"
+
+**洞见：** 使用"山丘图"来跟踪项目进度，以区分探索阶段的不确定性和执行阶段的确定性。
+
+**战术建议：**
+- 将工作可视化一座山丘：左侧是"摸索阶段"，右侧是"执行阶段"。
+- 识别卡在"上坡"一侧的项目，它们有错过截止日期的较高风险。
+- 将管理注意力集中在推动事项从山丘左侧到达山顶上。
+
+*时间戳：00:37:17*
+
+
+## Laura Modi
+*Laura Modi*
+
+> "你的工作不仅仅是让人们保持势头。你的工作是创造势头。而有时候，这种势头需要被制造出来。这是我最大的教训之一——作为领导者和初创公司的人，你如何迫使自己？有时候在早期阶段，你其实是在对自己做这件事——创造人为的截止日期和发布日。"
+
+**洞见：** 领导者常常需要创造人为的截止日期来维持组织的推进速度。
+
+**战术建议：**
+- 设定"人为的"截止日期和发布日来推动进展。
+- 使用任意里程碑来防止团队过度追求完美而错失机会。
+
+*时间戳：00:52:56*
+
+
+## Nan Yu
+*Nan Yu*
+
+> "让截止日期变得真实的唯一方法，就是把它们看得极其重要，基本上当作一个 P0 问题来处理，其他所有事情与之相比都必须不重要——因为这是你唯一能向团队以及所有相关方表明你确实在认真对待它的方式。"
+
+**洞见：** 截止日期只有在被当作最高优先级（P0）处理、其他一切事情都靠边站时，才会真正起作用。
+
+**战术建议：**
+- 不要有太多截止日期，只将它们用于关键的外部事件。
+- 一旦设定截止日期，就保护团队免受所有其他干扰。
+
+*时间戳：01:09:38*
+
+---
+
+> "为了赶上截止日期，我们几乎不做估算。我们做的是尽早发布。之前我们聊过，如果在 10% 的时间过去时你已经有了一个可运行的东西，那么你就可以用剩下的时间来决定是要再做一次迭代，还是打磨那个东西。"
+
+**洞见：** 通过尽早交付一个可用的版本来赶上截止日期，并用剩余时间进行迭代，而不是依赖前期的估算。
+
+**战术建议：**
+- 专注于尽快达到"可以上线或不上线"的可交付状态。
+- 从项目一开始就致力于快速迭代的流程。
+
+*时间戳：01:13:18*
+
+
+## Nir Eyal
+*Nir Eyal*
+
+> "任务实际完成所花的时间，往往是人们估算的三倍。为什么会这样？因为当你说'好吧，这是待办清单上的那件事，我要开始做它，看看需要多久才能完成'时，你做了五分钟，然后收到一封邮件，然后又来一条通知……你从来没有真正追踪过那件事到底花了多久才完成。"
+
+**洞见：** 规划谬误之所以发生，是因为我们没有把干扰考虑在内；准确的时间线需要衡量专注的工作时间。
+
+**战术建议：**
+- 衡量生产力的标准是：你是否按照自己说的那样，在不受干扰的情况下，做了自己说过要做的事情，并且做了自己说好的时长。
+- 使用时间盒来建立一个关于任务实际耗时的反馈循环。
+- 从待办清单（以输出为中心）转向日历（以投入为中心），以理解时间的约束。
+
+*时间戳：00:32:53*
+
+
+## Seth Godin
+*Seth Godin*
+
+> "关于项目的一点是：当你时间和金钱都用完的时候，项目就结束了。不要耗尽时间，不要耗尽金钱。良好的意愿不是延期的理由。专业人士不会要求延期，因为专业人士明白，意料之外的事情总会发生。"
+
+**洞见：** 产品管理中的专业精神意味着将意外情况纳入考量，并在最初的时间和预算约束内交付。
+
+**战术建议：**
+- 将截止日期和预算视为定义项目结束的硬约束。
+- 在计划中建立缓冲，以处理不可避免的意外事件，而无需要求延期。
+
+*时间戳：14:49*
+
+
+## Timothy Davis
+*Timothy Davis*
+
+> "我们有这样一个计算器，我们用它来看：'你在会议上花了多少时间？'……好吧，下个季度，它又红了。好吧，那也许我们该开始讨论，这个新员工会接手什么工作了。"
+
+**洞见：** 只有当团队成员在优化日程安排后仍然持续处于"红色"状态时，才使用量化容量计算器来证明新员工招聘的合理性。
+
+**战术建议：**
+- 对照一个季度的总天数，追踪会议时间、年假和优化任务。
+- 在批准新编制之前，先削减非必要的会议或项目参与。
+- 在启动招聘之前，等待连续两个季度的"红色"容量状态。
+
+*时间戳：01:16:59*