winter-super-cli 2026.5.32 → 2026.6.5

package/resources/local/ecc/docs/zh-CN/skills/inventory-demand-planning/SKILL.md

@@ -0,0 +1,233 @@
+---
+name: inventory-demand-planning
+description: 为多地点零售商提供需求预测、安全库存优化、补货规划及促销提升估算的编码化专业知识。基于拥有15年以上管理数百个SKU经验的需求规划师的专业知识。包括预测方法选择、ABC/XYZ分析、季节性过渡管理及供应商谈判框架。适用于预测需求、设定安全库存、规划补货、管理促销或优化库存水平时使用。license: Apache-2.0
+version: 1.0.0
+homepage: https://github.com/affaan-m/everything-claude-code
+origin: ECC
+metadata:
+  author: evos
+  clawdbot:
+    emoji: ""
+---
+
+# 库存需求规划
+
+## 角色与背景
+
+你是一家拥有40-200家门店及区域配送中心的多地点零售商的高级需求规划师。你负责管理300-800个活跃SKU，涵盖杂货、日用百货、季节性商品和促销品等多个品类。你的系统包括需求规划套件（Blue Yonder、Oracle Demantra或Kinaxis）、ERP系统（SAP、Oracle）、用于配送中心库存的WMS、门店级别的POS数据馈送以及用于采购订单管理的供应商门户。你处于商品企划（决定销售什么以及定价）、供应链（管理仓库容量和运输）和财务（设定库存投资预算和GMROI目标）之间。你的工作是将商业意图转化为可执行的采购订单，同时最小化缺货和过剩库存。
+
+## 使用时机
+
+* 为现有或新SKU生成或审查需求预测
+* 基于需求波动性和服务水平目标设定安全库存水平
+* 为季节性转换、促销或新产品上市规划补货
+* 评估预测准确性并调整模型或手动覆盖
+* 在供应商最小起订量约束或前置时间变化的情况下做出采购决策
+
+## 工作原理
+
+1. 收集需求信号（POS销售、订单、发货）并清理异常值
+2. 基于ABC/XYZ分类和需求模式，为每个SKU选择预测方法
+3. 应用促销提升、蚕食效应抵消和外部因果因素
+4. 使用需求波动性、前置时间波动性和目标满足率计算安全库存
+5. 生成建议采购订单，应用最小起订量/经济订货批量取整，并提交给规划师审查
+6. 监控预测准确性（MAPE、偏差）并在下一个规划周期调整模型
+
+## 示例
+
+* **季节性促销规划**：商品企划计划对前20名SKU之一进行为期3周的“买一送一”促销。使用历史促销弹性估算促销提升量，计算超前采购数量，与供应商协调提前采购订单和物流容量，并规划促销后的需求低谷。
+* **新SKU上市**：无需求历史可用。使用类比SKU映射（相似品类、价格点、品牌）生成初始预测，设定保守的安全库存（相当于2周的预计销售量），并定义前8周的审查节奏。
+* **前置时间变化下的配送中心补货**：主要供应商因港口拥堵将前置时间从14天延长至21天。重新计算所有受影响SKU的安全库存，识别哪些SKU在新采购订单到达前有缺货风险，并建议过渡订单或替代采购源。
+
+## 核心知识
+
+### 预测方法及各自适用场景
+
+**移动平均（简单、加权、追踪）**：适用于需求稳定、波动性低的商品，近期历史是可靠的预测指标。4周简单移动平均适用于商品化必需品。加权移动平均（近期权重更高）在需求稳定但呈现轻微漂移时效果更好。切勿对季节性商品使用移动平均——它们会滞后于趋势变化半个窗口长度。
+
+**指数平滑（单次、双次、三次）**：单次指数平滑（SES，alpha值0.1–0.3）适用于具有噪声的平稳需求。双次指数平滑（霍尔特方法）增加了趋势跟踪——适用于具有持续增长或下降趋势的商品。三次指数平滑（霍尔特-温特斯方法）增加了季节性指数——这是处理具有52周或12个月周期的季节性商品的主力方法。alpha/beta/gamma参数至关重要：高alpha值（>0.3）会追逐波动商品中的噪声；低alpha值（<0.1）对机制变化的响应太慢。在保留数据上优化，切勿在用于拟合的同一数据上进行。
+
+**季节性分解（STL、经典分解、X-13ARIMA-SEATS）**：当你需要分别隔离趋势、季节性和残差成分时使用。STL（使用Loess的季节和趋势分解）对异常值具有鲁棒性。当季节性模式逐年变化时，当你在对去季节化数据应用不同模型前需要去除季节性时，或者在干净的基线之上构建促销提升估算时，使用季节性分解。
+
+**因果/回归模型**：当外部因素（价格弹性、促销标志、天气、竞争对手行动、本地事件）驱动需求超出商品自身历史时使用。实际挑战在于特征工程：促销标志应编码深度（折扣百分比）、陈列类型、宣传页特性以及跨品类促销存在。在稀疏的促销历史上过拟合是最大的陷阱。积极进行正则化（Lasso/Ridge）并在时间外数据上验证，而非样本外数据。
+
+**机器学习（梯度提升、神经网络）**：当你有大量数据（1000+ SKU × 2年以上周度历史）、多个外部回归变量和一个ML工程团队时是合理的。经过适当特征工程的LightGBM/XGBoost在促销品和间歇性需求商品上的表现优于简单方法10-20% WAPE。但它们需要持续监控——零售业的模型漂移是真实存在的，季度性重新训练是最低要求。
+
+### 预测准确性指标
+
+* **MAPE（平均绝对百分比误差）**：标准指标，但在低销量商品上失效（除以接近零的实际值会产生夸大的百分比）。仅用于平均每周销量50+单位的商品。
+* **加权MAPE（WMAPE）**：绝对误差之和除以实际值之和。防止低销量商品主导该指标。这是财务部门关心的指标，因为它反映了金额。
+* **偏差**：平均符号误差。正偏差 = 预测系统性过高（库存过剩风险）。负偏差 = 系统性过低（缺货风险）。偏差 < ±5% 是健康的。偏差 > 10%（任一方向）意味着模型存在结构性问题，而非噪声。
+* **跟踪信号**：累积误差除以MAD（平均绝对偏差）。当跟踪信号超过±4时，模型已发生漂移，需要干预——要么重新参数化，要么切换方法。
+
+### 安全库存计算
+
+教科书公式为 `SS = Z × σ_d × √(LT + RP)`，其中 Z 是服务水平 z 分数，σ\_d 是每期需求的标准差，LT 是以周期为单位的前置时间，RP 是以周期为单位的审查周期。在实践中，此公式仅适用于正态分布、平稳的需求。
+
+**服务水平目标**：95% 服务水平（Z=1.65）是 A 类商品的标准。99%（Z=2.33）适用于关键/A+ 类商品，其缺货成本远高于持有成本。90%（Z=1.28）对于 C 类商品是可接受的。从 95% 提高到 99% 几乎会使安全库存翻倍——在承诺之前，务必量化增量服务水平的库存投资成本。
+
+**前置时间波动性**：当供应商前置时间不确定时，使用 `SS = Z × √(LT_avg × σ_d² + d_avg² × σ_LT²)` —— 这同时捕捉了需求波动性和前置时间波动性。前置时间变异系数（CV）> 0.3 的供应商所需的安全库存调整可能比仅考虑需求的公式建议的高出 40-60%。
+
+**间断性/间歇性需求**：正态分布的安全库存计算对于存在许多零需求周期的商品失效。对间歇性需求使用 Croston 方法（分别预测需求间隔和需求规模），并使用自举需求分布而非解析公式计算安全库存。
+
+**新产品**：无需求历史意味着没有 σ\_d。使用类比商品分析——找到处于相同生命周期阶段的最相似的 3-5 个商品，并使用它们的需求波动性作为代理。在前 8 周增加 20-30% 的缓冲，然后随着自身历史数据的积累逐渐减少。
+
+### 再订货逻辑
+
+**库存状况**：`IP = On-Hand + On-Order − Backorders − Committed (allocated to open customer orders)`。切勿仅基于在手库存再订货——当采购订单在途时，你会重复订货。
+
+**最小/最大库存**：简单，适用于需求稳定、前置时间一致的商品。最小值 = 前置时间内的平均需求 + 安全库存。最大值 = 最小值 + 经济订货批量。当库存状况降至最小值时，订购至最大值。缺点：除非手动调整，否则无法适应变化的需求模式。
+
+**再订货点 / 经济订货批量**：再订货点 = 前置时间内的平均需求 + 安全库存。经济订货批量 = √(2DS/H)，其中 D = 年需求，S = 订货成本，H = 每单位每年的持有成本。经济订货批量在理论上对恒定需求是最优的，但在实践中你需要取整到供应商的箱装、层装或托盘层级。一个“完美”的 847 单位经济订货批量毫无意义，如果供应商按 24 件一箱发货的话。
+
+**定期审查（R,S）**：每 R 个周期审查一次库存，订购至目标水平 S。当你在固定日期（例如，周二下单周四提货）向供应商合并订单时更好。R 由供应商交货计划设定；S = （R + LT）期间的平均需求 + 该组合期间的安全库存。
+
+**基于供应商层级的审查频率**：A 类供应商（按支出排名前10）采用每周审查周期。B 类供应商（接下来的20名）采用双周审查。C 类供应商（其余）采用每月审查。这使审查工作与财务影响保持一致，并允许获得合并折扣。
+
+### 促销规划
+
+**需求信号扭曲**：促销会制造人为的需求高峰，污染基线预测。在拟合基线模型之前，从历史中剔除促销量。保持一个单独的“促销提升”层，在促销周期间以乘法方式应用于基线之上。
+
+**提升估算方法**：（1）同一商品促销期与非促销期的同比比较。（2）使用历史促销深度、陈列类型和媒体支持作为输入的交叉弹性模型。（3）类比商品提升——新商品借用同一品类中先前促销过的类似商品的提升曲线。典型提升幅度：仅临时降价（TPR）为 15-40%，临时降价 + 陈列 + 宣传页特性为 80-200%，限时抢购/亏本引流活动为 300-500%+。
+
+**蚕食效应**：当 SKU A 促销时，SKU B（相同品类，相似价格点）会损失销量。对于近似替代品，蚕食效应估算为提升销量的 10-30%。忽略跨品类的蚕食效应，除非促销是改变购物篮构成的引流活动。
+
+**超前采购计算**：顾客在深度促销期间囤货，造成促销后低谷。低谷持续时间与产品保质期和促销深度相关。保质期 12 个月的食品储藏室商品打 7 折促销，会造成 2-4 周的低谷，因为家庭消耗囤积的存货。易腐品打 85 折促销几乎不会产生低谷。
+
+**促销后低谷**：预计在大型促销后会有 1-3 周低于基线的需求。低谷幅度通常是增量提升的 30-50%，集中在促销后的第一周。未能预测低谷会导致库存过剩和降价。
+
+### ABC/XYZ 分类
+
+**ABC（价值）**：A = 驱动 80% 收入/利润的前 20% SKU。B = 驱动 15% 的接下来 30%。C = 驱动 5% 的底部 50%。按利润贡献分类，而非收入，以避免过度投资于高收入低利润的商品。
+
+**XYZ（可预测性）**：X = 需求变异系数 < 0.5（高度可预测）。Y = 变异系数 0.5–1.0（中等可预测）。Z = 变异系数 > 1.0（不稳定/间断性）。基于去季节化、去促销化的需求计算，以避免惩罚实际上在其模式内可预测的季节性商品。
+
+**策略矩阵**：AX 类商品采用自动化补货和严格的安全库存。AZ 类商品每个周期都需要人工审查——它们价值高但不稳定。CX 类商品采用自动化补货和宽松的审查周期。CZ 类商品是考虑下架或转为按订单生产的候选对象。
+
+### 季节性转换管理
+
+**采购时机**：季节性采购（例如，节日、夏季、返校季）在销售季节前 12-20 周承诺。将预期季节需求的 60-70% 分配到初始采购中，保留 30-40% 用于基于季初销售情况的再订货。这个“待购额度”储备是你对冲预测误差的手段。
+
+**降价时机：** 当季中售罄进度低于计划的 60% 时，开始降价。早期浅度降价（20–30% 折扣）比后期深度降价（50–70% 折扣）能挽回更多利润。经验法则：降价启动每延迟一周，剩余库存的利润就会损失 3–5 个百分点。
+
+**季末清仓：** 设定一个硬性截止日期（通常在下一季产品到货前 2–3 周）。截止日期后剩余的所有产品将转至奥特莱斯、清仓渠道或捐赠。将季节性产品保留到下一年很少奏效——时尚产品会过时，仓储成本会侵蚀掉任何在下季销售中可能挽回的利润。
+
+## 决策框架
+
+### 按需求模式选择预测方法
+
+| 需求模式 | 主要方法 | 备选方法 | 审查触发条件 |
+|---|---|---|---|
+| 稳定、高销量、无季节性 | 加权移动平均（4–8 周） | 单指数平滑 | WMAPE > 25% 持续 4 周 |
+| 趋势性（增长或下降） | 霍尔特双指数平滑 | 对最近 26 周进行线性回归 | 跟踪信号超过 ±4 |
+| 季节性、重复模式 | 霍尔特-温特斯（增长型季节用乘法模型，稳定型用加法模型） | STL 分解 + 残差的 SES | 季节间模式相关性 < 0.7 |
+| 间歇性 / 不规则（>30% 零需求期） | 克罗斯顿方法或 SBA | 对需求间隔进行自助法模拟 | 平均需求间隔变化 >30% |
+| 促销驱动 | 因果回归（基线 + 促销提升层） | 类比商品提升 + 基线 | 促销后实际值与预测值偏差 >40% |
+| 新产品（0–12 周历史） | 类比商品轮廓结合生命周期曲线 | 品类平均值并向实际值衰减 | 自有数据 WMAPE 稳定低于基于类比商品的 WMAPE |
+| 事件驱动（天气、本地活动） | 带外部回归因子的回归 | 有理由说明的手动覆盖 | 当回归因子与需求相关性低于 0.6 或两个可比事件期间预测误差上升 >30% 时重新评估 |
+
+### 安全库存服务水平选择
+
+| 细分 | 目标服务水平 | Z-分数 | 依据 |
+|---|---|---|---|
+| AX（高价值、可预测） | 97.5% | 1.96 | 高价值证明投资合理；低变异性使 SS 保持适中 |
+| AY（高价值、中等变异性） | 95% | 1.65 | 标准目标；变异性使得更高的 SL 成本过高 |
+| AZ（高价值、不稳定） | 92–95% | 1.41–1.65 | 不稳定的需求使得高 SL 成本极高；需补充应急供货能力 |
+| BX/BY | 95% | 1.65 | 标准目标 |
+| BZ | 90% | 1.28 | 接受中端不稳定商品的一定缺货风险 |
+| CX/CY | 90–92% | 1.28–1.41 | 低价值不足以证明高 SS 投资合理 |
+| CZ | 85% | 1.04 | 考虑淘汰；最小化投资 |
+
+### 促销提升决策框架
+
+1. **此 SKU-促销类型组合是否有历史提升数据？** → 使用自有商品提升数据，并加权近期性（最近 3 次促销按 50/30/20 加权）。
+2. **无自有商品数据，但同品类有促销历史？** → 使用类比商品提升数据，并根据价格点和品牌层级进行调整。
+3. **全新品类或促销类型？** → 使用保守的品类平均提升值并打 8 折。为促销期建立更宽的安全库存缓冲。
+4. **与其他品类交叉促销？** → 分别模拟流量驱动商品和交叉促销受益商品。如果可用，应用交叉弹性系数；否则，默认跨品类光环提升为 0.15。
+5. **始终模拟促销后回落。** 默认值为增量提升的 40%，并按 60/30/10 的比例分布在促销后三周。
+
+### 降价时机决策
+
+| 季中售罄进度 | 行动 | 预期利润挽回率 |
+|---|---|---|
+| ≥ 80% 计划 | 保持价格。若周供应量 < 3，谨慎补货。 | 全额利润 |
+| 60–79% 计划 | 降价 20–25%。不补货。 | 原始利润的 70–80% |
+| 40–59% 计划 | 立即降价 30–40%。取消任何未结采购订单。 | 原始利润的 50–65% |
+| < 40% 计划 | 降价 50% 以上。探索清仓渠道。标记采购错误以供事后分析。 | 原始利润的 30–45% |
+
+### 滞销品淘汰决策
+
+每季度评估。当**所有**以下条件均满足时，标记为淘汰：
+
+* 按当前售罄速度，周供应量 > 26
+* 过去 13 周销售速度 < 该商品前 13 周速度的 50%（生命周期下降）
+* 未来 8 周内无计划促销活动
+* 商品无合同义务（货架陈列承诺、供应商协议）
+* 存在替代或替换 SKU，或品类可吸收缺口
+
+若标记，启动降价 30% 持续 4 周。若仍未动销，升级至 50% 折扣或清仓。从首次降价起设定 8 周的硬性退出日期。不要让滞销品在品类中无限期滞留——它们消耗货架空间、仓库位置和营运资金。
+
+## 关键边缘情况
+
+此处包含简要总结，以便您可以根据项目需要将其扩展为具体的应对手册。
+
+1. **无历史的新产品上市：** 类比商品轮廓分析是您唯一的工具。谨慎选择类比商品——匹配价格点、品类、品牌层级和目标客群，而不仅仅是产品类型。进行保守的初始采购（类比商品预测的 60%），并建立每周自动补货触发机制。
+2. **社交媒体病毒式传播激增：** 需求在无预警情况下激增 500–2000%。不要追逐——当您的供应链做出反应时（4–8 周前置期），激增已结束。从现有库存中尽力满足，制定分配规则防止单一地点囤积，并让浪潮过去。只有当激增后 4 周以上需求持续存在时，才修正基线。
+3. **供应商前置期一夜之间翻倍：** 立即使用新的前置期重新计算安全库存。如果 SS 翻倍，您很可能无法用现有库存填补缺口。为差额下达紧急订单，协商分批发货，并寻找二级供应商。告知商品部门服务水平将暂时下降。
+4. **计划外促销的蚕食效应：** 竞争对手或其他部门进行计划外促销，抢占了您品类的销量。您的预测将过高。通过监控每日 POS 数据以发现模式中断来及早发现，然后手动下调预测。如果可能，推迟到货订单。
+5. **需求模式体制变化：** 原本稳定-季节性的商品突然转变为趋势性或不稳定。常见于产品配方变更、包装更换或竞争对手进入/退出之后。旧模型会无声地失效。每周监控跟踪信号——当连续两个周期超过 ±4 时，触发模型重选。
+6. **虚增库存：** WMS 显示有 200 件；实际盘点显示 40 件。基于该虚增库存的每个预测和补货决策都是错误的。当服务水平下降但系统显示库存“充足”时，怀疑虚增库存。对任何系统显示不应缺货但实际缺货的商品进行循环盘点。
+7. **供应商 MOQ 冲突：** 您的 EOQ 建议订购 150 件；供应商的最小订单量是 500 件。您要么超订（接受数周的过量库存），要么协商。选项：与同一供应商的其他商品合并以满足金额最低要求，为此 SKU 协商更低的 MOQ，或者如果持有成本低于从替代供应商处采购的成本，则接受过量。
+8. **节假日日历偏移效应：** 当关键销售节假日（例如复活节在三月和四月之间移动）在日历上的位置发生变化时，周同比比较会失效。将预测对齐到“相对于节假日的周数”而非日历周数。若未能考虑复活节从第 13 周移至第 16 周，将导致两年都出现显著的预测误差。
+
+## 沟通模式
+
+### 语气校准
+
+* **供应商常规补货：** 事务性、简洁、以采购订单号为准。“根据约定日程，PO #XXXX 交付周为 MM/DD。”
+* **供应商前置期升级：** 坚定、基于事实、量化业务影响。“我们的分析显示，过去 8 周您的前置期已从 14 天增加到 22 天。这导致了 X 次缺货事件。我们需要在 \[日期] 前制定纠正计划。”
+* **内部缺货警报：** 紧急、可操作、包含预估风险收入。以客户影响为首，而非库存指标。“SKU X 将在周四前在 12 个地点缺货。预估销售损失：$XX,000。建议行动：\[加急/调拨/替代]。”
+* **向商品部门提出降价建议：** 数据驱动，包含利润影响分析。切勿表述为“我们买多了”——应表述为“为达到利润目标，售罄速度要求采取价格行动。”
+* **提交促销预测：** 结构化，分别说明基线、提升和促销后回落。包含假设和置信区间。“基线：500 件/周。促销提升预估：180%（增量 900 件）。促销后回落：−35% 持续 2 周。置信度：±25%。”
+* **新产品预测假设：** 明确记录每个假设，以便在事后分析时审计。“基于类比商品 \[列表]，我们预测第 1–4 周为 200 件/周，到第 8 周降至 120 件/周。假设：价格点 $X，分销至 80 个门店，窗口期内无竞争产品上市。”
+
+以上为简要模板。在用于生产环境前，请根据您的供应商、销售和运营规划工作流程进行调整。
+
+## 升级协议
+
+### 自动升级触发条件
+
+| 触发条件 | 行动 | 时间线 |
+|---|---|---|
+| A 类商品预计 7 天内缺货 | 通知需求规划经理 + 品类商品经理 | 4 小时内 |
+| 供应商确认前置期增加 > 25% | 通知供应链总监；重新计算所有未结采购订单 | 1 个工作日内 |
+| 促销预测偏差 > 40%（过高或过低） | 与商品部门和供应商进行促销后复盘 | 促销结束后 1 周内 |
+| 任何 A/B 类商品过量库存 > 26 周供应量 | 向商品副总裁提出降价建议 | 发现后 1 周内 |
+| 预测偏差连续 4 周超过 ±10% | 模型审查和参数重设 | 2 周内 |
+| 新产品上市 4 周后售罄进度 < 计划的 40% | 与商品部门进行品类审查 | 1 周内 |
+| 任何品类服务水平降至 90% 以下 | 根本原因分析和纠正计划 | 48 小时内 |
+
+### 升级链
+
+级别 1（需求规划师） → 级别 2（规划经理，24 小时） → 级别 3（供应链规划总监，48 小时） → 级别 4（供应链副总裁，72+ 小时或任何 A 类商品对重要客户缺货）
+
+## 绩效指标
+
+每周跟踪，每月分析趋势：
+
+| 指标 | 目标 | 危险信号 |
+|---|---|---|
+| WMAPE（加权平均绝对百分比误差） | < 25% | > 35% |
+| 预测偏差 | ±5% | > ±10% 持续 4+ 周 |
+| 现货率（A 类商品） | > 97% | < 94% |
+| 现货率（所有商品） | > 95% | < 92% |
+| 周供应量（总计） | 4–8 周 | > 12 或 < 3 |
+| 过量库存（>26 周供应量） | < 5% 的 SKU | > 10% 的 SKU |
+| 呆滞库存（零销售，13+ 周） | < 2% 的 SKU | > 5% 的 SKU |
+| 供应商采购订单履行率 | > 95% | < 90% |
+| 促销预测准确度（WMAPE） | < 35% | > 50% |
+
+## 附加资源
+
+* 将此技能与您的 SKU 细分模型、服务水平政策和规划师覆盖审计日志结合使用。
+* 将促销失误、供应商延迟和预测覆盖的事后分析存储在规划工作流旁边，以便边缘情况保持可操作性。

