mariadb-operator-comment

mariadb-operator コメント

mariadb-operator/mariadb-operator（またはユーザーが指定した別のリポジトリ）にコメントまたは PR レビューを投稿します。このスキルが扱うのは投稿のみです。内容がコードレビューの場合は、先に mariadb-operator-pr-review を実行するか、この会話ですでに生成されている場合はその出力を使い、書式を整えて投稿するためにここに渡してください。

確認なしに投稿しないでください

以下のどのルールよりも、このルールが重要です。 GitHub への投稿は公開され、完全に取り消すのは困難です（編集や削除をしても監査証跡が残り、通知をすでに読んだ人がいる可能性もあります）。また、チーム全体に表示されます。実際に何かを公開するツールを呼び出す前に、次の手順を実行してください。

1. 投稿する正確なテキストを、省略や要約をせず、すべて表示します。
2. 投稿先を正確に示します。owner/repo#number と、通常のコメント、レビューコメント、正式なレビューのいずれなのか（「変更をリクエスト」などの判定も含む）を明記します。
3. AskUserQuestion を使って、ユーザーに確認を求めます（「投稿する」／「先に編集する」／「キャンセル」などの選択肢を用意します）。返答がない場合、曖昧な返答の場合、または別の話題に移った場合は「いいえ」として扱い、推測で投稿しないでください。
4. 明確な承認を得た後に限り、投稿ツールまたは gh コマンドを呼び出します。

ユーザーが最初から「そのまま投稿して」と依頼した場合でも、ツールを呼び出す前に、投稿するテキストを表示して明確な確認を一度得てください。投稿の指示だけでは、何を投稿するかについての確認にはなりません。最後にユーザーが見てから、内容を書式設定または要約している可能性があるためです。

GitHub 認証情報

このスキルから GitHub にアクセスする場合（コメントの投稿または正式なレビュー）、以下の順序でアクセス方法を選択し、前の方法が利用できない場合にのみ次へ進んでください。

1. プロジェクト専用の GitHub MCP ツール（mcp__github-mariadb-operator__add_issue_comment、mcp__github-mariadb-operator__pull_request_review_write、mcp__github-mariadb-operator__add_comment_to_pending_review など）。これらは遅延読み込みツールとして表示される場合があります。その場合は、呼び出す前に ToolSearch でスキーマを読み込みます（例： ToolSearch({query: "select:mcp__github-mariadb-operator__add_issue_comment", max_results: 1})）。
2. mariadb-operator MCP サーバーが接続されていない場合は、プロジェクト専用トークンを使った gh CLI。環境に設定された gh auth セッションではなく、明示的に GITHUB_MARIADB_OPERATOR_TOKEN を使います（GH_TOKEN="$GITHUB_MARIADB_OPERATOR_TOKEN" gh ...）。
3. 上記のどちらも利用できない場合は、汎用の GitHub MCP ツール（mcp__github__*）。
4. 最後の手段として、デフォルトの認証情報を使った gh CLI（明示的なトークンを使わず、通常の gh auth を使用）。上記の方法がいずれも利用できない場合に限ります。

ステップ 1 — 投稿先を特定する

ユーザーが別のリポジトリを指定しない限り、既定のリポジトリは mariadb-operator/mariadb-operator です。イシュー／PR 番号は、ユーザーのメッセージまたは貼り付けられた URL（github.com/<owner>/<repo>/(issues|pull)/<n>）から取得します。イシューか PR かが曖昧な場合、通常のコメントではほとんど問題になりません（GitHub の PR は内部的にはイシューとして扱われるため、どちらにも同じコメントエンドポイントを使用できます）。ただし、正式な PR レビュー（ステップ 3）を投稿する場合は、実際のプルリクエストが必要です。

ステップ 2 — コメント本文を作成する

よくある情報源は 2 つあります。

• 直接の依頼：ユーザーが文章を提示するか、短い作成指示を出します（例：「修正はよさそうだと伝えつつ、移行方法について質問する」）。メンテナーのコメントらしい簡潔で具体的な文面にし、余計な言葉は入れないでください。
• mariadb-operator-pr-review の出力から作成：この会話内に、構造化されたレビュー（判定表と観点ごとの指摘）がすでにある場合、または作成を依頼された場合、その Markdown 出力は GitHub のコメントにそのまま貼り付けられる形式になっています。曖昧に要約し直すのではなく、ほぼそのまま使用してください。短くするために指摘を黙って削らないでください。削る場合は、何を削ったかをユーザーに伝えてください。

