wio

WIO

WIO 是一个包含五种命令模式的测试工作流技能：

• scan：为代码库、变更或范围找出价值最高的测试候选项。
• test：针对选定的行为、代码路径或回归风险，编写一个聚焦且价值高的测试。
• workload：生成真实且具有对抗性的工作负载，通过受控的变化、重放和正确性不变量，增加新的故障面、判定依据、执行序列或覆盖维度。
• review：从客户价值、开发者价值、信号质量和可维护性等方面，评审新编写或已有的测试。
• doctor：诊断代码库或范围内的测试套件健康问题。

通过 $wio 使用命令：

命令	功能	默认参考资料
$wio scan [target]	为代码库、变更或范围找出价值最高的测试候选项。	待测行为映射
$wio test [target]	找出有价值的候选项，选择策略，编写一个测试，进行验证和评审，并且仅在测试有价值时保留。	测试级别选择
$wio workload [target]	生成真实的工作负载，其新增的发现 Bug 价值超越现有工作负载，并包含重要的用户任务、对抗性边缘情况、断言、不变量和受控变化。	工作负载建模
$wio review [target]	评审测试是否具有切实的客户或开发者价值，并返回 KEEP、REDO 或 REMOVE。	测试判定依据与断言
$wio doctor [target]	诊断代码库或范围内的测试套件健康问题。	测试套件健康诊断

使用 references/index.md，根据代码证据和候选故障模式找到合适的策略参考资料。

参考资料加载

不要凭记忆或仅参考最相近的现有测试来选择测试策略。首先检查目标代码、公开行为、现有测试、测试夹具和测试命令。然后确定候选行为或工作负载及其可能的故障机制。只有确定候选项后，才加载选择策略所需的参考资料。

对于每个选定的候选项，在推荐或编写测试之前，至少加载一份与故障机制相匹配的策略参考资料：

• 当优先级、客户影响、安全／业务风险或有限的测试资源决定工作优先顺序时，加载 基于风险的测试。
• 当行为涉及用户旅程、产品工作流、API 消费者流程或运营人员任务时，加载 用户行为测试。
• 在选择单元、组件、集成、契约、端到端（E2E）、工作负载、合成或监控测试覆盖范围之前，加载 测试级别选择。
• 在编写或审查断言、不变量、快照、工作负载检查，或任何失败信号不明确的测试之前，加载 测试预期结果与断言。
• 当状态设置、种子数据、工厂、清理、权限或数据真实性会影响测试信号时，加载 测试数据与夹具。
• 当模拟对象、伪造对象、存根、模拟器或真实依赖项的选择可能改变保留的风险时，加载 模拟与测试替身。
• 当需要选择本地、PR CI、夜间、发布、金丝雀、合成或生产监控的部署位置时，加载 测试反馈循环。
• 仅当故障机制需要时，才加载专项参考资料：适用于广泛确定性输入空间的基于属性的测试、适用于解析器／不可信输入的模糊测试、用于发现薄弱断言的变异测试、用于延迟／饱和度的性能测试、用于依赖项故障的韧性测试、用于滥用或租户／身份验证风险的安全测试、用于代码／配置结构缺陷的静态分析，以及当完整测试套件过慢时使用的回归测试选择。

对于某个主题中的命令和仓库信号，在匹配的 overview.md 表明该主题相关后，再加载同目录下的 tools.md。说明哪些参考文件为所选策略提供了依据。

命令选择

当用户询问接下来该测试什么、哪些地方的覆盖率很重要、如何确定测试工作的优先级，或哪些测试可以降低用户、生产环境、支持团队或团队风险时，使用 scan。

当用户要求添加测试、改进某个具体测试、覆盖某个 bug，或通过有意义的自动化测试验证更改时，使用 test。

当用户要求生成逼真的用户会话工作负载、场景生成器、流量模型、负载／性能场景、浏览器旅程组合、合成用户流程，或在保持任务目标稳定的同时变化多样的工作负载时，使用 workload。