package/resources/local/ecc/docs/zh-CN/skills/investor-materials/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: investor-materials
+description: 创建和更新宣传文稿、一页简介、投资者备忘录、加速器申请、财务模型和融资材料。当用户需要面向投资者的文件、预测、资金用途表、里程碑计划或必须在多个融资资产中保持内部一致性的材料时使用。
+origin: ECC
+---
+
+# 投资者材料
+
+构建面向投资者的材料，要求一致、可信且易于辩护。
+
+## 何时启用
+
+* 创建或修订融资演讲稿
+* 撰写投资者备忘录或一页摘要
+* 构建财务模型、里程碑计划或资金使用表
+* 回答加速器或孵化器申请问题
+* 围绕单一事实来源统一多个融资文件
+
+## 黄金法则
+
+所有投资者材料必须彼此一致。
+
+在撰写前创建或确认单一事实来源：
+
+* 增长指标
+* 定价和收入假设
+* 融资规模和工具
+* 资金用途
+* 团队简介和头衔
+* 里程碑和时间线
+
+如果出现冲突的数字，请停止起草并解决它们。
+
+## 核心工作流程
+
+1. 清点规范事实
+2. 识别缺失的假设
+3. 选择资产类型
+4. 用明确的逻辑起草资产
+5. 根据事实来源交叉核对每个数字
+
+## 资产指南
+
+### 融资演讲稿
+
+推荐流程：
+
+1. 公司 + 切入点
+2. 问题
+3. 解决方案
+4. 产品 / 演示
+5. 市场
+6. 商业模式
+7. 增长
+8. 团队
+9. 竞争 / 差异化
+10. 融资需求
+11. 资金用途 / 里程碑
+12. 附录
+
+如果用户想要一个基于网页的演讲稿，请将此技能与 `frontend-slides` 配对使用。
+
+### 一页摘要 / 备忘录
+
+* 用一句清晰的话说明公司做什么
+* 展示为什么是现在
+* 尽早包含增长数据和证明点
+* 使融资需求精确
+* 保持主张易于验证
+
+### 财务模型
+
+包含：
+
+* 明确的假设
+* 在有用时包含悲观/基准/乐观情景
+* 清晰的逐层收入逻辑
+* 与里程碑挂钩的支出
+* 在决策依赖于假设的地方进行敏感性分析
+
+### 加速器申请
+
+* 回答被问的确切问题
+* 优先考虑增长数据、洞察力和团队优势
+* 避免夸大其词
+* 保持内部指标与演讲稿和模型一致
+
+## 需避免的危险信号
+
+* 无法验证的主张
+* 没有假设的模糊市场规模估算
+* 不一致的团队角色或头衔
+* 收入计算不清晰
+* 在假设脆弱的地方夸大确定性
+
+## 质量关卡
+
+在交付前：
+
+* 每个数字都与当前事实来源匹配
+* 资金用途和收入层级计算正确
+* 假设可见，而非隐藏
+* 故事清晰，没有夸张语言
+* 最终资产在合伙人会议上可辩护

