writing-checks

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Writing Checks

编写检查文件

Write check files for Continue — markdown files that define AI agents that review pull requests.

编写Continue的检查文件——这类Markdown文件定义了用于审核拉取请求（PR）的AI Agent。

File format

文件格式

A check is a markdown file with YAML frontmatter and a body. The frontmatter configures metadata. The body is the prompt the agent follows when reviewing a PR.

markdown

---
name: Migration Safety
description: Flag destructive database migrations
---

Your prompt here. This becomes the agent's system prompt
when evaluating the pull request.

检查文件是带有YAML前置元数据和正文的Markdown文件。前置元数据用于配置相关信息，正文则是Agent在审核PR时遵循的提示词。

markdown

---
name: Migration Safety
description: Flag destructive database migrations
---

Your prompt here. This becomes the agent's system prompt
when evaluating the pull request.

Frontmatter fields

前置元数据字段

Field	Required	Type	Description
`name`	Yes	string	Display name shown in GitHub status checks and on continue.dev
`description`	Yes	string	Short description of what the check verifies
`model`	No	string	Model to use. Defaults to Claude Sonnet. Example: `anthropic/claude-sonnet-4-5-20250514`

字段	是否必填	类型	描述
`name`	是	字符串	在GitHub状态检查和continue.dev上显示的名称
`description`	是	字符串	该检查所验证内容的简短描述
`model`	否	字符串	使用的模型，默认是Claude Sonnet。示例： `anthropic/claude-sonnet-4-5-20250514`

File location

文件位置

Save checks to

.continue/checks/<name>.md

at the repository root. Only

.md

files in that directory are scanned — subdirectories are not.

将检查文件保存到仓库根目录下的

.continue/checks/<name>.md

路径中。只有该目录下的

.md

文件会被扫描——子目录不会被扫描。

Writing the body

编写正文内容

The body is an agent prompt. Write it as direct instructions telling the agent what to look for and what to do about it.

正文部分是Agent的提示词。请以直接的指令方式编写，告诉Agent需要关注什么以及如何处理。

Scope narrowly

聚焦单一关注点

One check per concern. A check that tries to cover security, test coverage, and documentation will produce muddled results. Split into three checks.

一个检查文件对应一个关注点。如果一个检查试图同时覆盖安全、测试覆盖率和文档，会导致结果混乱。应拆分为三个独立的检查文件。

Be specific

内容要具体

List concrete criteria. Vague instructions produce vague results.

Good:

Look for these issues in the changed code and fix them:

- New REST endpoints missing request body validation
- Database queries using string interpolation instead of parameterized queries
- Error responses that expose stack traces or internal paths

Bad:

Check that the code is secure.

列出明确的判断标准。模糊的指令会产生模糊的结果。

好的示例：

Look for these issues in the changed code and fix them:

- New REST endpoints missing request body validation
- Database queries using string interpolation instead of parameterized queries
- Error responses that expose stack traces or internal paths

不好的示例：

Check that the code is secure.

What you don't need to write

无需编写的内容

The system automatically prepends a meta prompt that:

Provides the full diff and list of changed files
Instructs the agent to only review changed lines
Prevents the agent from touching pre-existing issues in unchanged code
Restricts edits to changed files only

Don't include instructions like "review the changed files" or "only look at the diff" — that's already handled. Focus on what to look for and how to fix it.

系统会自动添加一个元提示词，其中包含：

提供完整的代码差异和已修改文件列表
指示Agent仅审核已修改的代码行
阻止Agent处理未修改代码中已存在的问题
限制仅对已修改文件进行编辑

无需包含“审核已修改文件”或“仅查看代码差异”这类指令——这些已经由系统处理。请专注于需要关注的内容以及如何修复。

What checks can do

检查文件的能力

The agent running a check can:

Read files in the repository beyond the diff for context
Run bash commands like
```
grep
```
,
```
find
```
, or custom scripts
Use a browser to visit URLs, take screenshots, and verify rendered output
Access the PR diff including file names, additions, and deletions
Use the GitHub CLI (
```
gh
```
) to read PR metadata, comments, or linked issues

运行检查的Agent可以：

