tooluniverse-self-review

セルフレビュー：対象を把握してからレビューする

ユーザーが意図する実際の作業を、それが満たすことを目的としていた目標に照らしてレビューします。特に指定がなければ、簡潔な定性的評価を行います。採点と Qworld Recursive Expansion Tree（RET）の全体表示は、明示的に求められた場合のみ行います。

必ず守るルール

1. 評価の依頼と、評価対象のタスクを混同しないでください。
   「現在の作業を評価して」のような依頼文はレビューの指示です。判定対象となるタスクは、それより前に示されたユーザーの目標であり、作業成果物は現在の結果、実装、草案、計画、または進捗です。
2. eval を採点と同一視しないでください。
   ユーザーがスコア、成績、評価、点数、重み付きルーブリック、Qworld、RET、または数値尺度を明示的に求めない限り、Eval、evaluate、review、assess、check は定性的なレビューを意味します。
3. レビュー対象の作業をでっち上げないでください。
   会話と利用可能な成果物を確認してください。証拠が得られない場合は、何を検証できなかったのかを伝えてください。
4. 通常、プロセスを開示しないでください。
   ユーザーが成果物を求めない限り、シナリオの展開、視点の生成、ルーブリックの作成は内部で行ってください。
5. 一般的な品質テンプレートではなく、ユーザーの目標に照らしてレビューしてください。
   依頼内容、明示された制約、受け入れ基準、リスクから、関連する確認項目を導き出してください。

レビュー対象の特定

レビューを始める前に、次の3つを区別してください。

• 評価の指示：ユーザーが今求めていること（例：「これをレビューして」）。
• 元の目標：作業が満たすべき依頼、問題、または受け入れ基準。
• 作業成果物：確認対象となる回答、コード、ファイル、差分、計画、分析、または現在の進捗。

作業成果物は、次の順で特定してください。

1. 明示的に指定されたファイル、回答、コミット、差分、セクション、または成果物。
2. 現在のメッセージに貼り付けられた内容や添付された内容。
3. 会話がコード変更に関するものであれば、現在のリポジトリの実装または作業ツリーの差分。
4. 直前のユーザー目標に関連する、直近のアシスタントの成果物。
5. タスクが進行中であれば、現在の計画または部分的な進捗。

「現在の作業」「この作業」「ここまでの内容」「刚才的 工作」「当前工作」のような指示語は、上記の順に基づいて解釈してください。複数ターンの会話では、最後のユーザーメッセージは通常、評価の指示であり、元の目標ではありません。

目標と作業成果物を確実に特定できる場合は、質問せずに進めてください。レビュー可能な作業がない場合、または複数の候補があり、対象によってレビュー結果が大きく異なる場合に限り、簡潔な確認質問を1つだけしてください。

モードを1つ選ぶ

モード	選択条件	既定の出力
定性的レビュー（既定）	「現在の作業を評価／レビュー／確認して」「これは完了していますか？」「何が不足していますか？」	証拠に基づく所見、強み、不足点、修正案、完了判定。数値は使いません
チェックリスト	作業をレビューする対象がなく、完了の定義、成功基準、または完全性チェックリストを明示的に求められた場合	タスクに即したチェックリスト。点数は付けません
ルーブリック	評価基準またはルーブリックを明示的に求められているものの、採点は求められていない場合	必須／望ましい／任意に分類した、二択または観察可能な基準。点数は付けません
採点付き評価	スコア、成績、評価、点数、重み付き基準、LLM-as-judge による採点、Qworld、RET、または数値尺度を明示的に求められた場合	指定された尺度または RET を用いた、証拠に基づく採点レビュー

「これを評価して」だけの依頼は、作業成果物が提示されていても定性的レビューに該当します。作業成果物が存在するだけでは、採点は行いません。

評価の作成や実行、採点器の実装、評価テストの作成、またはベンチマークの構築を求める依頼は、エンジニアリングタスクです。eval という語が含まれているという理由だけで、このセルフレビューワークフローに振り分けないでください。

定性レビューのワークフロー（デフォルト）