package/resources/local/ecc/docs/zh-CN/skills/investor-outreach/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: investor-outreach
+description: 草拟冷邮件、热情介绍简介、跟进邮件、更新邮件和投资者沟通以筹集资金。当用户需要向天使投资人、风险投资公司、战略投资者或加速器进行推广，并需要简洁、个性化的面向投资者的消息时使用。
+origin: ECC
+---
+
+# 投资者接洽
+
+撰写简短、个性化且易于采取行动的投资者沟通内容。
+
+## 何时激活
+
+* 向投资者发送冷邮件时
+* 起草熟人介绍请求时
+* 在会议后或无回复时发送跟进邮件时
+* 在融资过程中撰写投资者更新时
+* 根据基金投资主题或合伙人契合度定制接洽内容时
+
+## 核心规则
+
+1. 个性化每一条外发信息。
+2. 保持请求低门槛。
+3. 使用证据，而非形容词。
+4. 保持简洁。
+5. 绝不发送可发给任何投资者的通用文案。
+
+## 冷邮件结构
+
+1. 主题行：简短且具体
+2. 开头：说明为何选择这位特定投资者
+3. 推介：公司做什么，为何是现在，什么证据重要
+4. 请求：一个具体的下一步行动
+5. 签名：姓名、职位，如需可加上一个可信度锚点
+
+## 个性化来源
+
+参考以下一项或多项：
+
+* 相关的投资组合公司
+* 公开的投资主题、演讲、帖子或文章
+* 共同的联系人
+* 与投资者关注点明确匹配的市场或产品契合度
+
+如果缺少相关背景信息，请询问或说明草稿是等待个性化的模板。
+
+## 跟进节奏
+
+默认节奏：
+
+* 第 0 天：初次外发
+* 第 4-5 天：简短跟进，附带一个新数据点
+* 第 10-12 天：最终跟进，干净利落地收尾
+
+之后除非用户要求更长的跟进序列，否则不再继续提醒。
+
+## 熟人介绍请求
+
+为介绍人提供便利：
+
+* 解释为何这次介绍是合适的
+* 包含可转发的简介
+* 将可转发的简介控制在 100 字以内
+
+## 会后更新
+
+包含：
+
+* 讨论的具体事项
+* 承诺的答复或更新
+* 如有可能，提供一个新证据点
+* 下一步行动
+
+## 质量关卡
+
+在交付前检查：
+
+* 信息已个性化
+* 请求明确
+* 没有废话或乞求性语言
+* 证据点具体
+* 字数保持紧凑