如果用户要求 generate 工作负载，则应将现有工作负载视为证据和可复用基础设施，而非交付成果。生成的工作负载必须至少新增一项故障面、对抗类别、判定依据／不变量、状态模型、依赖故障、用户／会话路径或覆盖维度。围绕现有工作负载添加封装器、运行器、种子遍历、参数扩展或仅修改文档，不算生成工作负载，除非用户明确要求运行器，或者该封装器新增了判定依据或对抗模型。

当用户询问某个测试是否值得保留、要求审查测试，或 $wio test 编写或更改测试后，使用 review。

当用户要求审计测试、审查套件质量、查找不稳定或价值较低的测试、检查 CI 测试健康状况，或解释测试套件为何缓慢、噪声大或信号弱时，使用 doctor。

如果用户明确指定 WIO 命令，则按该模式执行。如果未指定命令，则根据请求推断模式。如果未提供命令或目标，则显示命令表并询问用户想做什么。如果适用多个模式，则先使用 scan，再使用 test 或 workload；仅针对现有套件的健康状况使用 doctor。

通用规则

• 保护有意义的行为，而不是追求覆盖率数字。
• 先询问可能出什么问题，再询问已经出了什么问题；在设计仍易于修改时，根据答案选择测试。
• 在建议或编写测试前，先明确产品、用户、生产环境、支持、调试、审查或发布方面的风险。
• 优先关注 bug 常出现的目标：边界、权限、状态转换、持久化、外部依赖、并发／时间、验证／解析、迁移、配置、缓存、重试／幂等性、UI 工作流衔接，以及近期频繁变更的部分。
• 只有在测试能够捕获有意义的回归、节省开发者时间、提升发布信心，或暴露真实的运维／客户故障模式时，该测试才有价值。
• 在保留某个测试或工作负载之前，至少指出一个它可能捕获的 bug，以及会因此失败的断言或不变量。
• 优先选择能体现行为认知模型的断言和不变量，包括有效情况、无效情况及两者之间的边界转换。
• 优先使用仓库原生的框架、辅助工具、固定数据、命令和命名规范。
• 在能够保留真实故障机制的前提下，选择范围最小的测试级别。
• 选择策略前先阅读代码和测试；确定候选故障模式后，再加载有针对性的参考资料。
• 说明已检查的证据、已运行的命令、未运行的命令及剩余风险。
• 将价值较低的测试标记为 REDO 或 REMOVE，而不是 KEEP。

易踩问题

• 不要仅为了提高覆盖率而编写或保留测试。断言薄弱的已覆盖代码会带来虚假的信心。
• 不要模拟掉会造成实际风险的边界、状态、权限、时序、数据或依赖行为。
• 不要接受宽泛的快照，除非经过审查的快照就是受保护的契约，且更新流程严谨。
• 如果较小的命令能以相同的信号验证变更行为，就不要使用完整测试套件命令。
• 不要通过弱化断言来修复不稳定测试。应先检查非确定性、共享状态、时序、重试、顺序依赖或外部服务。
• 不要把 CI 通过当作测试有价值的证明。关键问题是：出现有意义的回归时，测试是否会失败。
• 不要接受仅能证明执行完成、结果为真、对象存在、状态码为 200、宽泛的快照相等或模拟调用次数的测试或工作负载，除非这种弱信号明确就是受保护的契约。
• 不要把现有工作负载的简单封装称为 $wio workload generate。如果变更只是重新运行、参数化、记录或扫描现有工作负载，就称其为运行器，并说明缺少哪些新的故障面。
• 不要让子 Agent 编写测试或决定最终价值；主 Agent 负责修改，并作出最终的 KEEP、REDO 或 REMOVE 决定。

可用脚本

• scripts/test-review-reminder.py：钩子辅助脚本，在测试文件变更后提醒当前 Agent 进行验证并应用 $wio review。
• scripts/check-wio-report.py：用于已保存 Markdown 报告的可选检查器。当 WIO 输出写入文件且需要快速检查结构时，运行 python3 scripts/check-wio-report.py review report.md。

子 Agent 工作流

当宿主支持子 Agent 或并行 Agent，且用户／宿主策略允许时，请使用官方宿主位置中的 WIO 子 Agent 规范，以提升质量并避免重复提供指导：

