azuresql-db-feedback

スキルまたはコンテナーに関する問題を報告する

ユーザーが手作業でバグレポートを作成する必要はありません。適切なレポートに必要な情報はすでにそろっています。使用していたスキル、その指示内容、実際に行う必要があったこと、イメージタグ、ホスト、ランタイム、失敗したコマンド、エラーです。それらを完全なレポートにまとめ、ユーザーが送信できるようにしてください。

リポジトリ： microsoft/azure-sql-database-container（コンテナーとスキルはどちらもここにあります）。

このスキルの記述は、エンジンではなく microsoft/azure-sql-database-container の Issue フォームについてのものなので、エンジンの測定値は適用されません。2026-09-05 に確認済みです。aka.ms/sql-agent-skills-feedback は引き続き、クエリ文字列が削除された状態で https://github.com/microsoft/azure-sql-database-container/issues/new?template=skill_feedback.yml へ 301 を返します。そのため、事前入力済みのレポートには完全な github.com URL を使う必要があります。フィールド ID、ラベル、ドロップダウンの値は、このリポジトリの Issue フォーム定義から取得し、 references/issue-fields.md にも反映されています。URL を作成する前に、このファイルを開いてください。

最も重要な2つのルール

1. 明示的な確認なしに、Issue を作成してはいけません。 まず、タイトルと本文の全文をユーザーに提示し、 明確な許可があるまで待ってください。提案はできますが、依頼されていないのに送信してはいけません。以下のすべての方法に適用されます。 gh CLI も例外ではありません。
2. 送信前に機密情報を伏せてください。 送信内容はすべて公開されます。機密情報の伏せ字化 を参照してください。

ステップ1：スキルの問題ですか、それともコンテナーの問題ですか？

まず正しく判断してください。使う Issue テンプレートが異なります。

実際に何が失敗したのかを考えてください。

問題	対象	テンプレート
スキルがエージェントに誤った指示をした、または必要な指示を伝えなかった	スキル	skill_feedback.yml
誤ったスキルが読み込まれた、または読み込まれるべきなのにスキルが読み込まれなかった	スキル	skill_feedback.yml
スキルをインストールできなかった、またはエージェントがスキルを認識しなかった	スキル	skill_feedback.yml
タスクを成功させるために、スキルの指示から逸脱する必要があった、または回避策が必要だった	スキル	skill_feedback.yml
スキルの指示は正しく、エージェントも正しく対応したのに、コンテナーで問題が起きた（起動しない、クエリでエラーが発生する、エンジンの挙動が予期しない）	コンテナー	bug_report.yml
ユーザーが求める機能をコンテナーが備えていない	コンテナー	feature_request.yml

判断基準は次のとおりです。指示が正しいのにエンジンで問題が起きた場合は、コンテナーのバグです。指示が誤っている、不完全である、または無視された場合は、スキルのバグです。 判断に迷う場合は、ユーザーに尋ねてください。推測してはいけません。また、両方に報告してはいけません。

ユーザーが何かうまくいったことだけを報告している場合は、Issue を作成しないでください。 Discussions を案内して終了してください。

ステップ2：事実を集める

答えがすでに分かっている場合、コマンドを実行する必要はありません。

スキルの問題の場合（特に重要な情報であり、通常は把握できない情報です）：

• スキル名（azuresql-db-rag など）。スキルが読み込まれていない場合は、そのことを伝えてください。それ自体がバグです。
• 使用しているエージェント（Claude Code、GitHub Copilot、Codex、Cursor）。ハーネスによってスキルの挙動が異なり、ユーザーがどれを使ったかはこちらでは把握できません。
• 誤っていた、または欠けていた指示をスキルから引用し、代わりに実際にうまくいった方法を記載してください。 これはレポート全体の中で最も重要な項目です。これがなければスキルを修正できません。
• ユーザーが入力したプロンプト。

コンテナーの問題の場合： イメージタグ、ホスト OS（ドロップダウンの正確な値に対応させてください）、コンテナーランタイムとバージョン、発生したこと、再現するコマンド。コンテナー自体に問題が起きた場合は docker logs sqldb を実行してください。

ステップ 3：情報の伏せ字処理（何かをビルドする前に実施）

ログや再現手順も含め、すべてのフィールドから次の情報を削除してください。

• SA パスワード（MSSQL_SA_PASSWORD、-P <password>、接続文字列の Password= フィールド）。*** に置き換えてください。
• レジストリの認証情報（docker login のユーザー名とパスワード）。
• 接続文字列全体。形式は残し、シークレットだけを削除してください：Server=localhost,1433;Database=appdb;User Id=sa;Password=***;TrustServerCertificate=true。
• ユーザーやその勤務先を特定できる顧客データやアプリケーションデータ、テーブルの内容、埋め込み表現、パス。
• あらゆる種類のアクセストークン。

