bb-spec-workflow

Plugin bb-spec-workflow from marketplace 0xbb2b in 0xBB2B/bb-spec. Commands read from the repo's manifest — 3 days ago.

Skills (10)

• doc-update

  文档与代码一致性维护——代码是事实，让仓库根目录下名单固定的根文档（README*.md、CLAUDE.md、AGENTS.md、CONTRIBUTING.md、ARCHITECTURE.md、DESIGN.md，名单外的文档不碰）追平代码现状（项目根没有 ARCHITECTURE.md 大纲时，全仓模式读代码起草），并检查代码是否违反 AGENTS.md 项目约束；/exec 与 /revise 收尾时以 --tail 收尾模式自动调用，额外核对本分支 PRD 与实际交付是否一致；已合并的 PRD 任何模式都不碰；改代码一律先问用户、转 /revise。触发：/doc-update、文档和代

• exec

  三 Agent 隔离执行 plan——由 /plan 自动调用或手动 /exec 续接；Test→Impl→Review 串行，三方各只看各的输入互不可见；互不依赖且文件目录不重叠的 plan 编为并行组并发推进；每步立即持久化 PROGRESS.md，跨会话/`/clear` 后从断点续接；启动先 worktree 感知定位执行现场（主仓库停在 main 时自动定位到进行中的 worktree）；全部完成后自动运行 /doc-update 收尾模式让本次 PRD 与 README 等文档追平代码、删除本次 plan 目录；收尾把无关发现合成一张清单一次问；每个 commit 带 `Requi

• git-clone

  把一个或多个远程仓库 clone 到本地并落 .bb-spec.yaml——先 AskUserQuestion 询问「单 repo 还是多 repo 工作区」+「base_dir 用默认还是自定义」；多 repo 模式建统一父目录 + 各成员独立 clone（不嵌套）+ 可选生成 workspace 根文件；落盘后写入 .bb-spec.yaml（base_dir 字段）。触发：clone 一下、把项目拉下来、初始化本地副本、新机器拉代码、接入 bb-spec 工作流。跳过：仓库已存在于目标路径（应走 git pull / 重置而非重新 clone）、纯私有 fork 临时实验（用裸 git

• git-push

  推送本地代码到远程并开 PR 全流程——识别仓库→确认分支（worktree 模式自动定位目标分支）→提交未暂存改动（禁 git add .）→同步基线（origin+upstream 双 remote 时先问合并对象、默认 origin/main；分支落后基线则 rebase）→本机装了 ocr 则跑一次 ocr review，Claude 逐条读代码核实后按 🔴/🔶/🔷 列出建议修复项、用户勾选后交 /revise 修→在同步后的代码上跑全量测试→若存在 AGENTS.md、本分支有新增 PRD 或本分支 commit 指向已合并 PRD 则 subagent 比对项目约束、PRD

• plan

  读本分支 PRD + 项目代码结构产出函数级实施计划——由 /prd 在用户读完 PRD 确认通过后自动调用，直接落盘到 .bb-spec/docs/plan/<日期>.<主题>/ 后自动运行 /exec，只在需要引入新技术时停下问用户；启动先 worktree 感知定位 plan 现场（主仓库停在 main 时自动定位到进行中的 worktree）；过程式只到函数级，声明式产物（DDL/API 契约/配置）必须内联完整成品。触发：/plan、生成实施计划、怎么落地这个 PRD。跳过：还没 PRD（→/prd）、本分支没有新 PRD。

• prd

  新需求的唯一入口——质疑→澄清→拆解，对话阶段只读对齐（涉及界面时先出 HTML 预览页请用户确认），对齐后落盘 PRD（.bb-spec/docs/prd/<日期>.<主题>/，写「为什么」与可测的约束和验收；本分支内可改、合并后冻结）与项目级约束（项目根 AGENTS.md，含"先读代码再回答"的查询规矩），弹窗请用户读完 PRD、确认通过后自动依次运行 /plan → /exec（/exec 收尾自动 /doc-update）；之后每个 commit 带 `Requirement: <PRD 目录名>` 标记，代码经 git 可反查回 PRD。触发：/prd、新需求、新增功能、改已合并功

• prototype

  界面原型的唯一规程——出原型和对比都派原型子代理做，主对话只派工和传话，先读项目根目录的 DESIGN.md（没有就起草、不达标就先补齐，都经用户确认，新建和修改都画成展示页给用户看），按 DESIGN.md 画出改动所在的整个页面，缺的只读对应源码，源码定不下来才问用户要不要跑服务；用统一的蓝图外壳出 HTML 原型：左栏切页面和状态、右上角按需切方案和页面主题、中间的框只放正式页面，多方案放同一份原型切换，改到用户明确说"可以"；也负责做完后拿实际界面和原型对比。触发：/prototype、做个原型、出个界面预览；/prd、/revise 要出原型时调用；/exec、/revise 收尾时

• revise

  产出修订（诊断→定向修正→回归验证）——对 PRD→plan→exec 偏差做根因归类：prd-defect / impl-defect / requirement-change；先读代码确认现状、经 git 标记查回相关 PRD 再归因；定出根因后搜全同根因位置、和用户报的那一处同一轮修完；改代码必先 Red 测试、最小影响只改必须改的层；需求变了（prd-defect / requirement-change）只在本分支 PRD 上改，相关 PRD 已合并或没有 PRD 时退出转 /prd 新开一份；bug、安全、鲁棒性修复留在本流程，修订原因与决策写进 commit 正文；完成后自动 /

• test-api

  后端 API e2e 验证——Docker 整栈拉起→md 用例渲染为单文件 TS runner→`bun run` 顺序跑完→报告与 /revise 闭环；时间敏感规则（token 过期 / 订单超时 / 积分过期）经协议契约 /test/advance-time、/test/backdate、/test/trigger-job 测，应用侧用什么语言/库实现自选；零 subagent、零并发；跑完无条件 docker compose down -v。触发：/test-api、跑后端接口测试、API e2e 验收、验证后端业务流。跳过：Docker 不可用、Bun 不可用、应用未暴露 /tes

• test-webview

  网页项目全量交互验证——Docker 整栈拉起→经浏览器 MCP（playwright/chrome-devtools）逐个跑完 webview 测试用例；每用例派隔离串行 subagent，主上下文只留 verdict 摘要；全程零并发；跑完无条件 docker compose down -v；失败转 /revise。触发：/test-webview、跑网页交互测试、端到端验证网页、webview 验收。跳过：无可用 HTTP 网页服务、无浏览器 MCP、Docker 不可用。

Subagents (8)

• code-investigator

  调查子代理——主窗口不知道答案在哪个文件、或预计要读 3 个以上源码文件时，替它搜索和翻读代码，弄清"系统现在怎么做"或"问题出在哪"，交回不超过 2,000 字符、每条带 文件:行号 的结论。派工：被 /prd、/revise、/exec 的主窗口调用。禁止：改项目文件、操作 git、猜测没读到的代码。

• impl-engineer

  exec 的实现工程师子代理（Green 阶段）——只读 plan 的函数清单+文件路径+测试文件，用最小代码让测试全绿；plan 含「成品定义」时原样落盘不得改写；引入新技术限 plan「新增技术」表内，表外的不引入、在报告里上报；按函数清单或成品定义无法让测试通过时以「方案问题」带证据上报、不硬凑。派工：被 /exec 在 Green 阶段调用。禁止：碰 PRD 原文、改测试、自行扩展功能、引入表外新技术、操作 git。

• prd-reviewer

  PRD 合规审查者（exec 第三步 Review）——读所有变更文件（测试+实现），逐条对照期望行为（本分支 PRD 的约束与验收，或 PRD 已合并时用户确认的行为）与 AGENTS.md 项目级约束核对实现合规性与测试覆盖，并以鲁棒性（真实非恶意故障路径）与安全（攻击者视角）两种视角过一遍变更代码，发现问题给出具体 file:line + 触发条件/攻击路径 + 修复方向，并附上变更文件之外的同类位置；输出合规 N/M 条、违规 X 条、测试遗漏 Y 条、鲁棒/安全问题 W 条的结构化报告。派工：被 /exec 在每个 plan 文件 Green 完成后调用做合规闭环。禁止：修改文件、操

• pre-reviewer

  分支规范自查者（PR 前 pre-review）——比对当前分支 vs 基线分支的 diff 与仓库根 AGENTS.md 项目级约束、本分支新增的 PRD、本分支 commit 正文写明的改动说明，输出 PASS|FAIL + 违规清单（file:line + 违反哪条项目约束、PRD 约束或改动说明 + 建议修法）；PRD 每条约束与验收逐条找实现，找不到即「未实现」违规；改已合并功能的分支以 commit 正文声明的新行为为准、已合并 PRD 只作背景；只读不改；规范来源仅限给定 agents_md、prd_dirs、change_notes、merged_prd_dirs，禁引入外部最

• prototype-designer

  界面原型设计者——按派工说明读 DESIGN.md、取证、用统一外壳出 HTML 原型，或在 compare 模式拿实际界面和原型对比；不能直接问用户，要用户答复的事一律写进报告「待用户确认的问题」，等主对话转来答复再做；每轮交回固定格式的简短报告（改了什么、依据、假数据和假操作、可能不准、待用户确认的问题）。派工：被 /prototype 按模式调用。禁止：直接问用户、改产品代码、操作 git。

• script-runner

  跑脚本的子代理——按主窗口给的命令和工作目录自己启动会自己结束的脚本（测试、构建、类型检查、审查），等到结束，交回几行结论和完整输出文件的路径；连续 30 分钟没有任何新输出判定卡死并停掉自己启动的脚本。派工：主窗口遇到预计超过 2 分钟或拿不准时长的脚本时调用。禁止：改项目文件、操作 git、重试启动失败的命令、停别的进程。

• test-engineer

  exec 的测试工程师子代理（Red 阶段）——根据 PRD 约束+验证预期写测试，每条约束至少一个用例、覆盖正常+边界+错误；按项目测试惯例（框架/目录/命名）组织；编译过断言失败=正确 Red、意外 PASS=如实报告；约束互相矛盾或无法写成可判定测试时以「方案问题」带证据上报、不硬凑；不猜实现的函数名/文件路径/内部结构。派工：被 /exec 在 Red 阶段调用。禁止：碰函数清单与实现路径、操作 git、写实现代码。

• webview-test-runner

  网页交互用例执行者——按 test_case_json 的 setup/steps/teardown 驱动真实浏览器，把抽象 action（navigate/click/fill/hover/press 等）映射到对应浏览器 MCP 工具执行；assert* 不通过立即停、截图+console 取证；交互后用 waitFor 替代固定 sleep；最少工具调用（连续断言复用快照、批量填表、只在必要时截图）。派工：被 /test-webview 对每个用例串行调用一次。禁止：探索其他页面、改代码、操作 git、并发跑多用例。