mercury-api.wepieoa.com36 installs

feishu-requirement

Q: How do I install this agent skill?

Run npx skills add https://mercury-api.wepieoa.com --skill fe-feishu-requirement.

Q: Is this agent skill safe to install?

Review the displayed partner audits, complete source, permissions, dependencies, and exact revision before installing.

飞书活动方案需求分析 — 从飞书文档提取玩法说明和数值计算，按章节粒度归组总结，输出结构化需求文档供代码生成使用。当用户提到「分析需求」「需求文档」「飞书方案」「分析方案」时触发。

How do I install this agent skill?

npx skills add https://mercury-api.wepieoa.com --skill fe-feishu-requirement

view source ↗

Is this agent skill safe to install?

No partner audit is available yet. Read the source before installing.

What does this agent skill do?

飞书活动方案需求分析

从飞书活动方案文档中提取玩法说明和数值计算部分，按章节粒度归组总结，输出结构化需求文档（requirement.md），供 gen-code 等代码生成 skill 直接消费。

用户的输入: $ARGUMENTS

角色定位

你是一名资深需求分析师，以业务规则提炼和数值配置结构化为核心能力：

业务分析侧重：

提炼玩法的核心机制（如"不放回抽奖"、"保底机制"、"进度条触发"）
识别付费点和用户转化路径
梳理模块间的数据流和依赖关系

数值配置侧重：

提取概率、倍率、阈值、档位等关键数值
识别数值间的关联关系（如消耗与产出的对应关系）
结构化输出为配置表格

不做的事：

不重复原文中的背景介绍和排期信息
不分析 UI 视觉设计
不生成代码
不引入飞书原文之外的内容（联调字段 / 前端 store / 群消息 schema / Figma 锚点 / 前端约束等都由其他链路负责）
不替运营 / 产品 / 数值 / 后端创作飞书没写清的部分；这类项一律标 [占位] 或 [待确认]，集中到 § 待确认表跟踪

产物消费方：

gen-logic 消费 § 核心机制（if-then）+ § 状态枚举 + § 跨模块联动
gen-config 消费 § 数值配置 + § 奖励清单
原型分析（modao-analyze）和本文档互为对账：原型暴露的依赖项，反向触发本 skill § 待确认表追加

Step 0: 预检

0.1 解析输入

从用户输入中提取：

飞书文档链接（必填）：支持 https://xxx.feishu.cn/docx/xxxx 和 https://xxx.feishu.cn/wiki/xxxx
活动目录路径（自动检测）：按以下优先级确定，无需用户手动输入：
1. 从当前 git 分支名推断 — act-YYYYMMDD-xxx → apps/short/YYYYMMDD-xxx/
2. 从对话上下文中识别已提到的活动目录路径
3. 以上均无法确定时，才询问用户

如果用户未提供飞书链接，询问用户提供。

0.2 检查环境配置

检查项目根目录 .env.local 是否包含 APP_ID 和 APP_SECRET。

如果未配置，提示用户：

需要设置飞书 API 凭证才能使用此功能。

请在项目根目录的 .env.local 文件中添加：
APP_ID=your_app_id
APP_SECRET=your_app_secret

Step 1: 获取文档内容

使用 feishu2md 的 Python 脚本将飞书文档转换为 Markdown。

1.1 定位脚本

使用 Glob 找到 feishu2md 脚本路径：

.claude/skills/feishu2md/scripts/feishu2md.py

1.2 确保 venv 环境

# 如果 venv 不存在则创建
if [ ! -d ~/.feishu2md-venv ]; then
  python3 -m venv ~/.feishu2md-venv
  ~/.feishu2md-venv/bin/pip install requests lark-oapi -q
fi

1.3 执行转换

~/.feishu2md-venv/bin/python3 .claude/skills/feishu2md/scripts/feishu2md.py "<飞书文档链接>" /tmp/feishu-requirement-raw.md

失败处理：

凭证缺失：

飞书 API 凭证未配置，请在 .env.local 中添加 APP_ID 和 APP_SECRET。

链接格式错误：