• wio-candidate-scout：只读地发现高价值测试候选项和实际风险。
• wio-strategy-critic：实现前只读地审视所选测试级别、判定依据、替身、夹具和验证循环。
• wio-test-reviewer：实现后进行审查，并返回 KEEP、REDO 或 REMOVE。

子 Agent 必须先检查目标代码和测试，再加载针对性的 WIO 参考资料。它们向主 Agent 返回发现结果；不得编写报告或复制参考内容。Claude 插件子 Agent 位于 plugins/wio/agents/；Claude 项目子 Agent 可位于 .claude/agents/；Codex 自定义 Agent 位于 .codex/agents/。使用 skills add 安装 WIO 不会创建这些运行时文件。

对于 $wio test，请按以下顺序操作：

1. 检查仓库和目标代码：公开行为、变更路径、现有测试、夹具、命令、依赖、状态、副作用和边界。
2. 根据行为、风险、易出错区域、现有覆盖缺口和代码证据，找出有价值的候选项。如有条件，使用 wio-candidate-scout。
3. 加载与所选候选项的故障机制相匹配的参考资料，然后确定策略：测试级别、判定依据、夹具／数据设置、替身、对抗性边界覆盖和验证命令。
4. 如有条件，在编辑前使用 wio-strategy-critic 挑战拟定的策略。
5. 由主 Agent 遵循仓库原生模式编写一个有针对性的测试。
6. 使用最小范围的相关命令进行验证。
7. 审查编写的测试。如有条件，使用 wio-test-reviewer。
8. 仅在审查返回 KEEP 时保留测试；否则进行修改（REDO）或删除（REMOVE）。

如果无法使用子 Agent，主 Agent 应执行相同阶段，并明确标注审查阶段。

scan

找出最值得优先测试的部分、每部分适用的策略，以及测试它们的投资回报率。此模式为只读：先检查仓库和现有测试，再加载策略参考资料；不要编辑文件。

**从代码证据入手：**检查产品界面、目标实现、现有测试、测试夹具和命令。然后使用 Behavior To Test Map 整理候选项，使用 Risk-Based Testing 权衡并排序，只有在确定候选项后，才使用 Test Level Selection。

工作流：

1. 根据仓库证据了解产品和客户背景。
2. 梳理现有测试框架、命令、测试夹具、CI 和测试层级。
3. 选择策略前，先检查目标实现及其附近的测试。
4. 先梳理高价值行为，再关注底层辅助代码。
5. 找出范围内容易出问题的部分。
6. 加载与各候选项故障机制相匹配的参考资料，然后选择能保留真实用户或生产风险的最精简策略。
7. 根据影响、可能性、信心缺口和成本对候选项排序。

输出模板：

## Scope And Evidence
[target, files/commands inspected, tests/CI found]

## Ranked Candidates
1. [behavior] - impact: [why it matters], risk: [fault mechanism], references: [files used], strategy: [level/tool], cost: [small/medium/large]

## Best Next Test
[first investment and why it beats the alternatives]

## Avoid
[coverage-padding or low-signal tests to skip]

## Open Questions
[only questions that would materially change the ranking]

test

只有在测试能保护有意义的行为时才编写测试。有用的测试能减少未来的用户错误、生产事故、支持工作、调试时间、评审时间或发布风险。不要直接开始实现或选择策略。

**从代码证据入手：**检查目标行为、实现、现有测试、测试夹具和命令。选定候选项后，在选择测试层级前加载 Test Level Selection，在编写断言前加载 Test Oracles And Assertions。如果测试信号取决于数据、测试替身、反馈机制或专门的参考资料，也应一并补充。

工作流：

