publish-message

この会話ですでに確立された結論を、プルリクエストやマージリクエスト、イシューやチケット、チャネルやスレッド、ドキュメントページ、メールなど、他の人が読む場所に投稿します。あらゆるレビュー元からの指摘を受け付け、確立された根拠と対応方針を入力として使います。 投稿先の慣習に沿って投稿文をすべて下書きし、正確な文面と投稿先について承認を得てから、投稿して内容を確認します。

AGENTS.md がタスクトラッカーの設定を参照している場合、その設定にはプロジェクトのトラッカーで検証済みの投稿方法が記録されており、毎回調べ直す必要がありません。該当する設定がない場合や、解決した投稿先が設定の対象外の場合は、手順 1 と 2 を直接実施して投稿先と投稿方法を解決します。

プロセス

1. 投稿先を解決する

ユーザーが指定した投稿先を使います。プルリクエストやマージリクエストの番号、イシューキー、チャネルやスレッド、ページ、宛先などです。指定がない場合は、候補が 1 つだけ当てはまるときに限り、現在のブランチを追跡するリクエストや、会話中に言及されたイシューキーやスレッドから推定します。いずれでも解決できない場合は質問してください。このメッセージは他の人にも見えるため、投稿先は推測せず、確認する必要があります。

投稿先の周辺の文脈を確認します。メッセージが投稿されるリクエストやチケットのタイトルと説明、スレッドの最近のメッセージ、ページの現在の内容などです。手順 3 では、言葉遣い、トーン、掲載位置を決めるためにこれらが必要です。想定読者と公開範囲（公開チャネル、外部の宛先、非公開スレッドなど）にも留意してください。これらはメッセージに含められる内容に影響します。

サービス、正確な投稿先、その周辺の文脈、想定読者がわかれば完了です。

2. 投稿方法を解決する

タスクトラッカーの設定が投稿先を対象としている場合は、そこに記録された方法を使います。投稿先のサービスとは異なるツールを指定する設定（Slack チャネルに対する GitHub トラッカーなど）は対象外です。その場合は、設定がないものとして投稿先を解決してください。それ以外の場合は、まずそのサービスに接続された MCP ツールまたはコネクター（GitHub、GitLab、Jira、Linear、Slack、Confluence、Notion、メールサーバーなど）を優先します。次に、そのサービスの CLI（gh、glab など）を使い、最後に、そのサービス向けにユーザーが設定した認証情報を使って、文書化された API を利用します。Git の認証情報ヘルパーなど、別のツールの保存領域にあるトークンを流用してはいけません。

複数のツールが使え、どれが投稿先に接続するのか不明な場合や、該当するツールがない場合に限り、投稿方法をユーザーに確認してください。投稿先に到達できる方法がない場合は、手順 5 で承認済みの文面をユーザーに渡します。

投稿先に到達できる検証済みの方法が 1 つ決まれば完了です。または、ユーザー自身が投稿することを把握している状態でも完了です。

3. 公開内容をすべて作成する

結論と理由を述べ、読者が該当する挙動を特定するのに十分な背景を示します。 レビューを要約する場合は、すべての指摘を考慮し、それぞれの対応状況、検証上の制約、未解決の要件、まだ必要な判断を維持します。 確認済みのローカルでの変更を、公開先のブランチに反映済みとして説明する前に、公開先にその変更が含まれていることを確認します。 それ以外の場合は、公開待ちのローカル変更として説明するか、公開先での状態は未確認であると明記します。

公開内容に GitHub または GitLab のリクエストへのインライン提案が含まれる場合は、指摘箇所の指定、差分の検証、送信時の対応について、inline-suggestions.md を確認します。 それ以外の場合は、単一のメッセージを作成します。

媒体に合わせてメッセージを調整します。

• 形式：公開先で表示されるマークアップ（GitHub または GitLab の Markdown、Jira または Confluence のマークアップ、Slack の mrkdwn、メールのプレーンテキストまたは HTML）を使い、読者が期待する構成にします。たとえば、リクエストにはレビューの概要、チケットには状況の更新、チャットでは結論を先に述べる短いメッセージとスレッド内の詳細、メールには件名を付けます。
• 長さ：媒体に合わせます。チャットやメールでは結論を先に述べ、短くまとめます。レビューの概要には、すべての指摘を含めます。
• 投稿場所：既存のスレッドや会話がある場合はそこに返信します。ユーザーから依頼があった場合、または既存のスレッドがない場合にのみ、新しいものを始めます。
• メンションと宛先：ユーザーが指定した人だけを含めます。メンションすると相手に通知されます。
• 読者：外部の読者や広範な読者が利用できない、または見せるべきでない内部情報（ファイルパス、ローカルのブランチ名、非公開リンク）は含めません。

会話で使われている言語とは限らず、公開先で使われている言語で書きます。公開先から言語が判断できない場合は、この会話の言語を使うか、判断できなければ確認します。

• ユーザー本人の口調で、簡潔な文章を書きます。各要点は段落を分けます。
• 思考をつなぐには、読点、句点、接続詞を使います。
• 略語の使い方について、プロジェクトのステアリングファイルやスタイルガイドに規則があれば従います。規則がなければ、略語より平易な用語を優先します。たとえば、コードベースでの呼び方でない限り、「NPE」ではなく「null チェック」とします。読み手が書き手と同じ技術的な知識を持っているとは限りません。
• 各要点を理解し、対応するために必要な背景と理由だけを残します。

意味や口調を変えずに、unslop.md に従って、メッセージやインラインコメントから AI らしい言い回しを取り除きます。 すべての指摘に明確な対応状況があり、各項目が公開先に合わせた正確な草案になっていれば完了です。

4. 公開内容全体の承認を得る

サービス、公開先、宛先またはメンション、各項目の最終文面を正確に提示します。インラインコメントがある場合は、それぞれのファイル、差分の左右どちらか、行範囲、理由、置き換え案も含めます。 公開内容全体について、ユーザーの責任のもとで公開してよいか確認し、明示的な承認が得られるまで投稿を待ちます。 ユーザーがこの最終内容一式と公開先をすでに承認している場合は、その承認を使用します。 修正を加えた後は、変更後の内容一式を提示し、改めて承認を得ます。 正確な内容一式と公開先について承認を得たら完了です。

5. 公開して確認する

単一のメッセージの場合は、ステップ 2 の方法で承認済みのテキストを公開し、公開先から読み戻して、テキストと配置を確認します。サービスから読み戻せない場合は、その確認上の制限を報告します。 インラインの提案を含む公開については、inline-suggestions.md の送信処理に従います。 公開先に届く方法がない場合は、そのまま貼り付けられる最終形式で、承認済みのテキストをユーザーに提示します。 一部のみの結果がある場合も含め、公開した URL または参照先を報告します。 承認済みの各項目が、承認済みの公開先で、承認済みの下書きと一致するテキストで公開されている（または制限を明記したうえでユーザーに渡されている）こと、および提示した提案数が実際に投稿された項目数と一致することをもって完了とします。