plastic-feedback

# 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 t...