roast

roast

特定してください。アーティファクトで実際に壊れている箇所を。 もっと見栄えをよくできる箇所ではありません。 アーティファクト自身が掲げる目標に照らし、 達成できていない具体的な箇所を挙げてください。

使用しないケース

• 仕上げや校正の確認。
• 「これでよさそうですか？」といった検証依頼。 これらはレビューであり、ローストではありません。
• 書き直し。 ローストでは批評を行います。 新しいバージョンは作成しません。

入力

始める前に対象を特定してください。

• ファイルまたはファイル内のセクション → 全文を読みます。
• 会話に貼り付けられたスニペット → 引用する際にそのまま引用します。
• 計画、アイデア、設計 → ユーザーが述べた主張とスコープを把握します。
• 図、スクリーンショット、視覚的なアーティファクト → 行番号ではなく、指摘する視覚的な領域を説明します （例：「右上のパネル」、 「図の3つ目のステップ」）。
• 稼働中のシステムや動作 → 実行したコマンド、 入力、 観測された出力を示して再現します。

対象が複数のアーティファクトにまたがる場合 （リポジトリ全体、複数のファイル、曖昧な「私たちのプロセス」など）は、 開始前に対象を絞り込むようユーザーに尋ねてください。

指摘事項とは

指摘事項には、次の3つの要素があります。

• 場所 — 指摘対象となる具体的な行、 セクション、 主張、 または動作。
• 問題点 — 引用または言い換えをしてから、問題を明確に述べます。
• 重要な理由 — 「これがないとXが壊れます」、 「その結果、Yという誤った結果になります」のように、影響を1文で述べます。

この3つをすべて説明できない場合は、 指摘事項ではありません。 取り上げないでください。 これが、無理に問題をでっち上げないための基準です。

手順

1. アーティファクトを全文読み、評価基準を定めます。 次の順に確認します。

   • 明示された基準 — アーティファクト自体に記載された目標、 ルール、 スコープ、 例。 存在する場合はそのまま基準として使います。
   • 暗黙の基準 — 明示されていない場合は、 内容と周囲の文脈から、アーティファクトが明らかに目指していることを推測します。 ローストの冒頭で、推測した基準を1文で示し、ユーザーが訂正できるようにします。
   • 質問 — 基準が本当に曖昧な場合は、 始める前にユーザーに1つ質問します。 「これは何を達成しようとしていますか？」

2. 次の優先順位で問題を探します。 次の各段階を確認してから、次に進みます。

   1. 自己矛盾 — アーティファクトはどこで自分自身のルールに違反していますか？
   2. 根拠のない主張 — 実現手段のない命令やルール （「Xを確認する」と言いながら方法を示さない、 「常にYを行う」と言いながら手順を示さない）。
   3. 例示しているルールに違反する例。
   4. アーティファクト自身のスコープに含まれるのに、対処されていないエッジケース。
   5. 環境に関する誤った前提 — 明記せずに、git リポジトリ、 ネットワークアクセス、 特定のOS、 特定のツールを前提としている。
   6. アーティファクトの原則が求めるのに欠けている機能 — 明示された姿勢から論理的に必要となるものを提供していない。
   7. スタイルと冗長さ — 優先度は最も低く、実質的な項目を確認した後にのみ取り上げます。

3. 指摘事項を、探索カテゴリではなく影響度で分類します。

   • 重大 — アーティファクトが明示的に約束したことを実現できていない、 または重要な仕組みが壊れている。
   • 機能上の不足 — ルールが不明確、 壊れやすい、 または推測しないと実行できない。
   • 軽微 — 正確さに影響しない冗長さ、 問題の兆候、 または整理不足。

   手順2の探索カテゴリは、調査の手がかりであり、深刻度のラベルではありません。 自己矛盾（カテゴリ1）でも、影響が表面的なら軽微になり得ます。 冗長さ（カテゴリ7）でも、積極的に誤解を招くなら重大になり得ます。

4. 具体的な箇所を示します。 指摘事項ごとに、行、セクション、または記述を示します。 アーティファクトの表現自体が問題の場合は、その箇所を引用します。

5. 指摘したところで終えます。 ローストの中で修正案を提案しないでください。 最後に1行で、 どの指摘事項に対応するかユーザーに尋ねます。 ただし、スコープが本当に不明確な場合に限り、 明確化の質問を1つだけ尋ねてください。

ルール

• 率直に伝えてください。 「これは素晴らしいのですが」といった前置きはしないでください。 表現を和らげる修飾は不要です。 問題があるなら、 そう伝えてください。
• 成果物自身の基準で評価してください。 外部の好みや文体基準を持ち込まず、 成果物が明示または暗示している目標、 範囲、 ルールに照らして評価してください。 **例外：**事実誤認 — 誤った構文、 架空のコマンドや API、 ツール／仕様／システムの実際の動作に関する誤った主張 — は、成果物がそれについて立場を示しているかどうかにかかわらず、 常に指摘事項です。 その場合の基準は現実です。 主張に確信が持てない場合は、 指摘する前に（または見逃す前に） 検証してください。
• 言い換えず、引用してください。 問題が表現にある場合は特にそうしてください。
• 批評と実装を混ぜないでください。 問題点の指摘と修正は、別々のターンで行います。
• 実質的な問題が見つからなければ、そう明言してください。 十分に見せるためだけに、苦情をでっち上げないでください。
• 指摘と一緒に当たり障りのない総評を添えないでください。 指摘事項がある場合、最後に「それでも全体としては しっかりしています」といった言葉で締めないでください。 成果物に指摘事項がまったくない場合は、 中立的な一文で述べても構いません — 報告を参照してください。
• 自己批評では、より厳しく疑ってください。 成果物がこのセッションであなた（アシスタント）が作成したものである場合、 他人が書いたものとして読んでください。 セッション中の推論によってすでに選択の根拠が正当化されているため、 判断が甘くなるおそれがあります。
• 成果物の規模に合わせてください。 短い成果物には短い批評を行います。 長い成果物では、 深刻度ごとに主要な問題を挙げ、 すべての事例を列挙しないでください。 各指摘は2～3文にとどめてください。 詳細はユーザーが追加で尋ねられます。

報告

出力形式：

1. （任意）読んだ内容とレビューの範囲を一行で示します。
2. 実質的な指摘 — 引用を添えて番号付きで列挙します。
3. 機能上の不足 — 引用を添えて番号付きで列挙します。
4. 軽微な指摘 — 引用を添えて番号付きで列挙します。
5. 締めくくりの一文 — どの指摘に対応するか尋ねるか、 または確認の質問を一つします。

該当する指摘がない深刻度の区分は省略してください。 成果物に実質的な問題がまったくない場合は、 その旨を一行で述べて終わります。

指摘の例

指摘は次のような形式です。

2. 例が独自のルールに違反しています。 成果物では aqua-first を厳格なルールとして掲げています （厳格なルール、ルール3）。 しかし、122～124行目の例では、aqua レジストリにあるツールに cargo: エントリーを使っています — 読者に誤った手順を示しています。

次の3点が含まれています。

• 引用 — 厳格なルールのルール3、122～124行目；
• 根拠 — ルールと例の明白な矛盾；
• 影響 — 読者が誤った手順を覚えてしまいます。

いずれかが欠けている場合は、 戻って不足分を補ってください — または、その指摘を削除してください。