writing-checks

チェックの作成

Continue 用のチェックファイルを作成します。これは、プルリクエストをレビューする AI エージェントを定義する Markdown ファイルです。

ファイル形式

チェックは、YAML フロントマターと本文で構成される Markdown ファイルです。フロントマターでメタデータを設定します。本文は、PR のレビュー時にエージェントが従うプロンプトです。

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

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

フロントマターのフィールド

フィールド	必須	型	説明
name	はい	文字列	GitHub のステータスチェックと continue.dev に表示される名前
description	はい	文字列	チェックで検証する内容の簡単な説明
model	いいえ	文字列	使用するモデル。デフォルトは Claude Sonnet です。例：anthropic/claude-sonnet-4-5-20250514

ファイルの配置場所

リポジトリのルートにある .continue/checks/<name>.md にチェックを保存します。このディレクトリ内の .md ファイルのみがスキャンされ、サブディレクトリは対象外です。

本文の作成

本文はエージェントへのプロンプトです。エージェントが確認すべきことと、それに対して行うべきことを直接指示する形で記述します。

対象を絞る

1 つの懸念事項につき、チェックを 1 つ作成します。セキュリティ、テストカバレッジ、ドキュメントをまとめて扱おうとすると、チェックの結果がまとまりません。3 つのチェックに分けてください。

具体的に書く

具体的な基準を列挙します。曖昧な指示では、結果も曖昧になります。

良い例：

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.

記述する必要がないこと

システムは、次の内容を含むメタプロンプトを自動的に追加します。

• 完全な差分と変更されたファイルの一覧を提示する
• 変更された行のみをレビューするようエージェントに指示する
• 変更されていないコードにある既存の問題にエージェントが手を出さないようにする
• 編集を変更されたファイルのみに制限する

「変更されたファイルをレビューする」や「差分だけを見る」といった指示は含めないでください。これらはすでに処理されています。何を確認し、どのように修正するかに集中してください。

チェックでできること

チェックを実行するエージェントは、次のことができます。

• コンテキストを把握するため、差分以外のリポジトリ内のファイルを読み取る
• grep、find、カスタムスクリプトなどの bash コマンドを実行する
• ブラウザーを使用して URL にアクセスし、スクリーンショットを撮影し、レンダリング結果を確認する
• ファイル名、追加、削除を含む PR の差分にアクセスする
• GitHub CLI（gh）を使用して、PR のメタデータ、コメント、関連する Issue を読み取る

チェック、テスト、Lint の違い

Lint は、フォーマット、スタイル、静的なパターンを扱います。構文のパターンマッチングで表現できるルールは、リンターで扱います。

テストは、正しさと動作を検証します。「この関数は正しい出力を返すか」という問いには、テストを書きます。

チェックは、コンテキストの理解が必要な判断を扱います。

• 「このデータベースのマイグレーションは、5 億行のテーブルに対して安全に実行できますか？」
• 「この PR は、エンドポイントの変更を反映するように API ドキュメントを更新していますか？」
• 「この認証フローには、リンターでは検出できないセキュリティ上の問題がありますか？」

ワークフロー

ユーザーからチェックの作成を依頼された場合：

1. コードベースを理解する — 関連するソースファイル、設定、.continue/checks/ 内の既存のチェックを読み、プロジェクトの技術スタック、規約、すでにカバーされている内容を把握します。
2. 懸念事項を 1 つ選ぶ — ユーザーの依頼が広範な場合（例：「セキュリティ」）、その技術スタックにとって最も影響の大きい懸念事項を 1 つ選び、それを対象とするチェックを作成します。追加のチェックについては、後続の依頼として作成を提案します。
3. 具体的な基準を記述する — 確認する項目を正確に列挙します。可能であれば、プロジェクトで実際に使われているフレームワークやパターンを用いて、良いコード例と悪いコード例を含めます。
4. 合格・不合格の基準を明確にする — エージェントが合格と不合格を判断できるようにします。適切な場合は、「対応不要」の条件を明記します。
5. ファイルを保存する — .continue/checks/<name>.md に保存します。

チェックの例

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