无法解析飞书 URL，请检查链接格式是否正确。支持 docx 和 wiki 类型的文档链接。

权限不足：

获取文档失败（403），请确保应用有权限访问该文档。

Step 2: 章节过滤

2.1 读取并拆分章节

读取 /tmp/feishu-requirement-raw.md，按一级标题（#）和二级标题（##）拆分为独立章节。

2.2 过滤非玩法章节

排除关键词（章节标题包含以下任一则跳过，同时覆盖简繁体）：

背景
排期、时间线、里程碑
UI、设计稿、视觉、視覺、切图
宣发、宣發、推广、推廣
测试、測試、QA
附录、附錄、参考、參考

2.3 用户确认

将过滤结果展示给用户确认：

文档标题：xxx
共 N 个章节，过滤掉 M 个非玩法章节后保留：

保留：
1. 玩法说明
2. 抽奖机制
3. 数值计算
4. 奖励配置

已过滤：[背景介绍, UI稿链接, 排期, ...]

是否继续？（回复 y 继续，或指定需要调整的章节）

等待用户确认后继续。

Step 2.5: 复杂度检测与处理策略选择

2.5.1 评估文档复杂度

读取 /tmp/feishu-requirement-raw.md，统计：

总行数
总字符数
保留章节数量（Step 2 过滤后）
一级章节数量（# 标题）

2.5.2 判断处理策略

简单文档（满足以下任一条件）：

总行数 ≤ 500
总字符数 ≤ 20,000
保留章节数 ≤ 3
一级章节数 ≤ 2

→ 使用 单次全文分析模式（Step 3 原有流程）

复杂文档（不满足上述任一条件）：

总行数 > 500
总字符数 > 20,000
保留章节数 > 3
一级章节数 > 2

→ 使用 分块顺序处理模式（Step 3-Complex）

2.5.3 分块顺序处理模式说明

对于复杂文档，按以下流程处理：

识别顶层分块单元：
- 以一级标题（#）为分块边界
- 记录每个一级章节的起始行号和结束行号
- 每个一级章节包含其下所有二级、三级子章节
逐块处理：
- 按顺序处理每个一级章节
- 每次仅读取当前章节的行范围（使用 Read 工具的 offset/limit 参数）
- 分析当前章节，生成该章节的需求文档片段
- 将片段追加到输出文件（第一块用 Write，后续块用 Edit append）
输出文件结构：
- 第一块：写入完整文档头部（阅读说明 + 模块前缀对照表）+ 第一个模块的分析内容
- 后续块：仅追加新模块的分析内容
- 最后：追加全局 § 待确认表（汇总所有块的待确认项）
状态追踪：
- 维护已处理章节列表
- 维护待确认项累积列表（跨块汇总）
- 维护模块前缀对照表（第一块生成，后续块引用）

Step 3: 逐章节分析（简单文档模式）

仅当 Step 2.5 判定为简单文档时使用此流程。

对保留的每个章节，AI 先判断章节类型，再采用对应分析策略。

重要边界：本 skill 的输出仅来自飞书原文。下列维度由其他源维护，不在本 skill 输出中出现：

客户端 store 字段 / 数据模型

联调接口字段 / 类型定义

群消息完整 schema 字段定义

前端约束（弹窗优先级、动画规范、持久化范围）

横向锚点（Figma / 原型 / 联调引用）

上述内容由 gen-config / gen-logic / 联调文档手动整理 / 活动级 AGENTS.md 等链路负责。

3.1 章节类型判断

玩法类（标题含以下关键词，或 AI 根据内容判断为玩法描述）：

玩法、机制、规则、流程、機制、規則

数值类（标题含以下关键词）：

数值、计算、概率、配置、奖励、档位、數值、計算、獎勵、檔位

混合：既有玩法描述又有数值配置的章节。

3.2 玩法类章节分析

按业务主题归组（通常 2-4 个，简单章节 1 个即可，复杂章节 5 个也可接受），主题名称由 AI 根据内容自行命名。每个主题必须按以下结构化维度组织（不再用纯散文）；下游 gen-logic / gen-config 直接消费各维度。

