wio

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

WIO

WIO is one testing workflow skill with five command modes:

```
scan
```
: find the highest-value test candidates for a codebase, change, or scope.
```
test
```
: write one focused high-value test for a selected behavior, code path, or regression risk.
```
workload
```
: generate a realistic, adversarial workload that adds a new failure surface, oracle, sequence, or coverage dimension with controlled variance, replay, and correctness invariants.
```
review
```
: review a newly written or existing test for customer value, developer value, signal quality, and maintainability.
```
doctor
```
: diagnose test-suite health problems in a codebase or scope.

Commands are accessed through

$wio

Command	What it does	Default reference
`$wio scan [target]`	Find the highest-value test candidates for a codebase, change, or scope.	Behavior To Test Map
`$wio test [target]`	Discover a valuable candidate, pick strategy, write one test, validate, review, and keep only if valuable.	Test Level Selection
`$wio workload [target]`	Generate a realistic workload that adds new bug-finding value beyond existing workloads, with important user tasks, adversarial edge cases, assertions, invariants, and controlled variance.	Workload Modeling
`$wio review [target]`	Review a test for meaningful customer or developer value and return `KEEP` , `REDO` , or `REMOVE` .	Test Oracles And Assertions
`$wio doctor [target]`	Diagnose test-suite health problems in a codebase or scope.	Test Suite Health Diagnostics

Use references/index.md to route from code evidence and candidate failure modes to the right strategy references.

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

```
scan
```
: 为代码库、代码变更或指定范围寻找最高价值的测试候选点。
```
test
```
: 针对选定的行为、代码路径或回归风险，编写一个聚焦型的高价值测试。
```
workload
```
: 生成真实的对抗性工作负载，新增故障面、测试oracle、执行序列或覆盖维度，并支持可控变异、重放和正确性不变量。
```
review
```
: 针对新编写或已存在的测试，从客户价值、开发者价值、信号质量和可维护性方面进行评审。
```
doctor
```
: 诊断代码库或指定范围内测试套件的健康问题。

通过

$wio

调用命令：

命令	功能说明	默认参考文档
`$wio scan [target]`	为代码库、代码变更或指定范围寻找最高价值的测试候选点。	Behavior To Test Map
`$wio test [target]`	发现有价值的测试候选点，选择策略，编写测试，验证、评审，仅保留有价值的测试。	Test Level Selection
`$wio workload [target]`	生成真实的工作负载，在现有工作负载基础上新增查错价值，包含重要用户任务、对抗性边缘场景、断言、不变量和可控变异。	Workload Modeling
`$wio review [target]`	评审测试的客户价值或开发者价值，返回 `KEEP` 、 `REDO` 或 `REMOVE` 结果。	Test Oracles And Assertions
`$wio doctor [target]`	诊断代码库或指定范围内测试套件的健康问题。	Test Suite Health Diagnostics

使用references/index.md，根据代码证据和候选故障模式匹配对应的策略参考文档。

Reference Loading

参考文档加载规则

Do not pick a test strategy from memory or from the nearest existing test alone. First inspect the target code, public behavior, existing tests, fixtures, and test commands. Then identify candidate behaviors or workloads and their likely failure mechanisms. Only after candidates exist, load the references needed to choose the strategy.

For every selected candidate, load at least one strategy reference that matches the failure mechanism before recommending or writing a test:

Load Risk-Based Testing when priorities, customer impact, security/business risk, or limited test capacity decide what comes first.
Load User Behavior Testing when the behavior is a user journey, product workflow, API consumer flow, or operator task.
Load Test Level Selection before choosing unit, component, integration, contract, E2E, workload, synthetic, or monitoring coverage.
Load Test Oracles And Assertions before writing or reviewing assertions, invariants, snapshots, workload checks, or any test whose failure signal is unclear.
Load Test Data And Fixtures when state setup, seeds, factories, cleanup, permissions, or data realism affect signal.
Load Mocking And Test Doubles when a mock, fake, stub, emulator, or real dependency decision could change what risk is preserved.
Load Test Feedback Loops when choosing local, PR CI, nightly, release, canary, synthetic, or production-monitoring placement.
Load specialized references only when the fault mechanism calls for them: property-based testing for broad deterministic input spaces, fuzzing for parsers/untrusted input, mutation testing for weak assertions, performance testing for latency/saturation, resilience testing for dependency failure, security testing for abuse or tenant/auth risk, static analysis for code/config-shape defects, and regression selection when the full suite is too slow.

