用途
testing-strategies 用于回答「我们该信任哪份验证包、实际需要什么置信度、团队下一步该做什么」这类测试策略问题。它的职责不是输出通用的测试金字塔宣言，也不是编写测试代码，而是把当前策略包规范化、明确真正要决策的关卡、选择一种主要策略模式、给出最小可信的层级组合，并区分本地、PR、发布与定时任务的不同期望。
主要能力
- 从已有策略包出发，将其归类为变更风险包、关卡设计包、不稳定与成本包、发布就绪包或事故回归棘轮包。
- 在展开层级之前先明确关卡真相：合并关卡、发布关卡或定时广度。
- 选择一种主要策略模式：层级选择、关卡塑造、不稳定与成本策略、事故回归棘轮或发布置信度。
- 对风险分级（Tier 0 至 Tier 3）并识别关键路径与失败成本。
- 选择最小可信的层级组合，并明确说明当前必需项与有意排除项。
- 区分本地、PR/合并、发布、定时/夜间四类循环的期望。
- 给出明确的例外与不稳定测试规则，包括阻断与信息性检查、隔离、修复、迁移或移除。
- 将实现、调试、评审、可访问性或性能工作路由到相邻技能。
使用方式
该技能以「验证策略简报」为输出格式，包含策略包、关卡真相、主要模式、风险等级、决策点、当前必需验证、关卡拆分、暂不纳入范围、例外与不稳定策略以及下一责任方等部分。处理不熟悉的策略包前，建议先阅读 references/intake-packets-and-route-outs.md；当歧义在于分支阻断与仅发布或平台发布证明时，阅读 references/gate-truth-and-release-handovers.md；选择最小可信层级组合时阅读 references/validation-matrix.md；判断下一步归属时阅读 references/handoff-boundaries.md。
适用场景
- 团队需要一份基于变更的验证简报，而不是笼统的「多加测试」建议。
- 开发者或评审者询问本地、PR、发布前或定时/夜间应运行什么。
- 需要判断单元、集成、契约、冒烟、探索性或手动检查是否真的必要。
- 不稳定或昂贵的测试套件问题实际上是关卡策略问题。
- 逃逸缺陷或事故需要合适的回归棘轮，而不是盲目扩大 E2E 覆盖。
- 发布就绪或 QA 签核工作需要与实际变更风险挂钩。
限制
该技能只负责策略与置信度决策，不负责下游实现。若主要任务是实现 API/服务/数据库/浏览器测试、夹具、mock 或 testcontainers，应使用 backend-testing 或对应技术栈的实现技能；若主要任务是复现失败、定位测试为何变红或调试不稳定行为，应使用 debugging；若主要任务是评审某个具体 PR、diff 或合并请求，应使用 code-review；若主要风险是性能基准、负载测试或帧预算策略，应使用 performance-optimization 或 game-performance-profiler；若涉及可访问性密集验证或视觉评审策略，应使用 web-accessibility。若尚无真实变更或决策点，应先定义变更内容与需要做出的置信度决策。