1. 目標を把握します。 元の目標と重要な制約を、1～2 文で要約します。推測した好みよりも、明示された受け入れ基準を優先します。
2. 成果物を確認します。 実際の会話出力、ファイル、差分、テスト結果、または提供された成果物を使用します。コードの場合は、関連する実装と検証の証拠を確認します。ファイルが確認できる場合は、要約だけを基に判断してはいけません。
3. 焦点を絞ったチェック項目を内部で導き出します。 正確性、完全性、ユーザーの意図、リスク、検証を判断するために必要な、そのタスク固有の観点だけを特定します。求められていない限り、大規模な評価基準を出力してはいけません。
4. 影響の大きい順に指摘事項を報告します。 具体的な問題や未達要件から述べます。各指摘について、証拠を引用し、その結果として生じる影響を説明します。
5. 機能している点を認めます。 意味のある長所を簡潔に挙げます。一般的な称賛で内容を水増ししてはいけません。
6. 優先順位を付けて修正を提案します。 重要な不足を解消できる、最小限の具体的な対応を推奨します。
7. 平易な言葉で判定を示します。 complete、mostly complete、partially complete、not complete、または unable to verify を使用し、短い理由を添えます。判定を数値に置き換えてはいけません。

デフォルトのレビュー形式

タスクに合わせて見出しを調整し、該当しないセクションは省略します。

1. 全体評価 — 対象、目標、判定。
2. 指摘事項 — 影響の大きい順に、証拠を添えて記載します。
3. 機能している点 — 簡潔で具体的な長所。
4. 推奨する次の対応 — 優先順位を付けた修正案。

コードレビューでは、概要よりも、実行可能な欠陥やリグレッションを優先します。可能な場合は、ファイルパスと該当箇所を絞った行番号の範囲を示します。問題が見つからなかった場合は、その旨を明言し、残っている検証上の制約があれば示します。

チェックリストおよび採点なしの評価基準モード

• 固定の観点リストではなく、タスクから基準を導き出します。
• 各項目は、観察可能で、確認できる程度に具体的にします。
• 優先順位付けに役立つ場合は、重要度を示すために must、should、could を使用します。
• 数値、重み、割合、獲得合計、合格率を付けてはいけません。
• 成果物も提供されている場合は、各項目を met、partially met、not met、または not verifiable と示し、簡潔な証拠を添えます。これらのラベルは採点ではありません。
• ユーザーが導出過程の提示を明示的に求めていない限り、シナリオや視点を生成してはいけません。

採点付き評価モード（明示的に求められた場合のみ）

このモードは、依頼に上記の明確な採点シグナルが含まれている場合にのみ使用します。

• ユーザーが尺度や採点方式を提示した場合は、それに従います。
• ユーザーがカスタム方式を指定せずに Qworld、RET、加重評価基準、または LLM-as-judge による採点を求めた場合は、 references/ret-scored-evaluation.md を読み、その指示に従います。
• すべての判定を証拠に基づいて行います。証拠がないことに対して評価を与えたり、元の目標に含まれない基準で減点したりしてはいけません。
• スコアの意味を説明し、影響の大きい不足点と修正案も示します。数値だけでは有用なレビューになりません。

適切な振り分けの例

ユーザーの依頼	適切な解釈
「現在の成果物を評価してください。」	直前の目標に照らして現在の結果をレビューします。定性的に評価し、採点はしません。
「元の依頼を完了したか評価してください。」	現在の成果物を確認し、完了判定を示します。採点はしません。
「この実装に何が不足していますか？」	指摘を最初に示す実装レビューです。採点はしません。
「この機能の完了条件チェックリストを作成してください。」	チェックリストモードです。採点はしません。
「これらの回答の評価基準を作成してください。」	重み付けや採点を求められていない限り、採点なしの評価基準を作成します。
「この回答を 1～10 で採点してください。」	指定された尺度で採点モードを使用します。
「これらの回答を Qworld/RET で採点してください。」	採点付き RET モードを完全に適用します。
「このエージェント用の評価スイートを作成してください。」	このスキルの対象外です。評価エンジニアリングのタスクとして扱います。

根拠と誠実さ

• 観察した根拠と推論を区別してください。
• 出力を確認できない限り、テストに合格したと主張しないでください。
• 差分に問題がないこと、自信に満ちた要約、またはファイルが存在することだけから、作業が完了したと推測しないでください。
• 作業の実行中にユーザーから評価を求められた場合は、確認できる進捗をレビューし、最終結果が存在するかのように装わず、未完了の部分を明示してください。
• 作業の規模に応じた回答にしてください。小さな変更に対して、巨大なフレームワークの説明を返さないでください。