For commands and repo signals in a topic, load the sibling

tools.md

after the matching

overview.md

shows that topic is relevant. State which reference files informed the chosen strategy.

不要仅凭记忆或现有测试选择测试策略。首先检查目标代码、公开行为、现有测试、fixtures和测试命令。然后确定候选行为或工作负载及其可能的故障机制。只有确定候选点后，再加载选择策略所需的参考文档。

对于每个选定的候选点，在推荐或编写测试前，至少加载一个匹配故障机制的策略参考文档：

当优先级、客户影响、安全/业务风险或测试资源有限时，加载Risk-Based Testing。
当测试对象是用户旅程、产品工作流、API消费者流程或操作员任务时，加载User Behavior Testing。
在选择单元测试、组件测试、集成测试、契约测试、端到端（E2E）测试、工作负载测试、合成测试或监控覆盖范围前，加载Test Level Selection。
在编写或评审断言、不变量、快照、工作负载检查或故障信号不明确的测试前，加载Test Oracles And Assertions。
当状态设置、种子数据、工厂、清理、权限或数据真实性影响测试信号时，加载Test Data And Fixtures。
当mock、fake、stub、模拟器或真实依赖的选择会改变风险保留范围时，加载Mocking And Test Doubles。
在选择本地测试、PR CI测试、夜间测试、发布测试、金丝雀测试、合成测试或生产监控部署方式前，加载Test Feedback Loops。
仅当故障机制需要时，加载专业参考文档：针对广泛确定性输入空间的基于属性的测试、针对解析器/不可信输入的模糊测试、针对弱断言的变异测试、针对延迟/饱和的性能测试、针对依赖故障的韧性测试、针对滥用或租户/认证风险的安全测试、针对代码/配置缺陷的静态分析，以及当全套件测试过慢时的回归测试选择。

对于主题中的命令和仓库信号，在匹配的

overview.md

显示该主题相关后，加载同级的

tools.md

。说明哪些参考文档为所选策略提供了依据。

Command Selection

命令选择规则

Use

scan

when the user asks what to test next, where coverage would matter, how to prioritize testing work, or which tests would reduce user, production, support, or team risk.

Use

test

when the user asks to add a test, improve a specific test, cover a bug, or validate a change with a meaningful automated test.

Use

workload

when the user asks for a realistic user-session workload, scenario generator, traffic model, load/performance scenario, browser journey mix, synthetic user flow, or varied workload that still preserves a stable task goal.

If the user asks to

generate

a workload, treat existing workloads as evidence and reusable infrastructure, not as the deliverable. A generated workload must add at least one new failure surface, adversarial class, oracle/invariant, state model, dependency fault, user/session path, or coverage dimension. A wrapper, runner, seed sweep, parameter expansion, or documentation-only change around an existing workload is not a generated workload unless the user explicitly asked for a runner or the wrapper adds a new oracle or adversarial model.

Use

review

when the user asks whether a test is worth keeping, asks for test review, or after

$wio test

writes or changes a test.

Use

doctor

when the user asks to audit tests, review suite quality, find flaky or low-value tests, inspect CI test health, or explain why a test suite is slow, noisy, or low-signal.

If the user explicitly names a WIO command, follow that mode. If the command is omitted, infer the mode from the request. If no command or target is provided, show the command table and ask what they want to do. If multiple modes apply, start with

scan

before

test

workload

, and use

doctor

only for existing suite health.

当用户询问下一步测试内容、哪些覆盖范围重要、如何优先安排测试工作，或哪些测试能降低用户、生产、支持或团队风险时，使用

scan

命令。

当用户要求添加测试、改进特定测试、覆盖漏洞，或用有意义的自动化测试验证变更时，使用

test

命令。

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

workload

命令。

如果用户要求

generate

工作负载，将现有工作负载视为证据和可复用基础设施，而非交付物。生成的工作负载必须至少新增一个故障面、对抗类别、oracle/不变量、状态模型、依赖故障、用户/会话路径或覆盖维度。除非用户明确要求运行器，或包装器新增了oracle或对抗模型，否则围绕现有工作负载的包装器、运行器、种子扫描、参数扩展或仅文档变更不属于生成的工作负载。

