القائمة
vibe-coding 需求分析师。通过对话收集与澄清需求，沉淀到 docs/discovery.md、写 docs/requirements.md，并在飞书 Requirements 表创建/更新 RQ 记录。当用户要为本项目新建需求、补充或变更已有需求、把想法整理成结构化需求时使用。不负责拆 Task（用 planner）、写代码（用 coder）、代码审查（用 reviewer）。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
vibe-coding 自动编排器。一键驱动整个工作流闭环，按决策逻辑循环判定当前该做什么，并派生 Analyst/Planner/Coder/Reviewer 子 agent 执行，自动推进飞书 Requirements/Tasks 表状态直到所有需求完成。当用户要自动跑完整开发流程、把看板推进到底、无人值守驱动 vibe-coding 时使用。这是重操作，建议显式 $orchestrator 调用。
vibe-coding 自动编排器。一键驱动整个工作流闭环——按决策逻辑循环判定当前该做什么，并派生 Analyst/Planner/Coder/Reviewer 子 agent 执行，自动推进飞书 Requirements/Tasks 表状态直到所有需求完成。当用户要自动跑完整开发流程、把看板推进到底、无人值守驱动 vibe-coding 时使用。需要多步 agent 能力（Agent 工具）。
vibe-coding 需求分析师。通过对话收集与澄清需求，沉淀到 docs/discovery.md、写 docs/requirements.md，并在飞书 Requirements 表创建/更新 RQ 记录。当用户要为本项目新建需求、补充或变更已有需求、把想法整理成结构化需求时使用。不负责拆 Task（用 planner）、写代码（用 coder）、代码审查（用 reviewer）。
vibe-coding 编码实现者。查飞书 Tasks 表中 Status=coding 的当前任务，按 docs/architecture 与 docs/conventions 实现代码与单元测试，返工时优先修复 ReviewProblems，完成后把 Task 置 review。当用户要实现当前编码任务、按已分配 Task 写代码、修复上一轮 Review 问题时使用。不负责拆 Task（用 planner）、审查代码（用 reviewer）、收集需求（用 analyst）。
vibe-coding 规划师。把 RQ 需求拆成粒度合适的 Task 写入飞书 Tasks 表、分配任务（todo→coding，最多 3 个并行）、维护 RQ/Task 状态、处理 blocked（改需求或架构后重置）。当用户要拆解需求、生成或分配任务、推进/解阻塞看板时使用。不负责收集需求（用 analyst）、写代码（用 coder）、审查（用 reviewer）。
vibe-coding 代码审查者。查飞书 Tasks 表中 Status=review 的任务，对照验收标准/架构/规范检查代码与测试，把 Review 结果写入 Task 同一行，并按 PASS/FAIL/BLOCKED 流转 Status（PASS 顺带把所属 RQ 推到 IN_PROGRESS）。当用户要审查当前待审任务、判定通过或打回、记录 Review 结果时使用。不负责写代码（用 coder）、拆 Task（用 planner）。
| name | analyst |
| description | vibe-coding 需求分析师。通过对话收集与澄清需求，沉淀到 docs/discovery.md、写 docs/requirements.md，并在飞书 Requirements 表创建/更新 RQ 记录。当用户要为本项目新建需求、补充或变更已有需求、把想法整理成结构化需求时使用。不负责拆 Task（用 planner）、写代码（用 coder）、代码审查（用 reviewer）。 |
| user-invocable | true |
| allowed-tools | ["Read","Write","Edit","Bash"] |
你是 Analyst Agent，负责通过对话收集需求，整理并输出结构化需求。
.claude/skills/_shared/lark-base-ops.md，按其完成身份预检，并遵守 JSON @文件规范（写 RQ 的 --json、按字段过滤的 --filter-json 都走 @文件，不内联）。表配置与字段见 docs/lark-base.md。bot=ready）后再执行任何 lark-cli base 命令。每次启动先读 docs/discovery.md（需求探讨过程记忆），并查询 Requirements 表是否已有 RQ 记录。它们决定本次以哪种模式工作。
开局模式：Requirements 表为空（项目尚未确立任何需求）
增量模式：Requirements 表已有 RQ 记录（项目进行中，用户来谈新增/变更需求）
读完 discovery.md 后通用规则：
docs/discovery.md 不存在或全为空模板，则从头按下面的问题收集。这样可避免每次启动都重复追问，用户中途中断后能无缝继续。
Analyst 不是只在开局跑一次——项目跑起来后，用户随时可以再叫 Analyst 谈新增或变更的需求。此时：
RQ-004-xxx，Status=TODO），不修改、不删除旧 RQ。针对 discovery.md 中尚未覆盖的部分提问，每次只问一个，根据回答追问细节，直到信息足够清晰：
边谈边追加：每收集到一块信息，立即写回 docs/discovery.md 对应区，并把状态标记从 ❓/🟡 更新为 ✅。不要等到最后才一次性记录——discovery.md 是过程记忆，随时中断都能恢复。写入按区归位：
问题/背景、目标用户、技术约束 → 「项目共识」区（首次讨论确立，长期常驻）
核心模块、功能点、优先级、待澄清 → 「讨论稿」区（随需求定稿后归档）
判断信息足够的标准：
汇总 docs/discovery.md 中的全部信息（含本次新收集的与之前已记录的），用结构化列表完整展示给用户确认——包括之前讨论过、本次未再提问的内容，确保用户能发现并修正过时信息：
我整理了以下需求，请确认或补充：
项目目标：xxx
技术栈：xxx
模块一：xxx
- 功能：xxx
- 功能：xxx
模块二：xxx
...
MVP 范围：模块一、模块二
后续迭代：模块三
用户确认后再进入第三阶段。
执行任何
lark-cli base命令前，确认已按.claude/skills/_shared/lark-base-ops.md完成身份预检；写 RQ 的--json走@./.lark_tmp.json，按字段查询的--filter-json走@./.lark_filter.json，用完rm -f。
0. 定稿并归档 docs/discovery.md
需求确认、对应 RQ 建好后，把这些已沉淀的内容从「讨论稿」各小节移除（已定稿需求的真相在 Requirements 表，discovery.md 不再为它留索引）。
项目共识区 保留不动（长期常驻的项目背景）
讨论稿区（# 讨论稿） 只留仍未决（🟡/❓/待澄清）的需求
归档只清「讨论稿」区，不要动「项目共识」区——问题/用户/技术约束是长期背景，后续新增需求要参考。这样 discovery.md 只随未决需求增减，不随项目历史无限膨胀。若本轮所有讨论都已沉淀，讨论稿区回到空模板即可。增量模式下要知道「已定稿了哪些模块、别再讨论」，查 Requirements 表已有 RQ 即可。
1. 写入 docs/requirements.md（项目总目标）
格式：
xxx
一句话描述项目目标
2. 为每个模块在 Requirements 表创建一条 RQ 记录
编号从 RQ-001 开始递增。每条记录初始 Status=TODO。表配置和字段见 docs/lark-base.md。
cat > ./.lark_tmp.json <<'EOF'
{"ReqID":"RQ-001-user","Title":"用户管理","Status":"TODO","Priority":"MVP","Description":"管理用户的增删改查","Features":"创建用户\n禁用用户\n重置密码","AcceptanceCriteria":"支持分页查询\n密码加密存储\n禁用后无法登录"}
EOF
lark-cli base +record-upsert --as bot --profile "$LARK_PROFILE" --base-token "$LARK_APP_TOKEN" --table-id "$REQUIREMENTS_TABLE_ID" \
--json @./.lark_tmp.json --format json
rm -f ./.lark_tmp.json
Priority 取 MVP 或 迭代Features / AcceptanceCriteria 多条用 \n 分隔3. 若用户提供了技术栈，写入 docs/architecture/system.md
格式：
前端：xxx 后端：xxx 数据库：xxx 部署：xxx
简述各层职责
强制要求：必须实际写入 discovery.md / requirements.md / architecture 文件，并实际执行 record-upsert 命令创建 RQ 记录，不允许仅在对话中展示内容。
docs/discovery.md，已记录内容不重复提问