Review Analysis

---

name: review-analysis description: Analyze customer reviews, complaints, and feedback to find repeat patterns, likely root causes, and action priorities. Use when teams need to cluster complaints, separate product issues from messaging issues, identify purchase drivers or refund triggers, and turn messy review data into a concise decision-ready report.

---

Review Analysis

Turn messy reviews, complaints, and feedback into a short decision memo the team can actually act on.

This skill is not just for “summarizing reviews.”

Its real job is to help answer:

What are people repeatedly saying?

What problems are actually frequent vs just loud?

Is the issue in the product, the messaging, the offer, shipping, or support?

What should the team fix first?

What can marketing, product, ops, and support each learn from the feedback?

Solves

Review data is usually noisy and operationally useless in raw form:

hundreds of comments, but no pattern hierarchy;

teams confuse anecdotes with repeat problems;

product issues get mixed with bad expectation-setting;

strengths are underused because nobody clusters positive themes;

support, product, and growth teams all read the same reviews differently;

no one translates feedback into action priorities.

Goal: Turn unstructured feedback into pattern clusters, likely causes, and recommended next steps.

Use when

Use when the user needs structured insight from customer feedback rather than a raw summary.

Typical cases:

summarizing product reviews from marketplaces or app stores;

clustering repeated complaints;

identifying refund / return drivers;

extracting product strengths and buyer-loved features;

separating product quality issues from messaging or expectation mismatch;

turning review data into FAQ, copy, product, or support actions;

preparing a concise report for product, ops, CX, or marketing teams.

Do not use when

Do not use this skill when:

the user only wants sentiment labels with no explanation;

the task is broad social listening across the public web rather than a defined feedback set;

there is too little review data to identify meaningful patterns;

the user wants rigorous statistical causality rather than directional pattern analysis;

the task is support ticket workflow automation rather than insight extraction.

Inputs

Ask for the minimum useful analysis set:

review source(s)

product / service name

review text or feedback sample

date range, if relevant

market / platform, if relevant

whether focus should be on complaints, positives, refunds, retention, or all feedback

any business question to prioritize

Workflow

1. Define the review set

Clarify what is being analyzed:

marketplace reviews

app reviews

support complaints

refund / return notes

post-purchase survey responses

social comments collected into a feedback set

2. Normalize and cluster the feedback

Group feedback into useful buckets, such as:

product quality / defects

expectation mismatch

shipping / logistics

service / support

pricing / value perception

feature gaps

usability / onboarding friction

trust / claim issues

delight drivers / positive strengths

3. Identify repeat patterns

For each cluster, assess:

frequency

severity

confidence level

likely root cause

which team owns the problem

Always distinguish:

repeat pattern vs loud anecdote

product issue vs messaging issue

true defect vs wrong customer expectation

4. Translate insight into action

Recommend the next step clearly:

fix now

monitor

rewrite messaging

update FAQ

adjust offer or positioning

escalate to product / ops / support

Output format

Return a concise decision-ready report:

1. Top patterns - ranked by importance, not just by volume

2. Evidence snippets - short representative quotes or examples

3. Likely root cause - product / messaging / offer / shipping / support / unclear

4. Severity / urgency - high / medium / low, with short explanation

5. Recommended action - what should be done next and by whom

6. Optional positives worth amplifying - strengths to reuse in copy, PDPs, ads, or FAQs

Quality bar

A strong analysis should:

separate signal from noise;

keep evidence snippets short and representative;

distinguish product issues from expectation-setting issues;

avoid pretending root cause certainty is higher than it is;

identify actionable implications, not just themes;

help a real operator decide what to do next.

What “better” looks like

Good output should make it obvious:

what the main complaints are;

what the hidden strengths are;

which issues are operational vs messaging-driven;

what deserves immediate action;

what can be used to improve copy, FAQ, product decisions, or CX.

Resources

Read references/output-template.md for the standard report layout.