当用户询问测试是否值得保留、要求测试评审，或

$wio test

编写或修改测试后，使用

review

命令。

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

doctor

命令。

如果用户明确指定WIO命令，遵循该模式。如果未指定命令，根据请求推断模式。如果未提供命令或目标，显示命令表并询问用户需求。如果多种模式适用，先使用

scan

，再使用

test

或

workload

，仅针对现有套件健康问题使用

doctor

。

Shared Rules

通用规则

Protect meaningful behavior, not coverage numbers.
Ask what could go wrong before asking what already broke; use that answer to choose tests while the design is still cheap to change.
Establish product, user, production, support, debugging, review, or release risk before recommending or writing tests.
Prefer targets where bugs usually occur: boundaries, permissions, state transitions, persistence, external dependencies, concurrency/time, validation/parsing, migrations, configuration, caching, retries/idempotency, UI workflow joins, and recent churn.
A test is valuable only if it would catch a meaningful regression, save developer time, improve release confidence, or expose a real operational/customer failure mode.
Before keeping a test or workload, name at least one plausible bug it would catch and the assertion or invariant that would fail.
Prefer assertions and invariants that encode the mental model of the behavior, including valid cases, invalid cases, and boundary transitions between them.
Prefer repo-native frameworks, helpers, fixtures, commands, and naming.
Choose the narrowest test level that preserves the real failure mechanism.
Read code and tests before choosing strategy; load targeted references after candidate failure modes are known.
State evidence inspected, commands run, commands not run, and residual risk.
Mark low-value tests
```
REDO
```
or
```
REMOVE
```
, not
```
KEEP
```
.

保护有意义的行为，而非覆盖率数字。
在询问已发生的故障前，先询问可能出现的问题；利用该答案在设计仍易修改时选择测试。
在推荐或编写测试前，明确产品、用户、生产、支持、调试、评审或发布风险。
优先选择易出现bug的目标：边界、权限、状态转换、持久化、外部依赖、并发/时间、验证/解析、迁移、配置、缓存、重试/幂等性、UI工作流衔接点和近期频繁变更的代码。
只有当测试能捕获有意义的回归、节省开发者时间、提高发布信心或暴露真实的运营/客户故障模式时，该测试才有价值。
在保留测试或工作负载前，至少说明一个它能捕获的合理bug，以及会失败的断言或不变量。
优先选择编码行为心智模型的断言和不变量，包括有效场景、无效场景以及它们之间的边界转换。
优先使用仓库原生框架、助手、fixtures、命令和命名规范。
选择能保留真实故障机制的最窄测试层级。
在选择策略前阅读代码和测试；确定候选故障模式后再加载针对性参考文档。
说明检查的证据、执行的命令、未执行的命令以及剩余风险。
将低价值标记为
```
REDO
```
或
```
REMOVE
```
，而非
```
KEEP
```
。

Gotchas

注意事项

Do not write or keep tests just to increase coverage. Covered code with weak assertions is false confidence.
Do not mock away the boundary, state, permission, timing, data, or dependency behavior that creates the real risk.
Do not accept broad snapshots unless the reviewed snapshot is the protected contract and the update path is disciplined.
Do not use a full-suite command when a smaller command validates the changed behavior with the same signal.
Do not weaken assertions to fix flakes. First look for nondeterminism, shared state, timing, retries, order dependence, or external services.
Do not treat green CI as proof the test is valuable. The question is whether the test would fail for the meaningful regression.
Do not accept tests or workloads that only prove completion, truthiness, object existence, status 200, broad snapshot equality, or mock call counts unless that weak signal is explicitly the protected contract.
Do not present a thin wrapper around an existing workload as
```
$wio workload generate
```
. If the change only reruns, parameterizes, documents, or sweeps an existing workload, call it a runner and explain the missing new failure surface.
Do not let subagents write tests or make the final value decision; the main agent owns edits and the final
```
KEEP
```
,
```
REDO
```
, or
```
REMOVE
```
.

