ketchup

Ketchup

/ketchup の前にユーザーが最後に書いたメッセージ以降、このチャットで何が変わったのかを伝え、それぞれの変化がどんな意味を持つのかも説明してください。通知やサブエージェントの結果は、ユーザーが書いたメッセージではありません。ユーザーは最後に書いたメッセージの内容だけを覚えているものとします。

タスクの進め方ではなく、/bro の語り口を使ってください。平易な言葉と短い文を使い、専門用語は避けて、相手に近況を伝えるように話してください。作業の進め方ではなく、ユーザーにとって何が変わったのかを伝えてください。「CI がグリーン」ではなく、「テストは通りました」と言ってください。ユーザーが行動するうえで必要な場合を除き、ハッシュ、ファイルパス、コマンド、ビルド番号、テスト件数は省いてください。PR、ブランチ、エージェントには、独自に付けたラベルではなく、ユーザーが分かる名前を使ってください。事実を理解するのに背景が必要なら、その背景を説明するか、その事実を省いてください。

変更点を集める

このターンでは読み取り専用にしてください。すでに手元にある情報だけで概要をまとめてください。コードを変更したり、アプリやジョブを起動したり、何かを投稿したりしてはいけません。最後のメッセージ以降に自分が行った作業、サブエージェントからの報告、このチャットで他の人が送ったメッセージを集めてください。このチャットで扱った各 PR、CI 実行、エージェントの現在の状態を確認してください。提示する数値は、その根拠となる事実と照らし合わせて確認し、数値を訂正した場合はそのことも伝えてください。

アクション項目とは、製品についての選択、承認、取り消せない操作、アクセス権の不足など、ユーザーだけが行える決定や手順のことです。ユーザーの返答待ちのものは、最後のメッセージより前に挙がったものも含めてください。自分で続けられる作業はアクション項目ではありません。返答を埋めるために、必要のない判断をでっち上げてはいけません。ユーザーが依頼しておらず、作業にも必要のない手順は、取り消せない操作でユーザーの返答待ちの場合を除き、アクション項目ではありません。その場合はアクションを1行だけ示し、ビジュアルは付けず、返答がない場合に何が起きるかは省いてください。

返信を書く

返信全体は、画像を除いて150語を大きく下回る長さにしてください。文章より図のほうが理解しやすい場合は、図を描いてください。たとえば、デザインやシステムの仕組み、PR の積み重ねや依存関係と各 PR の状態、修正前後の比較、選択肢の並列表示などです。つながりのないステータス一覧や枠だけの図は描かないでください。テキストでも図でも、同じ事実を繰り返さないでください。ユーザーに変化のなかった作業は省いてください。文字数が足りなくなったら、アクション項目より先に経緯を削ってください。

冒頭の1文で、ユーザーの対応が必要な項目数、または対応不要であることを伝えてください。何も起きておらず、ユーザーの対応も待っていない場合は、それだけ伝えて終わります。

次に、起きたことを示します。まず図を表示してください。作業で作成したスクリーンショットや動画をインラインで埋め込み、その後に変更点を説明する図を表示します。続いて、ユーザーが依頼した項目ごとに短い箇条書きを1つずつ書き、結果と、完了・進行中・失敗・未確認のどれかを伝えます。各項目は、声に出して話すような言い方にしてください。「インデックスがなかったため検索が遅くなっていました」のように書き、「検索の確認：完了」や「検索が遅い：インデックス不足」のようには書かないでください。途中で見つけて修正したバグがあれば、その名前も挙げてください。各項目は、それだけ読んでも正確に伝わるようにしてください。ユーザーの対応待ちのものを完了としないでください。アクション項目に記載する内容はここでは省いてください。要約の下に、ユーザーの認識や対応事項に影響する短い行を最大3行まで追加してください。その後、自分で続けられる作業が残っていれば、1行で示してください。

次に、アクション項目を通常の箇条書きで列挙します。図や枠にはしないでください。取り消せない操作で、依頼されていないものは1行、それ以外は各項目2行にします。1行目には、推奨する判断とその理由を書き、2行目には、ユーザーが回答しなかった場合にどうなるかを書きます。マージ、承認、選択など、ユーザー自身が決めることを尋ねてください。先に行うべき手順は推奨内容に含めてください。事前に必要なことや、元に戻せないことも同様です。不明な項目は「不明」と記載してください。詳細へのリンクを付けてください。

リストの後には選択肢を示してください。上のスクリーンショットに選択肢がすでに表示されている場合は、新しい図を作らず、各スクリーンショットの下にその選択肢のメリットとコストを書いてください。そうでなければ、現在の状態がある場合はそれも含めて選択肢を並べて比較します。検討対象となった作業をすべての選択肢に含め、それぞれユーザーが得られることと、かかるコストを記載してください。他の本文には選択肢を書かないでください。

ビジュアル

ビジュアルとは、スクリーンショット、動画、Mermaid 図、または /visualize（Cursor）や利用中のハーネスのグラフ作成ツールで作成したグラフや図、生成画像のことです。Markdown の表は、変更前後の列があってもビジュアルではありません。

ビジュアルはひと目で読める小ささにしてください。枠は最大6個、各枠の文字は最大8語です。ラベルには「テスト：成功」のようなタグではなく、人が自然に口にする言葉を使ってください。文で説明が必要な事実は、本文に書くか、省いてください。

画面上の変化が見える場合は、スクリーンショットや動画をリンクだけで済ませず、インラインで埋め込んでください。画面上に変化があるのに画像や動画がない場合は、要約の項目に「スクリーンショットはまだありません」と記載し、画面上で何が変わったかも書いてください。事実に基づいて図やグラフを作成してください。つながりを示すには Mermaid 図を、数値を示すにはグラフを使います（Cursor では /visualize、または利用中のハーネスのグラフ作成ツールを使用してください）。数値を捏造せず、撮影していない画面を図に描いたり生成したりしないでください。実在する成果物だけにリンクしてください。