qa-start

在尚无 QA 基础的情况下，按顺序启动 QA。检查代码仓库， 收集现有上下文，选定首个关键行为，并执行相应检查。 使用 `qa-project-context` → `test-strategy` → `test-planning` 明确记录决策， 然后提交测试证据和下一个具体差距，以及规划文档。

何时使用

每当你不确定“QA 应该从哪里开始”，且尚无 QA 基础时，就使用 qa-start：

• 没有测试基础设施的全新项目。
• 加入一个完全没有 QA 配置的现有代码库——代码虽然旧，但从未正式开展质量工作。仍然使用 qa-start，而不是 qa-project-bootstrap（后者适用于加入一个已经有测试的团队）。
• QA 工作因疏于维护而需要重启——测试已删除、覆盖率骤降，也没有策略。你要从基础开始重启 QA。

如果代码库已经有真正的测试套件，而你是加入团队的 QA 工程师，请改用 qa-project-bootstrap。

快速路径

选择入口点——已有对应文档时可跳过该步骤。

情况	从此处开始
完全没有 QA（没有上下文文件、策略或计划）	步骤 1
.agents/qa-project-context.md 已填写	跳过步骤 1——调用 test-strategy（步骤 2）
上下文文件和策略文档都已存在	跳过步骤 1 和 2——调用 test-planning（步骤 3）
三项都已完成——接下来做什么？	步骤 3 之后
正加入一个已有测试的现有团队的 QA 工程师	不适用此技能——请参阅 qa-project-bootstrap

步骤 1：收集项目上下文

技能： qa-project-context

在项目根目录中创建 .agents/qa-project-context.md。该文件记录技术栈、测试框架、CI/CD 流水线、环境、覆盖率目标、风险领域和团队结构。后续每项技能都会读取该文件，因此不会重复询问相同问题。

操作： 调用 qa-project-context。从代码仓库和现有任务开始了解情况， 然后编写文件。明确记录尚未确定的事项。只有在缺失答案会影响下一步行动时才提问；即使缺少可选上下文，也要继续开展有价值的检查。

完成标准： .agents/qa-project-context.md 记录了已观察到的配置、可用命令、 当前范围和未解决的决策。不要臆造团队结构、目标或凭据。

步骤 2：制定测试策略

技能： test-strategy

生成策略文档，定义项目如何保障质量：测试金字塔（产品适合采用的单元、集成和 E2E 测试比例）、准入和退出标准、工具选择、环境覆盖范围，以及 CI 和发布的质量门槛。

操作： 步骤 1 完成后调用 test-strategy。它会自动读取上下文文件，不会再次询问其中已有答案。

完成标准： 你已准备好一份策略文档（例如 strategy.md），其中涵盖测试金字塔的依据、附带理由的工具选择、CI 和发布的质量门槛，以及每种测试类型的准入和退出标准。清晰决策的一页文档胜过冗长的模板。

步骤 3：制定首个测试计划

技能： test-planning

将策略转化为首个迭代或版本的可执行计划。把功能映射到测试用例、分配工作量，并决定哪些内容优先覆盖、哪些延期。

操作： 步骤 2 完成后调用 test-planning。它会使用步骤 2 的策略和步骤 1 的上下文。根据提示提供功能列表或迭代范围。

完成标准： 你已准备好一份测试计划（例如 plan.md），其中将功能映射到测试用例、设定覆盖优先级、估算工作量，并明确范围边界。团队将依据此文档执行。

运行首次检查

在生成规划文档前检查代码库。利用现有上下文做出常规选择，并使初始策略和计划与项目规模相称。缺少可选的上下文文件，不会阻止经授权的本地测试运行。

当完整的 QA Skills 检出内容可用时，运行：

node <qa-skills>/scripts/qa.mjs init --project <project> --wire-agent
node <qa-skills>/scripts/qa.mjs run --project <project> --goal "Check the critical user flow"

init 会创建项目配置，且不会覆盖已有配置。如果用户希望将 QA 集成到未来的编码任务中，请使用 --wire-agent；它会在项目的 AGENTS.md 中添加一个范围明确的工作流，同时保留现有指令。已配置的项目请跳过 init。宿主 Agent 必须加载该项目指令，才能自动选择。

阅读选定的领域技能并执行其工作流。如果没有测试，就针对观察到的关键行为编写并运行首个测试；不要把设置过程说成测试通过。保留真实的 report.html 和 result.json，其中包括受阻的依赖项和未运行的流程。成功的冒烟检查只能证明已实际测试的行为。请参阅代码库中的 docs/QA-RUNNER.md，了解运行器约定。

第 3 步之后

现在你已具备基础：上下文、策略和首份计划。接下来的行动取决于你的技术栈——此启动器并非最终步骤。

• 首批自动化测试： 使用 playwright-automation 或 cypress-automation，针对风险最高的流程编写首批 E2E 测试。
• CI 集成： 使用 ci-cd-integration，让测试在每次拉取请求时运行。
• 质量跟踪： 测试套件运行后，使用 qa-metrics 定义质量状况的衡量标准，以及如何随时间进行测量。

qa-start 与 qa-project-bootstrap 和 qa-do 的区别

最常见的路由困惑，一次说清：

• qa-start — 为尚无 QA 的项目搭建 QA。适用于新项目，或 QA 已被删除、需要重新启动的情况。顺序：上下文 → 策略 → 首份计划。输出是 QA 的基础。
• qa-project-bootstrap — 为加入已有团队的 QA 工程师提供 30 天的适应计划，团队已有测试。涵盖团队流程、入职时间线，以及对现有测试套件的审查。应在已有基础之后使用，而非用于创建基础。
• qa-do — 当没有明显匹配项时，作为“我该使用哪项技能？”问题的最后兜底路由。如果你已确定没有 QA，请跳过它并运行 qa-start。

没有 QA 的全新项目——即使基于旧代码库——也应始终使用 qa-start，而非 qa-project-bootstrap。

固定为手动命令

可随时从 Claude Code 的 /skills 菜单重新运行。

若要将此技能固定为仅手动调用的命令，请在 frontmatter 中添加 disable-model-invocation: true，或通过 .claude/settings.local.json 中的 skillOverrides 设置。

注意：在某些 Claude Code 版本中，disable-model-invocation: true 也会禁用手动斜杠命令（参见 anthropics/claude-code#26251）。如果仍想手动调用 /qa-start，请将 skillOverrides 状态设为 user-invocable-only。

相关技能

• qa-project-context — 第 1 步。将项目设置、技术栈和质量目标记录到 .agents/qa-project-context.md。
• test-strategy — 第 2 步。定义测试方法、测试金字塔、工具和质量门禁。
• test-planning — 第 3 步。制定首份测试计划，将功能映射到测试用例。
• qa-project-bootstrap — 如果 QA 工程师加入已有团队且团队已有测试，请改用此技能；此技能创建基础，而 bootstrap 负责入职适应。
• qa-do — 没有明显匹配技能时使用的最后兜底路由；如果你已确定没有 QA，则无需使用。
• playwright-automation / cypress-automation — 制定计划后，针对风险最高的流程编写首批 E2E 测试。