ketchup

Ketchup

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

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

変更点を集める

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

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

返信を書く

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

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

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

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

その後に選択肢を示します。上のスクリーンショットですでに選択肢が示されている場合は、新しい図を描く代わりに、各スクリーンショットの下にその選択肢の利点とコストを書いてください。そうでなければ、現在の状態がある場合はそれも含めて、選択肢を並べて比較してください。各選択肢について、比較に含めた作業を明記し、ユーザーが得られることと、かかるコストをそれぞれ示してください。選択肢の説明は、ほかの文章に含めないでください。

ビジュアル

ビジュアルとは、スクリーンショット、動画、Mermaid 図、ハーネスがレンダリングするチャートや図、または生成画像です。Markdown の表は、変更前と変更後の列があってもビジュアルではありません。

各ビジュアルは、一目で読める小ささにしてください。ボックスは最大6つ、各ボックス内の語数は最大8語です。「テスト：成功」のようなタグではなく、人が口にするような普通の言葉でラベルを付けてください。文で説明すべき事実は、文章に記載するか、省いてください。

変更が見て分かる場合は、スクリーンショットや動画をリンクだけにせず、インラインで埋め込んでください。画面上の変更が見えるのに画像がない場合は、要約の行に「スクリーンショットはまだありません」と記載し、画面上で何が変わったかもそこで説明してください。事実に基づいて図やチャートを作成してください。つながりを示すには Mermaid 図を、数値を示すにはレンダリングされたチャートを使ってください。数値を捏造しないでください。実際に撮影していない画面の画像を描いたり生成したりしないでください。実在する成果物だけにリンクしてください。