用途
qa-project-bootstrap 用于两类任务：一是让新 QA 工程师入职已有代码库，二是审计现有测试架构。它产出 30 天入职计划，包含代码库导览、框架走查、首个测试合并、冲刺贡献与独立里程碑。
开始前需检查项目根目录是否存在 .agents/qa-project-context.md。若存在，它可回答大部分发现性问题并提供技术上下文；若不存在，创建它是第一项行动。
该技能服务三种不同任务：
- 让新人加入现有团队：产出带负责人和日期的 30 天入职计划。
- 接手无入职文档的现有测试套件：产出 1-2 页、五个维度的发现文档。
- 为编写测试的人提供参考文档：产出项目专属的 walkthrough.md。
真实入职通常三者都需要；快速健康检查只需审计。
主要能力
发现性问题
- 被入职者是谁：新 QA 工程师还是贡献测试的开发者？对测试框架的经验水平如何？是独立 QA 还是加入现有 QA 团队？
- 项目状态：是否已有测试框架及其健康度？是否有 .agents/qa-project-context.md？本地环境搭建是否有文档？
- 访问与工具：所需账号和权限是否就绪（仓库、CI 面板、预发环境、测试数据账号、缺陷跟踪、沟通渠道）。
核心原则
- 首个合并测试的时间是成功指标：目标两周内将真实测试合并进主分支并在 CI 中运行。
- 渐进式复杂度：从冒烟测试或页面加载验证开始，逐步到表单交互、多步用户流程。
- 记录部落知识：新人问到的未记录问题应沉淀到 .agents/qa-project-context.md、框架走查文档或代码注释。
- 先配对后独立：前 3 个测试应配对编写，新人主导、有经验成员导航。
- 让正确路径成为最省力路径：确保测试工具、fixture、页面对象和数据工厂使推荐模式最易遵循。
按团队成熟度校准（在 .agents/qa-project-context.md 中设置 team_maturity）：
- startup：聚焦第 1-10 天，让一个测试框架运行并覆盖一条关键路径，跳过流程仪式。
- growing：完整 30 天计划，含框架选择、CI 集成、覆盖基线、团队约定文档。
- established：30 天计划加审计现有套件反模式、提议工具升级、建立指标基线、安排定期质量评审。
30 天入职清单
第 1 周：环境、访问与导览
- 第 1-2 天：仓库克隆并本地构建、环境变量配置、应用本地运行、测试套件本地运行、IDE 配置、权限授予。
- 第 3-4 天：阅读或创建 .agents/qa-project-context.md、走查测试目录结构、理解测试金字塔、审查 CI 流水线、识别前 5 个关键用户流程、旁听一次 Three Amigos 或冲刺规划。还需识别团队使用的 AI 助手及其上下文位置、内部提示/技能、明确不委托给 AI 的任务，产出简短文档。
- 第 5 天：调试模式运行单个测试、修改一个断言验证失败后还原、阅读 3 个现有测试并标注各部分。
第 2 周：首个真实测试
- 识别简单低风险测试、使用现有页面对象和 fixture 编写（配对）、本地连续 3 次通过、开 PR 并迭代、CI 通过、首个测试合并。
第 3 周：冲刺贡献
- 在指导下承接冲刺故事的 QA 工作、编写覆盖验收标准的测试、识别至少一个未覆盖的边界情况、积极参与 Three Amigos 或故事细化、审查一个现有 PR 的测试质量。
第 4 周：独立里程碑
- 独立编写并合并多步 E2E 测试、参与缺陷分类并阐述测试缺口、向 .agents/qa-project-context.md 贡献新知识、在冲刺评审或站会展示测试结果、自我评估。
测试架构审计
加入现有项目时，先评估测试套件健康度再写新测试。审计耗时 2-4 小时。按 team_maturity 确定范围：startup 跳过完整审计；growing 运行全部五个维度一次建立基线；established 完整五维审计加定期质量评审。
评估五个维度，每个都有填写工作表：
- 覆盖度与分布：各层测试数量、金字塔形状、代码覆盖率及趋势。
- 可靠性：不稳定测试率、最不稳定测试、隔离数量与时长。
- CI 健康：全套件及各阶段时长、并行度、通过率、重试率。
- 技术债：跳过的测试、waitForTimeout/force: true 使用、硬编码数据、无断言测试、废弃 API、过时的 AI 生成测试、过时特性开关。
- 约定：页面对象、fixture、工厂、命名、共享工具、标签。
审计输出为 1-2 页文档，分类为：优势、缺口、风险、快速改进、战略性工作。
框架走查模板
为项目创建此文档，作为编写测试者的主要参考，含六部分：架构概览、如何运行测试、如何编写新测试（六步流程加 Arrange-Act-Assert 模板）、如何调试失败、常见模式与约定、何处寻求帮助。
代码库导览指南
60-90 分钟走查：测试目录结构导览、共享工具清单（认证 fixture、数据工厂、API 客户端、可访问性助手、断言）、页面对象走查、CI 流水线走查。
导师模式
- 前 3 个测试配对：测试 1 导航者/驱动者，测试 2 共同驾驶，测试 3 观察者。
- 前 2 周审查所有 PR，给出具体反馈：模式遵循、选择器策略、断言质量、测试隔离、命名。
- 测试伙伴系统：指定专人可随时提问，第一周每日检查，随叫随到，教育性评论，介绍团队规范。
- 渐进式责任阶梯：第 1-2 周为现有功能写测试；第 3-4 周为当前冲刺故事写测试；第 5-6 周独立编写并审查他人 PR；第 7-8 周贡献测试架构；第 3 个月起主导某功能领域测试规划并指导下一位新人。
反模式
- 放养式入职：只给仓库访问和 README。
- 纯教程入职：两周框架教程和玩具练习。
- 无文档全靠部落知识：每个问题都问同一个人。
- 完美主义瘫痪：期望首个测试完美。
- 忽视入职体验：不收集被入职者反馈。
- 不理解就复制粘贴：改了定位器和 URL 就完事。
使用方式
该技能以文档和清单形式提供，需在项目中创建 .agents/qa-project-context.md 并设置 team_maturity。具体安装命令与运行方式暂未提供。
适用场景
- 新 QA 工程师或贡献测试的开发者入职现有团队。
- 接手无入职文档的现有测试套件。
- 需要为编写测试的人提供项目专属参考文档。
- 对现有测试架构进行健康检查。
限制
资料未提供具体安装命令、运行方式、收费信息、支持平台或效果保证。部分内容（如 @playwright/cli 与 npx playwright test 的区别）仅作说明，未提供完整细节。