Feedback triage

Skill ramanbamba/10x-pm/skills/feedback-triage

Prompts don't compound. Skills do. The open-source AI toolkit for product managers — 13 Claude Code skills + 3 red-team agents for the full PM workflow.

Install

npx -y skills add ramanbamba/10x-pm --skill feedback-triage

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Classify and rank a pile of raw customer feedback — support tickets, app reviews, NPS verbatims, sales notes, survey responses — into themes with counts, severity, and recommended actions. Use when the user says "triage this feedback", "what are customers complaining about", "analyze these reviews/tickets", or shares a feedback export (CSV, text dump).

SKILL.md

2.9 KB, as published. Nobody here has run it

Feedback Triage

Turn a feedback dump into a ranked, countable picture of what's actually hurting users — with the receipts attached.

Before triaging

Confirm the source and time window. Reviews skew angry; sales notes skew deal-driven; NPS skews extremes. Name the skew in the output.
Ask if there's a segmentation field worth cutting by (plan tier, platform, tenure). A complaint from 40% of enterprise accounts ranks differently than 40% of free users.
For large files (>200 items), use code (Python/pandas) to count rather than eyeballing — exact counts, not impressions.

Workflow

Read/parse everything. For structured exports, load programmatically; dedupe obvious repeats from the same user.
Tag each item with: theme, severity (blocker / major friction / minor / request), and segment if available. Build the taxonomy bottom-up from the data — don't force items into preconceived buckets. Cap at ~10 themes; merge or use "Other" beyond that.
Count honestly. Report both raw counts and % of total. Never say "many users" when the number is 7.
Rank by pain, not just volume. Rank = f(count, severity, segment value, trend). A low-volume blocker for paying customers can outrank a high-volume cosmetic gripe — show the reasoning when rank diverges from raw count.
Pull 2–3 verbatim quotes per top theme. Quotes travel further in orgs than counts do.
Recommend a next action per top theme: fix now / investigate / add to backlog with link / communicate workaround / no action (with reason).

Output format

# Feedback triage — [source], [window]
**Volume:** [N] items ([deduped from M]) · **Known skew:** [source bias]

## Headline
[One sentence: the single most important thing this data says.]

## Themes by pain rank
| # | Theme | Count | % | Severity | Segment concentration | Trend |
|---|---|---|---|---|---|---|

## Top themes in detail
### 1. [Theme]
[Counts, quotes with source IDs, why it ranks here, recommended action + owner suggestion]

## Divergences
[Where pain-rank ≠ volume-rank, and why]

## Watch list
[Low-volume but new or fast-growing signals]

## Method notes
[Taxonomy decisions, dedupe rules, anything ambiguous in the tagging]

Quality bar — self-check

Every count is exact (computed, not estimated) for structured inputs.
Quotes are verbatim with a traceable ID.
Source skew is named in the header.
Rank divergences from volume are justified, never silent.
"No action" is used where honest — recommending action on everything is triage failure.