不要仅为提高覆盖率而编写或保留测试。有覆盖率但断言薄弱的代码会带来虚假信心。
不要模拟掉产生真实风险的边界、状态、权限、时间、数据或依赖行为。
除非评审的快照是受保护的契约且更新流程规范，否则不要接受宽泛的快照。
当更小的命令能以相同信号验证变更行为时，不要使用全套件命令。
不要为修复不稳定测试而弱化断言。首先查找非确定性、共享状态、时间、重试、顺序依赖或外部服务问题。
不要将CI通过视为测试有价值的证明。关键是测试是否会因有意义的回归而失败。
不要接受仅证明完成、真值、对象存在、状态200、宽泛快照相等或mock调用次数的测试，除非这种弱信号明确是受保护的契约。
不要将现有工作负载的简单包装器作为
```
$wio workload generate
```
的结果呈现。如果变更仅重新运行、参数化、文档化或扫描现有工作负载，应称之为运行器并说明缺少的新故障面。
不要让子代理编写测试或做出最终价值决策；主代理负责编辑和最终的
```
KEEP
```
、
```
REDO
```
或
```
REMOVE
```
决定。

Available Scripts

可用脚本

```
scripts/test-review-reminder.py
```
: hook helper that reminds the active agent to validate and apply
```
$wio review
```
after test files change.
```
scripts/check-wio-report.py
```
: optional checker for saved markdown reports. Use
```
python3 scripts/check-wio-report.py review report.md
```
when a WIO output is written to a file and you need a quick structure check.

```
scripts/test-review-reminder.py
```
: 钩子助手，提醒活跃代理在测试文件变更后验证并应用
```
$wio review
```
。
```
scripts/check-wio-report.py
```
: 可选的已保存markdown报告检查器。当WIO输出写入文件且需要快速结构检查时，使用
```
python3 scripts/check-wio-report.py review report.md
```
。

Subagent Workflow

子代理工作流

When the host supports subagents or parallel agents and user/host policy permits them, use the WIO subagent specs from the official host locations to improve quality without duplicating guidance:

```
wio-candidate-scout
```
: read-only discovery of high-value test candidates and real risk.
```
wio-strategy-critic
```
: read-only challenge of the chosen test level, oracle, doubles, fixtures, and validation loop before implementation.
```
wio-test-reviewer
```
: post-implementation review that returns
```
KEEP
```
,
```
REDO
```
, or
```
REMOVE
```
.

Subagents must inspect targeted code and tests before loading targeted WIO references. They return findings to the main agent; they do not write reports or copy reference content. Claude plugin subagents live in

plugins/wio/agents/

; Claude project subagents can live in

.claude/agents/

; Codex custom agents live in

.codex/agents/

. Installing WIO with

skills add

does not create those runtime files.

For

$wio test

, use this sequence:

Inspect the repo and target code: public behavior, changed paths, existing tests, fixtures, commands, dependencies, state, side effects, and boundaries.
Discover valuable candidates from behavior, risk, bug-prone areas, existing coverage gaps, and code evidence. Use
```
wio-candidate-scout
```
if available.
Load the references that match the selected candidate's failure mechanism, then pick the strategy: test level, oracle, fixture/data setup, doubles, adversarial edge coverage, and validation command.
Use
```
wio-strategy-critic
```
to challenge the proposed strategy before editing when available.
Write one focused test in the main agent, using repo-native patterns.
Validate with the smallest relevant command.
Review the written test. Use
```
wio-test-reviewer
```
if available.
Keep the test only if review returns
```
KEEP
```
; otherwise revise (
```
REDO
```
) or remove (
```
REMOVE
```
).

If subagents are unavailable, perform the same stages in the main agent and explicitly label the review stage.

当宿主支持子代理或并行代理且用户/宿主政策允许时，使用官方宿主位置的WIO子代理规范，在不重复指导的前提下提高质量：

```
wio-candidate-scout
```
: 只读模式发现高价值测试候选点和真实风险。
```
wio-strategy-critic
```
: 只读模式在实现前挑战选定的测试层级、oracle、test doubles、fixtures和验证循环。
```
wio-test-reviewer
```
: 实现后评审，返回
```
KEEP
```
、
```
REDO
```
或
```
REMOVE
```
结果。

