zombies

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

ZOMBIES

Arguments

参数

Raw arguments: $ARGUMENTS

If arguments are provided, treat them as a free-text feature description (e.g. "sign-in code login flow", "image upload validation"). Locate the relevant code and tests yourself using

Grep

Glob

If arguments are empty, run

git diff main...HEAD

and use the diff as the feature scope.

原始参数：$ARGUMENTS

若提供参数，则将其视为自由文本形式的功能描述（例如“登录验证码流程”“图片上传验证”）。请自行使用

Grep

Glob

定位相关代码和测试。

若未提供参数，则运行

git diff main...HEAD

并将差异内容作为功能范围。

Goal

目标

Identify the most valuable tests to write for the feature, using ZOMBIES as a thinking tool. The output is a list of test ideas the user can stub out themselves — do not write or stub the tests.

ZOMBIES stands for:

Zero — no inputs / empty state
One — a single input / the happy path
Many — multiple inputs, ordering, pagination, concurrency
Boundaries — limits, off-by-one, min/max lengths, timing edges, type edges
Interface — the contract/shape of the public API (return types, status codes, redirects)
Exceptions — invalid input, failures, expired/used/missing state, auth failures
Simple scenarios — the common everyday usage paths a real user takes

Skip categories that don't apply. A read-only endpoint may have nothing under "Many". A pure validator may have nothing under "Interface". Only list tests that are genuinely worth writing — quality over coverage.

以ZOMBIES为思考工具，确定为该功能编写的最具价值的测试。输出内容为用户可自行搭建的测试思路列表——请勿编写或搭建测试代码。

ZOMBIES代表：

Zero — 无输入/空状态
One — 单一输入/正常路径
Many — 多输入、排序、分页、并发
Boundaries — 限制值、差一错误、最小/最大长度、时间边缘、类型边缘
Interface — 公共API的契约/结构（返回类型、状态码、重定向）
Exceptions — 无效输入、失败场景、过期/已使用/缺失状态、认证失败
Simple scenarios — 真实用户日常使用的常见路径

跳过不适用的类别。只读端点可能没有属于“Many”的测试内容。纯验证器可能没有属于“Interface”的测试内容。仅列出真正值得编写的测试——质量优先于覆盖率。

Instructions

操作步骤

1. Locate the feature

1. 定位功能

With args: search the codebase with
```
Grep
```
/
```
Glob
```
for files matching the description. Read the implementation files (controllers, models, actions, validators) and the existing test file if one exists.
Without args: run
```
git diff --name-status main...HEAD
```
and
```
git diff main...HEAD
```
, then read the changed implementation files. Skip auto-generated files (lockfiles, compiled assets, generated route/type definitions).

有参数时：使用
```
Grep
```
/
```
Glob
```
在代码库中搜索与描述匹配的文件。阅读实现文件（控制器、模型、动作、验证器）以及现有测试文件（如果存在）。
无参数时：运行
```
git diff --name-status main...HEAD
```
和
```
git diff main...HEAD
```
，然后阅读有变更的实现文件。跳过自动生成的文件（锁定文件、编译后的资源、生成的路由/类型定义）。

2. Generate ZOMBIES suggestions

2. 生成ZOMBIES测试建议

For each ZOMBIES letter, ask: is there a test here that would catch a real bug or document real behaviour? If yes, list it. If no, skip the letter.

Suggestion quality bar:

Specific, not generic. "Test maximum email length (255 chars)" beats "Test boundaries".
Reference real values from the code when possible — column lengths from migrations, expiry windows from config, validation rules from FormRequests.
One test per bullet. Don't combine "test A and B" into one line.
Phrase as a behaviour to verify, not as a method name. "Expired sign-in code returns 422" beats "test_expired_code".

针对ZOMBIES的每个字母，思考：这里是否有能发现真实bug或记录真实行为的测试？ 如果有，列出它；如果没有，跳过该字母。

建议质量标准：

具体而非泛化。“测试邮箱最大长度（255字符）”优于“测试边界值”。
尽可能引用代码中的真实值——迁移中的列长度、配置中的过期窗口、FormRequests中的验证规则。
每个项目对应一个测试。不要将“测试A和测试B”合并到一行中。
以需验证的行为表述，而非方法名。“过期验证码返回422状态码”优于“test_expired_code”。

3. Output the report

3. 输出报告

Group by feature area first (if the diff covers multiple features), then by ZOMBIES letter within each. Use this format exactly:

undefined

首先按功能区域分组（如果差异内容涵盖多个功能），然后在每个区域内按ZOMBIES字母分组。严格使用以下格式：

undefined

[Feature Area]

[功能区域]

Boundaries

Email field rejects values longer than 255 chars (matches migration column)
Sign-in code expires exactly at the 15-minute mark

Exceptions

Expired code returns a validation error
Already-used code cannot be redeemed twice
Submitting code for an unknown email fails silently (no user enumeration)

Simple

Requesting a code emails the user and creates a
```
SignInCode
```
row
Submitting a valid code logs the user in and consumes the code


If multiple features are in scope, repeat the block per feature with its own `##` heading.

End with a one-line summary: `X test ideas.`

If there's nothing worth testing (e.g. trivial rename, pure config change), output exactly:

✅ Nothing worth writing tests for.

undefined

Boundaries

邮箱字段拒绝超过255字符的值（与迁移列定义一致）
验证码在15分钟整时过期

Exceptions

过期验证码返回验证错误
已使用的验证码无法重复兑换
为未知邮箱提交验证码时无提示失败（避免用户枚举）

Simple

请求验证码时向用户发送邮件并创建
```
SignInCode
```
记录
提交有效验证码后登录用户并标记该验证码已使用


如果范围包含多个功能，为每个功能重复上述区块并使用各自的`##`标题。

结尾添加一行总结：`X个测试思路。`

如果没有值得测试的内容（例如 trivial 的重命名、纯配置变更），请严格输出：

✅ 没有值得编写的测试内容。

undefined

Rules

规则

Don't stub the tests. This skill outputs ideas only — the user writes the tests.
Skip ZOMBIES letters that don't apply. Do not write "(none)" placeholders. Quality over coverage.
Be specific. Reference actual lengths, timings, statuses, route names from the code. Generic suggestions are worthless.
One behaviour per bullet. No "and" joining two tests.
No implementation hints. Don't suggest assertions, factories, or test setup — just what to verify.
Group by feature first, then by letter. Don't dump everything under one giant ZOMBIES list when the diff spans multiple features.
No preamble. No "Here are the tests I'd suggest…". Start with the first
```
## [Feature Area]
```
heading.
No closing advice beyond the
```
X test ideas.
```
summary line.

请勿搭建测试代码。该技能仅输出思路——由用户编写测试。
跳过不适用的ZOMBIES字母。不要写“(无)”作为占位符。质量优先于覆盖率。
保持具体。引用代码中的实际长度、时间、状态码、路由名称。泛化的建议毫无价值。
每个项目对应一个行为。不要用“和”连接两个测试。
不要提供实现提示。不要建议断言、工厂或测试设置——只需说明要验证的内容。
先按功能分组，再按字母分组。当差异内容涉及多个功能时，不要将所有内容放在一个庞大的ZOMBIES列表下。
不要添加开场白。不要写“以下是我建议的测试……”。直接以第一个
```
## [功能区域]
```
标题开头。
除
X个测试思路。
总结行外，不要添加收尾建议。