1. 检查目标范围内的代码、公开行为、现有测试、测试夹具、CI 和测试命令。
2. 根据产品风险、易出问题的部分、代码结构、现有覆盖缺口以及对用户和开发者的影响，找出范围内价值最高的候选项。
3. 为该候选项的故障机制加载合适的策略参考资料。
4. 根据代码证据和参考资料选择策略：测试层级、测试预言、数据／测试夹具设置、测试替身、专门方法和反馈循环。
5. 编辑前说明要保护的行为、可能捕获的回归、会失败的断言或不变量、其重要性、使用的参考资料以及验证命令。
6. 遵循仓库原生风格并使用现有辅助工具，编写一个聚焦的测试。
7. 使用最小范围的相关命令进行验证。如果存在风险或情况不明确，应如实说明，不要猜测。
8. 检查测试的价值、信号质量、可维护性以及对开发流程的影响。
9. 定稿前执行价值关卡：KEEP、REDO 或 REMOVE。

输出模板：

## Candidate
[behavior/failure mode chosen and why it beat alternatives]

## Strategy
[test level, oracle, data/fixtures, doubles, feedback loop, references used, and why this preserves the real risk]

## Changes
[files changed and concise implementation summary]

## Validation
[command run and result, or why it was not run]

## Review
Verdict: KEEP | REDO | REMOVE
Protected behavior: [...]
Value: [...]
Signal strengths: [...]
False-confidence risks: [...]
Falsification check: [plausible bug and assertion/invariant that would fail]

## Remaining Risk
[what this test does not cover]

工作负载

生成能够模拟有意义用户会话的工作负载，而不是一次性的理想路径测试，也不是对现有运行器的封装。工作负载应覆盖真实用户、API 客户端、运维人员或后台进程在会话期间执行的重要任务，并包含对抗性但符合实际的误用，以及受控变化；这些变化会改变数据、顺序、规模、时序或可选分支，同时保留相同的核心任务。

**从代码证据入手：**检查用户／会话入口、实现、现有测试、测试夹具、命令以及工作负载／E2E 工具。现有工作负载应帮助发现缺口，而不应成为默认实现。确定参与者、目标、易出错的交互以及现有工作负载覆盖情况后，加载 工作负载建模 和 测试预言与断言。仅当工作负载的风险取决于相应维度时，才添加性能、韧性、安全性、用户行为、基于属性的测试、模糊测试或数据相关参考资料。

**原创性门槛：**编辑之前，说明现有工作负载已经覆盖的内容，以及新工作负载将增加的内容。新工作负载必须至少引入以下一项：新的故障面、对抗类别、预言／不变量、状态模型、依赖故障、用户／会话路径、数据形态、时序／顺序维度或回放产物。如果下一步最佳做法只是封装、运行器、种子遍历或参数扩展，就应明确说明，不要称其为生成的工作负载，除非用户提出了此要求。

工作流：

1. 检查用户／会话入口、实现、现有测试、测试夹具、命令以及工作负载／E2E 工具。
2. 清点现有工作负载，并总结其参与者、故障面、预言／不变量、变化范围和回放行为。
3. 确定用户／会话目标，以及新工作负载应揭示的易出错交互。
4. 说明覆盖缺口：现有工作负载遗漏了什么，以及为何这一缺口很重要。
5. 加载与工作负载故障机制相匹配的参考资料。
6. 选择工作负载类型：浏览器流程、API 场景、CLI／会话脚本、后台任务流程、负载配置、合成监控或基于属性／有状态序列的测试。
7. 定义稳定的不变量和正确性断言，而不只是判断任务是否完成；并确定哪些检查应在每一步后、终态时或最终执行。
8. 有意添加对抗类别：无效状态转换、重复／重放操作、过时状态、权限／租户边界、格式错误但有效的数据、边界规模、依赖故障、时序／顺序变化、部分失败或恢复，以及明确的错误处理路径。
9. 使用种子、参数范围、可选分支、数据形态变化和记录的回放细节来添加受控变化。
10. 在适用时使用仓库原生库、测试夹具、辅助工具或工作负载工具进行实现，但不要原封不动地复用现有工作负载作为生成的工作负载。
11. 使用最小且安全的命令进行验证，并报告种子、交互覆盖范围、限制和剩余风险。

输出模板：

## Workload
Actor: [...]
Goal: [...]
Shape: [browser/API/CLI/job/load/synthetic/stateful]
References used: [...]