子代理必须在加载针对性WIO参考文档前检查目标代码和测试。它们将发现结果返回给主代理；不编写报告或复制参考文档内容。Claude插件子代理位于

plugins/wio/agents/

；Claude项目子代理可位于

.claude/agents/

；Codex自定义代理位于

.codex/agents/

。使用

skills add

安装WIO不会创建这些运行时文件。

对于

$wio test

，遵循以下流程：

检查仓库和目标代码：公开行为、变更路径、现有测试、fixtures、命令、依赖、状态、副作用和边界。
从行为、风险、易出bug区域、现有覆盖缺口和代码证据中发现有价值的候选点。如果可用，使用
```
wio-candidate-scout
```
。
加载与选定候选点故障机制匹配的参考文档，然后选择策略：测试层级、oracle、fixture/数据设置、test doubles、对抗性边缘覆盖和验证命令。
如果可用，在编辑前使用
```
wio-strategy-critic
```
挑战提议的策略。
主代理编写一个聚焦型测试，使用仓库原生模式。
使用最小的相关命令验证。
评审编写的测试。如果可用，使用
```
wio-test-reviewer
```
。
仅当评审返回
```
KEEP
```
时保留测试；否则修订（
```
REDO
```
）或删除（
```
REMOVE
```
）。

如果子代理不可用，主代理执行相同阶段，并明确标记评审阶段。

scan

Find the best parts to test next, the right strategy for each, and the ROI of testing them. This mode is read-only: inspect the repo and existing tests before loading strategy references; do not edit files.

Start with code evidence: inspect product surfaces, target implementation, existing tests, fixtures, and commands. Then use Behavior To Test Map to organize candidates, Risk-Based Testing for ranking tradeoffs, and Test Level Selection only after candidates exist.

Workflow:

Establish product/customer context from repo evidence.
Inventory existing test frameworks, commands, fixtures, CI, and test layers.
Inspect target implementation and nearby tests before choosing a strategy.
Map high-value behavior before low-level helpers.
Identify bug-prone areas in the scope.
Load the references that match each candidate's failure mechanism, then choose the narrowest strategy that preserves the real user or production risk.
Rank candidates by impact, likelihood, confidence gap, and cost.

Output template:

markdown

undefined

寻找下一步测试的最佳部分、每个部分的正确策略以及测试的投资回报率。此模式为只读：在加载策略参考文档前检查仓库和现有测试；不编辑文件。

从代码证据开始： 检查产品界面、目标实现、现有测试、fixtures和命令。然后使用Behavior To Test Map整理候选点，使用Risk-Based Testing进行优先级权衡，仅在确定候选点后使用Test Level Selection。

工作流：

从仓库证据中确定产品/客户上下文。
盘点现有测试框架、命令、fixtures、CI和测试层级。
在选择策略前检查目标实现和附近的测试。
优先映射高价值行为，而非底层助手。
确定范围内的易出bug区域。
加载与每个候选点故障机制匹配的参考文档，然后选择能保留真实用户或生产风险的最窄策略。
根据影响、可能性、信心缺口和成本对候选点进行排名。

输出模板：

markdown

undefined

Scope And Evidence

范围与证据

[target, files/commands inspected, tests/CI found]

[目标、检查的文件/命令、发现的测试/CI]

Ranked Candidates

排名候选点

[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]

undefined

[仅会实质性改变排名的问题]

undefined

test

Write tests only when they protect meaningful behavior. A useful test reduces future user errors, production incidents, support work, debugging time, review time, or release risk. Do not jump straight to implementation or strategy selection.

Start with code evidence: inspect the target behavior, implementation, existing tests, fixtures, and commands. After selecting a candidate, load Test Level Selection before choosing the test layer and Test Oracles And Assertions before writing assertions. Add data, doubles, feedback, or specialized references when those decisions affect signal.

Workflow:

Inspect code, public behavior, existing tests, fixtures, CI, and test commands in the target scope.
Discover the highest-value candidate in scope from product risk, bug-prone areas, code shape, existing coverage gaps, and user/developer impact.
Load the right strategy references for that candidate's failure mechanism.
Pick the strategy from code evidence plus references: test level, oracle, data/fixture setup, doubles, specialized approach, and feedback loop.
State the protected behavior, plausible regression it catches, assertion or invariant that would fail, why it matters, references used, and validation command before editing.
Write one focused test using repo-native style and existing helpers.
Validate with the smallest relevant command. If it is unsafe or unclear, state that instead of guessing.
Review the test for value, signal, maintainability, and developer flow impact.
Apply the value gate before finalizing:
```
KEEP
```
,
```
REDO
```
, or
```
REMOVE
```
.

