Feedback triage
Feedback arrives as a mess of threads and DMs. Triage turns it into a checklist someone can work from and,
later, read as a record of what was decided and why.
This repo is public (see CLAUDE.md → Security). Raw feedback is not publishable: it carries reporter
identities, private message content, internal ticket ids, and sometimes a named user's earnings. The
decisions are publishable, and are the part with long-term value. So every triage produces two files.
The two artifacts
|
Private |
Public |
| Where |
scratchpad dir, or the private repo |
docs/ |
| Reporter names / handles |
✅ |
❌ → "a creator", "a moderator" |
| Tracker links (ClickUp etc.) |
✅ |
❌ |
| Verbatim / paraphrased DM content |
✅ |
❌ → the underlying request only |
| A named user's earnings or moderation state |
✅ |
❌ never, in any form |
| The work item |
✅ |
✅ |
| The decision + reasoning |
✅ |
✅ |
| Commit shas, file paths, root causes |
✅ |
✅ |
| Done/not-done state |
✅ |
✅ |
The public file is not a summary — it should carry every item and every decision note. Only provenance is
removed. If stripping attribution makes an entry meaningless, the entry was gossip, not a work item.
Steps
- Collect the raw feedback. Keep the source (thread, date) in the private file only.
- Dedupe. The same complaint usually arrives from several people in different words. One item, and in
the private file note that it was independently reported — that's evidence of priority.
- Classify each item: bug, feature request, or decision needed. Separate already-shipped from open.
- Create tracker tasks and put the links in the private file.
- Write both files. Same items, same order, same headings, so they can be diffed against each other.
- As work lands, update both: tick the box and add a one-line outcome note (what shipped, what was
deliberately not done, the sha). This is the part people actually come back for.
Sanitizing — check each before publishing
- No personal handles or display names. "alexds9 reported X" → "a creator reported X".
- No tracker ids or links.
- No message quotes, timestamps, or "he then asked…" narration.
- No named user's financial or moderation detail — not their earnings, payout history, transaction
pattern, strikes, or content ratings. This is the one that is never fixable by rewording; drop the detail
and keep only the technical finding ("a payout report traced to a display bug in
<sha>").
- Re-read the result as a stranger: what could they do with it that they couldn't before? If the answer is
anything but "understand the product or contribute code", cut more.
Keeping them in sync
They drift. When you update one, update the other in the same turn. If only the private file is current,
say so in the public file's header rather than letting it silently rot.
If a public entry has been reduced to nothing useful by sanitizing, delete it from the public file rather
than leaving a stub — and note in the private file that it is private-only.
1---2name: feedback-triage3description: Turn a batch of user feedback (Discord threads, DMs, article comments, support tickets) into a triage checklist. Produces TWO artifacts — a full private one with attribution and tracker links, and a sanitized public one safe for docs/. Use when asked to triage feedback, build a feedback checklist, or record what a round of reports asked for.4---5
6# Feedback triage
7
8Feedback arrives as a mess of threads and DMs. Triage turns it into a checklist someone can work from and,
9later, read as a record of what was decided and why.
10
11**This repo is public** (see CLAUDE.md → Security). Raw feedback is not publishable: it carries reporter
12identities, private message content, internal ticket ids, and sometimes a named user's earnings. The
13decisions are publishable, and are the part with long-term value. So every triage produces two files.
14
15## The two artifacts
16
17| | Private | Public |
18|---|---|---|
19| Where | scratchpad dir, or the private repo | `docs/` |
20| Reporter names / handles | ✅ | ❌ → "a creator", "a moderator" |
21| Tracker links (ClickUp etc.) | ✅ | ❌ |
22| Verbatim / paraphrased DM content | ✅ | ❌ → the underlying request only |
23| A named user's earnings or moderation state | ✅ | ❌ **never**, in any form |
24| The work item | ✅ | ✅ |
25| The decision + reasoning | ✅ | ✅ |
26| Commit shas, file paths, root causes | ✅ | ✅ |
27| Done/not-done state | ✅ | ✅ |
28
29The public file is not a summary — it should carry every item and every decision note. Only provenance is
30removed. If stripping attribution makes an entry meaningless, the entry was gossip, not a work item.
31
32## Steps
33
341. **Collect** the raw feedback. Keep the source (thread, date) in the private file only.
352. **Dedupe.** The same complaint usually arrives from several people in different words. One item, and in
36 the private file note that it was independently reported — that's evidence of priority.
373. **Classify** each item: bug, feature request, or decision needed. Separate already-shipped from open.
384. **Create tracker tasks** and put the links in the **private** file.
395. **Write both files.** Same items, same order, same headings, so they can be diffed against each other.
406. **As work lands**, update both: tick the box and add a one-line outcome note (what shipped, what was
41 deliberately not done, the sha). This is the part people actually come back for.
42
43## Sanitizing — check each before publishing
44
45- No personal handles or display names. "alexds9 reported X" → "a creator reported X".
46- No tracker ids or links.
47- No message quotes, timestamps, or "he then asked…" narration.
48- **No named user's financial or moderation detail** — not their earnings, payout history, transaction
49 pattern, strikes, or content ratings. This is the one that is never fixable by rewording; drop the detail
50 and keep only the technical finding ("a payout report traced to a display bug in `<sha>`").
51- Re-read the result as a stranger: what could they do with it that they couldn't before? If the answer is
52 anything but "understand the product or contribute code", cut more.
53
54## Keeping them in sync
55
56They drift. When you update one, update the other in the same turn. If only the private file is current,
57say so in the public file's header rather than letting it silently rot.
58
59If a public entry has been reduced to nothing useful by sanitizing, delete it from the public file rather
60than leaving a stub — and note in the private file that it is private-only.
civitai