## Existing Coverage
Existing workloads found: [...]
What they cover: [...]
Gap this workload fills: [...]
Why this is not only a wrapper/runner/seed sweep: [...]

## Coverage
Interactions: [...]
Bug-prone areas: [...]
New failure surface/adversarial class/oracle: [...]
Invariants/assertions: [...]

## Adversarial Model
Misuse paths: [...]
Invalid transitions: [...]
Boundary inputs: [...]
Duplicate/replayed actions: [...]
Permission/tenant edges: [...]
Dependency/time/concurrency faults: [...]

## Variance And Replay
Seed: [...]
Variable inputs/branches/timing/scale: [...]
Replay command or notes: [...]

## Implementation And Validation
Tooling: [...]
Files changed: [...]
Command/result: [...]

## Falsification Check
Plausible bug caught: [...]
Assertion/invariant that fails: [...]
Manual mutation or fault tried, if any: [...]

## Limits
[environment, data, dependency, runtime, cleanup, or flake risk]

review

将测试视为质量门禁，而不是走过场。测试必须通过客户价值、生产价值、支持／调试价值、评审价值或发布信心来证明其存在的必要性。

**从代码证据入手：**检查测试差异和受保护的生产行为。然后加载 测试预言与断言。仅当测试的价值取决于相关问题时，才添加有关数据、替身、反馈循环或变异测试的参考资料。

工作流：

1. 检查测试差异和受保护的生产行为。
2. 确定测试声称要保护的行为或故障模式。
3. 加载评判测试策略、预言、设置、替身和反馈循环所需的参考资料。
4. 检查该行为是否关系到用户、运维人员、客户、API 消费者、发布、支持／调试流程或开发者工作流。
5. 检查断言是否会因有意义的回归而失败，并找出一个可能导致其失败的缺陷。
6. 检查设置、夹具、模拟对象和数据是否保留了真实的故障机制。
7. 检查验证命令是否为最小的有效反馈循环，以及 CI 中的安排是否恰当。
8. 提供 KEEP、REDO 或 REMOVE，并附上证据。

输出模板：

Verdict: KEEP | REDO | REMOVE

Protected behavior:
[what behavior or failure mode this test claims to protect]

Value:
[customer, operator, production, support, release, review, or developer-flow value]

Signal strengths:
[why it would fail for the meaningful regression]

False-confidence risks:
[weak assertions, unrealistic setup, over-mocking, snapshots, flake risk, wrong feedback loop]

References used:
[files that informed the decision]

Falsification check:
[plausible bug and assertion/invariant that would fail]

Required action:
[none for KEEP; exact redesign for REDO; removal reason for REMOVE]

doctor

运行只读的测试套件健康扫描，并提供有证据支持的潜在问题。不要编辑、删除、重写、隔离或禁用测试。

从此处开始：测试套件健康诊断。只有在套件证据表明存在相关问题后，才添加有关不稳定测试、反馈循环、测试金字塔、变异测试、数据、替身或预言的参考资料。

工作流：

1. 确定代码库根目录、语言／框架技术栈、测试运行器、CI 系统、命名约定和测试层级。
2. 清点套件构成和测试命令。
3. 扫描薄弱断言、过度模拟、计时不稳定、共享状态、范围过大的快照、慢速测试、跳过／隔离的测试，以及关键风险覆盖缺失等问题。
4. 在条件允许时检查 CI 和监控信号。
5. 评估可靠性、速度、信号、诊断价值、可维护性、风险覆盖和监控。

输出模板：

## Scope And Evidence
[stack, frameworks, CI, test commands, files inspected, tests run/not run]

## Overall
Grade: [A-F or Low/Medium/High trust]
Confidence: [low/medium/high with reason]

## Top Concerns
1. Severity: [P0-P3]
   Concern: [...]
   Evidence: [...]
   Why it matters: [...]
   Suggested action: [...]

## Rubric
Reliability: [...]
Speed: [...]
Signal: [...]
Diagnostic value: [...]
Maintainability: [...]
Risk coverage: [...]
Monitoring/CI fit: [...]

## Quick Wins And Questions
[small actions and only material follow-up questions]