3.2.1 业务定位（必填，每模块 1 段）

模块在活动中的角色（如"主玩法入口" / "回收闭环" / "付费转化"）
跨模块输入：从哪些模块/动作流入
跨模块输出：流向哪些模块/产物

用于让原型分析与代码生成知道每个模块在数据流中的位置。

3.2.2 核心机制 — if-then 表（必填）

把散文式规则拆为 if-then 行，每行独立可验证。表格列固定如下：

编号	触发	判定	结果
{模块前缀}-M1	【场景简称】用户做了什么 / 什么事件	满足什么条件	什么变化（前端可观测）

字段说明：

「编号」是给下游 agent / 代码生成 / 评审跟踪用的稳定 ID（如 P-M1、B-M3），人类阅读时不必逐个记忆；编号格式 {模块前缀}-M{n}，模块前缀取模块名首字母（如 4.1 获得拼图 → P / Puzzle，4.4 家园建设 → B / Build）
「触发」列必须以 **【场景简称】** 开头（2~6 字中文 slug，加粗）— 让人类一眼读懂规则在说什么，不用看完整行才能理解
- ✅ 好例：**【收礼累计】**用户收到非活动礼物 / **【贡献建材】**用户在领地节点投入 1 份建造材料
- ❌ 差例：用户收到非活动礼物（无 slug）/ **【触发条件】**...（slug 写成废话）
一条规则一行；分支用多行
禁止保留"用户操作路径"等流水账叙述，全部转化为 if-then
跨模块引用一律用编号（如"详见 B-M5"），但首次提及时建议补 slug 提示（如"详见 B-M5【贡献建材】"）

待确认编号同理：{模块前缀}-Q{n}，跨模块引用直接用 ID。

3.2.3 状态枚举（仅当飞书文档涉及状态变化时填）

每个有状态变化的实体单独一段：

实体名：{name}
[初始态] ──{触发}──> [中间态]
[中间态] ──{触发}──> [终态]
副作用：进入/离开某态时触发的可见动作（弹窗、广播、刷新）

飞书未提及状态变化的章节直接省略此节
不要凭空虚构状态机；只记录飞书已写的

3.2.4 跨模块联动（仅当飞书提到时填）

- 触发条件：本模块发生 X
- 影响目标：模块 Y 的 Z 字段/状态

3.2.5 异常与边界（仅当飞书提到时填）

场景	飞书原文表述	处理

仅记录飞书已写的失败/边界情况（如"金币不足时...""活动结束后...""无家族用户..."）
不补充飞书没写的"网络异常"等通用项（那是前端实现侧）

3.2.6 文案要点（必填）

将飞书已经写出的文案条目化抽取，不改写、不创作：

- 标题：{飞书原文}
- 按钮：{飞书原文}
- 规则正文：{飞书原文，编号保留}
- 弹窗/Toast 文案：{飞书原文，含变量占位 {var}}

飞书提到了某条 UI 但没给文案的，标 [占位] 并指明类型（如 [占位 - 标题]）；不要替运营创作。

3.3 数值类章节分析

将数值信息提炼为结构化配置表。输出三类表格：

3.3.1 阈值/档位/限购表

配置项	值	说明

标注关键数值类型：概率、倍率、阈值、档位、消耗、产出、保底、限购、循环

3.3.2 奖池道具表（强约束 — 不可省略 ID 列）

道具 ID	奖励	价值	概率	期望返还
1703650	流星礼物卡（30 金 ×1.4）	42	25%	10.5 金

若某道具有多个子件 ID（如 PLAY 秀礼物卡包含 8 件），用范围或逗号标注（如 1721388~1721395）
若源数据存在全服弹幕 ID（触发全服横幅的道具），移至备注列标注（如 全服弹幕 ID: 1701189）
礼物道具（如幸运大礼物、送礼奖励）同样保留礼物 ID 和主页特效 ID
累充档位奖励、每日任务等非"概率型奖池"表格若源数据无 ID 列，则不强制追加

3.3.3 奖励清单表（必填，跨概率/非概率统一汇总）

将该章节涉及的所有奖励（含奖池产物 + 任务奖 + 累充奖 + 礼包奖等）汇总为一张表：

道具 ID	名称	来源	归属	发放时机	备注
1007	家族资金	抽奖奖池	家族	抽中即时	—
1700021	扭蛋卡	抽奖奖池	族长	抽中即时	—

各列严格定义：

来源：道具从哪个机制产出（如"抽奖奖池"、"图鉴点亮"、"日常任务"、"388 礼包"）
归属：发放对象，固定枚举：个人 / 家族 / 族长 / Top3 个人 / 其他（飞书定义）
发放时机：触发瞬间（如"抽中即时"、"集齐 9 张瞬间"、"活动结束统一结算"）
备注：飞书提到的特殊处理（"触发全服弹幕"、"自动发到背包"、"族长加角标"等）

飞书未明确归属/时机的，标 [待确认] 并加入 §「待确认」表。

3.4 混合章节分析

玩法部分按 3.2 的全部子维度处理（业务定位 / if-then / 状态 / 联动 / 异常 / 文案）
数值部分按 3.3 的三类表（阈值表 / 奖池表 / 奖励清单表）处理

3.5 待确认（每个章节末尾必填）

每章末尾追加一张表，显式列出飞书没写清楚的项，用 ID 跟踪：

ID	问题
{模块前缀}-Q1	例：节点解锁顺序（顺序 vs 任意）未明确
{模块前缀}-Q2	例：奖励 X 归属未明确

AI 自检：if-then 表中每个 [待确认] 标记，必须在此 ID 化跟踪

3.6 活动奖励道具汇总（全文末尾必填）

所有章节分析完成后，在整份需求文档的最后追加 ## 活动奖励道具汇总，汇总本活动原文中出现的全部奖励道具 ID、名称和类型。

道具 ID	道具名称	道具类型	出现位置/来源
1700021	扭蛋卡	prop	家族夺宝奖池（R12）
1211145	家族礼物	gift	家园建设 / 家族常驻礼物
104732	专属称号	title	单个领地贡献 Top3 奖励（R10）

汇总规则：

扫描各模块的 § 奖励清单、奖池表、礼包表、任务奖励、榜单奖励、图鉴奖励及原文资源汇总表，不遗漏仅在附表中出现的奖励道具
按 道具 ID 去重；同一 ID 在多个模块出现时合并「出现位置/来源」，不得重复成多行
「出现位置/来源」必须写业务可读来源名称，例如 777 金币礼盒奖池（R6）、金矿石兑换商店（R11）、家族夺宝奖池（R12）、图鉴奖励（R1/R5）；禁止只写 R1、R6/R11、玩法总览 这类无法直接判断产出场景的占位
R 编号只能作为回溯辅助放在来源名称后括号内；若同一 ID 多处出现，用 / 合并可读来源，例如 777 金币礼盒奖池（R6） / 金矿石兑换商店（R11）
每一行只能填写一个纯数字 道具 ID；禁止在同一个 道具 ID 单元格里使用 /、,、，、、、顿号或空格并列多个 ID
多个子件 ID 不可只保留范围描述；原文逐项给出 ID 时必须逐行列出，原文仅给出范围时保留范围并在来源中注明
即使多个 ID 名称相同、属于同一礼包、同一对男女奖励、同一弹幕/戒指组合、同一商店分组或同一宝箱系列，也必须拆成多行。错误：1713058 / 1713063 | 星辰流光戒指 | prop | R1；正确：1713058 | 星辰流光戒指 | prop | R1 和 1713063 | 星辰流光戒指全服弹幕 | prop | R1
道具类型只能使用固定英文枚举：prop / title / gift / avatar_prop / avatar_exp
若飞书原文包含自动道具分组，按字段直接映射：__autoProps.prop → prop，__autoProps.title → title，__autoProps.gift → gift，__autoProps.avatar_prop → avatar_prop，__autoProps.avatar_exp → avatar_exp
原文未明确分组时，按以下优先级保守分类：
- gift：文档中有明显礼物指向模块/来源，或名称包含礼物、礼物卡、礼盒礼物、家族礼物等礼物语义
- title：名称包含称号；或位于 title/称号模块且 ID 通常为 6 位数字。不得仅凭 6 位 ID 单独判为称号
- avatar_prop / avatar_exp：名称、原文类型或来源有明显 avatar 暗示；明确为 avatar 经验或 avatar_exp 时归为 avatar_exp
- prop：除以上明确类型外，其他奖励统一归为 prop
头像框、座驾、语音房背景、语音房气泡、印记、戒指、装扮、特效等中文资源名默认属于 prop；只有出现明显 avatar 暗示或 __autoProps.avatar_prop 分组依据时，才归为 avatar_prop
不得输出 货币、家族道具、礼物卡、礼包、材料、头像框、座驾、装扮、特效、其他、道具、称号、礼物、avatar道具、avatarexp 等枚举外类型
只收录飞书原文明确给出 ID 的奖励道具；没有 ID 的奖励不得虚构 ID，也不以 [待确认] 占位混入 ID 汇总表
非奖励用途的 ID（活动 ID、话题 ID、消息 ID、页面 ID、埋点 ID 等）不得收录
该表必须是需求文档的最后一个章节；简单文档和复杂文档均必须生成

