| name | azuresql-db-feedback |
| description | Reports a bug or files feedback about the azuresql-db-* agent skills themselves, or about the Azure SQL Database container (the local Azure SQL Database engine, Private Preview). Use when the user says a skill or the container "did not work", hit an error, behaved unexpectedly, or is missing something; and when they say "report a bug", "file an issue", "open a GitHub issue", "request a feature", "give feedback", or "tell the team". Also use when you, the agent, had to deviate from an azuresql-db-* skill or work around a defect in one to finish a task: that is a bug in the skill and it is worth reporting, even if the task ultimately succeeded. Decides whether the problem belongs to the SKILL or to the CONTAINER, since they use different issue templates, then builds a complete prefilled GitHub issue from context you already have. Never submits anything without explicit confirmation from the user. |
Report a problem with the skills, or with the container
The user should never have to assemble a bug report by hand. You are already holding what a good one needs:
which skill you were following, what it told you to do, what you actually had to do, the image tag, the host,
the runtime, the failing command, and the error. Your job is to turn that into a complete report and hand it
to the user to submit.
Repository: microsoft/azure-sql-database-container (both the container and the skills live here).
The two rules that matter most
- Never create an issue without explicit confirmation. Show the user the full title and body first and
wait for a clear yes. You may offer; you may never submit unasked. This applies to every path below,
including the
gh CLI.
- Redact before you send. Everything submitted is public. See Redaction.
Step 1: skill problem, or container problem?
Get this right first: they use different issue templates.
Ask yourself what actually failed.
| The problem | It belongs to | Template |
|---|
| A skill told the agent to do the wrong thing, or failed to say something it needed to say | the skill | skill_feedback.yml |
| The wrong skill loaded, or no skill loaded when one should have | the skill | skill_feedback.yml |
| A skill would not install, or the agent never picked it up | the skill | skill_feedback.yml |
| You had to deviate from the skill or work around it to make the task succeed | the skill | skill_feedback.yml |
| The skill said the right thing, the agent did the right thing, and the container still failed (will not start, query errors, engine behaves unexpectedly) | the container | bug_report.yml |
| The container is missing a capability the user wants | the container | feature_request.yml |
The test that settles it: if the instructions were correct and the engine still broke, it is a container
bug. If the instructions were wrong, incomplete, or ignored, it is a skill bug. When genuinely torn, ask the
user. Do not guess, and do not file both.
If the user is only reporting that something worked well, do not open an issue. Point them at
Discussions and stop.
Step 2: gather the facts
Only run a command if you do not already know the answer.
For a skill problem (the important ones, and the ones we are otherwise blind to):
- Which skill, by name (
azuresql-db-rag, etc). If none loaded, say so: that is itself the bug.
- Which agent you are (Claude Code, GitHub Copilot, Codex, Cursor). Skills behave differently across
harnesses and we cannot see which one the user ran.
- The instruction that was wrong or missing, quoted from the skill, and what actually worked instead.
This is the single most valuable field in the whole report. Without it we cannot fix the skill.
- The prompt the user gave you.
For a container problem: the image tag, the host OS (mapped to the exact dropdown value), the container
runtime and version, what happened, and the commands that reproduce it. docker logs sqldb if the container
is what broke.
Step 3: redaction (do this before you build anything)
Strip all of the following from every field, including logs and repro steps:
- The SA password (
MSSQL_SA_PASSWORD, -P <password>, the Password= field of a connection string). Replace with ***.
- Registry credentials (the
docker login username and password).
- Full connection strings. Keep the shape, drop the secret:
Server=localhost,1433;Database=appdb;User Id=sa;Password=***;TrustServerCertificate=true.
- Any customer or application data, table contents, embeddings, or paths that identify the user or their employer.
- Access tokens of any kind.
The repository is public and issues are world readable. A report that leaks the user's password is worse than
no report at all.
Step 4: draft and show
Write the report, then show it to the user in full and ask whether to file it. Say which fields you filled and
which you left blank. If you could not determine a value confidently, leave it blank rather than guess: a
wrong skill name or host OS sends triage down the wrong path.
Step 5: submit
Try these in order, stop at the first that works, and confirm with the user first either way.
Tier 1: the gh CLI, if gh auth status succeeds. The issue is authored by the user, so they get replies.
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>
Write the body to a file rather than passing it inline, so quoting and newlines survive.
Tier 2: a prefilled URL. No credentials, no setup, and the user sees exactly what will be submitted before
anything happens. Use this whenever gh is not available; it always works.
Build the URL from the issue form's field ids and print it for the user to open. The field ids, the verbatim
dropdown values, and worked examples for all three templates are in
references/issue-fields.md. Read that file before constructing a URL.
Do not
- Do not create, comment on, or close an issue without explicit user confirmation.
- Do not include the SA password, registry credentials, or access tokens in any field. Ever.
- Do not file a skill problem on the container template, or the reverse. They are triaged by different people.
- Do not guess a dropdown value. Leave the field out if you are unsure; an omitted dropdown renders unselected, but a wrong one misroutes triage.
- Do not use an
aka.ms short link to carry a prefilled report. Those links drop query strings, so every field you filled in is silently lost. Use the full github.com URL. (The aka.ms links are for humans opening an empty form: skills feedback, container bug, container feature.)
- Do not open an issue for something already on the Known limitations page, or already in open issues. Point the user there instead.
- Do not nag. Offer once, take no for an answer, and move on.
References
- references/issue-fields.md: the exact field ids for all three templates, the verbatim dropdown values, URL construction and its length limit, and worked examples. Read this before building a prefilled URL.
Staying current
Authoritative, version-pinned references for the tools this skill uses (read the one you need):
If the Microsoft Learn MCP server is configured, use mcp__microsoft-learn__microsoft_docs_search or mcp__microsoft-learn__microsoft_docs_fetch to fetch the current version of any of these on demand. It is optional; when it is unavailable, the references above are authoritative.
