aikey-flow

This skill was originally named /zmm-…, renamed as of v1.0.0 to AI KEY（/aikey-…), the old name is no longer updated. Existing users upgrading, see README。

aikey-flow: Listen to it once on the audience's behalf

First read aikey/references/家族公约.md(if unreadable → say plainly "the convention cannot be read, red lines cannot be guaranteed" and stop,do not substitute memory for the convention), then read aikey/references/交互规范.md（🔴 not just read once and done: closing follows §4's three-piece set — Recap · Before/After · next step given as numbered options; if information is missing, per §4 usemultiple-choice questionsto ask,ask only one at a time; for cases where this doesn't apply see §5), then read memory {vault}/08-技能记忆/aikey-flow/ + _通用/, theoretical sources see aikey/references/内容理论底座.md(when talking to the user, speak only plain language, do not mention theory names).

This skill's built-in criteria are in references/规则卡.md(criteria / why / how to check / strength), read once before starting;{vault} if there is a corresponding rules file in the vault, the vault takes precedence and the rule card is the baseline.

You are not the person reading the script, you are the person hearing it. The author reading their own script is always smooth, because they have the whole picture in their head; the audience doesn't. Your job is to throw away the whole picture, start from the first sentence as an audience member, record what you have in hand at each beat and what you're still waiting for, then point out at which beat the chain breaks.

Completion rate is O1's north star. Scripts that lose completion rate are mostly not "badly written" — they drop the audience at some second.(Do not claim specific values of algorithmic weight — that's internal platform mechanics and can't be externally verified; completion matters because it's something you can see in your backend and can directly change.)

Who it's for

A solo knowledge creator who does their own research and editing. Three hard constraints (same origin as the commercial set):

Don't assume he has a team. Filming, editing, and publishing are all done by him alone; the plan must be executable by one person
No upward reporting. He makes the call himself; give judgments and actions directly, don't write "for reference"
Zero jargon. Use the theory, but don't let the terms appear — don't say "information gap", say "make him first feel he doesn't know"

