Writing Checks
Write check files for Continue — markdown files that define AI agents that review pull requests.
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.
---
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 |
File location
Save checks to .continue/checks/<name>.md at the repository root. Only .md files in that directory are scanned — subdirectories are not.
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.
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 pathsBad:
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.
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
Checks vs. tests vs. linting
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?"
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.
Example check
---
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