Convert a Feedback Thread to a Prompt — Rejections Are the Asset
In feedback threads the rejections carry the knowledge: the mocking empty-state enthusiasm, the passive phrasing — converted into the avoid-rules that define the style.
Overview
Feedback threads invert the usual distillation: the accepted version matters, but the REJECTIONS carry most of the knowledge — they encode taste. A UX-copy thread that killed exclamation-mark enthusiasm ("reads as mockery when a user has no data") and passive phrasing teaches more through what it refused than what it kept. The conversion preserves that: rejections become explicit avoid-rules with their reasons attached verbatim, and the accepted action-first pattern becomes the requirement. This setup loads exactly such a thread, rejection-heavy by design.
Workflow
-
Value the no
Each rejection carries a reason — and the reason travels verbatim into the avoid-rule.
-
Keep the accepted pattern
Action-first with time-to-result — the "keep this" moments become requirements.
-
Apply across the surface
The thread's own "use this style for the other empty states" extends the prompt's reach.
Why This Works
- Rejection-with-reason is the densest taste signal a thread produces
- Avoid-rules prevent regressions the next generation would otherwise repeat
- Style emerges from real feedback, not invented guidelines
Best for
- UX copy, design reviews, editorial feedback
- Threads where "no" taught more than "yes"
- Style guides born from real feedback
Not for
- Comparing two prompt versions formally — that's the Prompt Comparator
- Permanent team style conventions across all projects — future Project Context Builder territory
Use cases
- Converting design-feedback rounds into style rules
- Preserving the reasons behind rejections
- Encoding taste decisions as avoid-lists