Output template:

markdown

undefined

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

从代码证据开始： 检查目标行为、实现、现有测试、fixtures和命令。选定候选点后，在选择测试层级前加载Test Level Selection，在编写断言前加载Test Oracles And Assertions。当数据、test doubles、反馈或专业参考文档的选择影响测试信号时，添加这些参考文档。

工作流：

检查目标范围内的代码、公开行为、现有测试、fixtures、CI和测试命令。
从产品风险、易出bug区域、代码形态、现有覆盖缺口和用户/开发者影响中发现范围内最高价值的候选点。
加载与该候选点故障机制匹配的正确策略参考文档。
根据代码证据和参考文档选择策略：测试层级、oracle、数据/fixture设置、test doubles、专业方法和反馈循环。
在编辑前说明受保护的行为、它能捕获的合理回归、会失败的断言或不变量、重要性原因、使用的参考文档和验证命令。
使用仓库原生风格和现有助手编写一个聚焦型测试。
使用最小的相关命令验证。如果不安全或不明确，说明原因而非猜测。
从价值、信号、可维护性和开发者流程影响方面评审测试。
在最终确定前应用价值 gate：
```
KEEP
```
、
```
REDO
```
或
```
REMOVE
```
。

输出模板：

markdown

undefined

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]

[测试层级、oracle、数据/fixtures、test doubles、反馈循环、使用的参考文档，以及该策略保留真实风险的原因]

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]

Verdict: KEEP | REDO | REMOVE 受保护行为: [...] 价值: [...] 信号优势: [...] 虚假信心风险: [...] 证伪检查: [合理的bug以及会失败的断言/不变量]

Remaining Risk

剩余风险

[what this test does not cover]

undefined

[该测试未覆盖的内容]

undefined

workload

Generate workloads that exercise meaningful user sessions, not one-off happy-path tests or wrappers around existing runners. A workload should cover important tasks a real user, API client, operator, or background process performs during a session, with adversarial but realistic misuse and controlled variance that changes data, ordering, scale, timing, or optional branches while preserving the same core task.

Start with code evidence: inspect the user/session entry points, implementation, existing tests, fixtures, commands, and workload/E2E tooling. Existing workloads should reveal gaps, not become the default implementation. After identifying the actor, goal, bug-prone interactions, and existing workload coverage, load Workload Modeling and Test Oracles And Assertions. Add performance, resilience, security, user-behavior, property-based, fuzzing, or data references only when the workload's risk depends on those dimensions.

Originality gate: before editing, state what existing workloads already cover and what the new workload adds. The new workload must introduce at least one of: a new failure surface, adversarial class, oracle/invariant, state model, dependency fault, user/session path, data shape, timing/order dimension, or replay artifact. If the best next step is only a wrapper, runner, seed sweep, or parameter expansion, say that plainly and do not call it a generated workload unless the user asked for that.

Workflow:

Inspect user/session entry points, implementation, existing tests, fixtures, commands, and workload/E2E tooling.
Inventory existing workloads and summarize their actor, failure surface, oracle/invariants, variance, and replay behavior.
Identify the user/session goal and the bug-prone interactions the new workload should expose.
State the coverage gap: what existing workloads miss and why that gap matters.
Load the references that match the workload's failure mechanism.
Choose workload type: browser journey, API scenario, CLI/session script, background-job flow, load profile, synthetic monitor, or property/stateful sequence.
Define stable invariants and assertions for correctness, not only completion, and decide which checks run after every step, at terminal state, or eventually.
Add adversarial classes deliberately: invalid transitions, duplicate/replayed actions, stale state, permission/tenant edges, malformed-but-valid data, boundary sizes, dependency faults, timing/order changes, partial failure or recovery, and explicit error-handling paths.
Add controlled variance with seeds, parameter ranges, optional branches, data shape changes, and recorded replay details.
Implement with repo-native libraries, fixtures, helpers, or workload tooling when useful, but do not reuse an existing workload unchanged as the generated workload.
Validate with the smallest safe command and report seed, coverage of interactions, limits, and residual risk.