GitHub 上で表示されるとおりに、本文を Markdown で正確に整えてください。ステップ 4 でユーザーに見せる内容であり、ステップ 5 で投稿する内容でもあるため、両者の間に食い違いがあってはなりません。

ステップ 3 — 通常のコメントか正式なレビューかを選ぶ

• 通常のコメント（デフォルト）：issue／PR のタイムラインに投稿する 1 件のコメントです。1 つにまとめたレビュー（通常の mariadb-operator-pr-review の出力）、進捗報告、質問、または特定の差分行に紐付かない内容には、これを使用してください。こちらのほうがシンプルで、通常はシンプルな方法が適切です。指摘を行ごとに紐付ける必要が本当にある場合に限り、正式なレビューを選んでください。
• インラインコメント付きの正式な PR レビュー：ユーザーが指摘を差分内の該当行に紐付けることを明示的に希望する場合（例：「各指摘にインラインコメントを残して」）に限り、各指摘に具体的な file:line があることを確認して使用してください。これには、ステップ 5 の説明にあるように、インラインコメントを追加してから送信する保留中レビューが必要です。デフォルトではこちらを選ばないでください。一般的なケースでは、適切に書式を整えた単一のコメントで十分であり、投稿前にユーザーが確認しやすくなります。

ステップ 4 — 投稿内容をそのままユーザーに見せてから、確認を求める

次の内容をそのまま表示します。

Target: <owner>/<repo>#<number> (<issue|PR>)
Mode: <plain comment | formal review: VERDICT>

--- comment body ---
<full rendered Markdown>
--- end ---

続いて AskUserQuestion を呼び出し、投稿、編集、キャンセルのどれにするかを尋ねてください。明示的に「投稿して」と回答されるまでは、この先に進んではいけません。これが前述の必須確認ゲートです。ステップ 5 の処理は、この確認が済むまで何も実行しません。

ステップ 5 — 投稿する

GitHub 認証情報のセクションに従ってアクセス方法を選び、投稿してください。

通常のコメント：

• MCP（プロジェクトスコープまたは汎用）：owner、repo、issue_number、body を指定して add_issue_comment を使用します。issue と PR の両方で使えます。
• プロジェクトトークンを使う gh CLI：

  GH_TOKEN="$GITHUB_MARIADB_OPERATOR_TOKEN" gh issue comment <n> --repo mariadb-operator/mariadb-operator --body "<text>"
  # or for a PR:
  GH_TOKEN="$GITHUB_MARIADB_OPERATOR_TOKEN" gh pr comment <n> --repo mariadb-operator/mariadb-operator --body "<text>"
  

• デフォルトの認証情報を使う gh CLI（GH_TOKEN の上書きを外し、環境に設定された gh auth を使用）：

  gh issue comment <n> --repo mariadb-operator/mariadb-operator --body "<text>"
  # or for a PR:
  gh pr comment <n> --repo mariadb-operator/mariadb-operator --body "<text>"
  

  どちらの gh CLI でも、本文が長い場合や、引用符の扱いに注意が必要な文字が含まれる場合は、--body ではなく --body-file を使って本文を渡してください（先にスクラッチパッドディレクトリへ書き込みます）。シェルのエスケープ処理に悩むより安全です。

インラインコメント付きの正式なレビュー：

• MCP（プロジェクトスコープまたは汎用）：pull_request_review_write を使って保留中レビューを作成し、指摘ごとに add_comment_to_pending_review を呼び出します（各呼び出しに path、line、指摘本文が必要です）。その後、全体の判定（comment / approve / request changes）を指定して、pull_request_review_write で保留中レビューを送信します。
• 複数のインラインコメントを含むレビューに対応する、簡潔な gh CLI の方法はありません。MCP サーバーが利用できず、ユーザーがインラインコメントを希望する場合は、その旨を伝え、無理に脆弱な方法を考え出すのではなく、通常のコメントで代替する案を提示してください。

投稿後は、公開した内容へのリンクまたは参照を添えてユーザーに報告してください。「完了しました」とだけ伝えてはいけません。

このスキルで行わないこと

• PR について「何を伝えるか」は決めません。その役割は mariadb-operator-pr-review（またはユーザー自身の文面）が担います。このスキルは書式を整えて投稿するだけです。
• ユーザーから明示的に依頼されない限り、既存のコメントを編集または削除しません。編集や削除の前にも、同じ確認ゲートを適用します。