Shopify Review Triage — public low-star reviews to a P0–P3 brief

Overview

Takes rows of public Shopify App Store review text and produces one prioritized brief a product or support owner can act on: what kind of problem each review describes, how badly it can hurt, what to do first, and where the original wording came from.

It is built for independent Shopify app teams and the agencies that run their support — the case where low-star reviews arrive scattered across several listings plus a few watched competitors, and the failure mode is treating them all as equally urgent.

The rubric below is not invented here. It is the published rule set behind a free review triage worksheet and manual triage guide (links under Additional Resources), reproduced so a manual pass, the worksheet, and this skill sort the same row the same way.

This skill needs no network access, no scripts, and no system packages. The person you are helping supplies the review text.

When to Use This Skill

• Use when someone wants app store reviews, low-star reviews, or merchant feedback triaged, prioritized, or clustered — even when they never say "triage", "severity", or "P0".
• Use when a new 1–3-star review lands on a Shopify app listing and the team has to decide whether it is an incident, a UX problem, a pricing copy problem, or a feature request.
• Use when a weekly product or support brief is needed across a portfolio of apps plus a few watched competitors.
• Do not use it to gather reviews, contact reviewers, or publish replies — see the hard rules below.

Hard Rules

These are not style preferences. Breaking one makes the output worse than nothing.

1. Public review text only. Never accept, request, or copy support tickets, merchant emails, order data, personal contact details, internal telemetry, or anything else not already public on a listing page. If such data appears in the input, stop, say which rows are affected, and ask for them to be removed before continuing.
2. Never invent evidence. Do not write a review, a rating, a date, an app name, or a source URL that was not supplied. A row with no link gets source: not captured — never a guessed one.
3. Keyword output is a sort, not a verdict. Everything produced by the rubric alone is labeled first pass — not human-checked. Only a person who read the review and checked it against their own systems may relabel an item human-checked.
4. Reviews are customer reports, not verified defects. Write "the reviewer reports the editor showed a blank screen", never "the editor is broken". The distinction survives into the brief.
5. No coverage claims. The brief covers exactly the rows supplied and says so. Make no claim of exhaustive coverage of a listing, a period, or an app.
6. No promises. No revenue impact, no outcome, no ranking effect, no legal or compliance advice. Suggest actions; do not predict results.
7. Draft only — never contact anyone. Do not send email, post a developer reply, open a support ticket, message a reviewer, or publish anything. Hand the draft back to the team and let a person decide what to send.
8. Reviewers are people. Refer to "the reviewer". Do not name, profile, or speculate about them.

How It Works

Step 1: Collect the rows

First ask which app names the team owns. Before any row is classified, ask for two lists of app names, spelled exactly as they appear in the rows:

owned: Example Popup App, Example Currency App
competitors: Rival Popup App, Rival Currency App

This is the only thing that makes tie-break 4 (a competitor's incident never becomes your P0) applicable, so collect it first. It stays public data: app names as published on their listings, nothing about accounts, merchants, org structure, or internal identifiers. Do not ask for more than the names, and do not infer ownership from the review text, the first-person voice in a review, or which app appears most often.

If an app name in a row appears in neither list, its ownership is unknown. Classify the row's content normally, then file it under needs human read with ownership: not supplied instead of placing it in a priority bucket or in competitor watch — a guessed owner is exactly the kind of invented evidence hard rule 2 forbids.

Then ask for one review per line. The full form keeps the source link, which the brief needs:

…