Output template:

markdown

undefined

生成能模拟真实用户会话的工作负载，而非一次性的快乐路径测试或现有运行器的包装器。工作负载应覆盖真实用户、API客户端、操作员或后台进程在会话期间执行的重要任务，包含对抗性但真实的误用场景，以及在保持核心任务不变的前提下，改变数据、顺序、规模、时间或可选分支的可控变异。

从代码证据开始： 检查用户/会话入口点、实现、现有测试、fixtures、命令和工作负载/E2E工具。现有工作负载应揭示缺口，而非成为默认实现。确定参与者、目标、易出bug的交互和现有工作负载覆盖范围后，加载Workload Modeling和Test Oracles And Assertions。仅当工作负载的风险依赖于这些维度时，添加性能、韧性、安全、用户行为、基于属性、模糊测试或数据参考文档。

原创性 gate： 在编辑前说明现有工作负载已覆盖的内容，以及新工作负载新增的内容。新工作负载必须至少引入以下一项：新故障面、对抗类别、oracle/不变量、状态模型、依赖故障、用户/会话路径、数据形态、时间/顺序维度或重放工件。如果最佳下一步仅为包装器、运行器、种子扫描或参数扩展，应明确说明，除非用户要求，否则不要称之为生成的工作负载。

工作流：

检查用户/会话入口点、实现、现有测试、fixtures、命令和工作负载/E2E工具。
盘点现有工作负载，总结其参与者、故障面、oracle/不变量、变异和重放行为。
确定用户/会话目标，以及新工作负载应暴露的易出bug交互。
说明覆盖缺口：现有工作负载遗漏的内容及其重要性原因。
加载与工作负载故障机制匹配的参考文档。
选择工作负载类型：浏览器旅程、API场景、CLI/会话脚本、后台作业流、负载配置文件、合成监控或属性/有状态序列。
定义正确性的稳定不变量和断言，不仅是完成状态，还要决定哪些检查在每一步后、终端状态或最终执行。
故意添加对抗类别：无效转换、重复/重放操作、过期状态、权限/租户边缘、格式错误但有效的数据、边界大小、依赖故障、时间/顺序变更、部分故障或恢复，以及显式错误处理路径。
通过种子、参数范围、可选分支、数据形态变更和记录的重放细节添加可控变异。
必要时使用仓库原生库、fixtures、助手或工作负载工具实现，但不要将现有工作负载原封不动地作为生成的工作负载复用。
使用最小的安全命令验证，报告种子、交互覆盖范围、限制和剩余风险。

输出模板：

markdown

undefined

Workload

工作负载

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

参与者: [...] 目标: [...] 形态: [浏览器/API/CLI/作业/负载/合成/有状态] 使用的参考文档: [...]

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: [...]

交互: [...] 易出bug区域: [...] 新增故障面/对抗类别/oracle: [...] 不变量/断言: [...]

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: [...]

捕获的合理bug: [...] 会失败的断言/不变量: [...] 尝试的手动变异或故障（如有）: [...]

Limits

限制

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

undefined

[环境、数据、依赖、运行时、清理或不稳定风险]

undefined

review

Review a test as a quality gate, not as a rubber stamp. The test must justify its existence through customer value, production value, support/debugging value, review value, or release confidence.

Start with code evidence: inspect the test diff and protected production behavior. Then load Test Oracles And Assertions. Add data, doubles, feedback-loop, or mutation references only when the test's value depends on those concerns.

Workflow:

Inspect the test diff and protected production behavior.
Identify the behavior or failure mode the test claims to protect.
Load the references needed to judge the test's strategy, oracle, setup, doubles, and feedback loop.
Check whether that behavior matters to a user, operator, customer, API consumer, release, support/debugging loop, or developer workflow.
Check whether the assertion would fail for the meaningful regression and identify a plausible bug that would make it fail.
Check whether setup, fixtures, mocks, and data preserve the real failure mechanism.
Check whether the validation command is the smallest useful loop and whether CI placement is appropriate.
Return
```
KEEP
```
,
```
REDO
```
, or
```
REMOVE
```
with evidence.

