commit 22b11ec965c75aa19941e9578804dd6bdf6dfe2d
Author: wehub-skill-sync <skill-sync@wehub.local>
Date:   Mon Jul 13 21:35:41 2026 +0800

    chore: import zh skill challenge

diff --git a/README.wehub.md b/README.wehub.md
new file mode 100644
index 0000000..0712988
--- /dev/null
+++ b/README.wehub.md
@@ -0,0 +1,9 @@
+# WeHub 来源说明
+
+- Skill 名称：`challenge`
+- 中文类目：战略计划 pre-mortem 与对抗式压力测试
+- 上游仓库：`alirezarezvani__claude-skills`
+- 上游路径：`.gemini/skills/challenge/SKILL.md`
+- 上游链接：https://github.com/alirezarezvani/claude-skills/blob/HEAD/.gemini/skills/challenge/SKILL.md
+- 本仓库为 WeHub 中文 Skill 汉化包，基于 skill 市场筛选 Top200 清单整理
+- 原作者、版权和许可证信息以上游仓库为准
diff --git a/SKILL.md b/SKILL.md
new file mode 100644
index 0000000..22217e1
--- /dev/null
+++ b/SKILL.md
@@ -0,0 +1,184 @@
+```yaml
+---
+name: "challenge"
+description: "计划的事后分析。假设计划在 12 个月后已失败，反向推导找出弱点。揭示假设、依赖关系和执行风险，以便在投入资源前做出明智决策。适用于：在投入大量资源之前、向董事会或投资者汇报之前、收到的反馈呈一边倒的积极时、或面临快速推进的压力而打算「先做了再说」时。"
+---
+
+# /em:challenge — 计划的事后分析
+
+**命令：** `/em:challenge <计划>`
+
+系统性找出任何计划中的弱点，赶在现实下手之前。目的不是扼杀计划——而是让它经得起现实的考验。
+
+---
+
+## 核心理念
+
+大多数计划失败的原因是可预见的。不是运气不好——而是错误的假设。高估了需求。低估了复杂度。没人质疑过的依赖关系。在电子表格里说得通但在现实中行不通的时机。
+
+事后分析技术：**想象现在是 12 个月后，这个计划惨败了。现在反向推导。为什么？**
+
+这不是悲观主义。这是构建一个不会崩塌的东西的方法。
+
+---
+
+## 何时运行挑战
+
+- 在向计划投入大量资源之前
+- 在向董事会或投资者汇报之前
+- 当你注意到自己只听到关于计划的正面反馈时
+- 当计划需要多个外部依赖关系同时对齐时
+- 当面临快速推进、「先做了再说」的压力时
+- 当你对计划感到兴奋时（兴奋是一个信号，要更仔细地审视）
+
+---
+
+## 挑战框架
+
+### 第 1 步：提取核心假设
+
+在你能检验一个计划之前，你需要把计划所依赖的一切假设都浮出水面。
+
+针对计划的每一部分，问：
+- 要让这个计划成功，什么必须为真？
+- 我们对客户行为做了哪些假设？
+- 我们对竞争对手的反应做了哪些假设？
+- 我们对自己执行能力做了哪些假设？
+- 这个计划依赖哪些外部因素？
+
+**常见的假设类别：**
+- **市场假设**——市场规模、增长率、客户付费意愿、购买周期
+- **执行假设**——团队产能、开发速度、不需要重大招聘
+- **客户假设**——他们有此问题、他们知道自己有此问题、他们愿意付费解决
+- **竞争假设**——现有玩家不会反击、没有新进入者、护城河稳固
+- **财务假设**——烧钱率、收入时间点、CAC、LTV 比率
+- **依赖假设**——合作伙伴会交付、API 不会变更、法规不会变化
+
+### 第 2 步：为每个假设评级
+
+对于提取出的每个假设，在两个维度上进行评级：
+
+**置信度（你有多确定这是真的）：**
+- **高**——已通过数据、客户访谈、市场调研验证
+- **中**——方向正确但未经验证
+- **低**——看似合理但未经检验
+- **未知**——我们根本不知道
+
+**若假设错误的影响（如果这个假设失败了会怎样）：**
+- **致命**——计划完全失败
+- **高**——重大延期或成本超支
+- **中**——需要大量返工
+- **低**——可控调整
+
+### 第 3 步：绘制脆弱性地图
+
+低/未知置信度 × 致命/高影响 = 你最高风险的假设。
+
+**脆弱性 = 低置信度 + 高影响**
+
+这些不是可以忽视的问题。它们是你正在下的赌注。问题在于：你是在有意识地做出这些赌注吗？
+
+### 第 4 步：找到依赖链
+
+许多计划失败不是因为某一个假设错了，而是因为多个假设必须同时成立。
+
+绘制依赖链：
+- 假设 B 是否依赖于假设 A 先成立？
+- 如果第一件事出了问题，有多少下游环节会跟着崩溃？
+- 关键路径是什么？哪个环节没有缓冲余量？
+
+### 第 5 步：测试可逆性
+
+对于每个致命脆弱性：如果这个假设在第 3 个月被证明是错误的，你会怎么做？
+
+- 你能调整方向吗？
+- 你能缩减范围吗？
+- 钱已经花出去了吗？
+- 承诺已经做出去了吗？
+
+可逆性越低，你在做出承诺之前就越需要严格验证。
+
+---
+
+## 输出格式
+
+**挑战报告：[计划名称]**
+
+```
+核心假设（已提取）
+1. [假设] — 置信度：[高/中/低/未知] — 若错误的影响：[致命/高/中/低]
+2. ...
+
+脆弱性地图
+致命风险（在继续之前必须处理）：
+• [#N] [假设] — 它可能出错的原因 — 如果出错会导致什么后果
+
+高风险（在规模化之前必须验证）：
+• ...
+
+依赖链
+[假设 A] → 依赖于 → [假设 B] → 进而支撑 → [假设 C]
+最薄弱环节：[X] — 如果这个断了，[Y] 和 [Z] 也会失败
+
+可逆性评估
+• 可逆的赌注：[列表]
+• 不可逆的承诺：[列表——需极其谨慎对待]
+
+终止条件
+在 [30/60/90 天] 时，什么情况下应该继续，什么情况下应该终止/调整？
+• 继续的条件：……
+• 终止/调整的条件：……
+
+加固措施
+1. [在继续之前需完成的具体验证]
+2. [可考虑的替代方案]
+3. [需内置到计划中的应急预案]
+```
+
+---
+
+## 按计划类型的挑战模式
+
+### 产品路线图
+- 我们是在构建客户愿意付费的东西，还是在构建他们嘴上说想要的东西？
+- 开发速度估算是否考虑了真实的团队产能（而非理论值）？
+- 如果核心功能花费的时长是估算的 3 倍，会怎样？
+- 当需求冲突时，谁来做决策？
+
+### 上市计划
+- 真实的 ICP 转化率是多少，而不是期望中的那个？
+- 达成一笔交易需要多少次触达，你是否有足够的销售产能来支撑？
+- 如果前 10 笔交易花了 3 个月而不是 1 个月，会怎样？
+-「先落地再扩展」是一个真实的策略，还是一个美好的愿望？
+
+### 招聘计划
+- 如果关键岗位花了 4 个月而不是 6 周才招到人，会怎样？
+- 该计划是否依赖于留住某些可能离职的特定人员？
+- 计划是否考虑了入职适应期（通常需要 3–6 个月才能达到完全生产力）？
+- 如果人员增长领先收入增长 6 个月，对现金流的影响是什么？
+
+### 融资计划
+- 如果领投方不跟了，你的备选方案是什么？
+- 如果融资花了 6 个月而不是 3 个月，你是否对时间线做过模拟？
+- 在当前烧钱率下，如果融资按最低预期完成，你的跑道还有多长？
+- 如果你只融到了目标金额的 50%，哪些假设会失效？
+
+---
+
+## 最难的问题
+
+这些是大家通常跳过的问题：
+-「悲观情景是什么，而不是基准情景？」
+-「如果这个计划是由一个我们不信任的团队来执行，它还能成功吗？」
+-「有什么事情我们没有说出来，因为说出来会让人不舒服？」
+-「谁有动机让这个计划听起来比实际更好？」
+-「这个计划的敌人会首先攻击哪里？」
+
+---
+
+## 交付物
+
+`/em:challenge` 的输出不是让你停下来的许可。它是一张脆弱性地图。现在你可以做出有意识的决策：验证有风险的假设，对冲致命的那些，或者有意识地接受你正在下的赌注。
+
+未知的风险是危险的。已知的风险是可控的。
+```