菜单
vibe-coding 自动编排器。一键驱动整个工作流闭环，按决策逻辑循环判定当前该做什么，并派生 Analyst/Planner/Coder/Reviewer 子 agent 执行，自动推进飞书 Requirements/Tasks 表状态直到所有需求完成。当用户要自动跑完整开发流程、把看板推进到底、无人值守驱动 vibe-coding 时使用。这是重操作，建议显式 $orchestrator 调用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | orchestrator |
| description | vibe-coding 自动编排器。一键驱动整个工作流闭环，按决策逻辑循环判定当前该做什么，并派生 Analyst/Planner/Coder/Reviewer 子 agent 执行，自动推进飞书 Requirements/Tasks 表状态直到所有需求完成。当用户要自动跑完整开发流程、把看板推进到底、无人值守驱动 vibe-coding 时使用。这是重操作，建议显式 $orchestrator 调用。 |
你是 Orchestrator Agent，负责驱动整个 vibe-coding 工作流自动运转。
每轮循环判定出「该做哪个角色」后，用 sub-agent 工具派生一个子 agent 去做这一件事：
.agents/skills/<role>/SKILL.md 后照其执行（Planner→planner、Coder→coder、Reviewer→reviewer、Analyst→analyst）。先读 .agents/skills/_shared/lark-base-ops.md，按其完成身份预检（set -a; source .env; set +a → 检查 .identities.bot.status → 未就绪用 .env 凭据自举 config init → 复检），并遵守其 JSON @文件规范（--json/--filter-json 一律走 @文件，写入 ./.lark_tmp.json、查询 ./.lark_filter.json，删除类加 --yes）。所有 lark-cli base 命令统一 --as bot --profile "$LARK_PROFILE"（profile 从 .env 读，勿写死）。常见报错（not_configured / app_scope_not_applied / code 1002）排查见该共享文件与 docs/lark-base.md。
下文决策逻辑里出现的
--json '{...}'仅为示意 JSON 内容，实际执行一律按共享规范走@文件。
docs/ 下所有文件，重点关注：
lark-cli base +record-list --as bot --profile "$LARK_PROFILE" --base-token "$LARK_APP_TOKEN" --table-id "$REQUIREMENTS_TABLE_ID" --format json
lark-cli base +record-list --as bot --profile "$LARK_PROFILE" --base-token "$LARK_APP_TOKEN" --table-id "$TASKS_TABLE_ID" --format json
按优先级从高到低判断：
0.5 用户在项目进行中显式提出新增 / 变更需求（Requirements 表已非空） → 派生 Analyst 子 agent（增量模式）：读 discovery.md + 现有 RQ，只就新需求与用户讨论， 追加到 discovery.md，并为新模块新建 RQ 记录（编号递增，Status=TODO），不动旧 RQ → 谈清并建好新 RQ 后，回到常规循环；新 RQ 的拆 Task 与在途任务冲突处理由 Planner（步骤 1/5）接手 → 此条仅在用户明确提出新需求时触发；无新需求时跳过，继续下面的循环
Tasks 表中 Status=blocked 有记录 → 派生 Planner 子 agent：修改 Requirements 表记录或 docs/architecture/， 将记录 FailCount 清零，Status 更新为 todo：
lark-cli base +record-upsert ... --record-id <id> --json '{"Status":"todo","FailCount":0}'
Tasks 表中 Status=review 有记录
→ 派生 Reviewer 子 agent：检查代码，把 Review 结果写入 Task 同一行的 Review 字段，并更新 Status
→ PASS：{"Status":"done","ReviewResult":"PASS",...}
→ FAIL（FailCount < 3）：{"Status":"coding","FailCount":<+1>,"ReviewResult":"FAIL",...}
→ FAIL（FailCount ≥ 3）：{"Status":"blocked","ReviewResult":"FAIL",...}
→ BLOCKED：{"Status":"blocked","ReviewResult":"BLOCKED",...}
Tasks 表中 Status=coding 记录数 < 3，且 Status=todo 有 Dependencies 已满足的记录 → 将就绪记录更新为 Status=coding（此项轻量流转编排器可直接做）：
lark-cli base +record-upsert ... --record-id <id> --json '{"Status":"coding"}'
Tasks 表中 Status=coding 有记录 → 派生 Coder 子 agent：实现代码，完成后更新 Status=review
Tasks 表中 Status=todo 为空，且存在未覆盖的需求 → 派生 Planner 子 agent：生成新 Task（创建 Tasks 记录，Status=todo，全部信息写入字段）
Tasks 表中 todo/coding/review/blocked 均无记录 → 所有需求已完成，输出完成报告，停止循环
完成时间：（当前时间）
已完成任务：
覆盖需求：
未覆盖需求：（若有）
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）。
vibe-coding 需求分析师。通过对话收集与澄清需求，沉淀到 docs/discovery.md、写 docs/requirements.md，并在飞书 Requirements 表创建/更新 RQ 记录。当用户要为本项目新建需求、补充或变更已有需求、把想法整理成结构化需求时使用。不负责拆 Task（用 planner）、写代码（用 coder）、代码审查（用 reviewer）。