Clay Feedback
Send feedback or a bug report to the Clay team using clay feedback. It reads the message from stdin and automatically attaches environment details.
The CLI does no confirmation of its own, so confirm with the user before sending.
Feedback is one-way: it lands in the Clay team's triage queue and nobody replies. When the
user wants a human who responds — they explicitly ask for support, or the matter needs staff
action (a disputed or duplicate charge, a refund, account recovery) — use clay support
instead (see the clay skill's "Getting help and reporting problems"). Product feedback
about billing or plans (confusing UX, a feature request) is still feedback and belongs here.
Steps
Determine type. Default to
feedback. Choosebugonly when something that previously worked (or is established existing behavior) has regressed — it used to work and now doesn't. Choosefeedbackfor everything else: missing behavior, feature requests, UX suggestions, confusing flows, "I expected X but Clay doesn't do that," errors that look like product gaps rather than regressions, and general product ideas. Missing behavior is feedback (closer to a feature request), not a bug. If unclear whether this is a regression, preferfeedback; only ask the user when they clearly mean either a regression or a request for new/missing behavior and you still can't tell which.Get feedback text. Use the argument if provided (e.g.
/clay-feedback would love CSV export from the enrichment table). Otherwise ask the user what feedback or bug report they'd like to send.Confirm. Use your ask-user tool (
AskUserQuestion;askUserinside the Clay app). List what the report will include, and offer "Send" / "Cancel":This report will include:
- Type: {bug or feedback}
- Your feedback: {feedback text}
- Environment info (auto-collected)
Send this feedback?
If confirmed, send the message on stdin. The CLI reads the feedback from stdin. Do not pass it inline in the shell command (no heredoc, no
echo): the feedback is arbitrary user text, and a here-doc delimiter or quote appearing in it would truncate or mis-parse the message — or let pasted text run as shell. Instead, write the text to a temp file with your file-writing tool (which never goes through the shell), then redirect that file into the command. Always pass--type bugor--type feedbackfrom step 1.- Write the feedback text verbatim to a temp file with an unpredictable name (a shared
fixed path lets other local sessions read or clobber it), e.g.
/tmp/clay-feedback-<random>.txt. - Then run:
clay feedback --type <bug|feedback> < /tmp/clay-feedback-<random>.txt rm -f /tmp/clay-feedback-<random>.txt- Write the feedback text verbatim to a temp file with an unpredictable name (a shared
fixed path lets other local sessions read or clobber it), e.g.