Token导航 LogoToken导航

Agent Skill · 开发

feedback-analysis(反馈分析)

feedback-analysis 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

feedback-analysis 是开发类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为需要联网;许可证信息还不明确,第三方扫描有提醒项,按安装量在开发类的 21,746 个 Skill 里排第 17,122。

总安装 441周安装 18GitHub Stars 25下载 143核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:feedback-analysis(反馈分析)
来源仓库:https://github.com/oimiragieo/agent-studio
仓库路径:skills/feedback-analysis
安装命令:
npx skills add https://github.com/oimiragieo/agent-studio --skill feedback-analysis
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/oimiragieo/agent-studio --skill feedback-analysis

这个 Skill 是做什么的

开发类 Skill 面向写代码、改代码和排查问题,一般会读写仓库文件,部分还会执行构建或测试命令。

feedback-analysis 将客户反馈转化为可执行洞察,覆盖情感、NPS、聚类和路线图优先级。适用于 Codex、Claude、Cursor、Gemini CLI,适合产品改进和用户体验优化时使用。整合多渠道数据,提供六维度分析:情感、评分、聚类、分流、流失信号和优先级。

安装前需确认权限范围和维护状态,注意涉及用户数据时需确保合规处理。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:skills/feedback-analysis

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/oimiragieo/agent-studio --skill feedback-analy…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

feedback-analysis 怎么安装?

在终端执行 npx skills add https://github.com/oimiragieo/agent-studio --skill feedback-analysis。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

feedback-analysis 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

feedback-analysis 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

feedback-analysis 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

feedback-analysis 用的人多吗?

公开数据是累计安装 441 次,近一周安装 18 次,下载 143 次,GitHub 25 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

feedback-analysis 安全吗?

第三方扫描有提醒项,说明存在需要人工确认的行为。安装前请打开源码看清它读了什么、联网到哪里。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方扫描存在提醒项或未通过项,需要人工逐条确认。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理开发类任务、又不想每次都手写提示词的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

开发类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
skill-vetter

技能审查员 · OpenClaw

8,779,018986操作浏览器MIT-0通过
ontology

本体论 · OpenClaw

6,636,960576只读MIT-0通过
entra-app-registration

内部应用程序注册 · Codex、Claude

6,631,872764接触敏感数据未明确通过
entra-app-registration

内部应用程序注册 · Codex、Claude

3,757,680201接触敏感数据未明确通过
nano-banana-pro

纳米香蕉专业版 · OpenClaw

3,526,898364接触敏感数据MIT-0有提醒
feedback-analysis

反馈分析 · 本页

44125需要联网未明确有提醒

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Feedback Analysis

Overview

Customer feedback analysis transforms raw feedback into actionable intelligence across six interconnected capability areas. All capabilities share a common data pipeline: unified multi-channel feedback collection feeds sentiment detection, which powers NPS/CSAT scoring, feature clustering, ticket triage, churn signals, and ultimately roadmap prioritization.

Six Capability Areas:

  1. Sentiment Analysis — Multi-channel emotion detection beyond positive/negative/neutral
  2. NPS/CSAT Frameworks — Dual-track score + text analysis with mismatch detection
  3. Feature Request Clustering — Group and prioritize by frequency, emotion, and churn correlation
  4. Support Ticket Triage — Hierarchical taxonomy-based categorization and routing
  5. Churn Signal Detection — Behavioral and textual early warning systems
  6. Feedback-to-Roadmap Translation — Convert clusters to ranked product decisions

When to Invoke

Invoke Skill({skill: 'feedback-analysis'}) when:

  • Analyzing customer feedback at scale (>50 items)
  • Processing NPS/CSAT survey responses
  • Triaging support tickets or classifying issues
  • Detecting early churn signals in user behavior or feedback
  • Prioritizing the product roadmap from customer requests
  • Synthesizing qualitative feedback into actionable themes
  • Running feedback campaigns and evaluating results

The Six-Phase Process

Phase 1: Multi-Channel Data Unification (MANDATORY FIRST STEP)

Iron Law: All analysis degrades without unified data. Single-channel view creates blind spots.

Channels to unify:
- In-app surveys (NPS, CSAT, CES)
- Support tickets (Zendesk, Intercom, Freshdesk)
- App store reviews (iOS, Android)
- Social mentions (Twitter/X, Reddit, LinkedIn)
- Chat transcripts (live chat, chatbot logs)
- Product reviews (G2, Capterra, Trustpilot)
- Email responses

Output: A unified feedback dataset with source, timestamp, channel, user tier, and raw text per item.