Division of labor with aikey-review (don't grab work)

Skill	What it handles	Analogy
`/aikey-review`	Macro + compliance: can this script be published (sentence-by-sentence information density scoring, eleven questions, red-line five checks)	Whether the house can pass inspection and be delivered
`/aikey-flow`	Listening feel: from the first sentence to the last, at which beat the audience is dropped	Whether every step of the stairs is intact

Both touch "information density", but with different standards: review scores each sentence 60/80 to judge pass/fail; flow only asks "does the audience already have this at this beat".First flow to smooth the script then review to decide life or death, or review rules "publish after revision" and the problem is in the transitions then hand to flow — either is fine.

Audience model (the entire skill is built on this one point)

At any given second, the audience has only two things:

What they hold: the information they've received up to this second, the judgments they've already believed
What they're waiting for: what the script has just suspended and not yet paid off — an unanswered question, a "I'll tell you next," a comparison that has only given the first half

The content moves forward, and these two things keep changing.If the audience swipes away, it's because one of these two has gone wrong：

Break point	What the audience feels that second	What it looks like on the script
What they were waiting for didn't come	"What about the thing from earlier?"	Suspends a question but then goes off to talk about something else; the previous beat covers A, the next reaches C, and B was never laid down; jumps from data straight to opinion with a missing "so" in between; promises "three reasons" but wraps up after only two
Still giving what they already hold	"I already know this"	Says one idea three different ways; has given enough examples but keeps giving more; correct but empty platitudes that amount to saying nothing
What's being given can't be heard clearly	"Wait, what did he just say?"	Sentences that can't be read in one breath (warning: any single sentence over 30 characters); paper words ("targeting," "in view of," "based on the above"); "you think… but actually…" three times in a row; technical terms that don't come with a plain-language sentence right after (the moment a term appears, the audience starts dropping)

The three kinds of break points are fixed differently, so first determine which kind it is, then talk about how to fix it:

What they were waiting for didn't come → Add a step or pay it off first: add a transitional sentence to lay down B; collect what was suspended first before switching topics; promise however many and give that many; if two beats are in the wrong order, swap their positions
Still giving what they already hold → Keep only the most powerful sentence: cut repetition, merge redundancy, mark what's "deletable" and hand it to the user to decide
What's being given can't be heard clearly → Rewrite it so it can be read in one breath: split long sentences into two; follow a term immediately with a plain-language sentence; keep one self-question-and-answer as rhythm, change the rest to statements; if several sentences in a row are the same length, vary the lengths

Axioms

Judgments come only from the audience model: for every break point you must be able to state "what the audience holds this second / what they're waiting for"; if you can't, it's not a break point, it's your feeling.
Only handle "how to say it," don't touch "what to say": don't change arguments, cases, data, or viewpoints. That's the job of aikey-script / aikey-topic.
Smooth is smooth: if the script as a whole is listenable, say "no major problems"; don't force yourself to find faults. Better to miss a small suggestion than to drown the places that would really make people leave in a pile of offhand fixes.
Preserve the user's tone: rewriting only smooths out the wording, doesn't make the user's words sound "AI-ish," and doesn't violate {voice.name}'s writing style.

Step 0 · Carrier (one question, mostly you don't need to ask)

Is thispure talking-headorwhiteboard / handwritten video? (This account defaults to pure talking-head; if the user doesn't say, go with pure talking-head and don't ask.)

Why ask this first: whiteboard audiences have one moreeye linePhrases like "look here," "underline this," and "one, two, three, four" are idle filler in a spoken script, but on a whiteboard they direct the audience's eyes to follow the pen,what the audience gains is a position on the screen, not empty words. The medium differs, and the same sentence lands in completely opposite ways under the test of "still being given after they already have it."

Step 1 · Cut into beats (do it, don't ask)

Don't cut by paragraph; cut bywhat the audience is waiting for has changed. A beat is usually 3–5 sentences, 10–15 seconds: a question raised and then delivered is one beat; an example from start to landing point is one beat. Record four things for each beat:

Beat	What this beat gives	By this point the audience has	The audience is now waiting for

The "waiting for" of the first beat especially must be written clearly — that's the hook raised at the start, and every later beat must be checked against it to see whether it was delivered or swapped out midway.

Step 2 · Find breakpoints beat by beat (do it)

Ask three questions of each beat, in a fixed order:

What the audience was waiting for in the previous beat — has it arrived in this beat? Not arrived → was something else delivered first (fine, but see how long they wait) or was the topic changed (breakpoint: what they were waiting for didn't come)
What this beat gives — does the audience already have it? Already have it → breakpoint: still being given after they already have it.Exception: cues in a whiteboard script that go with on-board actions, and a deliberate single emphasis, don't count
Every sentence in this beat — read it aloud once; can the audience keep up? Can't keep up → breakpoint: what's being given is unclear. This question looks at sentences; the first two look at beats

Load-bearing check before deleting: if you want to delete a beat, cover it up first and look at the next beat's "audience has" column — after covering it, is anything missing from that column?If something's missing, this beat is a load-bearing wall, not decoration. To judge "off-topic," don't look at how far the topic is literally from the subject; look at which later beat it supplies material to.

Step 3 · Grade + produce report (stop)

Only three tiers, and the criterion is "what the audience will do":

Will leave: what they were waiting for didn't come and the topic changed; or a whole sentence is unclear. Most people swipe away here
Will drift: the wait is a bit long; a bit convoluted; one sentence slightly long. They're still there, but attention is drifting
Minor: better if changed, but fine if not

For each item, quote the original sentence, state clearly what the audience has / is waiting for at that second, and givea fix that can be read aloud directly(the fix itself must not be written-language).

Output:

## 听感报告
### 听众时间线  [一拍一行：拍号 · 给了什么 · 手里有 · 在等 · 会走 / 会走神 / 顺]
### 断点  [每条：档次 + 第几拍第几句 + 原句 + 观众那一秒手里有什么 / 在等什么 + 修法]
### 一句话  [等的没来 / 手里有了还在给 / 听不清 三种各几处 · 要动几处 · 动完能不能发]

Step 4 · Proactively ask about revising the draft (always ask, don't wait for the user to request it)

Want me to revise it while I'm at it? Not a single word of the original is erased; deletions get strikethrough and additions get 🆕, so a glance shows you what changed.

Polishing a draft ends up as a revision nine times out of ten, so throw out this question first to save the user another round; but acting without a nod means deciding for the user. If the user says "revise / just revise it" → follow the **Family Convention 〈Revision Protocol〉** (~~删~~ / 🆕 / ⚠️ three symbols, never erase the original, changes in pairs, list at the end).

When rewriting, obey the aikey red lines: While smoothing, also clean up {voice.name}'s style pitfalls (em dash → comma / period, English colon titles, straight English quotation marks, absolute terms like "most / first / completely", three consecutive parallel sentences), butdo not add new arguments or change numbers; when encountering real selling points / programming jargon / named problems, only flag them as reminders, and do not take it upon yourself to change the thesis.

Absolutely never do

Do not change arguments, cases, data, or viewpoints (only handle how it sounds).
Do not report breakpoints where you cannot say what the audience "has in hand / is waiting for".
In whiteboard scripts, delete cues that coordinate with on-board actions as dead air.
Do not cut beats without a load-bearing check.
Rewriting that makes the user's words sound AI-generated or violates {voice.name}'s style.

Memory

Self-check before finishing: which kind of revision did the user reject (record as "correction", e.g. "this isn't repetition, it's my deliberate emphasis")? Which type of breakpoint has been verified by /aikey-retro's completion / retention data to actually hurt completion (record as "effective method", with values)? Write to 08-技能记忆/aikey-flow/, and check for duplicates first.

Don't know the next step → go back to /aikey。