Muse feedback

Purpose

File a user's feedback with the Muse team via the feature-request CLI. Each report goes to the Muse team as a private note; nothing in it is published anywhere.

For Muse's general early access program, use /opt/hatch/skills/muse-early-access/SKILL.md.

When the user asks to share feedback, follow the filing steps below for the feedback they want to send. The guidance about when to offer feedback applies only to proactive offers.

When to offer feedback

• "I wish you could see the sleep data from my watch": a service Muse doesn't support. --kind missing-integration --subject <the-service>.
• "Can you scan this paper form?" when Muse has no such capability: --kind missing-capability --subject document-scanning.
• "Checkout on that store's site never loads": a supported feature failing somewhere specific, repeatably: --kind broken-behavior --subject <the-site>.
• A connect or setup flow that keeps failing until the user gives up ("forget it, I'll do it myself") is a gap too, even though nobody said "can't": broken-behavior with the service as subject.

A workaround does not cancel the report. When the user wanted an automatic connection and settles for pasting, typing, or doing it themselves, the wish they arrived with is exactly what the Muse team can't see; make the offer in the same message as the workaround: "I can't connect to your watch. Want me to mention to the Muse team that you'd like that? Meanwhile, paste me the numbers each morning and I'll track them the same way."

For feature requests naming an outside service or device, use missing-integration, even if the ask sounds like a capability, with that service's own name as the subject slug: lowercase, dashes for spaces, and for a site the name without the .com. Use missing-capability for gaps or requests to change a restriction with no outside service involved. Use broken-behavior for problems with Muse, including slowness and answer quality.

• Do not offer unprompted feedback about Muse being slow, expensive, limited, or broken, including sign-in failures, outages, and model quality. For failed connections to outside services, follow the give-up guideline above.
• Do not offer unprompted feedback about slowness, even at a named site, unless the task keeps failing.
• Do not offer unprompted feedback about changing an intentional restriction.
• Do not offer unprompted feedback about errors that recovered or failures without a specific point of failure.
• Fix or retry your own execution mistakes. Do not offer unprompted feedback about them.

When the user gets frustrated, ask yourself why. If the answer is something within your control, fix it: offering to report would only seem like an excuse. If the answer is an issue worth filing, offer to do so following our guidelines.

Positive feedback

When the user explicitly asks to pass along praise, such as "tell your developers I love this app", use positive-feedback. Never offer to report praise unprompted. Use the praised feature as the subject, or muse for the app overall. Also use positive-feedback for general offers to help or contribute, describing the offer as given. Follow the same filing and repeat-report rules below.

Filing

Keep feedback replies brief and focused on what the user needs to know.

1. Describe the feedback in terms any user could share, free of private data: no names, contact details, addresses, account numbers, or amounts. Do not claim an unverified cause. Everything about this user's own situation (their goal, their marathon, their job) belongs in --context, which never joins the report the Muse team receives; it is kept locally so a later conversation can be specific if the gap is ever closed.

   Use details already in the conversation. Use the affected feature, service, or issue as the subject, such as response-speed, answer-quality, or sign-in. Use muse when the conversation gives no more specific topic. Ask only for approval to send the report; do not ask the user for additional report details.

   Draft the report. Drafting sends nothing and files nothing. Pass no --context: the draft runs before the user has agreed, so nothing about their own situation belongs in it yet.

feature-request draft --kind missing-integration --subject whoop \
  --summary 'wants sleep and workout data from their Whoop watch'

2. Present the returned summary as an unsent draft, quoting it in full and verbatim. Ask whether to send it to the Muse team as a private note, and say that the report excludes details about the user's own situation. End your turn. Do not file until the user explicitly approves in a later turn. Ask once. If they decline or do not answer the offer, drop it for the rest of the conversation, including the goodbye.

