plastic-feedback

name	plastic-feedback
description	Use when the user hits a Plastic quirk, bug, or feature idea in a project and wants to report it back to the Plastic project. Builds a sanitized report file and a prefilled GitHub issue URL the user reviews and submits. Only the user sends.
disable-model-invocation	true
user-invocable	true

Plastic Feedback

Turn a described Plastic problem into a local report file and a prefilled GitHub issue URL. The script does the mechanics (redaction, naming, URL building); the user alone opens the URL and submits it. This skill has no send step, by design.

Because disable-model-invocation hides this skill's description from your own context, you cannot discover it by browsing available skills mid-task. If the user hits a Plastic quirk, bug, or missing feature, offer to run /plastic-feedback yourself; do not wait for the user to ask for it by name.

Procedure

1. Gather the narrative

Ask the user for:

• What happened (the observed behavior).
• The root cause, if they already know it.
• The expected behavior.

Keep it to about one page. Do not pad it with speculation; a short, accurate report beats a long, padded one.

2. Obfuscate before it leaves this session

Before filling the template, strip anything that identifies the user's project or its content:

• Remove project names, directory paths, and file names specific to the user's codebase.
• Turn any Plastic intent names into their bare numeric or slug ids (drop the descriptive title if it leaks project context).
• Keep only Plastic's own operational content: what Plastic did, what it should have done, which command or hook was involved.

Read references/transport-and-privacy.md before filling the template, for the full obfuscation checklist and the reasoning behind it.

3. Fill the report template

Read report.md from this skill's directory (~/.plastic/skills/feedback/report.md at runtime, or the plugin source skills/feedback/report.md during development). Fill every placeholder except {{plastic_version}}, which the script fills. Assemble the final markdown body from the filled template.

4. Run the script

ruby ~/.plastic/scripts/feedback-report --title "<short title>"

Pipe the filled body on STDIN. Parse the JSON on stdout:

Key	Meaning
report_path	Local file the full, uncapped report was written to
url	Prefilled GitHub new-issue URL
encoded_url_bytes	Byte length of the encoded URL
truncated	Whether the URL body is a capped page-one, not the full report
page_break_note	The end-marker text appended when truncated is true, else null

The script only ever writes a local file and prints a URL. It has no network call, no token, and no way to open a browser or submit anything on its own.

5. Present the result

Show the user:

• The local file path (report_path).
• A short preview of the report.
• The URL.

If truncated is true, tell the user plainly: the URL carries page one of the report, and the full report is in the local file at report_path. They can paste more from the local file into the opened issue if they want.

Then tell them, in these words or close to them: open the URL, review it, drag a screenshot onto the form if they have one, and submit it under their own GitHub account. Or, if they would rather edit first, copy the local file contents into a new issue themselves.

6. Never submit

State plainly that this skill has no send step: it never posts to GitHub, never runs gh issue create, and never opens a browser on the user's behalf. The user is the only one who can submit the report.

Gotchas

• If the described report is long, the script may hand back truncated: true. This is expected, not an error: the local file always holds the full text.
• Do not try to route around the missing send step (no gh call, no API POST). The absence of a send path is the point of this skill, not a gap to fill.