本文へ移動
cccskills
無料GitHub で公開

codexkit-csat-sentiment-analyzer

Analyze CSAT, NPS comments, reviews, and support feedback for sentiment, recurring themes, customer pain, and service improvement actions. Use for customer support and CX feedback reviews.

インストール方法を見る

含まれるファイル(2)

  • SKILL.md4.1 KB
  • agents/openai.yaml191 B

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

CSAT Sentiment Analyzer

When to Use

  • Analyzing CSAT, NPS, app reviews, support comments, or post-interaction feedback.
  • Finding recurring customer pain points and service improvement themes.
  • Preparing support, CX, product, or leadership feedback summaries.
  • Comparing sentiment across segments, channels, agents, products, or time periods.

Procedure

Step 1 - Normalize Feedback

Identify source, date range, channel, score type, segment, and any metadata. Keep raw counts separate from percentages.

Step 2 - Classify Sentiment

Use a simple sentiment label:

  • positive
  • neutral
  • negative
  • mixed
  • unclear

Include confidence when comments are short or ambiguous.

Step 3 - Code Themes

Group feedback into themes such as speed, quality, pricing, reliability, usability, billing, support tone, missing features, or documentation.

Step 4 - Quantify Patterns

Report counts, percentages, average score, trend direction, and representative examples. Avoid claiming statistical significance without enough data.

Step 5 - Recommend Actions

Link every action to a theme and owner group: support, product, docs, billing, success, operations, or leadership.

Inputs

InputRequiredFormat
Feedback datasetYesComments, scores, reviews, tickets
Date rangeRecommendedStart and end date
SegmentsOptionalPlan, region, product, channel, agent
Scoring systemOptionalCSAT 1-5, NPS, thumbs up/down
Business contextOptionalLaunch, outage, policy change

Output

## CSAT Sentiment Analysis - [Period]

### Executive Summary
[Key trend, sentiment, and action]

### Score Snapshot
| Metric | Value | Notes |
|--------|-------|-------|

### Theme Breakdown
| Theme | Sentiment | Count | Percent | Representative Comment | Recommended Action |
|-------|-----------|-------|---------|------------------------|--------------------|

### Segment Differences
| Segment | Pattern | Confidence |
|---------|---------|------------|

### Action Plan
| Owner | Action | Evidence | Priority |
|-------|--------|----------|----------|

Quality Criteria

  • Counts and percentages reconcile to the input size.
  • Themes are mutually understandable and not over-fragmented.
  • Representative comments are short and anonymized when needed.
  • Recommendations are tied to evidence.
  • Sensitive customer data is removed or masked.

Verification (4C)

CheckQuestion
CorrectnessDo sentiment labels and theme counts match the raw feedback?
CompletenessAre scores, themes, segments, evidence, and actions included?
Context-fitAre the recommendations realistic for the support or CX team?
ConsequenceCould a small sample or biased feedback source lead to the wrong product or staffing decision?

Edge Cases

  • Very small sample - Mark findings as directional and avoid percentages that imply precision.
  • Sarcasm or mixed sentiment - Use "mixed" or "unclear" instead of forcing polarity.
  • Personally identifiable information - Mask names, emails, phone numbers, and account IDs.
  • Outage or one-off incident - Separate incident-driven feedback from baseline sentiment.

Examples

Prompt: "Analyze these 300 CSAT comments from April. Break down sentiment, top pain themes, and the three actions support should take next."

Good pattern: "Billing confusion appears in 42 of 300 comments (14%). The most common evidence is customers not understanding prorated invoices after plan changes."

Definition of Done

  • Sentiment and theme counts are transparent.
  • Representative examples support the themes.
  • Actions are owner-specific and prioritized.
  • Bias and sample limits are documented.

Changelog

  • v1.0.0 - Initial release

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Design rigorous A/B test plans with hypothesis, sample size calculation, Minimum Detectable Effect (MDE), randomization strategy, and decision rules. Includes guardrail metrics and rollout playbook. Use when planning product experiments, conversion optimization, or data-driven feature decisions.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月8日 更新

Review REST and GraphQL API designs for consistency, usability, and best practices. Covers naming conventions, versioning strategy, error format, pagination, authentication patterns, and breaking change detection. Use when reviewing API specs, designing new APIs, or auditing existing endpoints.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月8日 更新

Write Architecture Decision Records (ADRs) following the Michael Nygard format. Captures context, options considered, decision rationale, and consequences. Use when making technology choices, framework selections, or any architectural decision that future developers need to understand.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月8日 更新

Assess organizational readiness for financial audits (internal or external). Map assertions to account balances, check evidence completeness, score readiness using a Red/Amber/Green framework, and generate a remediation timeline. Aligned with SOX, IFRS, and GAAP audit standards. Use before scheduled audits or when preparing for first-time compliance.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月8日 更新

Design safe recurring Codex automations with clear prompts, outputs, schedules, and gating rules.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月8日 更新

Refine Product Backlog Items to meet INVEST criteria. Write User Stories with Acceptance Criteria in Given/When/Then format, estimate with Story Points, and flag dependencies. Use before sprint planning when backlog items need grooming. Do not use to prioritize the backlog — that is the Product Owner's decision.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月8日 更新

hoavdc のスキルをすべて見る

このスキルの問題を報告する