/feedback

name: feedback
description: Collect and submit feedback about Superset (bug reports, feature requests, or general feedback) privately to the Superset team or as a public GitHub issue. Use when the user wants to report a Superset bug, request a feature, or send feedback about Superset.
argument-hint: describe the bug, request, or feedback
allowed-tools: Bash(superset:*) Bash(gh:*) Bash(uname:*)

Superset Feedback

Turn the user's feedback about Superset into a short, scannable report and submit it where they choose. Treat whatever they wrote after the command as the seed.

The reader is a Superset engineer triaging dozens of reports. They should get the point from the title, the full picture from the summary bullets, and only read further when they need detail. Cut everything that doesn't help them reproduce or decide.

0. Is this a follow-up?

Every private submission CCs the reporter, so they already have a copy in their inbox with a subject starting `[Feedback: ...]`. A reply to that email lands on the same thread; a new submission opens a new one and the team has to reconcile them by hand.

If the seed reads like a continuation ("follow-up", "again", "still happening", "update on", "retraction", "root cause", "I already sent", "third time"), or the user filed something on this topic earlier in the session, ask whether they already sent a report about it. If they did, tell them to reply to that email with the new information and stop here. Only file fresh when they confirm it's a different issue.

Never title a report "Follow-up:", "ROOT CAUSE:", or "RETRACTION"; those belong in a reply.

1. Gather context (best effort, never block)

Run in parallel; skip anything that fails:

• `superset --version` and `uname -sm` for the environment line
• `superset auth whoami` for the signed-in user/org (private submissions only)
• `superset status --json` for the host service; its `hostServiceVersion` is the desktop app's version when the app spawned the service

Don't include repository contents, terminal output, or logs unless the user explicitly agrees when asked; they can contain private paths and code.

Version check

Many reports describe bugs already fixed in a newer release. Desktop, CLI, and host service share one version number, so compare what's running against the latest release:

• Latest: `superset update --check --json` (standalone CLI). If it says the CLI is bundled with the desktop app, the CLI version is the app version; get the latest from `gh release download cli-latest -R superset-sh/superset -p version.txt -O -` instead.
• Running: the CLI version, and `hostServiceVersion` from `superset status --json` if it differs.

If anything is behind, say so before drafting and ask whether they want to update first (the desktop app updates itself from its menu; a standalone CLI with `superset update`). If they'd rather file now, note the versions in the report.

Bugs about hosts, automations, terminals, or remote workspaces

Symptoms like "host not registered", "hosts list is empty", "automations create fails", "host shows offline", "terminal won't attach", or "workspace missing from the sidebar" are the most common reports and usually have a known cause. Before drafting, run the doctor skill's snapshot (`superset status`, `superset auth whoami`, `superset hosts list`) and apply its signature table. If that fixes it, there's nothing to report. If it doesn't, keep the `superset status --json` output for the report; it's what the team asks for first.

Evidence (bugs only, offer, never assume)

• **Screenshot**: if the bug is visual and you can capture one, offer to attach it. Evidence beats prose.
• **Diagnostics**: offer the `--diagnostics` bundle: versions, OS, and the last 200 lines of the app log and the host-service log. Tell the user logs can contain file paths and project names before they agree. Prefer the bundle over attaching raw log files; attach a file only when the tail isn't enough. Attachments must total under about 3 MB; a single larger log is cut to its tail automatically.

2. Classify and draft

Classify as **bug**, **feature request**, or **general feedback** from their words; ask only if genuinely ambiguous.

**One report per root issue, one request per ask.** Two symptoms of the same failure are one bug. Three unrelated wishes are three feature requests; offer to split them, then file each separately. Don't file a second report for a different symptom of something the user just filed.

Title

`<Surface>: <symptom or ask>`, under 72 characters, no trailing period.

• Surface is the part of Superset involved: Terminal, Sidebar, Browser pane, Workspaces, Automations, CLI, Updater, Mobile, and so on.
• Bugs name the symptom, not the guess at the cause. Requests name the outcome, not the implementation.
• Don't prefix with "Bug:" or "Feature:"; the type is already carried separately.

Good: `Terminal: pane goes blank after waking from sleep`, `Sidebar: let me pin an automation to the top`. Bad: `Bug with terminal`, `Terminal rendering broken because xterm loses WebGL context on resume`.

Body

Plain text that also reads well as markdown: section labels on their own line, `-` bullets, numbered steps. No headings, bold, or tables; the private path is delivered as a plain-text email. Keep the user's own words where they're precise, tighten where they ramble. A one-line seed still gets Summary bullets.

Every report starts with a **Summary** of 2-4 bullets that stand alone. Someone reading only those bullets should know what's wrong (or wanted), how bad it is, and how often it happens. Summary bullets are observations, never hypotheses.

Bug:

Summary
- Terminal pane goes blank after the Mac wakes from sleep
- Happens every time; reloading the window fixes it
- Started in 1.21.0, didn't happen in 1.20.x

Steps to reproduce
1. Open a workspace with one terminal running
2. Close the lid for a minute, then open it
3. Click into the t