读取仓库文件：除了代码差异外，还能读取仓库中的其他文件以获取上下文
运行Bash命令：如
```
grep
```
、
```
find
```
或自定义脚本
使用浏览器：访问URL、截取屏幕截图并验证渲染后的输出
访问PR差异：包括文件名、新增和删除的内容
使用GitHub CLI（
gh
）：读取PR元数据、评论或关联的议题

Checks vs. tests vs. linting

检查文件 vs 测试 vs 代码扫描

Linting handles formatting, style, and static patterns. If a rule can be expressed as a pattern match on syntax, it belongs in a linter.

Tests verify correctness and behavior. If the question is "does this function return the right output," write a test.

Checks handle judgment calls that require understanding context:

"Is this database migration safe to run on a 500M-row table?"
"Does this PR update the API docs to reflect the endpoint changes?"
"Are there security issues in this auth flow a linter wouldn't catch?"

代码扫描（Linting）：处理格式、风格和静态模式。如果规则可以通过语法模式匹配来表达，应该用代码扫描工具实现。

测试：验证正确性和行为。如果问题是“这个函数是否返回正确的输出”，应该编写测试。

检查文件：处理需要上下文理解的判断类问题：

“这个数据库迁移在拥有5亿行数据的表上运行是否安全？”
“这个PR是否更新了API文档以反映端点的变化？”
“这个认证流程中是否存在代码扫描工具无法检测到的安全问题？”

Workflow

工作流程

When the user asks you to write a check:

Understand the codebase — Read relevant source files, configs, and existing checks in
```
.continue/checks/
```
to understand the project's stack, conventions, and what's already covered.
Pick one concern — If the user asks for something broad (e.g. "security"), identify the most impactful single concern for their stack and write a check for that. Offer to write more as follow-ups.
Write concrete criteria — List exactly what to look for. Include good/bad code examples using the project's actual frameworks and patterns when possible.
Define pass/fail clearly — The agent needs to know when to pass and when to fail. Include explicit "no action needed if" conditions where appropriate.
Save the file — Write to
```
.continue/checks/<name>.md
```
.

当用户要求你编写检查文件时：

理解代码库 —— 读取相关源码文件、配置文件以及
```
.continue/checks/
```
目录下已有的检查文件，以了解项目的技术栈、规范以及已覆盖的内容。
选择单一关注点 —— 如果用户的需求比较宽泛（例如“安全”），针对他们的技术栈确定最具影响力的单一关注点并编写对应的检查文件。可以提议后续编写更多相关检查文件。
编写明确的判断标准 —— 列出需要关注的具体内容。如果可能，使用项目实际使用的框架和模式提供好/坏代码示例。
清晰定义通过/失败条件 —— Agent需要知道何时通过检查、何时标记失败。在合适的情况下，明确包含“无需操作的条件”。
保存文件 —— 将文件写入
```
.continue/checks/<name>.md
```
路径。

Example check

示例检查文件

markdown

---
name: Migration Safety
description: Flag destructive database migrations
---

If no migration files were added or changed, no action is needed.

When migrations are present, look for these issues:

- `DROP TABLE` or `DROP COLUMN` without a preceding migration that backs up or migrates the data — add a data migration step or split into separate migrations
- Column type narrowing (e.g., `TEXT` to `VARCHAR(50)`, `BIGINT` to `INT`) without a backfill step — add a backfill or guard against data truncation
- `NOT NULL` constraint added to an existing column without a `DEFAULT` value — add a default or a data backfill migration
- Renaming a column or table that is referenced by application code without updating that code in the same PR — update the references
- A destructive and a constructive change in the same migration file — split into separate migrations for safe rollback

markdown

---
name: Migration Safety
description: Flag destructive database migrations
---

If no migration files were added or changed, no action is needed.

When migrations are present, look for these issues:

- `DROP TABLE` or `DROP COLUMN` without a preceding migration that backs up or migrates the data — add a data migration step or split into separate migrations
- Column type narrowing (e.g., `TEXT` to `VARCHAR(50)`, `BIGINT` to `INT`) without a backfill step — add a backfill or guard against data truncation
- `NOT NULL` constraint added to an existing column without a `DEFAULT` value — add a default or a data backfill migration
- Renaming a column or table that is referenced by application code without updating that code in the same PR — update the references
- A destructive and a constructive change in the same migration file — split into separate migrations for safe rollback