ShipMate QA Agent 实战指南从验收标准到结构化 QA 报告的多智能体质量保障流水线【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agentsShipMate 是当前仓库中一套运行在 Claude Code 等多 harness 环境下的 agentic 开发流水线插件它把一次功能交付拆解为 scan → orchestrate → architect → implement → review → QA → playwright 七个阶段。本文聚焦其中承担质量守门人角色的 QA Agent定义见 qa.md完整讲解它的角色边界、输入契约、Bug 严重度分级、七步测试工作流与 QA 报告模板并结合 ship.md 的状态机路由、orchestrate.md 的规格产出与 architect.md 的测试计划说明 QA 如何与 implement、review、playwright 各阶段闭环协作。读完本文你将掌握如何把任意一条功能 story 的验收标准系统转化为可执行、可追踪、可回环的质量门禁。QA Agent 在 ShipMate 流水线中的定位ShipMate 的设计理念是一个任务独立跑完整个流水线。以/ship stories/foo.md启动后流水线主路由器 ship.md 会维护一份.claude/pipeline/state.json其中通过stage、checkpoints、flags、iteration等字段记录每个阶段的进度与回环次数。QA 阶段处于 review 之后、playwright仅 FRONTEND 任务之前前一阶段review.md 的 PR Reviewer 完成代码审查并输出review-report.md若无 Critical 问题stage被置为qa后一阶段QA 签核通过后FRONTEND 任务进入 playwright 阶段BACKEND 任务直接完成。QA Agent 本身是一个带 frontmatter 的 agent 定义文件声明了它的名称、职责描述与推荐模型name: qa description: QA Agent. Tests all acceptance criteria and edge cases from orchestrator-output.md. Generates a structured qa-report.md with pass/fail per criterion and bug triage. Loops back to implement if bugs found (max 2 iterations). model: sonnet关键信息有三点QA 的测试依据是orchestrator-output.md中的验收标准与边界用例产出物是结构化qa-report.md逐条 PASS/FAIL Bug 分级发现 Bug 时最多回环 implement 两次与 state.json 中iteration.qa上限一致超出后升级人工。角色设定与严格边界qa.md 将 QA Agent 设定为具有 15 年软件测试经验的资深 QA 工程师强调其行事风格是系统化、证据驱动、彻底systematic, evidence-driven, thorough并明确针对需求测试而非修改生产代码。在开始任何测试之前它必须先阅读AGENTS.md——这份文件由 scan 技能SKILL.md在流水线初始化时基于代码库扫描自动生成内含项目专属的边界用例、关键用户路径与测试要求是 QA 判断该项目下什么算正确的依据。同时qa.md 为 QA Agent 划定了四条严格边界Strict Boundaries边界含义禁止修改生产代码只测试与验证不修复 Bug禁止做架构决策只验证实现是否符合需求禁止变更需求发现需求缺口时升级给人类而不是抛给架构师只测当前任务只测试current_task不测无关功能这条只测当前任务的边界与整个流水线一次只处理一个任务的设计一致——orchestrate、architect、implement等所有 Agent 都只围绕 state.json 中的current_task工作。输入契约QA 拿什么测、依据什么判qa.md 明确了 QA Agent 的四个输入来源它们构成了完整的可追踪测试链.claude/pipeline/orchestrator-output.md——由 orchestrate.md 的产品编排 Agent 产出包含澄清后的验收标准Acceptance Criteria、边界用例Edge Cases、错误状态Error States、范围外事项Out of Scope与假设记录AGENTS.md——项目专属 QA 指令、关键路径与覆盖率要求.claude/pipeline/architect-plan.md——由 architect.md 产出其中的 Test Plan 章节定义了必须测什么仓库中已实现的代码——被测对象本体。这条契约链的价值在于需求溯源QA 报告中每一条用例都可以追溯到 orchestrator-output.md 中的某条验收标准或边界用例从而保证测的就是该测的。这也呼应了 orchestrate 阶段要求以Given...when...then...格式书写验收标准的做法见 stories/_template.md使每条标准天然可转换为一个测试用例。Bug 严重度分级QA 回环的决策依据qa.md 给出了四级 Bug 严重度分类这是 QA 判定是否放行的核心模型严重度定义流水线动作Critical系统宕机、数据丢失、安全漏洞、功能完全失败阻断——立即升级High主要验收标准失败、对用户有重大影响阻断——QA 签核前必须修复Medium功能部分可用、边界用例失败、中等影响阻断——QA 签核前必须修复Low轻微外观问题、对用户影响极小仅记录——不阻断签核注意该表的一个特点Critical、High、Medium 全部阻断交付只有 Low 不阻断。这意味着 ShipMate 对质量采取偏严格的策略——部分可用Medium也不能放行必须回环修复。这个分级同时与 review.md 的三层发现分类 Critical / Should Fix / Consider形成对照Review 阶段允许 级问题由开发者自动修复而 QA 阶段的 Medium 以上问题一律走回环。七步工作流从输入读取到状态更新1. 读取全部输入QA Agent 启动后先完整读取 orchestrator-output.md、AGENTS.mdQA Agent 章节与 architect-plan.md 的 Test Plan在开始测试前就构建完整的测试清单——先明确该测什么再动手测。2. 构建测试清单测试清单由三个来源汇聚而成来自 orchestrator-output.md每条验收标准 → 一个测试用例每个边界用例 → 一个测试用例每个错误状态 → 一个测试用例来自 AGENTS.mdQA Agent 章节项目专属、每次都必须测的关键路径该领域已知的边界用例标准 QA 场景始终包含空/null 状态处理边界值最小值、最大值、零、负数非法输入处理并发/重复操作处理如适用权限/角色边界如适用网络错误处理如任务类型相关回归检查识别该变更可能影响到的相邻既有功能运行既有测试确认无回归3. 执行测试每个测试用例按固定四步执行定义前置条件 → 执行动作 → 将实际结果与预期结果对比 → 以证据记录 PASS 或 FAIL。qa.md 针对任务类型给出了差异化测试方法BACKEND 任务通过 API 调用测试验证响应码、响应体与错误响应FRONTEND 任务测试 UI 行为、状态变化、错误展示与用户流程完成度。安全测试每个任务强制验证响应或 UI 中不暴露敏感数据验证不存在认证绕过验证所有入口点均做了输入校验这条每个任务必做安全测试的强制要求与 implement、review 阶段的 Security Rules 一脉相承详见 implement.md 与 review.md构成贯穿全流水线的安全护栏。4. 撰写 QA 报告测试执行完毕后QA Agent 将结果写入.claude/pipeline/qa-report.md。qa.md 给出了完整的报告模板涵盖Summary执行的测试数、通过/失败/阻断数RecommendationAPPROVED 或 REJECTED 及理由Acceptance Criteria Results逐条验收标准的 PASS/FAIL 与证据或失败详情Edge Case Results与Error State Results边界用例与错误状态结果表Regression Check相邻功能回归结果Security Test敏感数据暴露、输入校验、认证边界三项结果Bugs Found每个 Bug 记录严重度、影响的验收标准、复现步骤Steps to Reproduce、预期行为、实际行为、影响范围Test Coverage新代码覆盖率、AGENTS.md 要求的最低覆盖率、PASS/FAIL 状态这份模板使 QA 报告不仅是结果清单更是可审计的质量证据链——每条 Bug 都能追溯到具体验收标准和复现路径。5. 判定结果QA 依据 Bug 严重度做出四种判定并通过修改 state.json 的flags.qa_bugs_pending字段驱动流水线情况state.json 变更流水线动作存在 Critical/High Bugflags.qa_bugs_pending true打印 Bug 列表给开发者修复由 ship 技能路由回 implement仅存在 Medium Bugflags.qa_bugs_pending true路由回 implementMedium 必须解决仅存在 Low Bugflags.qa_bugs_pending false在报告中记录 Low Bug继续签核全部通过flags.qa_bugs_pending falsecheckpoints.qa completed打印✅ QA sign-off granted. Feature meets all acceptance criteria.6. 检查 QA 循环上限路由回 Bug 后QA Agent 检查 state.json 中的iteration.qa。如果iteration.qa 2则不再尝试新一轮循环由 ship 技能升级给人类处理。这是 ShipMate 防循环机制Anti-Loop Guards在 QA 阶段的具体落地。7. 更新状态签核通过后更新 state.jsoncheckpoints.qa completed根据任务类型设置stageFRONTEND →playwrightBACKEND →complete随后打印结果并交接给下一阶段。与流水线状态机的闭环ship 技能如何路由 QAQA Agent 本身不负责路由——路由逻辑由主路由器 ship.md 的 Stage Routing 章节统一实现。两者通过 state.json 的flags.qa_bugs_pending字段协作ship 将stage置为qa后调用 qa 技能QA 完成后若flags.qa_bugs_pending trueship 递增iteration.qa若iteration.qa 2打印人工升级提示、设置flags.escalated true并暂停否则将stage置回implement进入 Bug 修复循环修复后经 review → QA 再次验证若 QA 通过设置checkpoints.qa completed并按task_type路由——FRONTEND 进入 playwright 阶段由 playwright.md 在真实浏览器中以 Page Object 模式验证验收标准BACKEND 直接完成当前任务。值得注意的是ship.md 还定义了跨阶段通用的三条防循环规则Repeated Blocker Rule同一阻断类型在同一条委托链上出现两次立即升级人工、No Cyclic Handoff不把工作发回已处理过同一问题的阶段、Two-Handoff Rule同一问题 2 次未解决即暂停升级由 state.json 中的iteration上限强制执行。QA 阶段的iteration.qa 2就是第二条规则的具体体现。落地建议让 QA 阶段真正发挥质量门禁作用基于 qa.md 的完整定义与 ShipMate 的整体设计在项目中使用 QA Agent 时有几点实操要点初始化是前提先运行/setup见 setup.md完成 scan生成AGENTS.md与project-doc.md否则 QA 缺乏项目专属的质量基线写好 story 是源头story 文件的验收标准越清晰参考 stories/_template.md 的Given/when/then格式QA 构建测试清单越容易报告的可追踪性越强善用/ship status与/ship resume流水线会在 architect 计划待审、review 发现 Critical 问题、QA 两次失败三种情况下暂停status可随时查看阶段进度resume可在人工处理后继续尊重回环上限QA 最多回环 implement 两次这是刻意设计的防死循环机制超过即升级人工不要绕过它强制自动修复到底把安全测试当硬门槛qa.md 规定每个任务必须执行敏感数据暴露、认证绕过、输入校验三项安全验证任何一项失败都不应签核。ShipMate 的 QA Agent 用一份结构化 agent 定义、一张严重度分级表和一套七步工作流把测试从模糊的口头要求变成了可审计、可回环、可升级的流水线一等公民——这正是多智能体开发流水线中质量保障环节值得借鉴的设计范式。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ShipMate QA Agent 实战指南：从验收标准到结构化 QA 报告的多智能体质量保障流水线
ShipMate QA Agent 实战指南从验收标准到结构化 QA 报告的多智能体质量保障流水线【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agentsShipMate 是当前仓库中一套运行在 Claude Code 等多 harness 环境下的 agentic 开发流水线插件它把一次功能交付拆解为 scan → orchestrate → architect → implement → review → QA → playwright 七个阶段。本文聚焦其中承担质量守门人角色的 QA Agent定义见 qa.md完整讲解它的角色边界、输入契约、Bug 严重度分级、七步测试工作流与 QA 报告模板并结合 ship.md 的状态机路由、orchestrate.md 的规格产出与 architect.md 的测试计划说明 QA 如何与 implement、review、playwright 各阶段闭环协作。读完本文你将掌握如何把任意一条功能 story 的验收标准系统转化为可执行、可追踪、可回环的质量门禁。QA Agent 在 ShipMate 流水线中的定位ShipMate 的设计理念是一个任务独立跑完整个流水线。以/ship stories/foo.md启动后流水线主路由器 ship.md 会维护一份.claude/pipeline/state.json其中通过stage、checkpoints、flags、iteration等字段记录每个阶段的进度与回环次数。QA 阶段处于 review 之后、playwright仅 FRONTEND 任务之前前一阶段review.md 的 PR Reviewer 完成代码审查并输出review-report.md若无 Critical 问题stage被置为qa后一阶段QA 签核通过后FRONTEND 任务进入 playwright 阶段BACKEND 任务直接完成。QA Agent 本身是一个带 frontmatter 的 agent 定义文件声明了它的名称、职责描述与推荐模型name: qa description: QA Agent. Tests all acceptance criteria and edge cases from orchestrator-output.md. Generates a structured qa-report.md with pass/fail per criterion and bug triage. Loops back to implement if bugs found (max 2 iterations). model: sonnet关键信息有三点QA 的测试依据是orchestrator-output.md中的验收标准与边界用例产出物是结构化qa-report.md逐条 PASS/FAIL Bug 分级发现 Bug 时最多回环 implement 两次与 state.json 中iteration.qa上限一致超出后升级人工。角色设定与严格边界qa.md 将 QA Agent 设定为具有 15 年软件测试经验的资深 QA 工程师强调其行事风格是系统化、证据驱动、彻底systematic, evidence-driven, thorough并明确针对需求测试而非修改生产代码。在开始任何测试之前它必须先阅读AGENTS.md——这份文件由 scan 技能SKILL.md在流水线初始化时基于代码库扫描自动生成内含项目专属的边界用例、关键用户路径与测试要求是 QA 判断该项目下什么算正确的依据。同时qa.md 为 QA Agent 划定了四条严格边界Strict Boundaries边界含义禁止修改生产代码只测试与验证不修复 Bug禁止做架构决策只验证实现是否符合需求禁止变更需求发现需求缺口时升级给人类而不是抛给架构师只测当前任务只测试current_task不测无关功能这条只测当前任务的边界与整个流水线一次只处理一个任务的设计一致——orchestrate、architect、implement等所有 Agent 都只围绕 state.json 中的current_task工作。输入契约QA 拿什么测、依据什么判qa.md 明确了 QA Agent 的四个输入来源它们构成了完整的可追踪测试链.claude/pipeline/orchestrator-output.md——由 orchestrate.md 的产品编排 Agent 产出包含澄清后的验收标准Acceptance Criteria、边界用例Edge Cases、错误状态Error States、范围外事项Out of Scope与假设记录AGENTS.md——项目专属 QA 指令、关键路径与覆盖率要求.claude/pipeline/architect-plan.md——由 architect.md 产出其中的 Test Plan 章节定义了必须测什么仓库中已实现的代码——被测对象本体。这条契约链的价值在于需求溯源QA 报告中每一条用例都可以追溯到 orchestrator-output.md 中的某条验收标准或边界用例从而保证测的就是该测的。这也呼应了 orchestrate 阶段要求以Given...when...then...格式书写验收标准的做法见 stories/_template.md使每条标准天然可转换为一个测试用例。Bug 严重度分级QA 回环的决策依据qa.md 给出了四级 Bug 严重度分类这是 QA 判定是否放行的核心模型严重度定义流水线动作Critical系统宕机、数据丢失、安全漏洞、功能完全失败阻断——立即升级High主要验收标准失败、对用户有重大影响阻断——QA 签核前必须修复Medium功能部分可用、边界用例失败、中等影响阻断——QA 签核前必须修复Low轻微外观问题、对用户影响极小仅记录——不阻断签核注意该表的一个特点Critical、High、Medium 全部阻断交付只有 Low 不阻断。这意味着 ShipMate 对质量采取偏严格的策略——部分可用Medium也不能放行必须回环修复。这个分级同时与 review.md 的三层发现分类 Critical / Should Fix / Consider形成对照Review 阶段允许 级问题由开发者自动修复而 QA 阶段的 Medium 以上问题一律走回环。七步工作流从输入读取到状态更新1. 读取全部输入QA Agent 启动后先完整读取 orchestrator-output.md、AGENTS.mdQA Agent 章节与 architect-plan.md 的 Test Plan在开始测试前就构建完整的测试清单——先明确该测什么再动手测。2. 构建测试清单测试清单由三个来源汇聚而成来自 orchestrator-output.md每条验收标准 → 一个测试用例每个边界用例 → 一个测试用例每个错误状态 → 一个测试用例来自 AGENTS.mdQA Agent 章节项目专属、每次都必须测的关键路径该领域已知的边界用例标准 QA 场景始终包含空/null 状态处理边界值最小值、最大值、零、负数非法输入处理并发/重复操作处理如适用权限/角色边界如适用网络错误处理如任务类型相关回归检查识别该变更可能影响到的相邻既有功能运行既有测试确认无回归3. 执行测试每个测试用例按固定四步执行定义前置条件 → 执行动作 → 将实际结果与预期结果对比 → 以证据记录 PASS 或 FAIL。qa.md 针对任务类型给出了差异化测试方法BACKEND 任务通过 API 调用测试验证响应码、响应体与错误响应FRONTEND 任务测试 UI 行为、状态变化、错误展示与用户流程完成度。安全测试每个任务强制验证响应或 UI 中不暴露敏感数据验证不存在认证绕过验证所有入口点均做了输入校验这条每个任务必做安全测试的强制要求与 implement、review 阶段的 Security Rules 一脉相承详见 implement.md 与 review.md构成贯穿全流水线的安全护栏。4. 撰写 QA 报告测试执行完毕后QA Agent 将结果写入.claude/pipeline/qa-report.md。qa.md 给出了完整的报告模板涵盖Summary执行的测试数、通过/失败/阻断数RecommendationAPPROVED 或 REJECTED 及理由Acceptance Criteria Results逐条验收标准的 PASS/FAIL 与证据或失败详情Edge Case Results与Error State Results边界用例与错误状态结果表Regression Check相邻功能回归结果Security Test敏感数据暴露、输入校验、认证边界三项结果Bugs Found每个 Bug 记录严重度、影响的验收标准、复现步骤Steps to Reproduce、预期行为、实际行为、影响范围Test Coverage新代码覆盖率、AGENTS.md 要求的最低覆盖率、PASS/FAIL 状态这份模板使 QA 报告不仅是结果清单更是可审计的质量证据链——每条 Bug 都能追溯到具体验收标准和复现路径。5. 判定结果QA 依据 Bug 严重度做出四种判定并通过修改 state.json 的flags.qa_bugs_pending字段驱动流水线情况state.json 变更流水线动作存在 Critical/High Bugflags.qa_bugs_pending true打印 Bug 列表给开发者修复由 ship 技能路由回 implement仅存在 Medium Bugflags.qa_bugs_pending true路由回 implementMedium 必须解决仅存在 Low Bugflags.qa_bugs_pending false在报告中记录 Low Bug继续签核全部通过flags.qa_bugs_pending falsecheckpoints.qa completed打印✅ QA sign-off granted. Feature meets all acceptance criteria.6. 检查 QA 循环上限路由回 Bug 后QA Agent 检查 state.json 中的iteration.qa。如果iteration.qa 2则不再尝试新一轮循环由 ship 技能升级给人类处理。这是 ShipMate 防循环机制Anti-Loop Guards在 QA 阶段的具体落地。7. 更新状态签核通过后更新 state.jsoncheckpoints.qa completed根据任务类型设置stageFRONTEND →playwrightBACKEND →complete随后打印结果并交接给下一阶段。与流水线状态机的闭环ship 技能如何路由 QAQA Agent 本身不负责路由——路由逻辑由主路由器 ship.md 的 Stage Routing 章节统一实现。两者通过 state.json 的flags.qa_bugs_pending字段协作ship 将stage置为qa后调用 qa 技能QA 完成后若flags.qa_bugs_pending trueship 递增iteration.qa若iteration.qa 2打印人工升级提示、设置flags.escalated true并暂停否则将stage置回implement进入 Bug 修复循环修复后经 review → QA 再次验证若 QA 通过设置checkpoints.qa completed并按task_type路由——FRONTEND 进入 playwright 阶段由 playwright.md 在真实浏览器中以 Page Object 模式验证验收标准BACKEND 直接完成当前任务。值得注意的是ship.md 还定义了跨阶段通用的三条防循环规则Repeated Blocker Rule同一阻断类型在同一条委托链上出现两次立即升级人工、No Cyclic Handoff不把工作发回已处理过同一问题的阶段、Two-Handoff Rule同一问题 2 次未解决即暂停升级由 state.json 中的iteration上限强制执行。QA 阶段的iteration.qa 2就是第二条规则的具体体现。落地建议让 QA 阶段真正发挥质量门禁作用基于 qa.md 的完整定义与 ShipMate 的整体设计在项目中使用 QA Agent 时有几点实操要点初始化是前提先运行/setup见 setup.md完成 scan生成AGENTS.md与project-doc.md否则 QA 缺乏项目专属的质量基线写好 story 是源头story 文件的验收标准越清晰参考 stories/_template.md 的Given/when/then格式QA 构建测试清单越容易报告的可追踪性越强善用/ship status与/ship resume流水线会在 architect 计划待审、review 发现 Critical 问题、QA 两次失败三种情况下暂停status可随时查看阶段进度resume可在人工处理后继续尊重回环上限QA 最多回环 implement 两次这是刻意设计的防死循环机制超过即升级人工不要绕过它强制自动修复到底把安全测试当硬门槛qa.md 规定每个任务必须执行敏感数据暴露、认证绕过、输入校验三项安全验证任何一项失败都不应签核。ShipMate 的 QA Agent 用一份结构化 agent 定义、一张严重度分级表和一套七步工作流把测试从模糊的口头要求变成了可审计、可回环、可升级的流水线一等公民——这正是多智能体开发流水线中质量保障环节值得借鉴的设计范式。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考