• Says "Check logic continuity", "Check if the logic is broken", "Is there any redundant content"
• Says "Help me check if this script flows smoothly", "Can viewers watch this script all the way through"
• Says "Check completion rate risks", "Where will viewers swipe away"
• Uses

  /dbs-script-flow

  or

  /逻辑延续

1. Logical break: The previous paragraph talks about A, the next suddenly jumps to C, missing B in between
2. Dropped information density: A paragraph repeats what has already been said, or goes in circles
3. Awkward spoken delivery: Sentences are too long, too formal, use rhetorical questions repeatedly, or are hard to pronounce

• Segment number
• Paragraph topic (one-sentence summary of what the segment is about)
• Paragraph function (Opening / Background setup / Argumentation / Case study / Transition / Climax / Conclusion)

• Is there a logical jump between the last sentence of the previous segment and the first sentence of this segment?
• After listening to the previous segment, can viewers naturally understand why this segment is being discussed?
• If not, what connecting information is missing?

• Sudden jump from a case to macro analysis without a transition sentence
• Sudden jump from explaining causes to another topic without wrapping up the previous one
• Jump from data to opinion without a "therefore" to connect them

• Add a transition sentence (usually one sentence is enough)
• Add a concluding sentence at the end of the previous segment
• Adjust the order of segments

• Does this segment repeat information that has already been mentioned?
• Does this segment go in circles (using 5 sentences to say what could be said in 1)?
• If this segment is deleted, will viewers miss key information?

• Repeating the same meaning in three different ways
• Giving too many examples when explaining a concept, even after viewers already understand
• A segment is "correct nonsense" — it says nothing meaningful

• Delete redundant expressions, keep only the most impactful one
• Merge redundant segments
• Mark as "Can be deleted" for the user to decide

• Can this sentence be spoken in one breath? (Single sentences over 30 words should be cautious)
• Does it use formal written language? (e.g., "Regarding", "In view of", "Based on the above analysis")
• Does it use repeated rhetorical questions? (e.g., "Do you think X? Actually Y" — acceptable occasionally, annoying if used continuously)
• Does it use self-created concepts? (Terms viewers don't understand without immediate explanation)

• Nested attributives, cramming too much information into one sentence
• Using a term without immediately explaining it
• Continuous short sentences with a choppy rhythm, or continuous long sentences with a dull rhythm

• Split long sentences into two
• Follow a term with a plain-language explanation
• Adjust the rhythm by alternating short and long sentences

Original text (end of Segment X): "……" Original text (start of Segment Y): "……"

"[Specific transition sentence]"

Original text: "……"

Revised to: "[Simplified text]"

Original text: "……"

Revised to: "[Rewritten sentence]"

• Logical Coherence: [One-sentence summary]
• Information Density: [One-sentence summary]
• Spoken Fluency: [One-sentence summary]
• Summary: [Overall judgment, number of fixes needed, whether it's ready to publish after fixes]

Would you like me to provide marked-up revisions? I'll keep your original text and mark changes with strikethrough and 🆕 emoji.

---

1. What they wrote
2. Which parts are AI's deletion/replacement suggestions
3. Which parts are AI's added content
4. Which parts were previously revised by AI and restored (avoid losing history in multi-round feedback)

1. Make changes directly in the original position — do not write a full new version at the bottom; mark in place
2. Pair each change —

   ~~Original text~~

   is immediately followed by 🆕 revised version, making the comparison clear
3. When deleting an entire segment: Keep the original segment with strikethrough, and use 🆕 below to explain why it's deleted (or provide a condensed alternative)
4. Provide a change list at the end — in table form, list the location, type, and reason for each change, allowing the user to review quickly
5. Append instead of overwriting in multi-round feedback — if the user points out a wrong revision, mark it as restored with ⚠️ instead of directly changing it back as if it never happened

1. Do not modify content views: This skill only cares about "how to say it", not "what to say". Do not modify the user's arguments, cases, or data
2. Fix suggestions must be conversational: The provided transition sentences and revisions must be directly speakable, not formal written language
3. Do not over-diagnose: If the script is overall smooth, say "No major issues" instead of forcing to find problems
4. Prioritize high-risk issues: It's better to miss a minor suggestion than to bury high-risk issues in a pile of minor ones
5. Maintain the user's tone: When revising, keep the user's speaking style, do not make the user's text sound "AI-like"
6. Provide specific locations: Each issue must quote the original text so the user can find it at a glance
7. Confirm filming method before revising: Whiteboard videos change the judgment criteria — parallel lists are a visual advantage, phrases like "Emphasize here" "Look here" are prompts matching on-board actions and should not be revised. If the user doesn't specify, ask "Is this a whiteboard video or pure spoken delivery?"
8. Ask before judging "off-topic": If this segment is deleted, can viewers infer the specific meaning on their own from the previous key point? If not, this segment is necessary supporting content, not redundant. Do not only look at "whether the topic is literally off", but "which argument this segment serves"

Original text: "You will enter another similar zone called the merchant traffic pool"

Revised to: "You'll have almost no traffic — not completely zero, but it will be very low" Directly state the result instead of introducing a concept.

Original text (end of Segment 7): "So next, you're violating the platform's引流 rules, and the platform bans your account." Original text (start of Segment 8): "Then something more interesting happens"

"So this lawyer's subsequent traffic restriction is actually the standard outcome of this process." "Standard outcome" wraps up the previous analysis before introducing new information.

• v1.0 (2026-04-09): Initial version, based on practical experience with the "Xiaohongshu Sued" script
• v1.1 (2026-05-04): Added marked-up revision process; proactively ask "Would you like marked-up revisions?" after diagnosis; added 2 notes (whiteboard video judgment criteria, check argument service before judging off-topic)