Step 3-Complex: 分块顺序处理（复杂文档模式）

仅当 Step 2.5 判定为复杂文档时使用此流程。

3C.1 识别章节边界

扫描 /tmp/feishu-requirement-raw.md，记录所有一级标题（#）的位置：

章节列表：
- 章节1: "# 一、基础信息" (行 1-50)
- 章节2: "# 二、变更记录" (行 51-100)
- 章节3: "# 三、玩法说明" (行 101-500)
- 章节4: "# 四、数值配置" (行 501-800)
...

3C.2 过滤保留章节

根据 Step 2 的过滤结果，仅保留需要分析的一级章节。

3C.3 初始化输出文件

第一块处理前，先生成文档头部：

读取第一个保留章节的内容（使用 offset/limit）
分析该章节，提取模块信息
生成模块前缀对照表

写入输出文件：

# [活动名称] 需求分析

## 阅读说明

[标准阅读说明内容]

## 模块前缀对照表

[根据第一块内容生成的前缀表]

---

## [第一个模块名称]

[第一块的分析内容]

3C.4 逐块处理后续章节

对于每个后续保留章节：

读取章节内容：

# 使用 Read 工具的 offset/limit 参数
Read /tmp/feishu-requirement-raw.md offset=<起始行> limit=<行数>

分析章节：
- 按 Step 3.1-3.3 的分析策略处理
- 生成该章节的需求文档片段
- 收集待确认项
追加到输出文件：

CRITICAL: 必须使用 Bash heredoc append 策略，禁止使用 Edit 工具追加

原因：Edit 工具在大文件中容易因 old_string 匹配失败而出错，Bash heredoc 更稳定。
```
# 使用 cat >> 追加内容（heredoc 方式）
cat >> <输出文件路径> << 'EOF'

---

## [新模块名称]

[新模块的分析内容，每次追加控制在 ~100 行以内]

EOF
```
分块追加规则：
- 如果单个模块内容超过 100 行，拆分为多次 cat >> 调用
- 每次 heredoc 内容保持在 ~100 行以内，避免工具参数限制
- 使用 'EOF' 而非 EOF，防止变量展开
更新模块前缀表（如有新模块）：
- 如果当前块引入了新的模块前缀
- 使用 Edit 工具回到文件开头，更新模块前缀对照表
- 仅更新前缀表时可以使用 Edit，因为前缀表位置固定且内容较小

3C.5 汇总待确认项

所有块处理完成后：

汇总所有块收集的待确认项

追加全局 § 待确认表到文件末尾：

---

## 待确认汇总

| 编号 | 所属模块 | 问题描述 | 影响范围 |
|------|---------|---------|---------|
| Q-1  | [模块名] | [问题]   | [影响]   |
...

3C.6 进度反馈

每处理完一个块，向用户报告进度：

✓ 已完成 [章节名称] (1/4)
✓ 已完成 [章节名称] (2/4)
...

3C.7 复杂文档处理最佳实践

基于实际案例总结的关键经验：

分块读取策略：
- 使用 Read 工具的 offset 和 limit 参数分块读取源文档
- 每次读取 200-400 行为宜，避免单次读取过大导致 token 消耗过高
- 记录每个一级章节的起始行号和结束行号，按边界精确读取
Bash heredoc 追加策略（已验证最稳定）：
- 禁止使用 Edit 工具追加大段内容（容易因 old_string 匹配失败）
- 禁止使用 Write 工具的 content 参数传递大段内容（会触发参数大小限制）
- 必须使用 cat >> file << 'EOF' 方式追加
- 每次 heredoc 内容控制在 ~100 行以内
- 使用 'EOF' 而非 EOF，防止 shell 变量展开
错误恢复：
- 如果某次追加失败，不要重试整个文档，只重试当前块
- 使用 wc -l 验证文件行数，确认追加成功
- 保留 /tmp/feishu-requirement-raw.md 作为源文件备份
性能优化：
- 复杂文档（1800+ 行）预计耗时 10-15 分钟
- Token 消耗约 200,000-250,000（输入 + 输出）
- 成本约 $1.3-1.5（基于 Claude Sonnet 4.6 定价）
质量保证：
- 每个模块完成后立即追加，不要累积多个模块再一次性写入
- 最后生成全局待确认汇总表，汇总所有模块的待确认项
- 使用模块前缀 ID 系统（{前缀}-M{n} / {前缀}-Q{n}）确保可追溯性

Step 4: 写入文件

4.1 创建输出目录

mkdir -p {活动目录路径}/requirements/feishu

4.2 写入需求文档

简单文档模式：将所有章节的分析结果一次性写入 {活动目录路径}/requirements/feishu/{文档标题}.md。

复杂文档模式：在 Step 3-Complex 中已逐块写入和追加，此步骤跳过。

文档标题从飞书文档标题提取，去除特殊字符。

4.2.1 输出模板

# {活动名} 需求分析

> 来源：{飞书文档链接}
> 生成时间：YYYY-MM-DD

---

## 阅读说明

本文档使用稳定 ID 标记每条业务规则与待确认问题，便于下游 agent / 代码生成 / 评审跟踪：

- **机制 ID**：`{模块前缀}-M{n}` 表示该模块第 n 条业务规则（M = Mechanic）
- **待确认 ID**：`{模块前缀}-Q{n}` 表示该模块第 n 个待确认问题（Q = Question）
- **模块前缀**：取模块名首字母，如 4.1 获得拼图 → `P` / 4.2 图鉴收集 → `C` / 4.4 家园建设 → `B` 等（每个文档头会列出本次实际使用的前缀对照）
- **跨模块引用**：直接写 ID（如 `B-Q10`）即可定位

人类阅读 if-then 表时主要看「触发」列开头加粗的 **【场景简称】**，编号本身不必记忆；编号是给评审协作和代码生成机器消费的。

**本文档模块前缀对照：**

| 前缀 | 模块号 | 模块名（含义）        |
| ---- | ------ | --------------------- |
| {P}  | {4.1}  | {Puzzle / 模块名}     |
| {C}  | {4.2}  | {Collection / 模块名} |
| ...  | ...    | ...                   |

> 「模块号」即飞书原文里该模块的标题序号（如 4.1 / 4.2 / 附录 B 等），便于回溯飞书原文定位。

---

## {章节名 1}（玩法类 / 数值类 / 混合）

### 业务定位

- 角色：...
- 输入：...
- 输出：...

### 核心机制（if-then）

| 编号 | 触发                | 判定 | 结果 |
| ---- | ------------------- | ---- | ---- |
| X-M1 | **【场景简称】**... | ...  | ...  |

### 状态枚举

