一键导入
clay-feedback
Clay feedback — send a bug report or product feedback to the Clay team via the `clay feedback` CLI, optionally including this session's transcript.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Clay feedback — send a bug report or product feedback to the Clay team via the `clay feedback` CLI, optionally including this session's transcript.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | clay-feedback |
| description | Clay feedback — send a bug report or product feedback to the Clay team via the `clay feedback` CLI, optionally including this session's transcript. |
| allowed-tools | Bash(clay *), Bash(ls *), Bash(pwd), Bash(sed *), Bash(head *), Bash(rm *), Write, AskUserQuestion |
Send feedback or a bug report to the Clay team using clay feedback. It reads the message from stdin and automatically attaches environment details. To include this conversation's transcript, you attach it explicitly with --transcript-file — the CLI does not look for it on its own.
The transcript is the current conversation, so confirm with the user before sending (the CLI does no confirmation of its own).
Get feedback text. Use the argument if provided (e.g. /clay-feedback the enrichment table returns no results). Otherwise ask the user what feedback or bug report they'd like to send.
Find this session's transcript — you attach it, the CLI won't. You are responsible for locating the current conversation's transcript file and passing its path to --transcript-file in step 4. Use whatever your runtime exposes:
Claude Code: the newest .jsonl under the project dir whose name is the working directory with / and . replaced by - (checking the normal home and the Cowork mount):
proj="$(pwd | sed 's#[/.]#-#g')"
ls -t "$HOME"/.claude/projects/"$proj"/*.jsonl "$HOME"/mnt/.claude/projects/"$proj"/*.jsonl 2>/dev/null | head -1
Other runtimes (Codex, Cursor, …): locate the current session transcript the way your client stores it.
If you can't determine a transcript path, proceed without one — the report still sends.
Confirm. Use AskUserQuestion. List what the report will include:
This report will include:
- Your feedback: {feedback text}
- This conversation's transcript (only if step 2 found one)
- 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. Substitute the path from step 2 directly — each Bash call is a fresh shell, so a variable set in step 2 won't survive here. Include --transcript-file only if the user chose to send the transcript:
/tmp/clay-feedback.txt.clay feedback --transcript-file <path from step 2> < /tmp/clay-feedback.txt
rm -f /tmp/clay-feedback.txt
To send without the transcript, omit --transcript-file entirely.
Interpret the JSON output (printed on success, exit 0):
{ "ok": true, "includedTranscript": true, "environment": { ... } }
transcriptError appears only when you passed --transcript-file but it couldn't be attached (missing, unreadable, or too large).
includedTranscript is false and transcriptError is set, the report was still sent — only the transcript was skipped. Tell the user; double-check the path from step 2 before retrying.validation_error (exit 2) — the stdin message was empty or nothing was piped. Make sure the temp file has the feedback text and is redirected in (< /tmp/clay-feedback.txt).auth_required (exit 3) — Clay isn't authenticated. Run the setup skill or clay login, then retry.rate_limited (exit 4) — too many reports recently; surface details.retryAfter and try again later.Tell the user it was sent, noting whether the transcript was included. If cancelled, do nothing.
Clay — start here. A table of contents for working with Clay and which skill to use for each thing — search (find people/companies), routines (run Clay-managed and custom functions), tables (query/export data), the CLI (ephemeral programmatic access), the Public API (build services on Clay), workflows (build automations, Alpha), and feedback. Read this first to answer "what can I do with Clay?"
Clay Public API — HTTP access for building services, apps, and integrations: structured-filter search over Clay's GTM database, structured table queries, and async routine and batch runs.
Clay search — find people or companies in Clay's GTM database from structured filters, and page through the matches. Use when the user wants to search Clay for prospects/accounts, not query an existing table.
Clay setup — authenticate both the `clay` CLI and the Clay MCP server (both are required to use the plugin). Use when `clay` is not found on PATH or the `clay` found in the PATH is the wrong version, `clay whoami` fails, the MCP tools (`read`, `edit_node`) error on auth or don't appear at all despite a Connected server, the CLI isn't signed in, the Cursor plugin never appears after a local install, or the user wants to configure Clay.
Clay tables — analyze what a table does: reconstruct the column DAG, stage it, and narrate the workflow encoded in its columns. Use when the user asks "what does this table do?", "explain the {table} workflow", "walk me through this table", or "what's set up here?".
Clay tables — locate a record by identifier and snapshot its state: which table(s) hold it and each cell's status. Use when the user has an id and asks "trace {id}", "where is {id}?", "what enrichments ran for this lead?", or "is this record done?".