Phase 2: Sentiment Analysis

Method: NLP-based multi-dimensional sentiment classification.

Classifications:

  • Polarity: Positive / Negative / Neutral
  • Emotion: Frustration, Satisfaction, Confusion, Delight, Urgency
  • Intensity: High / Medium / Low
  • Topic: Product area, feature, support experience, pricing

Key Pattern — Mismatch Detection (Critical Insight):

A customer scoring 8 (NPS Passive) with deeply negative text is high churn risk. A customer scoring 6 (NPS Detractor) with positive text is recoverable. Mismatch = highest priority segment for intervention.
Mismatch Types:
- High score + negative text → At-risk, intervention needed
- Low score + positive text → Recoverable, reduce friction
- Neutral score + high emotion → Emerging issue, monitor closely

Output: Sentiment-tagged dataset with polarity, emotion, intensity, and mismatch flags.

Phase 3: NPS/CSAT Frameworks

Dual-Track Analysis: Process numerical scores AND open-text responses in parallel.

NPS Segments:

  • Promoters (9-10): Surface testimonials, referral triggers
  • Passives (7-8): Identify friction points preventing promotion
  • Detractors (0-6): Root cause analysis, recovery playbooks

CSAT Layers:

  • Score distribution by product area, agent, date range, cohort
  • Text sentiment correlation with CSAT score
  • Trend analysis: rolling averages, anomaly detection on score drops
  • Causation analysis: what drove score changes?

Multi-Dimensional Segmentation:

Dimensions to segment by:
- User tier (free, pro, enterprise)
- Acquisition channel
- Product area (onboarding, core feature, billing, support)
- Agent/team (for support CSAT)
- Cohort (joined date, plan upgrade date)
- Region/language

Output: NPS/CSAT dashboard data with trend lines, mismatch segments, and causation narratives.

Phase 4: Feature Request Clustering

Method: Group verbatims into themes without manual tagging using pattern detection.

Clustering Dimensions:

  • Frequency: How many users requested this?
  • Emotional Weight: How strongly do they feel? (high emotion = high priority)
  • Churn Correlation: Does absence of this feature correlate with churned users?
  • Segment Impact: Which user tiers/cohorts are most affected?

Category Taxonomy:

Request Categories:
- Bug Report (broken functionality)
- Feature Gap (missing capability)
- UX Friction (confusing/slow workflow)
- Performance Issue (speed, reliability)
- Integration Request (connect to other tools)
- Pricing Feedback (too expensive, wrong tier)
- Documentation Gap (can't figure out how to use it)

Prioritization Formula:

Priority Score = (Frequency × 0.3) + (Emotion Weight × 0.3) + (Churn Correlation × 0.4)

Output: Ranked feature request list with evidence count, sentiment weight, and churn correlation per cluster.

Phase 5: Support Ticket Triage

Taxonomy Design: Hierarchical, max 30-50 tags to prevent tag bloat.

Recommended Taxonomy Structure:

Level 1 (Category):        Level 2 (Subcategory):       Level 3 (Root Cause):
- Technical Issue          - Login/Auth                  - Password reset broken
- Billing                  - Charge dispute              - Double-charged
- Feature Usage            - Onboarding                  - Setup wizard unclear
- Performance              - Slow response               - Database timeout
- Integration              - API error                   - Rate limit exceeded
- Account Management       - Team permissions            - Role not propagating

Triage Modes:

  1. Rule-based: Fast pattern matching for obvious categories
  2. AI-powered: NLP for ambiguous tickets (45% faster routing per Zendesk data)
  3. Human review: Escalation queue for complex/sensitive cases

Priority Scoring:

Ticket Priority = Urgency (language cues) + Impact (user tier/revenue) + Sentiment (frustration level)
- P0: Critical + Enterprise user + High frustration
- P1: High urgency + Any paid user + Negative sentiment
- P2: Medium urgency + Any user + Neutral/negative
- P3: Low urgency + Any user + Neutral

Output: Categorized and prioritized ticket queue with taxonomy assignments and routing rules.

Phase 6: Churn Signal Detection

Behavioral Profile Clustering:

User Engagement Profiles:
- Power User: High session frequency, feature breadth, collaborative
- Dabbler: Irregular sessions, single workflow, no integrations
- One-Feature User: Deep single-feature use, no expansion
- Trial Tourist: Onboarding complete, then disengaged

Early Warning Signals (detect BEFORE explicit churn):

  • Session frequency drop (>50% decrease week-over-week)
  • Feature contraction (fewer features used than prior period)
  • Support ticket surge (3+ tickets in 2 weeks)
  • Negative sentiment spike in recent feedback
  • Admin account downgrade events
  • Billing inquiry (pricing-related tickets/queries)
  • Export activity (data portability requests)

Churn Risk Scoring:

Churn Risk = (Behavioral signals × 0.4) + (Feedback sentiment × 0.3) + (Support ticket pattern × 0.3)
Risk Tiers:
- High (>0.7): Trigger immediate retention playbook
- Medium (0.4-0.7): Proactive outreach + success check-in
- Low (<0.4): Monitor, standard touchpoints

Reason Code Generation: Each high-risk user gets a human-readable reason code:

  • "Feature-gap: Missing [X] blocking workflow"
  • "Billing: Perceives pricing as misaligned with value"
  • "Support: 3 unresolved critical tickets in 14 days"

Output: Churn risk cohort with risk scores, reason codes, and triggered playbook recommendations.

Phase 7: Feedback-to-Roadmap Translation

Input: Completed phases 1-6 (sentiment, NPS/CSAT, clusters, triage, churn signals)

Prioritization Matrix:

Roadmap Score = (Feature Request Frequency × 0.25)
              + (Churn Correlation × 0.35)
              + (NPS Impact × 0.25)
              + (Support Volume × 0.15)

Stakeholder Output Format:

## Roadmap Recommendation: [Feature/Fix Name]

**Evidence Summary**: [N] users requested this across [channels]
**Sentiment**: [Avg. emotional weight and polarity]
**Churn Correlation**: [% of churned users mentioned this]
**NPS Impact**: [Correlation to Detractor-to-Promoter potential]
**Support Impact**: [Ticket volume and priority distribution]

**Recommended Action**: [Implement / Investigate / Defer / Decline]
**Priority Tier**: P0 / P1 / P2 / P3
**Supporting Quotes**: [3-5 verbatim user quotes]

Continuous Loop: Feed roadmap decisions back into feedback collection ("Did we solve the problem?").

Output: Ranked roadmap items with quantitative evidence, stakeholder narrative, and action recommendations.


Iron Laws

  1. ALWAYS unify channels first — single-channel analysis creates blind spots that lead to wrong prioritization decisions.
  2. ALWAYS run mismatch detection — numerical scores alone miss high-churn-risk Passives and recoverable Detractors.
  3. ALWAYS produce an actionable output — analysis that doesn't result in a decision, playbook trigger, or roadmap item has failed its purpose.
  4. NEVER use flat taxonomy with >50 tags — tag bloat causes inconsistent categorization; use hierarchical taxonomy with 30-50 leaf nodes.
  5. ALWAYS correlate feature requests with churn data — frequency alone is a poor proxy for priority; churn correlation is the real signal.

Anti-Patterns

Anti-PatternWhy It FailsCorrect Approach
Analyzing only NPS scores without textMisses mismatch segments (fake Promoters, recoverable Detractors)Always run dual-track score + text analysis
Flat taxonomy with 200+ ticket tagsAgents use first matching tag; root cause data is lostHierarchical taxonomy, max 50 leaf nodes
Clustering by frequency aloneMissing features that don't come up often but cause 80% of churnWeight clusters by churn correlation (0.4 weight)
Waiting for explicit churn to detect itPost-churn analysis doesn't save the customerBehavioral early warning signals, 14-day detection horizon
Roadmap items without evidence countStakeholders can't evaluate priority or trade-offsEvery roadmap item needs: frequency, sentiment weight, churn %, quotes
Single-channel feedback collectionBlind spots by channel; social complaints ≠ support ticketsUnify all channels before analysis

Enforcement Hooks

Input validated against schemas/input.schema.json before execution. Output contract defined in schemas/output.schema.json. Pre-execution hook: hooks/pre-execute.cjs Post-execution hook (observability): hooks/post-execute.cjs

Memory Protocol (MANDATORY)

Before starting: Read .claude/context/memory/learnings.md

Check for:

  • Previous feedback analysis results
  • Known data quality issues in feedback channels
  • Prior roadmap decisions from feedback

After completing:

  • New pattern discovered → .claude/context/memory/learnings.md
  • Issue found → .claude/context/memory/issues.md
  • Roadmap decision → .claude/context/memory/decisions.md
ASSUME INTERRUPTION: If it's not in memory, it didn't happen.

平台分布

Codex

37.72%
按下载量换算54

Claude

29.64%
按下载量换算42

Cursor

19.94%
按下载量换算29

Gemini CLI

8.42%
按下载量换算12

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在提醒或未通过项,安装前请自行复核。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills