mcpField
C
check

check

github.com/continuedevテスト・品質645 回インストール
リポジトリ

check について

check は、現在の変更に対して `.continue/checks/` 内の Markdown チェックを実行するローカルランナーです。差分とコミット情報を用意し、バックグラウンドのエージェントで並列実行して結果をまとめます。

主な機能

  1. 01`.continue/checks/` のチェック実行
  2. 02差分とコミット情報ファイルの準備
  3. 03サブエージェントによる並列実行
  4. 04合格・失敗結果の集約
  5. 05検出事項のユーザーによるトリアージ

活用シーン

  1. 01ローカル変更に対するリポジトリチェック
  2. 02プルリクエスト前のブランチ確認
  3. 03自動レビューでの検出事項の整理

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/continuedev/skills --skill check

インストール後、Claude Code で/checkを入力して読み込まれたか確認します。

詳細

ローカルチェックランナー

CI で GitHub の PR チェックが実行されるのと同じように、現在の変更に対してすべての .continue/checks/*.md チェックを実行します。

ワークフロー

1. コンテキストを収集する（コンテキストには取り込まず、ディスクに書き込む）
  • git diff main...HEAD を実行し、/tmp/check-diff.patch に書き込みます。差分が空の場合は、git diff --cached と git diff も試します。
    • 差分の上限：差分が3000行を超える場合、書き込む際に3000行までに切り詰めます。最後の行に \n... (diff truncated at 3000 lines) を追加します。
    • 次のような単一の bash コマンドを使用します：git diff main...HEAD | head -3000 > /tmp/check-diff.patch
  • git log main..HEAD --oneline を実行し、/tmp/check-log.txt に書き込みます。
  • 変更がまったくない場合は、ユーザーに伝えて終了します。
  • これらのファイルを自分のコンテキストに読み戻さないでください。 サブエージェントが直接読み込みます。
2. チェックを見つける
  • .continue/checks/*.md を glob して、すべてのチェックファイルを見つけます。
  • チェックファイルを読まないでください。 ファイル名だけを取り出し、それを使ってチェック名を導き出します（例：code-conventions.md →「コード規約」）。
  • 実行するチェックの一覧をユーザーに提示し、待たずにすぐ続行します。
3. チェックを並列実行する（バックグラウンドエージェント）

チェックファイルごとに、以下の設定でサブエージェントを起動します。

  • subagent_type: "general-purpose"
  • run_in_background: true

次のプロンプト構成を使用します。

You are a code reviewer running an automated check on a pull request.

## Setup
1. Read your check instructions from: {absolute path to .continue/checks/xxx.md}
2. Read the diff from: /tmp/check-diff.patch
3. Read the commit log from: /tmp/check-log.txt

## Your Task
Review the diff according to your check instructions. For each finding:
1. State the severity (Error / Warning / Info)
2. Reference the specific file and line from the diff
3. Explain what's wrong and how to fix it

If everything looks good and you have no findings, say "PASS" and briefly explain why the changes are clean for your check.

If you have findings, say "FAIL" and list them.

Keep your response concise. Do not repeat the diff back. Focus only on actionable findings.
Your final message must start with either "PASS" or "FAIL" on its own line.

すべてのサブエージェントを、1つのメッセージでまとめて起動します（Agent ツールの呼び出しをすべてまとめます）。

4. 結果を収集する

すべてのエージェントが完了したら、各出力ファイルの最後の30行だけを読み込みます：tail -30 {output_file}。PASS または FAIL と書かれているかを判定し、主な指摘事項を抽出します。

5. 結果を要約する

次の要約表を提示します。

| Check | Result |
|-------|--------|
| Code Conventions | Passed |
| Security | 2 errors, 1 warning |
| Test Quality | Passed |
6. 指摘事項をトリアージする

失敗の詳細を大きなブロックにまとめてすべて表示しないでください。代わりに AskUserQuestion を使い、失敗した各チェックの指摘事項を提示して、ユーザーに対応を選んでもらいます。

指摘事項のあるチェックごとに、次の内容を含む AskUserQuestion を1つ提示します。

  • チェック名をヘッダーにする
  • 質問文で指摘事項を簡潔に説明する
  • 次のような選択肢を用意する：
    • 「修正する」— 問題を修正します
    • 「スキップ」— この指摘事項を無視します

失敗したチェックが複数ある場合は、1回の AskUserQuestion 呼び出しに最大4つまで質問をまとめられます（失敗したチェックごとに質問を1つ提示）。失敗したチェックが4つを超える場合は、AskUserQuestion を複数回呼び出します。

その後、ユーザーが修正を選んだ問題を修正し、スキップを選んだ問題はスキップします。

コメント

Markdown 対応