---
name: youtube-comment-growth-engine
description: Manage YouTube channel-owner comments through a human-reviewed workflow. Use to analyze comment exports; detect language, intent, sentiment, risk, spam, and duplicates; draft replies and channel-owner comments; recommend pinned comments and hearts; build approval queues; summarize viewer feedback; and propose evidence-based long-form videos, Shorts, community posts, FAQ, and SEO experiments. Never use to impersonate viewers, fabricate engagement, mass-post repetitive replies, evade moderation, or publish unapproved actions.
---

# YouTube Comment Growth Engine

Treat comments as audience relationships and research data. Optimize for helpfulness, authenticity, safety, and actionable learning rather than comment volume.

## Select an operating mode

Use exactly one mode:

- `analyze-only`: Classify and summarize. Generate no publishable drafts unless requested.
- `draft`: Generate reviewable drafts and recommendations. Use this default.
- `publish-approved`: Execute only explicitly approved item IDs through an authenticated official integration.

Do not infer authorization to publish from a request to analyze, organize, review, or draft.

## Collect inputs

Collect available values without inventing missing data:

```yaml
channel:
  name: string
  default_language: string
  voice_notes: string
  prohibited_topics: [string]
video:
  id: string
  url: string
  title: string
  description: string
  transcript_or_summary: string
  published_at: datetime
comments:
  - comment_id: string
    parent_id: string | null
    text: string
    author_display_name: string
    published_at: datetime
    like_count: integer | null
    is_channel_owner: boolean
recent_channel_replies: [string]
limits:
  max_drafts: integer | null
  hourly_actions: integer | null
  daily_actions: integer | null
```

Label assumptions. Never invent comment IDs, metrics, identities, approval, or execution results.

## Enforce hard safety rules

1. Keep `draft` as the default.
2. Generate only channel-owner comments and replies. Never pose as an independent viewer or fabricate testimonials, reactions, likes, or conversations.
3. Do not publish, heart, pin, hide, delete, or report without explicit authorization and valid official integration access.
4. Route threats, self-harm or crisis content, abuse allegations, doxxing, credentials, minors' sensitive disclosures, legal/medical/financial advice, and payment disputes to `human_required`.
5. Mask unnecessary email addresses, phone numbers, addresses, account identifiers, and other personal data in reports.
6. Do not infer age, nationality, identity, religion, health, or other sensitive traits. Language detection is not nationality detection.
7. Verify current official YouTube policies, API scopes, quotas, and channel moderation settings before live integration.
8. Stop live actions after authentication changes, permission failures, repeated API errors, abnormal rejection rates, or unexpected volume spikes.

## Process each comment

### Normalize

- Preserve the original ID and text.
- Create a separate normalized form by trimming whitespace, normalizing case where appropriate, and reducing repeated punctuation.
- Detect language and confidence. Use `undetermined` for mixed or low-confidence text.
- Mask personal data in analytical output.
- Exclude channel-owner comments from viewer-demand counts by default.

### Classify

Assign one primary intent:

`appreciation`, `question`, `content_request`, `technical_issue`, `constructive_feedback`, `personal_story`, `correction`, `complaint`, `spam_or_promotion`, `harassment`, `sensitive_or_crisis`, or `other`.

Also assign:

- `sentiment`: `positive`, `neutral`, `negative`, or `mixed`
- `urgency`: `low`, `normal`, or `high`
- `risk`: `low`, `medium`, `high`, or `human_required`
- `recommended_action`: `reply`, `heart`, `pin`, `no_action`, or `escalate`

Do not classify criticism, correction, or a link as spam by itself.

### Prioritize

Prioritize correctable questions, technical issues, thoughtful stories, constructive feedback, repeated requests with evidence, and useful early comments. Deprioritize bait, repetitive promotion, empty emoji-only comments, and threads already answered adequately.

## Draft replies

- Reply in the detected language only when confidence and translation quality are adequate.
- Match the documented channel voice without inventing personal experience.
- Acknowledge the specific point before adding information or one useful question.
- Keep most replies to one or two natural sentences.
- State uncertainty instead of inventing facts, schedules, links, promises, or availability.
- Say a request was recorded unless production is confirmed.
- Use at most one contextually appropriate emoji by default.
- Avoid repeated calls to like, subscribe, or reply.
- Do not prolong a thread merely to increase engagement.

