critique

critique skill の概要

critique とは

critique skill は、複数の専門的な判定役によるレビュー、議論、合意形成を通じて、完了した作業を評価するためのレビュー用ワークフローです。コードレビューや、単発の所感以上の判断が必要な変更レビューに向いています。

どんな人向けか

マージ前に、agent に正確性、品質、見落としを評価してほしいなら critique を使います。レビュー担当者、メンテナー、ビルダーが、Code Review 用の一般的な prompt ではなく、構造化された critique skill を必要とする場面に適しています。

なぜ重要か

主な価値は、不確実な状況でも判断の一貫性を保てることです。各判定役が独立して作業を確認し、自分の発見を検証し、意見の食い違いをすり合わせます。その結果、表面的な称賛、見落とし、単線的なフィードバックを減らせます。

どんな場面に最適か

この skill が最も強いのは、すでに作業が存在していて、それを「作り直す」のでなく「評価する」ことが目的のときです。実装、リファクタリング、自動修正が必要なら、critique は適切なツールではありません。

critique skill の使い方

critique skill をインストールする

npx skills add NeoLabHQ/context-engineering-kit --skill critique でインストールします。repo path は plugins/reflexion/skills/critique なので、この skill は単体ユーティリティとしてではなく、context-engineering kit の中で使う前提です。

明確なレビュー対象を与える

critique の使い方は、変更ファイル、commit 範囲、PR link、特定の懸念点など、具体的なスコープを渡すと最も効果的です。組み込みのヒントは file path、commit、context を受け付け、何も与えない場合は最近の変更だけを対象にします。

最初に適切なファイルを見る

まず SKILL.md を読み、その後に repo 内の近い workflow ファイルや metadata ファイルを確認します。この plugin には scripts/、references/、resources/、rules/ の補助ファイルがないため、基本的な運用指示は skill file 自体にまとまっています。

レビュー意図を定義する prompt を書く

より強い依頼は、たとえば「src/auth.ts と src/session.ts を security、regression risk、test coverage の抜けで critique して」のようになります。一方で「この code を review して」だけだと、どの基準が重要か判定役が判断しにくくなり、critique guide の価値が下がります。

critique skill FAQ

critique は code review 専用ですか？

いいえ。単純な code review より広く、完了した作業、設計判断、実装品質を評価できます。ただし、最終成果物が patch ではなく review report であるべき場合に最も適しています。

critique は通常の prompt とどう違いますか？

通常の prompt は、ふつう 1 つの意見を返します。critique skill は、構造化されたマルチエージェントのプロセス、独立した検証、合意形成を加えるため、信頼性や解釈の競合が重要なときに向いています。

critique は初心者向けですか？

はい、スコープが具体的なら向いています。初心者は、skill にすべてを推測させるよりも、対象の file や変更セットを正確に指定し、重視したい基準を明示したほうが、より良い結果を得られます。

critique を使わないほうがよいのはいつですか？

自動で編集を適用したいとき、課題が単純すぎるとき、あるいはレビュー範囲が曖昧で公平に評価できないときは使わないでください。その場合は、直接的な実装 prompt か、対象を絞った lint/test workflow のほうが速いです。

critique skill を改善する方法

より強いレビュー基準を与える

品質を最も大きく引き上げるのは、critique に何を最適化させるかを伝えることです。たとえば、正確性、security、performance、maintainability、API compatibility、test completeness です。これがないと、判定役は目立つ問題に引っ張られ、本当に気にすべきリスクを見逃すことがあります。

依頼前にスコープを絞る

レビュー対象が大きい場合は、commit、module、feature slice に分割してください。critique skill は、入力が十分に限定されていると、リポジトリ全体の要約ではなく、実際のトレードオフに議論を集中できるため、よりよく機能します。

判定役が確認できる証拠を入れる

関連する file path、期待動作、制約、既知の failure mode を提示してください。そうすると critique skill は意図を推測するのではなく、主張を検証できます。これは、Code Review 向けの critique では特に重要です。

最初のレポートをもとに繰り返す

まず最初の pass で意見の食い違いを洗い出し、その後、リスクの高い指摘や根拠の弱い箇所についてもう一度 critique を依頼します。この反復ループによって、critique skill は一回きりの要約ではなく、より鋭い意思決定支援になります。