// docs / feedback
Tell the maker, from where you work.
An agent that hits a missing or broken tool says so in one line, in the middle of the task. The maker reads it and closes it with the commit that fixed it.
The pattern
- Report. The agent (or you) sends one short factual sentence: what was missing, what broke, what the tool answered. No questions, no forms.
- Triage. Each report is a row with a status:
new,triaged,doneorwontfix. - Close with proof. A report is closed with the commit that fixed it, so "done" always points at a change you can read.
From a terminal or a script: ple feedback
ple feedback "ple search should also look inside prompt bodies"
ple feedback --type bug --prompt "code review" "get printed the wrong version"
ple feedback --type missing --json "no way to rename a repo from the CLI"--type is bug, missing, idea (the default) or prompt. --prompt names the prompt it is about by title or id, never by its text; --email is optional and only needed if you want an answer. A message is 1 to 2000 characters.
It never asks a question and never waits for input, so a script or an agent can call it. The exit code says what happened:
0 sent
1 something unexpected
2 usage or validation error (nothing was sent)
3 rate limited; try again after the printed delay
4 server or network problem; a report is saved to a local queue and sent by a later ple command (not saved with PLE_FEEDBACK_QUEUE=off); list: nothing was changed; close: it may have been applied, check with ple feedback listWhen nothing is found, ple search and a failing ple get print one line on stderr that points here (Missing something? ple feedback --type missing "..."). It never goes into output you pipe. Details are in the CLI reference.
From an agent: submit_feedback
The MCP server has a submit_feedback tool (the eighth, promptlike-mcp 0.6+). The agent calls it when a PromptLikeEngineer tool is missing, broken or confusing, returned a wrong result, or a saved prompt did not work. Arguments: message, and optionally type, prompt (title or id) and email. It works without a session. The Claude Code plugin's skill tells Claude when to use it.
A rate limit, a network problem or a server error comes back as a tool error with a code and whether it is retryable. Nothing is queued on this path. See MCP docs and Use it from Claude Code.
Closing a report with proof
Reading and closing is limited to the owner of the PromptLikeEngineer account. It is done from the same CLI, so the maker can do it from the terminal, right after the fix:
ple feedback list --status new
ple feedback close <id> --commit <sha> # status done
ple feedback close <id> --commit <sha> --status wontfixThe commit is stored with the report. There is no public list of reports.
What is sent, what is not
This is what the feedback feature sends, nothing more:
- the type and your message;
- the prompt title or id, and your email, only if you gave them;
- whether a person or an agent wrote it, and the agent's name if it gave one;
- where it came from (CLI, MCP server, web or extension);
- technical details: the
pleor server version, OS and CPU, Node version, and the command or tool name (for the CLI, the names of the flags you used, never their values).
Signed in, the report is tied to your account. Signed out, it is anonymous.
- Never sent: the text of your prompts, files, paths or flag values.
- Secrets are refused. A message that looks like an API key, a token or a private key is rejected, and the error names the kind, not the value.
- Abuse limit. Anonymous reports are limited to 5 per hour per network, signed-in ones to 30 per day. For anonymous reports only, a hash of the IP address is stored to apply the limit. It is made with a key that changes every day, so it cannot be matched across days, and the IP address itself is never stored.
- Retention and deletion. Feedback is deleted automatically after 24 months. To have an entry deleted sooner, write to zeynepaslierhan@gmail.com.
The general rules are in the Privacy Policy.