review-image

review-image

画像に対して本格的な作業に取りかかる前に、低コストでビジョンモデルの意見を得たい場合にこのスキルを使用します。

使用する場面

• VRT の簡易的な妥当性確認
• 明らかに壊れている、空白、不正な形式、または不審な入力の検出
• スクリーンショットや生成画像がプロンプトに一致するかモデルに確認
• CI にシンプルな画像レビューチェックを追加

必要条件

• Deno
• OPENROUTER_API_KEY または OPENROUTER_KEY

呼び出し方法

どちらのスクリプトも実行可能な Deno ファイルで、shebang は #!/usr/bin/env -S deno run --allow-env --allow-net --allow-read です。直接実行してください。deno run でラップする必要はありません。

APM でスキルをインストールした場合、スクリプトは ~/.claude/skills/review-image/scripts/ にあります。以下の例では、シェルによって展開される ~/... 形式を使用しています。シェル以外の exec コンテキスト（例：shell: true を指定しない child_process.spawn）では、~ と $HOME はそのままの文字列として扱われます。その場合は、解決済みの絶対パス（/Users/<you>/.claude/skills/review-image/scripts/...）に置き換えてください。

フラグは位置引数の前、間、後のいずれにも指定できます。--model は --model X と --model=X の両方を受け付けます。どちらのスクリプトも、プログラムの出力は stdout に、ログとエラーは stderr に書き込みます。ただし、jq や JSON.parse に直接渡して安全に処理できるのは、JSON を出力するモード（CI ゲートは常に、フリーフォームは --json 指定時）のみです。フリーフォームのデフォルトモードは JSON ではなく、通常の文章を出力します。

スクリプト

フリーフォームレビュー — review-image.ts

~/.claude/skills/review-image/scripts/review-image.ts <image-path-or-url> "<prompt>" [--model <id>] [--json]

# example with flag interleaved with positionals:
~/.claude/skills/review-image/scripts/review-image.ts ./shot.png "VRT diff broken?" --model google/gemini-2.5-flash

デフォルトの出力：stdout にプレーンテキストの文章（モデルの回答を単一ブロックで出力）。

--json を指定すると、stdout に単一の JSON オブジェクトが出力され、jq や JSON.parse に安全に渡せます。

{
  "id": "gen-...",
  "model": "<resolved>",
  "text": "<freeform answer>",
  "usage": { "prompt_tokens": 123, "completion_tokens": 45, "total_tokens": 168, "cost": 0.0001 },
  "raw": { /* full upstream OpenRouter response, opaque */ }
}

回答は .text を参照してください。コストの把握には .usage.cost（USD）と .usage.total_tokens を使用します。

終了コード：成功時は 0、エラー時（API キーの不足、ネットワーク／HTTP の失敗、不正な形式のレスポンス）は 1 です。

CI ゲート — review-image-ci.ts

~/.claude/skills/review-image/scripts/review-image-ci.ts <image-path-or-url> "<prompt>" [--model <id>]

stdout には常に単一の JSON オブジェクトが出力されます（--json フラグは警告なしで無視されます。出力は常に JSON です）。

{
  "decision": "pass",
  "summary": "<short reason>",
  "issues": [],
  "model": "<resolved>",
  "usage": { "prompt_tokens": 123, "completion_tokens": 45, "total_tokens": 168, "cost": 0.0001 },
  "rawText": "<unparsed model reply>"
}

issues は常に文字列の配列です（null になることも、省略されることもありません）。pass の場合は空で、fail の場合は 1 つ以上の理由が格納されます。usage のキーはフリーフォームスクリプトと一致しますが、OpenRouter からパススルーされた追加のフィールド（例：is_byok、*_details）が含まれる場合があります。安定した仕様として扱うのは、記載されている 4 つのキー（prompt_tokens、completion_tokens、total_tokens、cost）です。

CI ゲートは、モデルへの指示を厳格な JSON Schema 形式にするため、プロンプトを内部でラップします。ゲートの条件は、<prompt> に平易な英語で記述してください。スキーマ、書式の指示、「JSON で回答してください」といった指示は含めないでください。これらは自動的に追加されるため、独自の指示を加えると競合する可能性があります。

終了コード：

• 0 — decision: pass
• 2 — decision: fail
• 1 — スクリプトエラー（API キーの不足、ネットワーク／HTTP の失敗、不正な形式のモデルレスポンス）。CI では pass とも fail とも扱わないでください。$? -ne 0 だけを条件にゲートを設定しないでください。

プロンプトの作成

<prompt> 引数には、確認する内容を平易な英語で記述します。以下を出発点として使用してください。

CI ゲート（合格条件の形式） — どうあるべきか、何を失敗とみなすかを記述します。「これは壊れていますか？」のような曖昧な表現は避けてください。ピクセルアートや意図的に低解像度のコンテンツは、曖昧な表現のゲートでは誤って失敗になることがあります。

"This image is {expected: a Playwright screenshot of /dashboard / a generated cactus illustration / ...}. Pass if it shows recognizable intended content (any style, including pixel art, low-res, or stylized). Fail only if blank, all-black/all-white, corrupted, an error page, or visibly malformed."

フリーフォーム（診断形式） — 文章での回答を具体的なアクションにつなげられるよう、詳細を尋ねてください。

"This image is supposed to be {expected subject}. Describe what you see and call out any visual artifacts, broken layout, color anomalies, or signs of file corruption."

デフォルトモデル

google/gemini-2.5-flash-lite

呼び出しごとに --model で、または全体に OPENROUTER_MODEL で上書きできます。