Turn a pile of user feedback into a backlog that keeps the original wording

When to use

Two hundred pieces of feedback across support chat, comments, and tickets, and you need a backlog you can assign. The real fear is losing the original wording, so nobody believes the need exists.

Preparation

Host version

To fill (record the exact rc version when testing)

Model

To fill

Mode / permissions

Standard mode + modify-within-workspace is enough to start

Plugins required

None (add name & version after testing if used)

Input materials

Keep in a separate workspace; back up originals first

Full instruction

Read every .txt and .md file under feedback/ and turn this user feedback into a backlog at backlog.md.

[Input]
- Each item is a line or a paragraph, possibly without field labels
- Files may contain internal notes (lines starting with 'internal:'); these stay out of the backlog but must be counted at the end

[Output]
A table with columns: id | one-line need | occurrences | user's words (verbatim, max 3) | source file:line | my judgement (may be empty)

Requirements:
1. State the merge rule explicitly: which items count as the same need and which do not. Put the rule above the table; do not keep it implicit.
2. 'User's words' must be verbatim, character for character, including typos and colloquialisms. Cite file and line.
3. A need backed by a single mention still appears, marked 'single occurrence'.
4. Never force-merge similar-but-different needs. Prefer more rows. Where a merge is arguable, keep both readings.
5. Report at the end: total feedback items, number of needs, how many are single-occurrence, how many internal notes, and any files that could not be read.

Do only the first 20 items so I can check the format, then continue.

Copy full instruction

Run log

Output

After a successful run, list files and screenshots here, and note whether originals changed.

Acceptance checklist

Tap to tick each item off as you verify.

• The merge rule sits above the table, not buried in prose
• Every 'user's words' cell can be found verbatim in its source file
• Single-occurrence needs are marked and not merged away
• Internal notes did not leak into the backlog, and the count matches the report
• Total = items in needs + internal notes + unreadable items

Failures & boundaries

• Feedback often contains the same person submitting the same thing repeatedly; counting by row inflates demand. Deduplicate first, or say in the report that you did not
• The merge rule easily becomes post-hoc rationalisation: cluster first, invent a rule after. The order is rule first, clustering second
• Quoting emotional wording on a public page needs care; confirm nobody becomes identifiable
• Blocked on: Needs real multi-source feedback (support chat, comments, tickets). Synthetic feedback reads too uniformly to test whether the merge rule holds when one complaint arrives in ten different phrasings, which is the hard part.

Claim this recipe Back to recipes