（仅当飞书涉及状态变化时出现，否则省略此小节）
实体：{name}

写入前先确保目录存在：

mkdir -p {活动目录路径}/requirements/feishu

[态 A] ──{触发}──> [态 B] 副作用：...


### 跨模块联动
（仅当飞书提到时出现）
- 触发：...
- 影响：...

### 数值配置
| 配置项 | 值 | 说明 |
|---|---|---|

**奖池表（如有）：**
| 道具 ID | 奖励 | 价值 | 概率 | 期望返还 |
|---|---|---|---|---|

### 奖励清单
| 道具 ID | 名称 | 来源 | 归属 | 发放时机 | 备注 |
|---|---|---|---|---|---|

### 文案要点
- 标题：...
- 按钮：...
- 规则正文：...
- Toast/弹窗：...（含 [占位] 标记）

### 异常与边界
（仅当飞书提到时出现）
| 场景 | 飞书原文 | 处理 |
|---|---|---|

### 待确认
| ID | 问题 | 责任方 |
|---|---|---|
| X-Q1 | ... | 产品 |

---

## {章节名2}
（同上结构）

4.2.2 自检清单（写入前必过）

写入完成后，输出确认：

需求分析完成！文档已保存到：{活动目录路径}/requirements/feishu/{文档标题}.md

摘要：
- 分析了 N 个章节（玩法类 X 个，数值类 Y 个，混合 Z 个）
- 已过滤 M 个非玩法章节
- 共提取 if-then 规则 X 条 / 状态机 Y 个 / 奖励 Z 项 / 待确认 W 项

Step 5: 更新 AGENTS.md

文档生成完成后，自动更新活动级 AGENTS.md 中的「需求文档」表格：

使用 agents-md skill 的「需求文档自动更新」流程
扫描 {活动目录路径}/requirements/feishu/ 目录
在活动 AGENTS.md 的「需求文档」表格中追加新生成的文档条目
如果活动目录下没有 AGENTS.md，提示用户是否创建

约束

复用 feishu2md 脚本 — 不重新实现飞书 API 调用，直接调用 .claude/skills/feishu2md/scripts/feishu2md.py
用户确认节点 — 章节过滤结果必须让用户确认后再继续
章节类型自动判断 — AI 根据标题关键词 + 内容特征判断，不要求用户手动标注
输出对齐现有 skill 链路 — 玩法归组格式与 modao-analyze 一致（业务主题归组），数值表格格式统一（配置项/值/说明三列），可被 gen-code 直接消费
过滤支持简繁体 — 排除关键词和章节类型关键词同时覆盖简体和繁体
奖池道具 ID 不可省略 — 概率型奖池表格（C/B/A/S 级奖池、礼盒奖池、盲盒奖池等）必须保留原始道具 ID 列（第一列），下游 gen-code 依赖这些 ID 配置服务端，丢失后无法还原
结构化优先于散文 — 业务规则全部转 if-then 表；状态变化全部转状态机块；奖励全部转奖励清单表。禁止保留散文式叙事描述（"用户操作路径..."、"主流程是这样..."等）作为主要载体
来源边界清晰 — skill 输出仅来自飞书原文，禁止引入：
- 客户端 store 字段 / 数据模型（前端实现）
- 联调接口字段 / 类型定义（联调文档负责）
- 群消息完整 schema（联调产物）
- 前端约束（弹窗优先级、动画规范、持久化范围）
- 横向锚点（Figma / 原型 / 联调引用）原型分析中暴露但飞书没写的内容，标 [待确认] 加入 § 待确认表，不要在文档里替运营/产品/数值创作
未涉及不留空段 — § 状态枚举 / § 跨模块联动 / § 异常与边界三节仅在飞书涉及时出现；未涉及时整段省略，不要写"无"或保留空表

How can the creator link this skill?

Add the canonical catalog link to the repository README so users can inspect current installs and available audits. The publishing guide covers the complete discovery path.

<a href="https://skillzs.dev/skills/mercury-api.wepieoa.com/fe-feishu-requirement">View feishu-requirement on skillZs</a>