---
name: feedback
description: Use when a user corrects or asks to redo work performed with a plugin skill, or asks to report plugin feedback. Offer to turn the correction into a test for the plugin owner. Exclude corrections unrelated to plugin use and ordinary new requirements.
---

# Plugin feedback

Turn a user correction into a test the plugin owner can use.

## Offer

Continue the requested rework. Identify the plugin and skill actually used;
a model mistake alone does not establish a plugin defect. When the correction
suggests a reusable plugin improvement, ask once whether the user wants it
captured for the owner. For example: “Should we turn this correction into a
test for the plugin owner?” Use the user's language.

Existing consent is enough; an explicit request to prepare feedback needs no
second offer. After a refusal, continue the original task without preparing
feedback or repeating the offer unless the user reopens it. A new requirement
or a one-off preference does not by itself call for plugin feedback.

## Test

After consent, extract the smallest faithful case from the session:

- plugin and skill, source repository and revision or version if known;
- minimal input, necessary context, and setup or invocation;
- observed behavior and the user's expected behavior;
- concrete pass/fail checks and how to run the case;
- execution status and actual result, with model and environment when relevant
  and known.

Use a behavioral scenario with explicit checks, or an executable test when an
existing harness can verify the behavior. Preserve the user's correction
without turning a local preference into a universal rule. Include only data
suitable for the recipient; replace private details with faithful fixtures
and check that the replacement preserves the case.

Call the artifact a **test**. Call it a **red test** only after running that
case against the affected version and observing failure against its checks.
Record a passing result or an unavailable run as such. A tool or environment
failure alone does not prove the plugin failed the test.

## Delivery

Resolve the owner's repository from the plugin's source metadata; the user's
current repository and the installed plugin cache are not delivery targets.
Prepare the test without changing the plugin's instructions or implementation.

Offer a test-only PR when available access supports it, including through a
fork. Follow the target repository's test layout and state any observed failure
in the PR. Before publishing, use existing authorization or show the prepared
test and destination and ask for the missing publication approval.

If PR access is unavailable or the user wants text, return the same test in one
copyable Markdown block for the owner. Missing metadata or execution access
should be stated, not invented, and does not prevent preparing the test.