Feedback

Turns a problem with a Crowdin component (a skill in this plugin, the Crowdin MCP server, the Crowdin CLI, the Crowdin API, the product) into a short, factual draft on the user's machine and, only when the user asks, into a GitHub issue the Crowdin team reads.

When to draft

Draft at high-signal moments, with or without being asked:

• The user asks: "report this", "file feedback", "this should be an issue", "tell Crowdin about this", "the skill was wrong about X".
• A Crowdin skill instruction, CLI command, MCP tool call or API call failed reproducibly and was just fixed or given up on.
• The user expressed clear frustration with a Crowdin component.
• A Crowdin capability the user reasonably expected does not exist and blocked the task.

Type each draft as one of bug (something behaves differently from what the documentation, the skill or the user reasonably expected), idea (a change that would have made the task easier) or missing_capability (something Crowdin cannot do that blocked the task).

One draft per distinct problem per session. Before writing, list ~/.crowdin/feedback/; if a draft there describes the same problem, update it rather than create a second one. The same failure hit twice in different places is still one problem.

Drafting is silent. Finish the current reply as you would have, then add one line at the very end: Drafted feedback about <short title> to ~/.crowdin/feedback/<file>. Say "send feedback" to review and send it. That line is the only trace of the draft in the reply; questions about it wait until the user brings it up. When the user asked for the draft explicitly, show the draft in the reply instead of that line.