Skip to content

lumiogames/workflow

v1.3.6MIT

让 AI Agent 直连 Workflow(workflow.games):本地优先规划与拆解需求、自动查重和补全依赖、按权限模式受控并发上传、规划需求与需求室、记 bug、查任务、拿单执行与证据回写、跨仓库交接纪要、线上 QA 验收、查文档、经确认后向平台方匿名反馈问题与建议

brainstorming

开始创造性工作(新功能、建组件、加能力、改行为)之前、动手实现之前使用——澄清用户意图与需求,比较方案,把设计共识写成项目活文档并记录决策,再交给 workflow-planning 拆单;小而清楚的改动不必用它。

receiving-code-review

收到审查反馈(reviewer 报告、退回的 bug 单、评论、外部审查意见)之后、动手改之前使用——先核实再改,一次改一项各自验证,不表演性认同,有理有据地反驳;尤其在反馈不清楚或技术上可疑时。不用于自己去审别人的交付。

spec-steward

维护项目 .spec/ 的结构并把改动沉淀进知识库——放对位置(插件资产 vs 项目实例)、校验 frontmatter、同步导航与索引、更新状态、文档里落了单的地方写单号。当新增或修改知识文档、决策或项目规则,或完成一处改动后需要沉淀时使用。

systematic-debugging

遇到任何 bug、测试失败、构建失败或意外行为时、在提出修法之前使用——按「根因调查 → 模式分析 → 假设验证 → 实施」四阶段排障,先找根因再动手;修 3 次不成就质疑架构。

test-driven-development

实现功能、修 bug 或重构、要写生产代码之前使用——按「先写失败测试 → 最小实现 → 重构」推进;这是用 TDD 时的规矩,不是推分支前的门,推分支前不要求跑任何命令。

workflow-dependencies

分析 Workflow 单据或本地草稿的上下游依赖,补全直接关系、计算传递链并生成可审计的关系写入清单;不负责代码图谱或关系图 UI。

workflow-dispatch

主 loop 要把多张 Workflow(workflow.games)单同时派给多个 worker 并合入时使用——从 Room 取 readiness=ready 且文件集互斥的单、各开独立 git worktree 并行派遣、收交回物以 diff 为准、主 loop 合入、合入后触发一次 reviewer、把结论写成 bug 单与评论。用户说派活、扇出、并行开工、几张单一起做时使用;单张单自己承接用 workflow-execute,拆单用 workflow-planning。

workflow-docs

用户询问 Workflow(workflow.games)的 API 或产品功能怎么用、字段什么含义、支不支持某个能力、错误码什么意思,但不需要立刻执行操作时使用。抓取线上文档作答,不凭记忆。

workflow-execute

以执行者身份承接并交付一张已存在的 Workflow(workflow.games)单据时使用——查找指派给自己的需求或工作项、开工前读单核对前置与验收项、流转到进行中、完成后回写证据评论与附件并流转到待验收、按统一格式交回。用户说拿单、领任务、认领、开工、按单执行、做完了回写交单时使用;不做需求规划与落单(workflow-planning)、不做字段已明确的单次增删改(workflow-ops)、不做线上验收判定(workflow-qa)。

workflow-feedback

向 Workflow(workflow.games)平台方反馈问题与建议时使用——报错、API 行为与文档不符、体验不好、加载或操作明显卡慢、缺失功能、产品建议都算;只收集用户主动提供的信息组装报告,逐字展示完整报告与附件清单取得确认后,调公开匿名收件端点提交,以 sup_ 收件编号如实收尾。用户说向 Workflow 反馈、给平台提建议、插件好像有 bug、这里太卡太慢、要是有某功能就好了时使用;不往自己项目里记 bug(workflow-ops)、不答疑用法(workflow-docs)、不读取任何 Workflow 凭证。

workflow-init

装好插件后每个项目跑一次(也可重跑):生成 .spec 骨架与根入口,并接入 Workflow。已有项目文件默认不覆盖;已连通则只报告身份。还没有账号或 API token、调 API 遇到 401 或 403、要查连接或新增/切换项目时使用。

workflow-ops

在 Workflow(workflow.games)项目里执行字段与内容已经明确的单次操作,包括建一张需求、记 bug/缺陷、建任务、查询或搜索工作项、指派、状态流转、评论、附件和交接纪要。写操作先进入本地可恢复 bundle,再按权限模式上传并读回验证;模糊想法、PRD 梳理、多专业拆解或完整 Agent 提示词应使用 workflow-planning。

workflow-planning

把模糊想法、长文、附件或讨论结果澄清为可执行的 Workflow 开发蓝图,写成本地可恢复 bundle,自动分析依赖并按权限模式上传。用户要求规划、梳理或拆解游戏/软件功能,编写 PRD、需求池或多轨道交付计划时使用;不用于直接编码。

workflow-qa

以 QA 身份在真实线上环境跑测并验收 Workflow(workflow.games)的单据时使用——核实某张 bug 单是否真实存在、复测已修复的缺陷、验收功能上线效果,然后把判定与证据回写原单并按结论流转状态。用户要求复现、复测、跑测、验收、判断某个单号是否还成立时使用;只跑测与验收,不改代码、不修 bug。

workflow-update

更新或检查 Workflow(workflow.games)Agent 插件版本时使用;其他 workflow-* 技能的行为与线上 API 明显不符(多半是插件过期)时也用本技能先核对版本。

workflow-upload

将 Workflow 本地草稿按权限模式、全局查重、依赖拓扑和 Provider 协议可靠上传,并以受控并发批量执行、逐项读回验证;支持部分成功恢复。