About superset-feedback
Superset Feedback is a skill that helps turn feedback about Superset into a structured report and submit it privately to the team or as a public GitHub issue. It guides users through drafting, optional evidence, destination choice, and confirmation.
Key features
- 01Classifies feedback as bug, request, or general
- 02Drafts titles and report details
- 03Offers optional screenshots and diagnostics
- 04Submits privately or via GitHub
- 05Checks public issues for duplicates
Use cases
- 01Reporting a Superset bug
- 02Suggesting a Superset feature
- 03Sending general feedback
- 04Attaching approved diagnostic evidence
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ superset-sh/ skills --skill superset-feedbackAfter installing, type/superset-feedbackin Claude Code to confirm it loaded.
Details
From the project READMESuperset Feedback
Help the user turn their feedback about Superset into a well-formed report and submit it where they choose. Treat whatever they wrote after the command as the seed.
1. Gather context (best effort, never block)
Run in parallel; skip anything that fails:
superset --versionanduname -smfor the environment blocksuperset auth whoamifor the signed-in user/org (private submissions only)
Do NOT include repository contents, terminal output, or logs unless the user explicitly agrees when asked.
For bugs, also offer (never assume):
- Screenshot — if the bug is visual and you can capture one, offer to attach it. Evidence beats prose.
- Diagnostics — offer to attach a diagnostics bundle (CLI version, OS, last 200 app log lines) via the
--diagnosticsflag. Tell the user logs can contain file paths and project names before they agree.
2. Classify and draft
Classify as bug, feature request, or general feedback from their words; ask only if genuinely ambiguous. Then draft:
- Title — one line, imperative, specific
- What happened / What you want — 2-5 sentences in the user's voice
- Steps to reproduce — bugs only, numbered
- Environment — Superset version, OS (bugs only)
3. Ask where to send it
Show the full draft, then ask the user (use the ask_user tool if available, otherwise a plain question) with exactly these options:
- Send privately to the Superset team
- Open a public GitHub issue
- Edit the draft first
- Cancel
Never submit anything before the user explicitly picks 1 or 2. Loop on edits.
4. Submit
Private path:
- If
superset feedback --helpexits 0, submit via stdin (note:--body-file=-with the equals sign; a space-separated-is rejected by the parser):
Only when the user agreed to them in step 1, addsuperset feedback submit --type bug --title "..." --body-file=- <<'EOF' <drafted report> EOF--attach /path/to/screenshot.png(comma-separated paths, 10MB total) and/or--diagnostics. The submission is sent from the user's Superset account, a copy is CC'd to them, and the team replies to their account email. - If the CLI is missing or not logged in (
superset auth whoamifails), offersuperset auth loginfirst; if declined, fall back to email: give the user a clickable mailto link (mailto:[email protected]?subject=<url-encoded title>&body=<url-encoded body>) and also print the raw draft so they can copy it.
Public path:
- Check for duplicates first:
gh search issues -R superset-sh/superset "<key terms>" --limit 5. If an existing issue matches, show it and offer to comment there (gh issue comment) instead of opening a new one — only create a fresh issue if the user confirms it's genuinely different. - If
ghis installed andgh auth statussucceeds:gh issue create -R superset-sh/superset --title "..." --body "..."(write the body via a heredoc or temp file, never inline-escape). - Otherwise open the prefilled form in the browser:
https://github.com/superset-sh/superset/issues/new?title=<url-encoded>&body=<url-encoded>.
5. Confirm
Report back the issue URL (public) or a confirmation of what was sent and to whom (private). If anything failed, show the draft so the user's writing is never lost.