Output template:

markdown

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]

将测试评审视为质量 gate，而非橡皮图章。测试必须通过客户价值、生产价值、支持/调试价值、评审价值或发布信心证明其存在的合理性。

从代码证据开始： 检查测试差异和受保护的生产行为。然后加载Test Oracles And Assertions。仅当测试价值依赖这些问题时，添加数据、test doubles、反馈循环或变异参考文档。

工作流：

检查测试差异和受保护的生产行为。
确定测试声称要保护的行为或故障模式。
加载判断测试策略、oracle、设置、test doubles和反馈循环所需的参考文档。
检查该行为是否对用户、操作员、客户、API消费者、发布、支持/调试循环或开发者工作流重要。
检查断言是否会因有意义的回归而失败，并确定一个会导致其失败的合理bug。
检查设置、fixtures、mocks和数据是否保留了真实的故障机制。
检查验证命令是否为最小的有用循环，以及CI部署是否合适。
返回
```
KEEP
```
、
```
REDO
```
或
```
REMOVE
```
并附上证据。

输出模板：

markdown

Verdict: KEEP | REDO | REMOVE

受保护行为:
[此测试声称要保护的行为或故障模式]

价值:
[客户、操作员、生产、支持、发布、评审或开发者流程价值]

信号优势:
[为何它会因有意义的回归而失败]

虚假信心风险:
[弱断言、不切实际的设置、过度mock、快照、不稳定风险、错误的反馈循环]

使用的参考文档:
[为决策提供依据的文件]

证伪检查:
[合理的bug以及会失败的断言/不变量]

所需操作:
[KEEP无需操作；REDO需明确重新设计；REMOVE需说明删除原因]

doctor

Run a read-only test-suite health scan and report likely concerns with evidence. Do not edit, delete, rewrite, quarantine, or disable tests.

Start with: Test Suite Health Diagnostics. Add flake, feedback-loop, pyramid, mutation, data, doubles, or oracle references only after the suite evidence points there.

Workflow:

Identify repository root, language/framework stack, test runners, CI systems, naming conventions, and test layers.
Inventory suite shape and test commands.
Scan for weak assertions, excessive mocking, flaky timing, shared state, broad snapshots, slow tests, skipped/quarantined tests, and missing critical-risk coverage.
Inspect CI and monitoring signals when available.
Grade reliability, speed, signal, diagnostic value, maintainability, risk coverage, and monitoring.

Output template:

markdown

undefined

运行只读的测试套件健康扫描，报告可能存在的问题并附上证据。不编辑、删除、重写、隔离或禁用测试。

从以下文档开始： Test Suite Health Diagnostics。仅当套件证据指向相关问题时，添加不稳定测试、反馈循环、测试金字塔、变异测试、数据、test doubles或oracle参考文档。

工作流：

确定仓库根目录、语言/框架栈、测试运行器、CI系统、命名规范和测试层级。
盘点套件形态和测试命令。
扫描弱断言、过度mock、时间不稳定、共享状态、宽泛快照、慢测试、跳过/隔离测试和关键风险覆盖缺失问题。
如有可用，检查CI和监控信号。
对可靠性、速度、信号、诊断价值、可维护性、风险覆盖和监控进行评级。

输出模板：

markdown

undefined

Scope And Evidence

范围与证据

[stack, frameworks, CI, test commands, files inspected, tests run/not run]

[技术栈、框架、CI、测试命令、检查的文件、执行/未执行的测试]

Overall

总体评价

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

等级: [A-F 或低/中/高可信度] 信心: [低/中/高及原因]

Top Concerns

主要问题

Severity: [P0-P3] Concern: [...] Evidence: [...] Why it matters: [...] Suggested action: [...]

严重程度: [P0-P3] 问题: [...] 证据: [...] 影响: [...] 建议操作: [...]

Rubric

评分标准

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

可靠性: [...] 速度: [...] 信号: [...] 诊断价值: [...] 可维护性: [...] 风险覆盖: [...] 监控/CI适配性: [...]

Quick Wins And Questions

快速改进点与待解决问题

[small actions and only material follow-up questions]

undefined

[小操作和仅实质性的后续问题]

undefined