xhs-kol-script-review

Purpose

Review creator collaboration scripts with source fidelity and practical editorial judgment. Focus on whether the creator-native story works, whether the product is integrated naturally, whether the script shows product differentiation beyond generic AI, and whether the deliverable is ready for creator communication or video production.

Use this skill to turn messy draft histories, Tencent Docs comments, and multiple script versions into a clear review report and concrete rewrite guidance.

When to use

Trigger this skill when the user asks to:

• 审稿 / 审核达人脚本 / 看文案 / 看稿件 / 给修改意见。
• Compare V1/V2/V3/V4 script versions and identify what changed.
• Extract and summarize comments, notes, or reviewer feedback from a Tencent Docs script.
• Review creator collaboration content for 小红书, KOL, KOC, 达人, 素人, or PR publishing.
• Check whether product mentions are too hard-sell, too generic, risky, or insufficiently differentiated.
• Produce creator-facing feedback, internal review notes, or a revised script direction.

Do not use this skill for generic copywriting unrelated to creator collaboration review.

Core principles

1. Preserve source meaning. Do not invent comments, versions, product features, titles, tags, or missing content.
2. Prioritize creator-native content before product selling. The script must first work as the creator's own post.
3. Treat product placement as a scene solution, not a feature list.
4. Explain why a change is needed. Give concrete replacement wording when possible.
5. Separate internal judgment from creator-facing feedback when the user needs external communication.
6. Flag uncertainty explicitly when comments, screenshots, attachments, or right-side Tencent Docs bubbles are not accessible.

Review workflow

1. Collect source material

• Read all provided documents or pasted scripts.
• If the user provides Tencent Docs links and the connector is available, fetch the full document content by file ID.
• If only the page title or partial content is accessible, state the access boundary and ask for exported text or pasted content only if needed.
• Identify these sections when present:
• brief / 注意事项 / timeline
• 一句话介绍
• 大纲
• 脚本 versions
• 视频成片
• 封标文案
• reviewer comments / notes / 批注
• attachments or demo placeholders

2. Parse versions and comments

• Extract every version label exactly as written, such as V1, V2, V3, V4, v2 0423, V1 0427.
• Keep version order based on document structure and dates when available.
• Distinguish three content types:

1. Original script text
2. Reviewer comments or editorial notes
3. Execution requirements such as screenshots, demo videos, tags, covers, or titles
• If the source contains visible comments in the body but not formal comment metadata, call them "正文可见审稿意见" rather than claiming they are Tencent Docs side comments.

3. Compare version changes

For each major version transition, summarize:

• Hook change: what opening angle changed and why.
• Story/scene change: how creator-native context changed.
• Product placement change: where the product enters and whether it feels natural.
• Product differentiation change: whether the script moved beyond generic AI abilities.
• Risk control change: whether hard-sell, platform, PR, or sentiment risks were reduced.
• Demo/execution change: whether visual proof became clearer.

Use concise tables when helpful, but preserve enough detail for decision-making.

4. Audit the script on seven dimensions

Assess the current or latest draft using these dimensions:

1. 选题贴合度: Does the topic match the creator's existing persona and proven content direction?
2. 达人原生感: Does it sound like the creator's own story, tone, and audience promise?
3. 产品进入方式: Does the product enter after a real pain point, not as an abrupt ad?
4. 产品差异表达: Does it show product-specific value rather than generic AI?
5. 场景故事感: Is there emotion, conflict, or a concrete use case?
6. Demo可拍性: Are screenshots, screen recordings, app actions, and visual beats clear?
7. 风险控制: Are platform, PR, product-claim, hard-sell, and sentiment risks handled?

Optional scoring: use 1-5 only when the user asks for a score or when a quick diagnosis is useful.

5. Apply product-specific checks

Look for at least one concrete product-differentiated strength in the script. Common areas to audit:

• Distinctive workflow or multi-step capability: whether the script shows a logical chain of tasks (e.g., topic research → script drafting → title optimization → publishing plan → data review), not isolated features.
• Multi-agent or multi-role collaboration: whether the script conveys that different roles work together, with handoffs between steps.
• Persona / customization: whether the script shows the product adapting to the creator's own style or preferences.
• Platform integration: whether the script mentions cross-platform or multi-device linkage (desktop + mobile, mini-program, etc.) when relevant.
• Visual or interactive demo potential: whether the script leans into fast, visual demonstration rather than long feature explanation.

Common correction:

• If the script only says "AI帮我写稿/整理信息/生成文档", ask what makes this product different from any generic AI tool.
• Embed the product inside the creator's proven topic instead of introducing it as a standalone feature demo.
• Strengthen with chain-based language: "不是一个AI在帮我做一件事，而是一整支AI团队在帮我跑完全部流程。"

6. Apply platform and PR risk checks

Flag and fix these risks:

• Avoid hashtags that the brief prohibits or limits.
• Avoid hard-sell words: 现在下载, 优惠, 积分, token优惠, credit优惠, 立刻购买, 引流式官网下载.
• Avoid product names in title or cover when the brief forbids it.
• Avoid overclaiming product abilities that cannot be demonstrated.
• Avoid medical, veterinary, legal, financial, or other professional diagnosis claims unless the product is explicitly approved for that use. For pet-care scripts, do not let the product appear to diagnose conditions or replace a veterinarian; soften to "先做初步排查/记录观察/必要时及时就医" and avoid definitive claims unless sourced and verified.
• Avoid external-app diversion wording; use softer phrasing such as "这里用的是 XX 产品" when appropriate.
• Avoid overly attacking or stigmatizing language such as "拉完了", "没成长", or broad negative judgments. Convert to constructive wording such as "难评", "成长空间有限", "普通文科生自救".
• Prefer scene/story framing over direct ads.

7. Check production completeness

Verify whether the script includes or still needs:

• Complete口播台词
• 发布标题
• 简介/正文文案
• 话题 tag
• 大致时长
• Product demo screenshots or videos
• Cover direction
• Video cut/花字/function-demo verification notes
• Version labels preserved without overwriting older drafts

Output formats

Standard internal review report

Use this format by default:

1. 一句话结论
2. 版本变化对比
3. 已读到的审稿意见/批注记录
4. 当前稿件主要问题
5. 建议修改方向
6. 可直接替换的表达 when useful
7. 待补齐素材/演示画面

End with a compact JSON block when useful for tracking:

{
  "summary": "一句话总结",
  "categories": ["版本对比", "产品植入", "风险检查", "demo补齐"]
}

Creator-facing feedback

Use this format when the user asks for comments that can be sent to the creator:

• Start with the strongest retained direction.
• Use direct but non-accusatory wording.
• Group feedback by "内容方向", "产品露出", "画面/demo", "风险&发布".
• Avoid exposing internal uncertainty or harsh critique unless needed.
• Provide replacement wording the creator can paste into the draft.

Quick diagnosis

Use this format when the user wants a fast answer:

• 结论
• 最大问题
• 必改点
• 可保留点

Reference cases

Load @references/review-casebook.md when needing concrete patterns from prior reviewed drafts.

Load @templates/review-report-template.md when producing a structured report.

Pitfalls

• Do not collapse version histories into a single rewritten script unless asked.
• Do not treat visible body notes as inaccessible Tencent Docs bubble comments.
• Do not invent missing titles, tags, or demo assets.
• Do not over-index on product features at the expense of creator content.
• Do not leave vague advice such as "更自然一点" without a concrete rewrite direction.

Verification

Before finalizing a review, check:

• All source documents named by the user were read or access limitations were stated.
• Every version mentioned in the source is either summarized or explicitly skipped with reason.
• Reviewer comments are separated from model judgment.
• Product-specific recommendations match the actual product named in the script.
• Risk notes include a concrete safer alternative.
• Output is concise enough to be usable by a product/ops reviewer.