| name | feishu-bug |
| description | 飞书 Bug 全流程管理。这是与飞书项目 Bug 交互的唯一入口。
MUST INVOKE THIS SKILL when 用户提到 Bug、飞书项目、meegle、查bug、拉bug、同步bug、
看看bug、fetch bugs、新bug、bug列表、bug状态、流转bug、修bug、修复bug、
有没有bug、有什么bug、bug还有多少、待测试、未开始、进行中。
禁止直接调用 meegle 命令，必须先经过本 Skill。
|
飞书 Bug 工作流
多人使用说明
本 Skill 面向所有前端研发人员使用，查询逻辑是动态的：
- MQL 使用
current_login_user() 函数，谁登录就拉谁的 Bug
- 每个同事先执行
meegle auth login --device-code --host project.feishu.cn 登录自己的飞书账号
docs/bugs.md 记录的是当前登录人的 Bug 列表，每次拉取会刷新为登录人的数据- 项目 repo 中建议每人用自己的分支，避免
docs/bugs.md 互相覆盖
铁律
- 拉取 ≠ 修复 — 拉完 Bug 只创建 MDD task，不直接改代码
- 修复前必须确认 — 等用户审核 task plan 后再动手
- 流转前必须确认 — 修改飞书状态/评论必须用户点头（有的 Bug 需要人眼看效果）
- 看不懂就问 — Bug 描述不清晰时先拉评论和图片，搞清楚再写 task
Phase 1：拉取 Bug
Step 1.1：认证检查
meegle auth status
非 authenticated 则走 meegle auth login --device-code --host project.feishu.cn。
Step 1.2：查询 Bug
对以下项目空间逐个查询 Bug（与 sync-workhours 源项目一致）：
| 项目 key | 项目名称 |
|---|
8qo9g3 | 星云具身智能体开放平台（默认） |
youling_external_project | 有灵外部项目 |
yunjie | 云界 |
youyan | 有言 AIGC 视频创作 |
meegle workitem query --project-key <project_key> \
--mql "SELECT \`work_item_id\`, \`name\`, \`work_item_status\`, \`priority\`, \`current_status_operator\`, \`start_time\`, \`severity\`, \`bug_classification\` FROM \`<project_key>\`.\`Bug\` WHERE array_contains(\`current_status_operator\`, current_login_user()) ORDER BY \`start_time\` DESC LIMIT 50" \
--format json
默认从 8qo9g3 开始，用户可指定项目或全部查询。
Step 1.3：获取详情和评论
对每个未解决的 Bug（状态为"未开始"/"进行中"/"重新解决"），拉取详情和评论：
meegle workitem get --project-key <project_key> --work-item-id <id>
meegle comment list --project-key <project_key> --work-item-id <id>
评论中有图片时下载查看。
Step 1.4：生成 docs/bugs.md
按以下格式更新：
# Bug 列表
> 查询范围：youling_external_project, 8qo9g3, yunjie, youyan
> 查询时间：<当前日期>
| # | 项目 | 工作项 ID | 标题 | 优先级 | 严重程度 | Bug 类型 | 状态 | 提出时间 |
|---|------|----------|------|--------|----------|----------|------|----------|
共 N 个 Bug：X 个未开始，Y 个待测试，Z 个老 Bug。
按状态排序：未开始/进行中/重新解决 > 待测试 > 已完成/已关闭。
只列出未解决的 Bug（状态不是"已完成"/"已关闭"/"关闭"的）。
Phase 2：创建 MDD Task
对每个未解决的 Bug，用 MDD 流程创建独立 task 文件：docs/refactor/tasks/bug-<id>.md。
Task 文件模板
# Bug <id>：<标题>
**状态：** 🔴 待开始
**飞书链接：** https://project.feishu.cn/<project_key>/issue/detail/<id>
**预估影响范围：** <待分析>
## 问题描述
<从飞书详情和评论中提取的问题描述>
## 飞书评论摘要
<关键评论和图片描述>
## 根因分析
<!-- Claude 分析后填写 -->
## 修复方案
<!-- Claude 分析后填写，等用户确认 -->
## 约束
- 修根因不修症状
- 不改无关代码
- 修复后需人工视觉验证
## 执行步骤
<!-- 用户确认后填写 -->
## 验收标准
- [ ] TypeScript 类型检查通过
- [ ] 构建成功
## 完成记录
- **完成时间：** —
- **影响范围：** —
- **验证结果：** —
## 待确认
<!-- Claude 不确定的地方在此追加 -->
## 流转信息
- **自测结论：** <!-- 用户确认后填写 -->
- **影响范围：** <!-- 用户确认后填写，用中文功能描述，不写组件名 -->
创建完所有 Task 后汇报
告诉用户：
- 新增了哪些 Bug
- 已关闭/通过的 Bug 有哪些（不需要处理）
- 每个 Bug 的 task 文件路径
- 强调：需要用户 review task plan 之后再开始修
Phase 3：修复 Bug
等用户确认 task plan 后，按 MDD 流程执行 /mdd run bug-<id>。
必须在 task 文件中先填写根因分析和修复方案，等用户确认后再改代码。
Phase 4：提交 & 流转（必须用户确认）
修复完成后
- 提交 commit，内容是中文
- 汇报给用户，列出修改了什么
- 等用户确认效果 OK 后再流转飞书状态
用户确认后
- 填字段：
meegle workitem update --project-key <project_key> --work-item-id <id> \
--fields '{"field_key":"field_2aa3c4","field_value":"<开发自测结论>"}' \
--fields '{"field_key":"field_4cd554","field_value":"<影响范围（中文功能描述，不写组件名）>"}'
- 流转状态：
meegle workflow transition-state --project-key <project_key> --work-item-id <id> --transition-id 27686542
meegle workflow transition-state --project-key <project_key> --work-item-id <id> --transition-id 27686547
- 加评论：
meegle comment add --project-key <project_key> --work-item-id <id> \
--content "**根因**: ... **修复**: ..."
评论规范：
- 只写根因和修复方案
- 不写修改了哪些文件
- 影响范围用中文功能描述，不写组件名或文件路径
状态流转速查
| 当前状态 | 目标状态 | transition_id | 需要填的字段 |
|---|
| 未开始 | 进行中 | 27686542 | 无 |
| 进行中 | 待测试 | 27686547 | field_2aa3c4（开发自测结论）、field_4cd554（bug 影响范围） |
| 重新解决 | 待测试 | 27686557 | 无（但建议填上面两个字段） |
反模式
- ❌ 拉完 Bug 就改代码 — 先创建 task plan 让用户 review
- ❌ 没搞清楚问题就修 — 先看评论和图片
- ❌ 修完就流转 — 等用户确认效果
- ❌ 评论里写组件名/文件路径 — 用中文功能描述
- ❌ 自测结论写在流转前 — 先问用户要不要流转
- ❌ 理解错 Bug 就动手 — 创建 task 让用户比对，用户能发现理解偏差
