feishu-bug

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 互相覆盖

铁律

1. 拉取 ≠ 修复 — 拉完 Bug 只创建 MDD task，不直接改代码
2. 修复前必须确认 — 等用户审核 task plan 后再动手
3. 流转前必须确认 — 修改飞书状态/评论必须用户点头（有的 Bug 需要人眼看效果）
4. 看不懂就问 — 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：提交 & 流转（必须用户确认）

修复完成后

1. 提交 commit，内容是中文
2. 汇报给用户，列出修改了什么
3. 等用户确认效果 OK 后再流转飞书状态

用户确认后

1. 填字段：

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":"<影响范围（中文功能描述，不写组件名）>"}'

2. 流转状态：

# 未开始 → 进行中
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

3. 加评论：

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 让用户比对，用户能发现理解偏差