| name | analyzing-feedback |
| description | Parses raw customer feedback (app reviews, support tickets, interview transcripts) into categorized severity-ranked themes, scans the codebase to identify affected files and components, and proposes 3 structural edit options per theme (minimal/refactor/architectural) with rationale tied directly to the original feedback. Trigger when: user provides raw customer feedback and wants to know what to change in the code; or an agent holds user complaints needing file-level engineering proposals. Do NOT trigger for: internal PR/code review comments (use receiving-code-review instead), stack-trace bug reports (use systematic-debugging instead), or PRD drafting. |
Analyzing Feedback
Translates raw customer language into ranked, file-level structural edit proposals.
Reference files
references/feedback-taxonomy.md — categories, severity tiers, intent tags, negative triggersreferences/edit-proposal-template.md — A/B/C option output formatreferences/context-augmentation.md — codebase context packing guide
Process
Step 1 — Ingest and clarify
Receive raw feedback (pasted text, file path, or description). Check: is there at least one concrete user behaviour described (an action attempted, a screen visited, an outcome expected vs. received)?
If not — ask exactly one clarifying question: "What were users trying to do when they gave this feedback?"
If the feedback is multi-source (e.g. 50 reviews, a CSV), confirm the format before proceeding.
Do not scan the codebase until at least one concrete behaviour is confirmed.
Principle: the FeedbackEval benchmark shows raw human language feedback achieves only 50.5% edit success; converting to structured form first is the single highest-leverage step.
Step 2 — Categorize and cluster (human gate)
Read references/feedback-taxonomy.md. For each distinct piece of feedback, assign:
- Category — UX / Performance / Bug / Feature / Content / Other
- User intent — the underlying job-to-be-done (not the literal request)
- Severity — Critical / Important / Minor
- Pattern count — number of independent users/sources who mentioned this
Apply the pattern threshold: only advance themes with 2+ independent mentions OR Critical severity. Flag single-mention items explicitly — do not silently drop them.
Present the categorized table to the user:
| Theme | Category | Severity | Pattern count | Advance? |
|---|
→ Human gate: "Should I scan the codebase for these themes, or adjust any before I proceed?"
Do not continue to Step 3 until confirmed.
Step 3 — Scan codebase
For each approved theme, use Glob and Grep to identify affected files:
- Search by component names, route paths, function names, and UI labels derived from the theme description
- Identify related test files
- Note any existing TODO / FIXME comments in the area
Read every identified file. Do not propose edits to any file that has not been read.
Read references/context-augmentation.md to pack context efficiently for large codebases.
After reading, record for each theme:
- Files confirmed relevant (with a 1-line reason each)
- Files skipped (not relevant after reading)
- Test coverage status (covered / partial / none)
Step 4 — Propose edits (human gate)
For each theme (highest severity first), produce exactly 3 options. Read references/edit-proposal-template.md for the required format.
- Option A — Minimal: targeted patch, narrowest scope, lowest risk
- Option B — Structural refactor: addresses root cause, moderate scope
- Option C — Architectural: most comprehensive, highest scope
Each option must include:
- File(s) affected (list every file)
- Nature of change: add / modify / delete / extract / move
- Two-sentence rationale quoting or directly referencing the original feedback words
- Risk flag: "⚠ Touches shared code" or "⚠ No test coverage" where applicable
→ Human gate: Present all proposals. Ask: "Which options should I implement? (e.g. Theme 1: B, Theme 2: A)"
Do not implement anything until explicit option selections are received.
Step 5 — Implement (only if approved)
Apply approved proposals atomically — one theme at a time, one file at a time.
Before editing any file with no test coverage: state the gap and recommend writing a test first. Proceed only if the user confirms.
After each theme is complete, note which feedback items from Step 2 it resolves.
Rules
- Never scan the codebase before the Step 2 human gate confirms themes
- Never propose edits to files not read in Step 3
- Never implement without explicit Step 4 approval
- Always produce exactly 3 options (A/B/C) at Step 4 — never a single recommendation
- Single-mention feedback must be flagged, not dropped or silently advanced
- If changed code has no test coverage, flag before editing — do not skip this
- When the user flags something to never do again: update
references/feedback-taxonomy.md immediately
- When the user approves a final proposal set: save it as an example in
assets/approved-proposals/
