ketchup

ケチャップ

太字またはバッククォートで記されたスキル名、あるいは /<name> として実行されるスキルは、このスキルのディレクトリと同じ階層にある ../<name>/SKILL.md ファイルです。接頭辞なしで記された原則名は ../principle-<name>/SKILL.md です。そのファイルを読み、指示に従ってください。pstack のスキルの大半はユーザー専用なので、あなたのスキルツールでは読み込めません。

/ketchup より前にユーザーが最後に書いたメッセージ以降、このチャットで何が変わったのかをユーザーに伝え、それぞれの変更がどんな意味を持つのかも説明してください。現在の状況だけでなく、各変更がどういうものかを伝えます。そのうえで、ユーザーがあなたの返信だけを見て対応できるよう、返答待ちの項目をすべて示してください。通知やサブエージェントの結果は、ユーザーのメッセージではありません。ユーザーは自分が最後に書いたメッセージ以降のことは何も覚えていないものとして扱ってください。

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

変更点を集める

このターンでは読み取り専用にしてください。すでに得られている情報だけを使って状況をまとめ、コードの変更、アプリやジョブの起動、投稿はしないでください。最後のメッセージ以降のあなた自身の作業、サブエージェントからの報告、このチャットで他の人が送ったメッセージを集めてください。このチャットで触れた各 PR、CI 実行、エージェントの現在の状況を確認してください。記載する数値はそれぞれ根拠となる情報と照合し、訂正する場合はその旨を伝えてください。

アクション項目とは、製品に関する選択、承認、取り消せない操作、あなたにはないアクセス権など、ユーザーにしかできない判断や手順のことです。以前のメッセージで提示されていても、まだユーザーの対応待ちであれば含めてください。あなた自身でまだ進められる作業はアクション項目ではありません。返答を埋めるために、判断を勝手に作り出してはいけません。ユーザーが依頼しておらず、作業にも必要のない手順は、取り消せない操作でユーザーの対応待ちである場合を除き、アクション項目ではありません。その場合は、図を付けずに一行で記載してください。

ひとつの判断項目で、たとえばマージ待ちの複数の PR をまとめて扱うことができます。各項目について、リンク、ユーザーにとっての変更点、判断の根拠、リスク、あなたの推奨案を集めてください。判断に必要な情報がわからない場合は「不明」と記載してください。リンクが手元にない場合は、リンクを記載しないでください。

返信を書く

説明ではなく、判断が必要な点に文字数を使います。何が起きたかは、画像を除いて100語未満に収め、起きたことが少ない場合はさらに短くします。ユーザーに何ももたらさなかった作業は省きます。各項目は30語程度にします。返信の長さは項目数に応じて増やします。2項目なら、画像を除いて合計150語を大きく下回る長さにし、30項目なら、はるかに長くなります。語数制限に合わせるために項目を省いたり、短くしたりしてはいけません。項目の代わりに件数だけを示したり、リンクだけを載せたりしてはいけません。リンクは補足情報として役立ちますが、返信だけで判断できるようにします。

最初に、ユーザーの対応が必要なことを短く示すか、何もないと伝える一文を書きます。詳細はアクション項目に記載します。何も起きておらず、ユーザーの対応も不要なら、その旨だけを伝えて終わります。

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

次に、アクション項目を列挙します。マージ、承認、選択など、ユーザーが決める必要のあることを尋ね、推奨案も示します。最初に行うべき手順は推奨案に含めます。先に済ませる必要があることや、元に戻せないことも同様です。判断に関係する各PR、issue、エージェントの番号またはリンクを、選択肢を比べる場合はその選択肢とあわせて記載します。

判断内容に合わせて形式を調整します。1項目についての判断なら、箇条書きは1つにします。判断内容、推奨案、ユーザーにとっての変更点、推奨の根拠、リスクを記載し、項目名は1回だけ示します。複数の項目が同じ判断に関わる場合は、判断内容と推奨案を最初に1度だけ示し、その下に項目ごとの箇条書きをリスクの高い順に並べます。それぞれの項目について、リンクと名前、ユーザーにとっての変更点、推奨の根拠、リスクを記載します。項目ごとの推奨案が全体の判断と異なる場合に限り、その項目の推奨案を明記します。リスクが低い場合も、各項目のリスクを記載します。たとえば、「低リスク：色だけが変わります」のように書きます。待つことで生じる損失が単なる遅延を超える場合、たとえば期限やデータの損失がある場合に限り、待つことの不利益を記載します。

複数の選択肢から選ぶ判断では、検討したすべての選択肢を示します。それぞれについて、ユーザーが得られるものと、その代償を記載し、該当する場合は現在の状況も示します。これらの代償が判断に伴うリスクとなるため、別途リスクの行は追加しません。上のスクリーンショットで選択肢を示している場合は、それぞれのスクリーンショットの下に、その選択肢の利点と代償を記載します。

ビジュアル

ビジュアルとは画像のことです。スクリーンショット、動画、Mermaid 図、グラフ、または html_preview の後に html_render で表示するために作成したページ内の図や、生成画像が該当します。Markdown の表は、変更前と変更後の列があってもビジュアルではありません。

文章より画像のほうが理解しやすいものは、図にしてください。たとえば、デザインやシステムの仕組み、各 PR の状態を示した PR の積み重ねや依存関係の連鎖、修正前と修正後の比較、選択肢の並列表示などです。ステータス一覧やアクション項目のリスト、何もつながっていないボックスは図にしないでください。テキスト内でもビジュアル内でも、同じ事実を二度示さないでください。

各ビジュアルは、一目で読める大きさにしてください。ボックスは最大 6 個、それぞれ最大 8 語にしてください。ラベルには、「Tests: pass」のようなタグではなく、人が口にするような普通の言葉を使ってください。文章が必要な事実は、テキストに記載するか、記載しないでください。

変更が目で見てわかる場合、スクリーンショットや動画（preview_* または device_* のキャプチャ）をリンクだけにせず、本文に埋め込んでください。目で見てわかる変更にキャプチャがない場合は、概要の行に「スクリーンショットはまだありません」と記載し、その行で画面上の変更内容を説明してください。事実に基づいて図やグラフを作成してください。つながりを示すには Mermaid 図を使い、数値には html_preview の後に html_render で表示するグラフページを使ってください。数値を捏造せず、キャプチャしていない画面の画像を描いたり生成したりしないでください。実在する成果物のみリンクしてください。