リポジトリは公開されており、イシューは誰でも閲覧できます。ユーザーのパスワードが漏えいする報告は、報告がないよりも悪いものです。

ステップ 4：下書きを作成して提示する

報告を作成し、全文をユーザーに提示して、登録してよいか確認してください。入力したフィールドと空欄にしたフィールドを伝えてください。値を確実に特定できない場合は、推測せず空欄のままにしてください。スキル名やホスト OS を間違えると、トリアージの方向を誤らせます。

ステップ 5：送信

次の順に試し、最初に成功した方法で停止してください。どちらの場合も、必ず事前にユーザーの確認を得てください。

ティア 1：gh CLI。gh auth status が成功する場合に使用します。イシューはユーザー本人の名義で作成されるため、返信を受け取れます。

gh issue create --repo microsoft/azure-sql-database-container \
  --title "[Skill]: <one-line summary>" \
  --label skills --label needs-triage --label User-filled --label via-skill \
  --body-file <path-to-body>

本文はインラインで渡すのではなく、ファイルに書き込んでください。そうすることで、引用符や改行が保持されます。

ティア 2：入力済み URL。 認証情報もセットアップも不要で、送信前にユーザーが送信内容を正確に確認できます。gh が利用できない場合は必ずこちらを使用してください。

イシューフォームのフィールド ID を使って URL を作成し、ユーザーが開けるように表示してください。フィールド ID、ドロップダウンの値の原文、3 種類すべてのテンプレートの記入例は、references/issue-fields.md にあります。URL を作成する前に、このファイルを読んでください。

検証ルール

• 送信前に、ユーザーが正確なタイトル、本文、ラベルを確認し、同意していること。
• 正しいテンプレートに報告されていること：スキルの問題はスキル用フォームに、コンテナーの問題はコンテナー用フォームに送信します。
• どのフィールドにも SA パスワード、レジストリの認証情報、アクセストークンが含まれていないこと。送信前に本文をもう一度読み直してください。
• 各ドロップダウンの値が、URL を作成する前に開いたフィールド参照ファイルの値と完全に一致すること。または、そのフィールドが省略されていること。
• 入力済みの報告には完全な github.com URL を使用し、aka.ms リンクは決して使用しないこと。aka.ms リンクではクエリ文字列が削除されます。
• ティア 1 は gh issue create が新しいイシューの URL を出力した場合に成功です。ティア 2 はユーザーが URL を開き、フィールドが入力済みのフォームが表示された場合に成功です。どちらも起きなかった場合、報告は登録されていません。登録したかのように伝えず、その旨を伝えてください。

禁止事項

• ユーザーの明確な確認なしに、イシューを作成、コメント、クローズしないでください。
• どのフィールドにも SA パスワード、レジストリの認証情報、アクセストークンを決して含めないでください。
• スキルの問題をコンテナー用テンプレートに登録したり、その逆をしたりしないでください。別々の担当者がトリアージします。
• ドロップダウンの値を推測しないでください。不確かな場合はそのフィールドを省略してください。省略したドロップダウンは未選択になりますが、誤った値を選ぶとトリアージ先を間違えます。
• 入力済みの報告を送るために aka.ms の短縮リンクを使わないでください。これらのリンクではクエリ文字列が削除されるため、入力したフィールドがすべて失われます。完全な github.com URL を使用してください。（aka.ms リンクは、空のフォームを開くためのものです：スキルに関するフィードバック、コンテナーのバグ、コンテナーの機能要望。）
• 既知の制限事項ページに記載されている内容や、すでにオープン中のイシューにある内容について、イシューを作成しないでください。代わりに、該当ページをユーザーに案内してください。
• しつこく勧めないでください。一度だけ提案し、断られたら受け入れて次に進んでください。

参考資料

• references/issue-fields.md：3 つすべてのテンプレートの正確なフィールド ID、ドロップダウンの値（原文どおり）、URL の構築方法と長さ制限、および具体例が記載されています。事前入力済みの URL を作成する前にお読みください。

最新情報の確認

このスキルで使用するツールの、バージョンが固定された信頼できる参考資料です（必要なものをお読みください）。

• GitHub issue-form schema syntax：事前入力で対応するフォームスキーマのフィールド（input、textarea、dropdown）について説明しています。

Microsoft Learn MCP サーバーが設定されている場合は、mcp__microsoft-learn__microsoft_docs_search または mcp__microsoft-learn__microsoft_docs_fetch を使用して、これらの資料の最新バージョンを必要に応じて取得してください。利用は任意です。利用できない場合は、上記の参考資料を信頼できる情報源として扱ってください。