package/resources/local/ecc/docs/zh-CN/skills/iterative-retrieval/SKILL.md

@@ -0,0 +1,215 @@
+---
+name: iterative-retrieval
+description: 逐步优化上下文检索以解决子代理上下文问题的模式
+origin: ECC
+---
+
+# 迭代检索模式
+
+解决多智能体工作流中的“上下文问题”，即子智能体在开始工作前不知道需要哪些上下文。
+
+## 何时激活
+
+* 当需要生成需要代码库上下文但无法预先预测的子代理时
+* 构建需要逐步完善上下文的多代理工作流时
+* 在代理任务中遇到"上下文过大"或"缺少上下文"的失败时
+* 为代码探索设计类似 RAG 的检索管道时
+* 在代理编排中优化令牌使用时
+
+## 问题
+
+子智能体被生成时上下文有限。它们不知道：
+
+* 哪些文件包含相关代码
+* 代码库中存在哪些模式
+* 项目使用什么术语
+
+标准方法会失败：
+
+* **发送所有内容**：超出上下文限制
+* **不发送任何内容**：智能体缺乏关键信息
+* **猜测所需内容**：经常出错
+
+## 解决方案：迭代检索
+
+一个逐步优化上下文的 4 阶段循环：
+
+```
+┌─────────────────────────────────────────────┐
+│                                             │
+│   ┌──────────┐      ┌──────────┐            │
+│   │  调度    │─────│  评估    │            │
+│   └──────────┘      └──────────┘            │
+│        ▲                  │                 │
+│        │                  ▼                 │
+│   ┌──────────┐      ┌──────────┐            │
+│   │  循环    │─────│  优化    │            │
+│   └──────────┘      └──────────┘            │
+│                                             │
+│        最多3次循环，然后继续                 │
+└─────────────────────────────────────────────┘
+```
+
+### 阶段 1：调度
+
+初始的广泛查询以收集候选文件：
+
+```javascript
+// Start with high-level intent
+const initialQuery = {
+  patterns: ['src/**/*.ts', 'lib/**/*.ts'],
+  keywords: ['authentication', 'user', 'session'],
+  excludes: ['*.test.ts', '*.spec.ts']
+};
+
+// Dispatch to retrieval agent
+const candidates = await retrieveFiles(initialQuery);
+```
+
+### 阶段 2：评估
+
+评估检索到的内容的相关性：
+
+```javascript
+function evaluateRelevance(files, task) {
+  return files.map(file => ({
+    path: file.path,
+    relevance: scoreRelevance(file.content, task),
+    reason: explainRelevance(file.content, task),
+    missingContext: identifyGaps(file.content, task)
+  }));
+}
+```
+
+评分标准：
+
+* **高 (0.8-1.0)**：直接实现目标功能
+* **中 (0.5-0.7)**：包含相关模式或类型
+* **低 (0.2-0.4)**：略微相关
+* **无 (0-0.2)**：不相关，排除
+
+### 阶段 3：优化
+
+根据评估结果更新搜索条件：
+
+```javascript
+function refineQuery(evaluation, previousQuery) {
+  return {
+    // Add new patterns discovered in high-relevance files
+    patterns: [...previousQuery.patterns, ...extractPatterns(evaluation)],
+
+    // Add terminology found in codebase
+    keywords: [...previousQuery.keywords, ...extractKeywords(evaluation)],
+
+    // Exclude confirmed irrelevant paths
+    excludes: [...previousQuery.excludes, ...evaluation
+      .filter(e => e.relevance < 0.2)
+      .map(e => e.path)
+    ],
+
+    // Target specific gaps
+    focusAreas: evaluation
+      .flatMap(e => e.missingContext)
+      .filter(unique)
+  };
+}
+```
+
+### 阶段 4：循环
+
+使用优化后的条件重复（最多 3 个周期）：
+
+```javascript
+async function iterativeRetrieve(task, maxCycles = 3) {
+  let query = createInitialQuery(task);
+  let bestContext = [];
+
+  for (let cycle = 0; cycle < maxCycles; cycle++) {
+    const candidates = await retrieveFiles(query);
+    const evaluation = evaluateRelevance(candidates, task);
+
+    // Check if we have sufficient context
+    const highRelevance = evaluation.filter(e => e.relevance >= 0.7);
+    if (highRelevance.length >= 3 && !hasCriticalGaps(evaluation)) {
+      return highRelevance;
+    }
+
+    // Refine and continue
+    query = refineQuery(evaluation, query);
+    bestContext = mergeContext(bestContext, highRelevance);
+  }
+
+  return bestContext;
+}
+```
+
+## 实际示例
+
+### 示例 1：错误修复上下文
+
+```
+任务："修复身份验证令牌过期错误"
+
+循环 1:
+  分发：在 src/** 中搜索 "token"、"auth"、"expiry"
+  评估：找到 auth.ts (0.9)、tokens.ts (0.8)、user.ts (0.3)
+  优化：添加 "refresh"、"jwt" 关键词；排除 user.ts
+
+循环 2:
+  分发：搜索优化后的关键词
+  评估：找到 session-manager.ts (0.95)、jwt-utils.ts (0.85)
+  优化：上下文已充分（2 个高相关文件）
+
+结果：auth.ts、tokens.ts、session-manager.ts、jwt-utils.ts
+```
+
+### 示例 2：功能实现
+
+```
+任务："为API端点添加速率限制"
+
+周期 1：
+  分发：在 routes/** 中搜索 "rate"、"limit"、"api"
+  评估：无匹配项 - 代码库使用 "throttle" 术语
+  优化：添加 "throttle"、"middleware" 关键词
+
+周期 2：
+  分发：搜索优化后的术语
+  评估：找到 throttle.ts (0.9)、middleware/index.ts (0.7)
+  优化：需要路由模式
+
+周期 3：
+  分发：搜索 "router"、"express" 模式
+  评估：找到 router-setup.ts (0.8)
+  优化：上下文已足够
+
+结果：throttle.ts、middleware/index.ts、router-setup.ts
+```
+
+## 与智能体集成
+
+在智能体提示中使用：
+
+```markdown
+在为该任务检索上下文时：
+1. 从广泛的关键词搜索开始
+2. 评估每个文件的相关性（0-1 分制）
+3. 识别仍缺失哪些上下文
+4. 优化搜索条件并重复（最多 3 个循环）
+5. 返回相关性 >= 0.7 的文件
+
+```
+
+## 最佳实践
+
+1. **先宽泛，后逐步细化** - 不要过度指定初始查询
+2. **学习代码库术语** - 第一轮循环通常能揭示命名约定
+3. **跟踪缺失内容** - 明确识别差距以驱动优化
+4. **在“足够好”时停止** - 3 个高相关性文件胜过 10 个中等相关性文件
+5. **自信地排除** - 低相关性文件不会变得相关
+
+## 相关
+
+* [长篇指南](https://x.com/affaanmustafa/status/2014040193557471352) - 子代理编排章节
+* `continuous-learning` 技能 - 适用于随时间改进的模式
+* 与 ECC 捆绑的代理定义（手动安装路径：`agents/`）