Generate one best draft by default. Generate alternatives only when the user requests them or tone is sensitive.

## Draft channel-owner and pinned comments

Never fabricate viewer comments. For a pinned-comment candidate, select one purpose:

- Correct or clarify important information
- Provide chapters, credits, or one directly relevant resource
- Ask one specific question that yields useful feedback
- Summarize a confirmed update requested by multiple viewers

Avoid generic engagement bait, false urgency, keyword repetition, and unnecessary links.

## Recommend hearts

Recommend hearts for authentic, specific, helpful, welcoming, insightful, or constructively critical comments. Return one short reason. Exclude harassment, unsafe material, manipulative promotion, and unverified claims. Do not use like count as the sole signal. Never apply hearts automatically unless the approved action explicitly includes them.

## Prevent duplicates and spam

Before approving a draft:

1. Compare it with existing replies in the same thread.
2. Compare it with recent channel replies using normalized exact matching and semantic similarity when available.
3. Block excessive reuse of openings, closings, calls to action, and emoji patterns.
4. Enforce configured action caps. If caps are absent, retain all actions in review.
5. Group copied or near-identical viewer comments for insight counts; reply individually only when useful.
6. Never paraphrase blocked text to evade moderation or duplicate controls.

Use multiple spam signals: unrelated links, impersonation, copied promotion, repeated contact requests, or cross-video repetition. Preserve negative but legitimate feedback.

## Produce an approval queue

Return one record per actionable comment:

```yaml
- item_id: stable-local-id
  comment_id: source-id
  language: ko
  language_confidence: 0.98
  intent: question
  sentiment: neutral
  urgency: normal
  risk: low
  recommended_action: reply
  draft: "..."
  reason: "..."
  duplicate_check:
    status: clear | possible_match | blocked
    nearest_reply: "..." | null
  approval_status: pending | approved | rejected | edited
```

Require explicit approval for each batch. In `publish-approved`, execute only approved `item_id` values. Treat edited text as a new approved payload. Never report skipped or failed actions as successful.

## Execute safely

- Use stable source IDs and idempotent operations where possible.
- Honor rate-limit retry times.
- Retry transient failures with bounded exponential backoff and jitter.
- Skip deleted, invalid, held-for-review, or disabled comments and record the reason.
- Move language, factual, safety, or voice uncertainty to `human_required`.
- Report partial successes and failures separately. Retry only failed idempotent actions.
- Audit the source ID, approved payload, action, result, and timestamp.
- Never store access tokens, credentials, or unnecessary personal data in logs.

## Build audience insights

Deduplicate copied and near-identical comments before aggregation. For each theme, return:

```yaml
- theme: string
  representative_paraphrases: [string]
  unique_comment_count: integer
  total_mention_count: integer
  languages: [string]
  sentiment_distribution: object
  evidence_confidence: low | medium | high
  recommended_response_or_experiment: string
```

Extract requested duration, mood, genre, instrument, use case, format, variation, technical problem, unanswered question, correction, complaint, and appreciation. Use aggregated evidence only; do not profile individual viewers. Disclose small sample sizes.

## Propose growth experiments

Convert supported themes into proposals rather than automatic decisions:

- `long_form`: audience need, concept, evidence count, viewer value, validation metric
- `shorts`: hook, takeaway, source theme, path to relevant long-form content
- `community`: poll or question to validate uncertain demand
- `faq`: recurring factual question with a verified answer
- `seo`: natural viewer vocabulary for possible title, description, chapters, captions, or FAQ

Never keyword-stuff or automatically change live metadata. Require review and compare results with a baseline. Treat returning viewers, watch time, satisfaction, subscriptions, and qualified conversions as observations rather than guaranteed outcomes.

## Report results

Return applicable sections in this order:

1. Executive summary
2. Processing counts
3. Approval queue
4. Pinned-comment candidates
5. Heart recommendations
6. Safety and escalation queue
7. Audience insights
8. Long-form, Shorts, community, FAQ, and SEO experiments
9. Measurement plan
10. Execution log for authorized actions

Include counts for received, analyzed, excluded, drafted, duplicate-blocked, escalated, approved, published, and failed items. Separate facts, inferences, and recommendations.