[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PYYAAHWE5H7N85QH6CSK4F":3,"skill-same:01M6PYYAAHWE5H7N85QH6CSK4F":77},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":28,"commitSha":58,"skillDirectory":59,"forksCount":13,"repositoryHtmlUrl":60,"repositoryHomepageUrl":6,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M6PYYAAHWE5H7N85QH6CSK4F","shopify-review-triage",null,"Turn public 1-3-star Shopify App Store review rows into a P0-P3 triage brief: incident risk, repeated friction, pricing confusion, feature requests, and an explicit needs-human-read bucket.","duc-duy-1612\u002FOnline-Delivery-Systems-Web","duc-duy-1612","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F192231384?v=4","01M6NSDKQQDKVTHZ8DZMZ1VYY6","01M6NSDKW8DDVTQHBT1HBDDJPT",0,"MIT","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fshopify-review-triage\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"triage","review","review triage","shopify review triage","shopify","app store","reviews","app","human","incident","main","community","read","feedback","risk","brief","shopify app store review","product","support","customer","2026-11-10 10:12:30",false,"---\nname: shopify-review-triage\ndescription: \"Turn public 1-3-star Shopify App Store review rows into a P0-P3 triage brief: incident risk, repeated friction, pricing confusion, feature requests, and an explicit needs-human-read bucket.\"\ncategory: product\nrisk: none\nsource: community\nsource_repo: alfredtech2026\u002Fshopify-app-review-brief\nsource_type: community\ndate_added: \"2026-08-03\"\nauthor: alfredtech2026\ntags: [shopify, app-store-reviews, customer-feedback, triage, product-management, support]\ntools: [claude, cursor, codex, gemini, antigravity]\nlicense: \"MIT\"\nlicense_source: \"https:\u002F\u002Fgithub.com\u002Falfredtech2026\u002Fshopify-app-review-brief\u002Fblob\u002Fmain\u002FLICENSE\"\n---\n\n# Shopify Review Triage — public low-star reviews to a P0–P3 brief\n\n## Overview\n\nTakes rows of **public** Shopify App Store review text and produces one prioritized brief a\nproduct or support owner can act on: what kind of problem each review describes, how badly it\ncan hurt, what to do first, and where the original wording came from.\n\nIt is built for independent Shopify app teams and the agencies that run their support — the\ncase where low-star reviews arrive scattered across several listings plus a few watched\ncompetitors, and the failure mode is treating them all as equally urgent.\n\nThe rubric below is not invented here. It is the published rule set behind a free review triage\nworksheet and manual triage guide (links under [Additional Resources](#additional-resources)),\nreproduced so a manual pass, the worksheet, and this skill sort the same row the same way.\n\nThis skill needs no network access, no scripts, and no system packages. The person you are\nhelping supplies the review text.\n\n## When to Use This Skill\n\n- Use when someone wants app store reviews, low-star reviews, or merchant feedback triaged,\n  prioritized, or clustered — even when they never say \"triage\", \"severity\", or \"P0\".\n- Use when a new 1–3-star review lands on a Shopify app listing and the team has to decide\n  whether it is an incident, a UX problem, a pricing copy problem, or a feature request.\n- Use when a weekly product or support brief is needed across a portfolio of apps plus a few\n  watched competitors.\n- Do **not** use it to gather reviews, contact reviewers, or publish replies — see the hard\n  rules below.\n\n## Hard Rules\n\nThese are not style preferences. Breaking one makes the output worse than nothing.\n\n1. **Public review text only.** Never accept, request, or copy support tickets, merchant emails,\n   order data, personal contact details, internal telemetry, or anything else not already public\n   on a listing page. If such data appears in the input, stop, say which rows are affected, and\n   ask for them to be removed before continuing.\n2. **Never invent evidence.** Do not write a review, a rating, a date, an app name, or a source\n   URL that was not supplied. A row with no link gets `source: not captured` — never a guessed one.\n3. **Keyword output is a sort, not a verdict.** Everything produced by the rubric alone is\n   labeled *first pass — not human-checked*. Only a person who read the review and checked it\n   against their own systems may relabel an item *human-checked*.\n4. **Reviews are customer reports, not verified defects.** Write \"the reviewer reports the editor\n   showed a blank screen\", never \"the editor is broken\". The distinction survives into the brief.\n5. **No coverage claims.** The brief covers exactly the rows supplied and says so. Make no claim\n   of exhaustive coverage of a listing, a period, or an app.\n6. **No promises.** No revenue impact, no outcome, no ranking effect, no legal or compliance\n   advice. Suggest actions; do not predict results.\n7. **Draft only — never contact anyone.** Do not send email, post a developer reply, open a\n   support ticket, message a reviewer, or publish anything. Hand the draft back to the team and\n   let a person decide what to send.\n8. **Reviewers are people.** Refer to \"the reviewer\". Do not name, profile, or speculate about them.\n\n## How It Works\n\n### Step 1: Collect the rows\n\n**First ask which app names the team owns.** Before any row is classified, ask for two lists of\napp names, spelled exactly as they appear in the rows:\n\n```text\nowned: Example Popup App, Example Currency App\ncompetitors: Rival Popup App, Rival Currency App\n```\n\nThis is the only thing that makes tie-break 4 (*a competitor's incident never becomes your P0*)\napplicable, so collect it first. It stays public data: app names as published on their listings,\nnothing about accounts, merchants, org structure, or internal identifiers. Do not ask for more\nthan the names, and do not infer ownership from the review text, the first-person voice in a\nreview, or which app appears most often.\n\nIf an app name in a row appears in neither list, its ownership is unknown. Classify the row's\ncontent normally, then file it under **needs human read** with `ownership: not supplied` instead\nof placing it in a priority bucket or in competitor watch — a guessed owner is exactly the kind\nof invented evidence hard rule 2 forbids.\n\nThen ask for one review per line. The full form keeps the source link, which the brief needs:\n\n```text\nrating | app name | review date | public reviews URL | review text\n```\n\nThe shorter form used by the free worksheet is also fine — treat field 1 as the rating when it\nis a bare 1–5 (optionally followed by `star`\u002F`stars`\u002F`★`), otherwise as the app name:\n\n```text\nrating | app name | review text\n```\n\nRules for this step:\n\n- Lines starting with `#` are comments. Blank lines are skipped.\n- If a row lacks a source URL, carry `source: not captured` through to the brief. Do not drop\n  the row and do not fabricate a link.\n- Do not go and fetch anything yourself. This skill needs no network access; the person you are\n  helping pastes the public rows they already opened.\n- The trigger this rubric is tuned for is a **new 1–3-star review**. Higher-rated rows still\n  classify correctly (a 5★ review often lands in feature requests or needs-human-read), so keep\n  them if they were supplied, but never present them as low-star signal.\n\n### Step 2: First pass — apply the rubric\n\nLower-case the review text and normalize curly apostrophes (`’` → `'`) before matching, so a\npasted \"won’t load\" still matches `won't load`.\n\nFive buckets. Each row gets exactly **one primary** bucket — the first dimension below, in this\norder, with any matching keyword. Further matches are recorded as **secondary**, never as a\nsecond brief item.\n\n#### P0 · Incident risk\n\nThe purchase path, app activation, or merchant data may be at stake right now. Left alone it\ncosts the merchant money and the team installs.\n\n**Suggested action.** Try to reproduce on a test store today. If confirmed, treat it as an incident: fix or mitigate first, then reply to the reviewer with what changed.\n\n**Signal keywords.** `won't load`, `wont load`, `won't open`, `wont open`, `can't close`, `cannot close`, `won't close`, `blank screen`, `broken`, `crash`, `stopped working`, `not working`, `doesn't work`, `does not work`, `checkout`, `losing sales`, `lost sales`, `error`\n\n#### P1 · Repeated friction\n\nThe product works, but the same struggle keeps showing up across reviews or against an open\nsupport theme. Repetition is the signal, not volume of adjectives.\n\n**Suggested action.** Log it against the matching support theme. If the same complaint repeats across rows, schedule a UX fix ahead of new feature work.\n\n**Signal keywords.** `confusing`, `unclear`, `hard to`, `difficult`, `complicated`, `clunky`, `slow`, `couldn't figure`, `could not figure`, `annoying`, `had to contact support`, `setup took`, `too many steps`\n\n#### P2 · Pricing confusion\n\nWhat the merchant expected to pay and what happened diverged. Usually a copy problem in the\nlisting, the plan limits, or the upgrade prompts — not a code problem.\n\n**Suggested action.** Compare what the reviewer expected with the listing's pricing section and in-app upgrade prompts; clarify the copy where they diverge.\n\n**Signal keywords.** `pricing`, `price`, `charged`, `charge`, `billing`, `billed`, `expensive`, `free plan`, `trial`, `refund`, `hidden fee`, `hidden cost`, `paywall`\n\n#### P3 · Feature request\n\nThe merchant wants something the app does not do, or could not find. Valuable as a log entry,\nrarely urgent on its own.\n\n**Suggested action.** Add it to the feature-request log with a link to the review. If the capability already exists, reply to the reviewer with where to find it.\n\n**Signal keywords.** `wish`, `would be great`, `would love`, `please add`, `feature request`, `missing`, `if only`, `would like`, `no option to`, `needs an option`, `hope you add`, `add support for`\n\n#### Needs human read\n\nNo keyword matched. Vague frustration, sarcasm, mixed praise, or a story that needs context.\n\n**Suggested action.** No keyword matched. Read the full review yourself and file it manually — the heuristic makes no guess here.\n\n**Priority.** The worksheet labels this bucket `P2` and sorts it last. Treat that label as\nprovisional placement in the queue, not as a severity judgment — nothing has been judged yet.\n\n#### Tie-breaks and escalation\n\n1. **Most severe wins.** A row naming both a broken checkout and a billing surprise files under\n   P0 with pricing noted as secondary. Never split one review across two brief items.\n2. **Repetition escalates.** If the same friction or pricing theme appears in three or more\n   reviews within about 60 days, move it up one level and say how many rows drove the change.\n3. **Age discounts.** A review older than a year is background, not evidence of a current\n   problem, unless a recent row corroborates it. Cite it as context, never as the headline.\n4. **Competitor reviews never create a P0 for you.** Resolve the row's app name against the\n   ownership lists from step 1: `owned` keeps its rubric bucket, `competitors` moves to the\n   competitor watch section whatever its keywords matched, and a name in neither list goes to\n   needs human read with `ownership: not supplied`. A competitor's incident is roadmap,\n   positioning, or copy input — never your P0.\n5. **When unsure, choose needs human read.** The bucket exists so the rubric never launders\n   uncertainty into a priority label.\n\n### Step 3: Human pass — verify before you promote anything\n\nThe first pass is where this skill stops being able to help on its own. Before any item is\npresented as more than a keyword match, a person on the team has to:\n\n- read the full original review at its source link;\n- for P0 candidates, attempt to reproduce on a development store and check the error tracker and\n  support inbox for matching signals from the same period;\n- record the outcome as *reproduced*, *not reproduced*, or *attempted — notes attached*.\n\nAsk for these outcomes rather than assuming them. Until you have them, every item stays labeled\n*first pass — not human-checked*, including in the summary line. An unverified P0 is a candidate,\nnot an incident.\n\nKnown limits to state plainly when they apply: keyword matching is English-only, misses sarcasm\nand context, can misfile a review that mentions \"checkout\" in passing, and sees only the rows\nsupplied.\n\n### Step 4: Write the brief\n\nOne document per portfolio, sections in rubric order, every item carrying an owner, a next\naction, and a source link. An item without an owner is a note, not a brief entry.\n\n\u003C!-- brief-template -->\n```markdown\n# Low-star review brief — {portfolio or team name} — week of {YYYY-MM-DD}\n\nScope: {apps monitored} · {competitors watched} · {N} rows supplied, {date range}.\nCovers only the rows supplied — no claim of exhaustive coverage.\nReviews are customer reports, not verified defects. Items marked \"first pass\" are\nunverified keyword matches; \"human-checked\" means a person read the review and checked it.\n\n## P0 — Incident risk\n- **{App} — {signal in a few words}** ({rating}★, {review date}, source: {public reviews URL or not captured})\n  - Reviewer reports: {one sentence, in their words where possible}\n  - Status: first pass — not human-checked \u002F human-checked\n  - Reproduced: {yes \u002F no \u002F attempted — notes}\n  - Next action: {action} — owner {name}, due {date}\n\n## P1 — Repeated friction\n- **{App} — {theme}** ({rating}★, {date}, source: {public reviews URL or not captured}; also seen: {where})\n  - Status: first pass — not human-checked \u002F human-checked\n  - Next action: {UX or docs change} — owner {name}, due {date}\n\n## P2 — Pricing confusion\n- **{App} — {signal}** ({rating}★, {date}, source: {public reviews URL or not captured})\n  - Expected vs. actual: {one line}\n  - Status: first pass — not human-checked \u002F human-checked\n  - Next action: {copy or prompt change} — owner {name}, due {date}\n\n## P3 — Feature requests\n- **{App} — {request}** ({rating}★, {date}, source: {public reviews URL or not captured}) — {log it \u002F already exists → reply with where to find it}\n\n## Needs human read\n- **{App}** ({rating}★, {date}, source: {public reviews URL or not captured}) — {no keyword matched; what a human should look for}{, or: ownership: not supplied — app name on neither list}\n\n## Competitor watch\n- **{Competitor} — {signal}**: {what it implies for our roadmap, copy, or positioning}\n\n## Decisions this week\n- {one decision or experiment, with the row(s) that motivated it}\n```\n\nOpen the summary line with the counts, e.g. *\"Triaged 8 rows supplied: 3 incident risk,\n2 repeated friction, 1 pricing confusion, 1 feature request, 1 needs human read — first pass,\nnot human-checked.\"*\n\n### Step 5: Self-check before you hand it over\n\nRefuse to deliver until every line is true:\n\n- [ ] Every item names its bucket and priority from the rubric above, and nothing else.\n- [ ] Every item carries a source link or an explicit `source: not captured`.\n- [ ] Every P0–P3 item is an app on the `owned` list; every competitor row sits in competitor\n      watch; every unlisted app name says `ownership: not supplied` under needs human read.\n- [ ] No review text, rating, date, app name, or URL appears that was not supplied.\n- [ ] Every unverified item says *first pass — not human-checked*; nothing claims a human check\n      that did not happen.\n- [ ] Claims are phrased as reports (\"the reviewer reports…\"), not as findings about the code.\n- [ ] The scope line says how many rows were supplied and makes no coverage claim.\n- [ ] No promise about revenue, ratings, outcomes, or compliance appears anywhere.\n- [ ] No private data survived into the output.\n- [ ] Nothing was sent, posted, or published — the brief is a draft for the team.\n\n## Examples\n\n### Example 1: Worked example — eight rows in, first pass out\n\nThese eight fictional rows are the worksheet's own example set, so the two tools can be compared\ndirectly. Two of them are deliberately 4★ and 5★, to exercise the feature-request and\nneeds-human-read buckets.\n\nOwnership context, collected before any of it is classified:\n\n```text\nowned: Example Popup App, Example Currency App, Example Reviews App\ncompetitors: (none supplied)\n```\n\n```text\n1 | Example Popup App | The editor shows a blank screen and the popup won't load. We are losing sales every day.\n2 | Example Popup App | The overlay can't close on mobile and it blocks the checkout button.\n1 | Example Currency App | Conversion is broken at checkout and we were still billed for the month.\n3 | Example Currency App | Setup took hours and the settings screen is confusing. Support was slow to reply.\n3 | Example Reviews App | The widget looks fine but the template editor is confusing and hard to use on a tablet.\n2 | Example Currency App | We kept getting charged after uninstalling, and the pricing page never mentioned this.\n4 | Example Reviews App | Great app, but I wish it could export reviews to CSV. Please add filtering by country.\n5 | Example Reviews App | Does what it promises and support replied the same day.\n```\n\nFirst pass over those rows:\n\n```text\nrow 1 → P0 incident risk\nrow 2 → P0 incident risk\nrow 3 → P0 incident risk (secondary: pricing confusion)\nrow 4 → P1 repeated friction\nrow 5 → P1 repeated friction\nrow 6 → P2 pricing confusion\nrow 7 → P3 feature request\nrow 8 → needs human read\n```\n\n**Explanation:** Rows 4 and 5 both matched `confusing`, so they are flagged as a repeated theme —\ntwo rows, which is a cluster to watch, not yet the three that trigger escalation. Row 3 is a\nsingle P0 item with pricing recorded as secondary, never two items. Row 8 matched nothing and\nstays unjudged. All three app names are on the `owned` list, so every bucket above is the team's\nown queue and competitor watch is empty; had `Example Reviews App` been listed as a competitor\ninstead, rows 5, 7, and 8 would move there and none of them could become a P0. None of these rows\ncarried a source URL, so each item would read `source: not captured` until the team supplies the\nlisting links.\n\n### Example 2: A row that carries its source link\n\n```text\n1 | Example Popup App | 2026-07-28 | https:\u002F\u002Fapps.shopify.com\u002Fexample-popup-app\u002Freviews?ratings%5B%5D=1 | The editor shows a blank screen and the popup won't load. We are losing sales every day.\n```\n\nRendered into the brief:\n\n```markdown\n## P0 — Incident risk\n- **Example Popup App — editor reported blank, popup reported not loading** (1★, 2026-07-28, [source](https:\u002F\u002Fapps.shopify.com\u002Fexample-popup-app\u002Freviews?ratings%5B%5D=1))\n  - Reviewer reports: the editor shows a blank screen, the popup does not load, and they are losing sales daily.\n  - Status: first pass — not human-checked\n  - Reproduced: not yet attempted\n  - Next action: attempt reproduction on a development store today — owner {name}, due {date}\n```\n\n**Explanation:** It files as a P0 only because `Example Popup App` is on the `owned` list; the\nsame row from a competitor listing would render under competitor watch instead. The wording stays\na report (\"the reviewer reports\"), the status stays *first pass — not human-checked* until a\nperson verifies it, and the source link is the listing's public reviews page with the rating\nfilter kept — the App Store has no per-review permalink.\n\n## Best Practices\n\n- ✅ **Do:** keep one review in exactly one bucket, and record extra matches as secondary notes.\n- ✅ **Do:** carry `source: not captured` forward when a row has no link, so the gap is visible.\n- ✅ **Do:** label every unverified item *first pass — not human-checked*, including in the summary.\n- ✅ **Do:** phrase every finding as a customer report, not as a confirmed defect.\n- ✅ **Do:** state how many rows were supplied and refuse any coverage claim beyond them.\n- ❌ **Don't:** fetch reviews, scrape listings, or ask for support tickets, emails, or order data.\n- ❌ **Don't:** invent a rating, date, app name, or URL that was not supplied.\n- ❌ **Don't:** send, post, or publish anything — including a developer reply to a reviewer.\n- ❌ **Don't:** promise a revenue, ratings, or compliance outcome from any suggested action.\n\n## Limitations\n\n- Keyword matching is **English-only**. Non-English reviews match nothing and land in\n  needs-human-read; that is the correct outcome, not a bug to work around by translating first.\n- The rubric misses sarcasm, irony, and context, and can misfile a review that mentions\n  \"checkout\" or \"missing\" in passing.\n- It sees only the rows the person supplies. It cannot know a listing's full review history, the\n  team's error tracker, or their support inbox.\n- It cannot verify anything. Every P0 it produces is a *candidate*, not a confirmed incident,\n  until a person reproduces it.\n- It does not replace environment-specific validation, testing, or expert review. Stop and ask\n  for clarification if required inputs, permissions, or safety boundaries are missing.\n\n## Security & Safety Notes\n\n- **No commands, no network, no credentials.** This skill runs on pasted text only. It must not\n  fetch listings, call APIs, or read files outside what the person supplies.\n- **Private data is a stop condition.** If support tickets, merchant emails, order records,\n  personal contact details, or internal telemetry appear in the input, stop, name the affected\n  rows, and ask for them to be removed before continuing.\n- **No outbound messaging.** The output is a draft handed back to the team. Sending email,\n  posting a public developer reply, opening a ticket, or contacting a reviewer is out of scope\n  under every circumstance (hard rule 7).\n- **Reviewers are people.** Do not name, profile, or speculate about a reviewer; refer to\n  \"the reviewer\".\n- **No promises.** No revenue, ratings, ranking, legal, or compliance claims belong in a brief.\n\n## Common Pitfalls\n\n- **Problem:** The Shopify App Store has no stable per-review permalink.\n  **Solution:** Cite the listing's public reviews page, keep the rating filter if one was used\n  (`…\u002Freviews?ratings%5B%5D=1`), and pin the item with the review date plus the reviewer's first\n  few words so a human can find it again.\n- **Problem:** `checkout` is the noisiest keyword in the set — it fires on \"we love the checkout\n  upsell\".\n  **Solution:** A P0 whose only evidence is the word `checkout` is a needs-human-read row wearing\n  a P0 badge. Say so instead of promoting it.\n- **Problem:** `missing` and `error` cross buckets — \"missing a dark mode\" is P3, \"settings page\n  errors out\" is P0.\n  **Solution:** Primary-bucket order resolves the collision mechanically; the human pass fixes\n  the ones where it guessed wrong.\n- **Problem:** A competitor's incident looks worse than anything on the team's own listings.\n  **Solution:** It still goes to competitor watch. A competitor's P0 is never yours.\n- **Problem:** One review gets split across two sections, double-counting the same merchant and\n  inflating every count in the summary line.\n  **Solution:** One review, one item. Secondary matches are annotations.\n- **Problem:** The free in-browser worksheet parses three fields and folds everything after the\n  second `|` into the review text, so a five-field row displays its date and URL inside the quote.\n  **Solution:** Paste the short form into the worksheet and keep the long form here.\n\n## Related Skills\n\n- `@customer-research` — when the goal is broader voice-of-customer synthesis rather than\n  prioritizing a specific set of low-star review rows.\n- `@shopify-apps` — when the next step is actually building or fixing the Shopify app behavior a\n  triaged P0 points at.\n- `@before-you-build` — when a P3 feature request needs product-risk review before it becomes\n  roadmap work.\n\n## Additional Resources\n\nThis skill packages the public rubric behind **Shopify App Review Brief**, an independent\nopen-source project that is not affiliated with or endorsed by Shopify Inc. or any app developer.\nThe same four dimensions, priorities, keyword lists, and suggested actions are published in three\nplaces:\n\n- [Manual guide, tie-break rules, and brief template](https:\u002F\u002Falfredtech2026.github.io\u002Fshopify-app-review-brief\u002Fguides\u002Fshopify-app-review-triage.html)\n- [Free in-browser worksheet that automates the first pass](https:\u002F\u002Falfredtech2026.github.io\u002Fshopify-app-review-brief\u002Ftools\u002Freview-triage-worksheet.html)\n- [Two worked sample briefs over real public reviews](https:\u002F\u002Falfredtech2026.github.io\u002Fshopify-app-review-brief\u002F#samples)\n\nUpstream source repository: [alfredtech2026\u002Fshopify-app-review-brief](https:\u002F\u002Fgithub.com\u002Falfredtech2026\u002Fshopify-app-review-brief) (MIT).\n","# Shopify Review Triage — public low-star reviews to a P0–P3 brief\n\n## Overview\n\nTakes rows of **public** Shopify App Store review text and produces one prioritized brief a\nproduct or support owner can act on: what kind of problem each review describes, how badly it\ncan hurt, what to do first, and where the original wording came from.\n\nIt is built for independent Shopify app teams and the agencies that run their support — the\ncase where low-star reviews arrive scattered across several listings plus a few watched\ncompetitors, and the failure mode is treating them all as equally urgent.\n\nThe rubric below is not invented here. It is the published rule set behind a free review triage\nworksheet and manual triage guide (links under [Additional Resources](#additional-resources)),\nreproduced so a manual pass, the worksheet, and this skill sort the same row the same way.\n\nThis skill needs no network access, no scripts, and no system packages. The person you are\nhelping supplies the review text.\n\n## When to Use This Skill\n\n- Use when someone wants app store reviews, low-star reviews, or merchant feedback triaged,\n  prioritized, or clustered — even when they never say \"triage\", \"severity\", or \"P0\".\n- Use when a new 1–3-star review lands on a Shopify app listing and the team has to decide\n  whether it is an incident, a UX problem, a pricing copy problem, or a feature request.\n- Use when a weekly product or support brief is needed across a portfolio of apps plus a few\n  watched competitors.\n- Do **not** use it to gather reviews, contact reviewers, or publish replies — see the hard\n  rules below.\n\n## Hard Rules\n\nThese are not style preferences. Breaking one makes the output worse than nothing.\n\n1. **Public review text only.** Never accept, request, or copy support tickets, merchant emails,\n   order data, personal contact details, internal telemetry, or anything else not already public\n   on a listing page. If such data appears in the input, stop, say which rows are affected, and\n   ask for them to be removed before continuing.\n2. **Never invent evidence.** Do not write a review, a rating, a date, an app name, or a source\n   URL that was not supplied. A row with no link gets `source: not captured` — never a guessed one.\n3. **Keyword output is a sort, not a verdict.** Everything produced by the rubric alone is\n   labeled *first pass — not human-checked*. Only a person who read the review and checked it\n   against their own systems may relabel an item *human-checked*.\n4. **Reviews are customer reports, not verified defects.** Write \"the reviewer reports the editor\n   showed a blank screen\", never \"the editor is broken\". The distinction survives into the brief.\n5. **No coverage claims.** The brief covers exactly the rows supplied and says so. Make no claim\n   of exhaustive coverage of a listing, a period, or an app.\n6. **No promises.** No revenue impact, no outcome, no ranking effect, no legal or compliance\n   advice. Suggest actions; do not predict results.\n7. **Draft only — never contact anyone.** Do not send email, post a developer reply, open a\n   support ticket, message a reviewer, or publish anything. Hand the draft back to the team and\n   let a person decide what to send.\n8. **Reviewers are people.** Refer to \"the reviewer\". Do not name, profile, or speculate about them.\n\n## How It Works\n\n### Step 1: Collect the rows\n\n**First ask which app names the team owns.** Before any row is classified, ask for two lists of\napp names, spelled exactly as they appear in the rows:\n\n```text\nowned: Example Popup App, Example Currency App\ncompetitors: Rival Popup App, Rival Currency App\n```\n\nThis is the only thing that makes tie-break 4 (*a competitor's incident never becomes your P0*)\napplicable, so collect it first. It stays public data: app names as published on their listings,\nnothing about accounts, merchants, org structure, or internal identifiers. Do not ask for more\nthan the names, and do not infer ownership from the review text, the first-person voice in a\nreview, or which app appears most often.\n\nIf an app name in a row appears in neither list, its ownership is unknown. Classify the row's\ncontent normally, then file it under **needs human read** with `ownership: not supplied` instead\nof placing it in a priority bucket or in competitor watch — a guessed owner is exactly the kind\nof invented evidence hard rule 2 forbids.\n\nThen ask for one review per line. The full form keeps the source link, which the brief needs:\n\n```text\nrating | app name | review date | public reviews URL | review text\n```\n\nThe shorter form used by the free worksheet is also fine — treat field 1 as the rating when it\nis a bare 1–5 (optionally followed by `star`\u002F`stars`\u002F`★`), otherwise as the app name:\n\n```text\nrating | app name | review text\n```\n\nRules for this step:\n\n- Lines starting with `#` are comments. Blank lines are skipped.\n- If a row lacks a source URL, carry `source: not captured` through to the brief. Do not drop\n  the row and do not fabricate a link.\n- Do not go and fetch anything yourself. This skill needs no network access; the person you are\n  helping pastes the public rows they already opened.\n- The trigger this rubric is tuned for is a **new 1–3-star review**. Higher-rated rows still\n  classify correctly (a 5★ review often lands in feature requests or needs-human-read), so keep\n  them if they were supplied, but never present them as low-star signal.\n\n### Step 2: First pass — apply the rubric\n\nLower-case the review text and normalize curly apostrophes (`’` → `'`) before matching, so a\npasted \"won’t load\" still matches `won't load`.\n\nFive buckets. Each row gets exactly **one primary** bucket — the first dimension below, in this\norder, with any matching keyword. Further matches are recorded as **secondary**, never as a\nsecond brief item.\n\n#### P0 · Incident risk\n\nThe purchase path, app activation, or merchant data may be at stake right now. Left alone it\ncosts the merchant money and the team installs.\n\n**Suggested action.** Try to reproduce on a test store today. If confirmed, treat it as an incident: fix or mitigate first, then reply to the reviewer with what changed.\n\n**Signal keywords.** `won't load`, `wont load`, `won't open`, `wont open`, `can't close`, `cannot close`, `won't close`, `blank screen`, `broken`, `crash`, `stopped working`, `not working`, `doesn't work`, `does not work`, `checkout`, `losing sales`, `lost sales`, `error`\n\n#### P1 · Repeated friction\n\nThe product works, but the same struggle keeps showing up across reviews or against an open\nsupport theme. Repetition is the signal, not volume of adjectives.\n\n**Suggested action.** Log it against the matching support theme. If the same complaint repeats across rows, schedule a UX fix ahead of new feature work.\n\n**Signal keywords.** `confusing`, `unclear`, `hard to`, `difficult`, `complicated`, `clunky`, `slow`, `couldn't figure`, `could not figure`, `annoying`, `had to contact support`, `setup took`, `too many steps`\n\n#### P2 · Pricing confusion\n\nWhat the merchant expected to pay and what happened diverged. Usually a copy problem in the\nlisting, the plan limits, or the upgrade prompts — not a code problem.\n\n**Suggested action.** Compare what the reviewer expected with the listing's pricing section and in-app upgrade prompts; clarify the copy where they diverge.\n\n**Signal keywords.** `pricing`, `price`, `charged`, `charge`, `billing`, `billed`, `expensive`, `free plan`, `trial`, `refund`, `hidden fee`, `hidden cost`, `paywall`\n\n#### P3 · Feature request\n\nThe merchant wants something the app does not do, or could not find. Valuable as a log entry,\nrarely urgent on its own.\n\n**Suggested action.** Add it to the feature-request log with a link to the review. If the capability already exists, reply to the reviewer with where to find it.\n\n**Signal keywords.** `wish`, `would be great`, `would love`, `please add`, `feature request`, `missing`, `if only`, `would like`, `no option to`, `needs an option`, `hope you add`, `add support for`\n\n#### Needs human read\n\nNo keyword matched. Vague frustration, sarcasm, mixed praise, or a story that needs context.\n\n**Suggested action.** No keyword matched. Read the full review yourself and file it manually — the heuristic makes no guess here.\n\n**Priority.** The worksheet labels this bucket `P2` and sorts it last. Treat that label as\nprovisional placement in the queue, not as a severity judgment — nothing has been judged yet.\n\n#### Tie-breaks and escalation\n\n1. **Most severe wins.** A row naming both a broken checkout and a billing surprise files under\n   P0 with pricing noted as secondary. Never split one review across two brief items.\n2. **Repetition escalates.** If the same friction or pricing theme appears in three or more\n   reviews within about 60 days, move it up one level and say how many rows drove the change.\n3. **Age discounts.** A review older than a year is background, not evidence of a current\n   problem, unless a recent row corroborates it. Cite it as context, never as the headline.\n4. **Competitor reviews never create a P0 for you.** Resolve the row's app name against the\n   ownership lists from step 1: `owned` keeps its rubric bucket, `competitors` moves to the\n   competitor watch section whatever its keywords matched, and a name in neither list goes to\n   needs human read with `ownership: not supplied`. A competitor's incident is roadmap,\n   positioning, or copy input — never your P0.\n5. **When unsure, choose needs human read.** The bucket exists so the rubric never launders\n   uncertainty into a priority label.\n\n### Step 3: Human pass — verify before you promote anything\n\nThe first pass is where this skill stops being able to help on its own. Before any item is\npresented as more than a keyword match, a person on the team has to:\n\n- read the full original review at its source link;\n- for P0 candidates, attempt to reproduce on a development store and check the error tracker and\n  support inbox for matching signals from the same period;\n- record the outcome as *reproduced*, *not reproduced*, or *attempted — notes attached*.\n\nAsk for these outcomes rather than assuming them. Until you have them, every item stays labeled\n*first pass — not human-checked*, including in the summary line. An unverified P0 is a candidate,\nnot an incident.\n\nKnown limits to state plainly when they apply: keyword matching is English-only, misses sarcasm\nand context, can misfile a review that mentions \"checkout\" in passing, and sees only the rows\nsupplied.\n\n### Step 4: Write the brief\n\nOne document per portfolio, sections in rubric order, every item carrying an owner, a next\naction, and a source link. An item without an owner is a note, not a brief entry.\n\n\u003C!-- brief-template -->\n```markdown\n# Low-star review brief — {portfolio or team name} — week of {YYYY-MM-DD}\n\nScope: {apps monitored} · {competitors watched} · {N} rows supplied, {date range}.\nCovers only the rows supplied — no claim of exhaustive coverage.\nReviews are customer reports, not verified defects. Items marked \"first pass\" are\nunverified keyword matches; \"human-checked\" means a person read the review and checked it.\n\n## P0 — Incident risk\n- **{App} — {signal in a few words}** ({rating}★, {review date}, source: {public reviews URL or not captured})\n  - Reviewer reports: {one sentence, in their words where possible}\n  - Status: first pass — not human-checked \u002F human-checked\n  - Reproduced: {yes \u002F no \u002F attempted — notes}\n  - Next action: {action} — owner {name}, due {date}\n\n## P1 — Repeated friction\n- **{App} — {theme}** ({rating}★, {date}, source: {public reviews URL or not captured}; also seen: {where})\n  - Status: first pass — not human-checked \u002F human-checked\n  - Next action: {UX or docs change} — owner {name}, due {date}\n\n## P2 — Pricing confusion\n- **{App} — {signal}** ({rating}★, {date}, source: {public reviews URL or not captured})\n  - Expected vs. actual: {one line}\n  - Status: first pass — not human-checked \u002F human-checked\n  - Next action: {copy or prompt change} — owner {name}, due {date}\n\n## P3 — Feature requests\n- **{App} — {request}** ({rating}★, {date}, source: {public reviews URL or not captured}) — {log it \u002F already exists → reply with where to find it}\n\n## Needs human read\n- **{App}** ({rating}★, {date}, source: {public reviews URL or not captured}) — {no keyword matched; what a human should look for}{, or: ownership: not supplied — app name on neither list}\n\n## Competitor watch\n- **{Competitor} — {signal}**: {what it implies for our roadmap, copy, or positioning}\n\n## Decisions this week\n- {one decision or experiment, with the row(s) that motivated it}\n```\n\nOpen the summary line with the counts, e.g. *\"Triaged 8 rows supplied: 3 incident risk,\n2 repeated friction, 1 pricing confusion, 1 feature request, 1 needs human read — first pass,\nnot human-checked.\"*\n\n### Step 5: Self-check before you hand it over\n\nRefuse to deliver until every line is true:\n\n- [ ] Every item names its bucket and priority from the rubric above, and nothing else.\n- [ ] Every item carries a source link or an explicit `source: not captured`.\n- [ ] Every P0–P3 item is an app on the `owned` list; every competitor row sits in competitor\n      watch; every unlisted app name says `ownership: not supplied` under needs human read.\n- [ ] No review text, rating, date, app name, or URL appears that was not supplied.\n- [ ] Every unverified item says *first pass — not human-checked*; nothing claims a human check\n      that did not happen.\n- [ ] Claims are phrased as reports (\"the reviewer reports…\"), not as findings about the code.\n- [ ] The scope line says how many rows were supplied and makes no coverage claim.\n- [ ] No promise about revenue, ratings, outcomes, or compliance appears anywhere.\n- [ ] No private data survived into the output.\n- [ ] Nothing was sent, posted, or published — the brief is a draft for the team.\n\n## Examples\n\n### Example 1: Worked example — eight rows in, first pass out\n\nThese eight fictional rows are the worksheet's own example set, so the two tools can be compared\ndirectly. Two of them are deliberately 4★ and 5★, to exercise the feature-request and\nneeds-human-read buckets.\n\nOwnership context, collected before any of it is classified:\n\n```text\nowned: Example Popup App, Example Currency App, Example Reviews App\ncompetitors: (none supplied)\n```\n\n```text\n1 | Example Popup App | The editor shows a blank screen and the popup won't load. We are losing sales every day.\n2 | Example Popup App | The overlay can't close on mobile and it blocks the checkout button.\n1 | Example Currency App | Conversion is broken at checkout and we were still billed for the month.\n3 | Example Currency App | Setup took hours and the settings screen is confusing. Support was slow to reply.\n3 | Example Reviews App | The widget looks fine but the template editor is confusing and hard to use on a tablet.\n2 | Example Currency App | We kept getting charged after uninstalling, and the pricing page never mentioned this.\n4 | Example Reviews App | Great app, but I wish it could export reviews to CSV. Please add filtering by country.\n5 | Example Reviews App | Does what it promises and support replied the same day.\n```\n\nFirst pass over those rows:\n\n```text\nrow 1 → P0 incident risk\nrow 2 → P0 incident risk\nrow 3 → P0 incident risk (secondary: pricing confusion)\nrow 4 → P1 repeated friction\nrow 5 → P1 repeated friction\nrow 6 → P2 pricing confusion\nrow 7 → P3 feature request\nrow 8 → needs human read\n```\n\n**Explanation:** Rows 4 and 5 both matched `confusing`, so they are flagged as a repeated theme —\ntwo rows, which is a cluster to watch, not yet the three that trigger escalation. Row 3 is a\nsingle P0 item with pricing recorded as secondary, never two items. Row 8 matched nothing and\nstays unjudged. All three app names are on the `owned` list, so every bucket above is the team's\nown queue and competitor watch is empty; had `Example Reviews App` been listed as a competitor\ninstead, rows 5, 7, and 8 would move there and none of them could become a P0. None of these rows\ncarried a source URL, so each item would read `source: not captured` until the team supplies the\nlisting links.\n\n### Example 2: A row that carries its source link\n\n```text\n1 | Example Popup App | 2026-07-28 | https:\u002F\u002Fapps.shopify.com\u002Fexample-popup-app\u002Freviews?ratings%5B%5D=1 | The editor shows a blank screen and the popup won't load. We are losing sales every day.\n```\n\nRendered into the brief:\n\n```markdown\n## P0 — Incident risk\n- **Example Popup App — editor reported blank, popup reported not loading** (1★, 2026-07-28, [source](https:\u002F\u002Fapps.shopify.com\u002Fexample-popup-app\u002Freviews?ratings%5B%5D=1))\n  - Reviewer reports: the editor shows a blank screen, the popup does not load, and they are losing sales daily.\n  - Status: first pass — not human-checked\n  - Reproduced: not yet attempted\n  - Next action: attempt reproduction on a development store today — owner {name}, due {date}\n```\n\n**Explanation:** It files as a P0 only because `Example Popup App` is on the `owned` list; the\nsame row from a competitor listing would render under competitor watch instead. The wording stays\na report (\"the reviewer reports\"), the status stays *first pass — not human-checked* until a\nperson verifies it, and the source link is the listing's public reviews page with the rating\nfilter kept — the App Store has no per-review permalink.\n\n## Best Practices\n\n- ✅ **Do:** keep one review in exactly one bucket, and record extra matches as secondary notes.\n- ✅ **Do:** carry `source: not captured` forward when a row has no link, so the gap is visible.\n- ✅ **Do:** label every unverified item *first pass — not human-checked*, including in the summary.\n- ✅ **Do:** phrase every finding as a customer report, not as a confirmed defect.\n- ✅ **Do:** state how many rows were supplied and refuse any coverage claim beyond them.\n- ❌ **Don't:** fetch reviews, scrape listings, or ask for support tickets, emails, or order data.\n- ❌ **Don't:** invent a rating, date, app name, or URL that was not supplied.\n- ❌ **Don't:** send, post, or publish anything — including a developer reply to a reviewer.\n- ❌ **Don't:** promise a revenue, ratings, or compliance outcome from any suggested action.\n\n## Limitations\n\n- Keyword matching is **English-only**. Non-English reviews match nothing and land in\n  needs-human-read; that is the correct outcome, not a bug to work around by translating first.\n- The rubric misses sarcasm, irony, and context, and can misfile a review that mentions\n  \"checkout\" or \"missing\" in passing.\n- It sees only the rows the person supplies. It cannot know a listing's full review history, the\n  team's error tracker, or their support inbox.\n- It cannot verify anything. Every P0 it produces is a *candidate*, not a confirmed incident,\n  until a person reproduces it.\n- It does not replace environment-specific validation, testing, or expert review. Stop and ask\n  for clarification if required inputs, permissions, or safety boundaries are missing.\n\n## Security & Safety Notes\n\n- **No commands, no network, no credentials.** This skill runs on pasted text only. It must not\n  fetch listings, call APIs, or read files outside what the person supplies.\n- **Private data is a stop condition.** If support tickets, merchant emails, order records,\n  personal contact details, or internal telemetry appear in the input, stop, name the affected\n  rows, and ask for them to be removed before continuing.\n- **No outbound messaging.** The output is a draft handed back to the team. Sending email,\n  posting a public developer reply, opening a ticket, or contacting a reviewer is out of scope\n  under every circumstance (hard rule 7).\n- **Reviewers are people.** Do not name, profile, or speculate about a reviewer; refer to\n  \"the reviewer\".\n- **No promises.** No revenue, ratings, ranking, legal, or compliance claims belong in a brief.\n\n## Common Pitfalls\n\n- **Problem:** The Shopify App Store has no stable per-review permalink.\n  **Solution:** Cite the listing's public reviews page, keep the rating filter if one was used\n  (`…\u002Freviews?ratings%5B%5D=1`), and pin the item with the review date plus the reviewer's first\n  few words so a human can find it again.\n- **Problem:** `checkout` is the noisiest keyword in the set — it fires on \"we love the checkout\n  upsell\".\n  **Solution:** A P0 whose only evidence is the word `checkout` is a needs-human-read row wearing\n  a P0 badge. Say so instead of promoting it.\n- **Problem:** `missing` and `error` cross buckets — \"missing a dark mode\" is P3, \"settings page\n  errors out\" is P0.\n  **Solution:** Primary-bucket order resolves the collision mechanically; the human pass fixes\n  the ones where it guessed wrong.\n- **Problem:** A competitor's incident looks worse than anything on the team's own listings.\n  **Solution:** It still goes to competitor watch. A competitor's P0 is never yours.\n- **Problem:** One review gets split across two sections, double-counting the same merchant and\n  inflating every count in the summary line.\n  **Solution:** One review, one item. Secondary matches are annotations.\n- **Problem:** The free in-browser worksheet parses three fields and folds everything after the\n  second `|` into the review text, so a five-field row displays its date and URL inside the quote.\n  **Solution:** Paste the short form into the worksheet and keep the long form here.\n\n## Related Skills\n\n- `@customer-research` — when the goal is broader voice-of-customer synthesis rather than\n  prioritizing a specific set of low-star review rows.\n- `@shopify-apps` — when the next step is actually building or fixing the Shopify app behavior a\n  triaged P0 points at.\n- `@before-you-build` — when a P3 feature request needs product-risk review before it becomes\n  roadmap work.\n\n## Additional Resources\n\nThis skill packages the public rubric behind **Shopify App Review Brief**, an independent\nopen-source project that is not affiliated with or endorsed by Shopify Inc. or any app developer.\nThe same four dimensions, priorities, keyword lists, and suggested actions are published in three\nplaces:\n\n- [Manual guide, tie-break rules, and brief template](https:\u002F\u002Falfredtech2026.github.io\u002Fshopify-app-review-brief\u002Fguides\u002Fshopify-app-review-triage.html)\n- [Free in-browser worksheet that automates the first pass](https:\u002F\u002Falfredtech2026.github.io\u002Fshopify-app-review-brief\u002Ftools\u002Freview-triage-worksheet.html)\n- [Two worked sample briefs over real public reviews](https:\u002F\u002Falfredtech2026.github.io\u002Fshopify-app-review-brief\u002F#samples)\n\nUpstream source repository: [alfredtech2026\u002Fshopify-app-review-brief](https:\u002F\u002Fgithub.com\u002Falfredtech2026\u002Fshopify-app-review-brief) (MIT).\n",{"name":5,"risk":43,"tags":44,"tools":48,"author":54,"source":29,"license":14,"category":35,"date_added":55,"description":7,"source_repo":56,"source_type":29,"license_source":57},"none",[22,45,46,18,47,36],"app-store-reviews","customer-feedback","product-management",[49,50,51,52,53],"claude","cursor","codex","gemini","antigravity","alfredtech2026","2026-08-03","alfredtech2026\u002Fshopify-app-review-brief","https:\u002F\u002Fgithub.com\u002Falfredtech2026\u002Fshopify-app-review-brief\u002Fblob\u002Fmain\u002FLICENSE","f3312ba749561b6159f477dbfc9313c875d40a56",".agents\u002Fskills_archive\u002Fshopify-review-triage","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612","2026-10-25 23:50:58",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill shopify-review-triage",{"tool":69,"command":70},"bunx","bunx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill shopify-review-triage",{"tool":72,"command":73},"pnpm","pnpm dlx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill shopify-review-triage","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fshopify-review-triage\u002FSKILL.md",true,[],[78,107,128,152,179,203],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":89,"publishedAt":38},"01M6Q0FA5FZ410Z33Z3TFQ4DBA","zero-trust","Implement zero-trust network architecture. Configure identity-based access, micro-segmentation, and continuous verification. Use when implementing modern security architectures.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fzero-trust\u002FSKILL.md",[84],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[90,91,92,93,94,95,80,96,97,98,99,100,29,28,101,102,103,104,105,106],"ZeRO","trust","zero trust","architecture","assessment","verification","segmentation","devops-security","access","configure","only","active","critical","scope","scripts","relevant","implementing",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":38},"01M6Q0F1YZJW3KX5FBKEVZ8CV4","zcode-delegate","Delegate coding tasks to the Z.AI ZCode CLI only when the user explicitly requests it, while the orchestrator retains review and landing responsibility.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fzcode-delegate\u002FSKILL.md",[],[114,115,116,19,117,118,119,120,121,122,123,30,124,100,125,29,126,25,102,127],"delegate","zcode","zcode delegate","cli","orchestration","tasks","run","Bash","model","node","orchestrator","files","desktop app","agent-orchestration",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":38},"01M6Q0ETK41VGNMYEXW0T00AJN","youtube-transcript","Fetch YouTube transcripts through DeepAPI or local fallback tooling and save clean text output.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-transcript\u002FSKILL.md",[],[135,136,137,138,139,51,140,141,142,143,144,145,146,29,28,147,148,149,150,151],"transcript","youtube transcript","youtube","safe","github","research","license","https","text","fetch","tooling","clean","local","output","deepapi","youtube transcripts","blob",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":169,"publishedAt":38},"01M6Q0EPPH2PVMDW40017F8WX0","youtube-transcript-skills","Fetch YouTube video transcripts, search videos\u002Fchannels, browse channels, and extract playlists via the getyoutubetranscript.com API - free tier, no card required.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-transcript-skills\u002FSKILL.md",[158,161,164],{"categoryNo":159,"categoryName":160,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":162,"categoryName":163,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":165,"categoryName":166,"taxonomyType":167,"taxonomyTypeDesc":168},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[135,136,137,170,138,52,139,51,141,171,172,173,174,144,175,29,28,176,177,178],"youtube transcript skills","search","api","Video","browse","api-integration","free","card","channels",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":189,"publishedAt":38},"01M6Q0EAB96PX83W5PTE8A0R8D","youtube-notetaker","Turn YouTube talks into local study notes with slides, transcripts, editable annotations, and a markdown-backed viewer.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-notetaker\u002FSKILL.md",[185,188],{"categoryNo":186,"categoryName":187,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":162,"categoryName":163,"taxonomyType":87,"taxonomyTypeDesc":88},[137,190,191,117,138,192,193,194,195,141,173,196,197,198,199,28,200,147,201,202],"youtube notetaker","notetaker","workflow","official","notes","code","markdown","slides","annotations","README","study","dair-academy","viewer",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":207,"categories":208,"keywords":210,"publishedAt":38},"01M6Q0E55F0GW5MX48V8HXS8B5","youtube-full","Fetch YouTube transcripts, search videos, browse channels, and extract playlists via TranscriptAPI — no yt-dlp, no Google API key, works from any cloud server.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-full\u002FSKILL.md",[209],{"categoryNo":159,"categoryName":160,"taxonomyType":87,"taxonomyTypeDesc":88},[211,137,212,213,138,52,171,214,215,172,173,174,144,216,175,29,28,176,217,150],"youtube full","full","google","server","dlp","credits","automatic"]