使い方
- インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
- 必要なツール、認証情報、対応環境を原文で確認します。
- 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/elliottlawson/open-review --skill review-as-json開始前の確認
- 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
- スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
リポジトリの原文
見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。
Review as JSON
Run /review on this change and follow it exactly.
Emit the result as a single JSON object instead of a prose report:
json
{
"verdict": "approve | changes_needed | hold",
"summary": "One or two sentences on the change overall.",
"findings": [
{
"severity": "critical | warning | info",
"type": "issue | suggestion | question",
"category": "mission | architecture | implementation | craft | security | performance",
"title": "Short imperative, e.g. 'Sanitize user input before query'",
"description": "What it is, why it matters, and the consequence.",
"file": "path/to/file.ts",
"line": 42,
"suggestedFix": "Optional concrete fix."
}
],
"passes": {
"mission": "met | missing | different | unclear",
"architecture": "ok | concern | blocking",
"implementation": "ok | concern | blocking",
"craft": "ok | concern | blocking",
"security": "ok | concern | blocking",
"performance": "ok | concern | blocking"
},
"sectionSummaries": {
"mustFix": "1-2 sentences on the critical findings, if any.",
"shouldFix": "1-2 sentences on the warnings, if any.",
"questions": "1-2 sentences on the questions, if any.",
"suggestions": "1-2 sentences on the suggestions, if any."
}
}Rules for the output:
- Emit only the JSON object. No preamble, no commentary, no markdown fences around it.
- Severity.
criticalblocks merge (bugs, security holes, data loss).warningshould be addressed but isn't a blocker.infois a note. - Summary. Never restate the verdict ("This PR is approved", "Changes requested") — the presentation layer renders it. The summary answers why.
- sectionSummaries. Explain the underlying theme ("Missing input validation across the new endpoints"), never just count findings.
- Type.
questionis something you need answered rather than a defect.suggestionis an optional improvement. Everything else is anissue. - Category. Every finding's
categoryis the pass that found it — this is how the passes show up in CI output. - Verify before you flag still applies. Every finding needs a concrete file, line, and consequence. If you can't verify it, make it a
question. - If there are no findings, emit an empty
findingsarray and anapproveverdict.