3. File it in the later turn, once the user says yes. Pass the same --kind, --subject and --summary you drafted, and add the --context the draft would not take. The command refuses a summary that changed after the user saw it. Send the line they agreed to, or draft the new wording and ask again.

   Set file --client-surface from the current message's Sent from metadata: web, ios, or android. For a provider chat, use its channel: whatsapp or messenger. Use unknown when the metadata is unavailable. Do not ask the user which client they are using or append a surface tag to new summaries.

feature-request file --kind missing-integration --subject whoop \
  --summary 'wants sleep and workout data from their Whoop watch' \
  --context 'training for a marathon; wants readiness briefings'

Single-quote --summary and --context: inside double quotes bash reads $650 as a variable and drops it, so "pays $650 rent" records as "pays 50 rent".

4. Describe the report category in ordinary words, such as "a missing fitness-watch connection". Do not show field names, slugs, or raw command output. Do not quote the summary again. Report delivery according to the command's output:

   • sent_to_developers: true: confirm that the report went to the Muse team as a private note and excludes the user's personal context.
   • sent_to_developers: false with delivery_confirmed: true: it was already with the Muse team; nothing new went out, and never say it was.
   • sent_to_developers: false with delivery_confirmed: false: nothing went out this time and no earlier delivery was ever confirmed. Tell the user: "I've kept your request here, but I couldn't confirm it reached the Muse team. I won't resend it right now in case it already got through."

5. Read the error text when the command fails. Every refusal below recorded nothing and sent nothing.

   • Summary mismatch: retry in the same turn with the exact draft summary. For a first filing, this must be the wording the user approved. To change a new report's wording, draft it and ask for approval again.
   • Missing draft: draft the report and file in a later turn. For a first filing, ask for approval before filing.
   • Same-turn draft: end the turn and file after the user replies in a later turn. For a first filing, that reply must explicitly approve the report.
   • Expired draft: draft the report again and file in a later turn. For a first filing, ask for approval again.
   • Hourly limit: nothing was recorded or sent. Say it could not be filed now, and do not run file again in this conversation.

   For every other error, do not run the command again in this conversation, because the report may already have reached the Muse team. Do not promise a background retry, and do not tell the user you will make sure it lands.

One report per gap

The Muse team counts how many people ask, not how many times. When the user raises an already-filed gap again, use the existing report and its original approval. Do not offer another report or request approval again.

1. Draft the same kind and subject. The later filing must use the exact summary from this draft.
2. End your turn acknowledging the user's new details. Do not say they are saved yet. Do not present the draft summary as new wording to send; repeat filings retain the original report's summary.
3. Once the user replies in a later turn, file with the drafted fields and updated --context. Say the details are saved only after the command succeeds. Do not say the new details will be sent to the Muse team; context is excluded from the report. Report delivery according to Filing step 4.

The command re-sends only while no delivery was ever confirmed, at most once a day, so a later-day re-run recovers an unconfirmed report and cannot file a duplicate.

In a new conversation you may not remember whether a gap was filed. Check before offering: feature-request show --kind <kind> --subject <subject> returns the report if it exists (then proceed as above, without a new offer). If report is null and removals is empty, this is a first filing and needs the user's go-ahead. If removals is nonempty, do not offer or attempt a new filing while the earlier withdrawal remains recorded.

Viewing and withdrawing reports

• When the user asks what they have reported, read /opt/hatch/bin/feature-request list --help.
• When the user asks what became of a report, read /opt/hatch/bin/feature-request show --help.
• Before asking for approval to withdraw a report, read /opt/hatch/bin/feature-request delete --help.

Announcing a shipped request

When a message from the Muse team names addressed kind/subject pairs, read /opt/hatch/bin/feature-request show --help and share the news right then.

Promises

Promise only what happens: the report helps the Muse team understand user feedback. Nobody replies and there is no ticket; never promise a fix, a timeline, or an answer, and never promise to watch for the capability or ping the user when it lands. If it ships, the product will say so itself.