dbs-script-flow — Logic Continuity Check

Trigger Conditions

• 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

  /逻辑延续

Differences from Other Skills

/检查文稿

/dbs-script-flow

/文稿分析

Core Principles

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

Check Process

Step 1: Segment the Script

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

Step 2: Scan Each Segment Across Three Dimensions

Dimension 1: Logical Coherence (Between Segments)

• 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

Dimension 2: Information Density (Within 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

Dimension 3: Spoken Fluency (Sentence Level)

• 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

Step 3: Label Risk Levels

Output Format

## Logic Continuity Check Report

### Paragraph Structure

| Segment No. | Topic | Function | Status |
|-------------|-------|----------|--------|
| 1 | [Topic] | Opening | ✅ |
| 2 | [Topic] | Background setup | ✅ |
| 3 | [Topic] | Argumentation | 🟡 |
| ... | ... | ... | ... |

### Issue List

**🔴 Issue 1: Segment X → Segment Y, Logical Break**

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

**Problem**: [Specific description of why viewers can't keep up here]

**Fix Suggestion**: Add a transition sentence at the end of Segment X:
> "[Specific transition sentence]"

---

**🟡 Issue 2: Segment Z, Dropped Information Density**

> Original text: "……"

**Problem**: [Specific description of why viewers may get distracted here]

**Fix Suggestion**:
> Revised to: "[Simplified text]"

---

**🟢 Issue 3: Sentence N in Segment W, Awkward Spoken Delivery**

> Original text: "……"

**Problem**: [Specific description of why this sentence is hard to pronounce]

**Fix Suggestion**:
> Revised to: "[Rewritten sentence]"

---

### Overall Assessment

- **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]

### Ask for Revision Confirmation

After outputting the overall assessment, you must proactively ask the user:

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

**Do not wait for the user to ask** — most users check the script to get revisions, so asking proactively saves back-and-forth.
But **do not revise without asking** — leave the decision to the user, as they may want to revise it themselves.

Marked-Up Revision Process (Execute After User Confirmation)

Core Principles

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)

Three Markers (High Visual Contrast)

~~Strikethrough~~

~~The key point is, let's emphasize here~~

🆕 Here's a key point

⚠️ The previous deletion judgment was wrong, restored. These three segments are not off-topic, but are breaking down……

Revision Rules

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

Output Format After Revision

[Original text + marked-up changes, edited in place]

---

### Change List

| Location | Type | Explanation |
|----------|------|-------------|
| Opening | 🟢 Replacement | [Brief explanation] |
| Segment X | 🔴 Full deletion | [Reason] |
| Ending | 🟡 Addition | [What was added and why] |

Notes

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"

Practical Cases

Case: "Xiaohongshu Sued" Script (2026-04-09)

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.

Version History

• 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)