tighten-doc

name

tighten-doc

description

润色文档 / 精简文档 / 改下文档 / AI 味太重 / 废话太多 / polish / make shorter / remove AI tone；**该画时序图还是状态机 / 这里要不要配图 / 图画完了总觉得不对劲说不上哪不对 / 缺图例 / 连线没标签 / 全是表格要不要补图 / 图里字看不清** → finalize wording after substance is settled: clarify, shorten, restructure lightly, preserve decisions, and keep comments safe. Proactively draft a no-owner deliverable doc（「写一份分享/给同事的文档」）. 图与表的**表示形式**（图种由主张形态推出、记法硬约束、版式契约、对比度、可跑的检查器）归本技能，**系统边界与架构决策本身仍归架构技能**。Skip while a sibling owns the substance（定稿仍回本技能）: spec/PRD/标准 → product-rd-workflow; 技术方案/架构文档 → architecture 技能; 发布文档 → release-doc-writer; 测试用例文档 → test-artifact-management.

tighten-doc — 文档写作与优化

Use this as the default document finalization and editing skill; new-substance authoring routes to the owner skill first. A deliverable doc is written for its reader (product / business / exec / teammate), not for the author. Default form = one-page operational/task manual: few short headings, enumerations as tables/bullets (one point per line), short sentences, no bracket piles, no template scaffolding.

When to use

Use any time you rewrite, tighten, polish, or finalize a doc someone else must read, after owner and scope are clear: strategy, plan, spec, task card, runbook, release note, or collaborative doc.

Three modes:

• Draft: after the owner skill has settled the substance, turn rough intent, notes, meeting output, or task context into a readable first version. Route to an owner when substance is unsettled and the type matches an installed owner skill: spec/standards/guideline -> product-rd-workflow, test cases -> test-artifact-management, architecture -> architecture skill, code/correctness -> stack/review skill. For new standards/spec authoring, product-rd-workflow is the single entry; the hand-back marker is product-rd owner-ready with authority statement, doc-family layer, and enumeration evidence — after that, finish wording here. If that marker is absent for a standards/spec artifact, polish only locally and mark pre-owner blocked (share/publish gate below). Standalone non-spec artifacts without family references skip it. If no owner skill is installed or reachable, draft from the charter plus user/session-supplied substance — never invent substantive decisions; they stay owner/user-provided. 多轮文档先锁 charter：references/doc-charter-first.md
• Rewrite: restructure an existing doc so decisions, owners, gates, and next actions are easier to scan.
• Tighten: remove filler, duplication, AI tone, meta narration, and over-long sentences without deleting decisions.

先判文档类型，再定形态：读者是在用一件已存在的东西（tutorial / how-to / reference / explanation 四模式），还是要据此决定或执行一件尚未做完的事（方案·架构 / 调研 / 现状梳理 / 评审 / 计划）。两轴的判据、每类的首稿必答节、正文与证据分册、图形态，以及「只标记拆分候选、不自行拆分」的收尾边界，见 references/deliverable-doc-genre-skeletons.md。一页纸操作手册默认形态对应 how-to / reference，别硬套到其他类型上。

For spec/standard/guideline artifacts, the pre-owner blocked marker rule applies to all three modes — do not share/publish until the owner marker exists; local wording polish must preserve the blocked label.

Before sharing, syncing, committing, or publishing a concrete deliverable artifact, run Tighten mode by default. Do not ask the user whether to optimize unless the edit would change a substantive decision, remove required detail, or risk collaborative-comment loss. A request to write a template, SOP, report, checklist, Feishu/Lark doc, task card, or launch material already includes the optimization pass after the owner skill has settled the substance.

After multi-round edits that added, restructured, or changed reader-facing prose or meaning, always run the Tighten mode before sharing or publishing; rounds of only exempt trivial edits (typo/link/format) may record that exemption instead. What counts as evidence for this pass: re-read the affected deliverable surface against the rubric (duplication — including same-content-different-face introduced by your own earlier edits in the same session — 一坨, term drift, cell-fits-column) and record: the surface, the touched blocks since the last full pass (the minimum index of scope, not the ceiling — include sections whose meaning the edits change), whether a full-card / family-wide sweep trigger below applies, the defects found or an explicit none, and the reason if scope stops at the touched blocks. Per-edit rubric compliance while writing, grep-only closeout scans (halfwidth / residual-wording checks), or a substance review do not substitute, singly or jointly — the recurring miss is accepting them as equivalent evidence and shipping a self-introduced duplication the surface re-read would have caught.

技术 / 参考文档：form 优化 ≠ 内容已核。 当本轮新增 / 改写 / 发布了可对源码核验的承载性技术断言（API 签名、env 行为 / 优先级、字段 / label 名、默认值——这类文档常自述真值源），且一手源用户已给、在当前工作区可得、或用户明确授权查证时，form 清理之外要把这些断言对一手源码（SDK / specs / fixtures / 可跑命令）核一遍。核出不符：仅 source-literal 的 typo / 名称 / 默认值笔误可直接照证据改；会改动 substantive contract / decision 的只标 discrepancy / pending 交 owner（stack / review skill），tighten-doc 不接管纠错。源不可得、超出本轮范围、或只是轻量润色：只做 form 并声明「形式已优化、内容未核」，不得裸称「文档已优化 / 准确」（别把每次 tighten 滚成一次代码审计）。

DELETE (废话 — cut these)

1. 元语自证 / doc-about-itself: "这是X不是Y文档", "本文档/本卡…", "读者是…", "别写空话". 最高频的 agent 自插入形态：给自己新写的段落加的向导式 opener/closer —— "本节只做X", "本页/这里不维护Y", "这张表只是…", "执行时不要只按本页…", 以及自述用途的引用开场（"用于配套《X》…放引用链接"）。读着像帮读者，其实是 元语自证 + 废话；删掉让内容自己站住。发布任何你自己写的段落前，先扫它的开场/收尾句是否是这一类——这正是"我把信息写对了"之后还残留、要读者来挑的废话。（承载真实决策/边界/受众约束/例外/后果的开场不算，删的是只描述"本节存在/本节是什么"的句子。）
2. 翻旧账 / blame: "没人跟全空", "证据：…当初也写过".
3. 修辞尾巴 / 口号 used as a closer: "…= 没解决", "做得再全也…", "上线≠X" as a rallying shout.
4. 无动作语气词: "周会点名" (doesn't say who / when / what) — replace with the real mechanism.
5. 无谓条件前缀 / 连接: "…时", "节奏跑不动时", "总之", "换句话说", "值得一提的是".
6. 重复: a heading restating the table's column names; a clause duplicated in another section. Index docs especially: define each term/role exactly once — later sections reference, never re-explain. When a line is challenged, first check if its content already appears in another section; keep only the delta. Aggregation / cross-cut / "references" sections are the prime filler suspect (they compress per-card content into slash-soup that also duplicates the cards) — collapse to a plain short gate list or delete. 近义词斜杠堆 = 重复：一行里 A/B/C 若各词同指一件事，收成 1 个代表词；各项确为不同事才留斜杠列表。逻辑子集措辞 = 表面冗余：并列两项中一项是另一项子集时读着冗余——删子集项，或点名两个不同失效机制让区分显式。跨节正反复述 = 隐蔽 dup：同一组判据被一节正面写（"满足 A+B = 通过"），另一节反面 / 否决形式重写（"反面 ¬A / ¬B 任一成立 = 不通过"）——内核同一份内容、换面孔。审查主动配对扫：每个"判定为 Y"句的 criteria 在别处是否以"否决 / 反证 / 不通过"形式重列；命中 pick 一处保留（通常留反向 / 否决列表，更直接 checkable），另处删。这类 dup 在"已清"二审里最易漏过，是 R1 review-completeness 的重点 watch。 图↔文字双写 = 重复：图承载流程 / 连线 / 状态迁移，文字别逐条复述。但文字要保留图说不清或不能丢的执行信息——判据 / 为什么 / 例外 / owner / 硬规则 / 阈值 / 后果 / 验收 / 非渲染 fallback（即 KEEP 项一律留，别当"复述图"删掉）。 加图 / 表后必做配对扫（加图时最常自引入的 dup）：是找 delete candidate 不是命中即删——只删纯步骤 / 节点复述；查的范围覆盖图所在小节 + 相邻小节 + 验收 / 红线段，不只邻近 bullet。 Row-granularity in an index/owner/lane table: one row per domain/lane. A row that is actually a sub-component of another row's domain (e.g. an SDK or a gateway sub-piece listed beside whole domains) → merge it into the parent row (fold its owner/progress/goal in), renumber, update the heading count. Do NOT merge two rows with distinct owners or timelines — that loses accountability; an owner-justified split stays.
7. 病句 / bulk-replace artifacts: e.g. "一键回退排障手册" (missing separator).
8. 自造版本号或前缀: never invent "v7 战略文档" — verify the real title first; a _v1 filename ≠ the doc title.
9. 编辑性括号副标题: "（按对的赌注不折中）", "（诚实校准）", "（怎么算通过）", "（含…前置底座）".
10. 画蛇添足的解释尾: "中途不换手", "（DoD）" tacked onto an already-clear line.
11. 假目标: a 目标/DoD cell that is a bare verb with no object or threshold ("V1 修完 + V2 决议", "止血/打通/完善", "韧性补齐"). Not filler-to-delete but filler-to-fix → rewrite as a falsifiable DoD traced to the owning card (never invent a threshold); if the real DoD lives in that card, replace with the pointer "见〔X 域卡〕". If the cell references an undefined term (e.g. "V2"), trace it to its definition point and either inline-gloss it once so the cell is self-explanatory, or point to the card — a reader having to ask "X 是啥" means the cell failed.

KEEP (实质 — NOT filler; deleting them drops a decision)

owner · 硬规则 · 完成标准/DoD · 里程碑 · 数值阈值 · the real build-vs-buy decision · severity/consequence rationale ("=资损法律风险 / =假安全 / =刑责风险 / 损失大" — that IS the judgment, keep it). Word it as severity, never as "死". The consequence label is KEEP, but the word "死" (资损法律死/刑责死/信任死/组织死) is rejected — reword to 风险高 / 损失大 / 刑责风险 / 信任崩 / 组织级风险. ("死" only stays in its non-consequence senses: 死线=deadline, 死约束=hard constraint, 死信=dead-letter, 钉死/封死=lock, 生死=critical-emphasis.) Compression ≠ deleting decisions: before compressing, extract the decided-points checklist (目标 / owner / 硬规则 / 后果论据 / build-vs-buy / DoD / 里程碑 / 最小交付) and verify each survives the rewrite.

FORM

• Named hyperlinks, never bare URLs: [真实文档名](url). Verify the real title before naming a reference; don't fabricate version prefixes.
• Collaborative docs that support rich structure (Feishu/Lark Docx/wiki, Confluence-like pages) should use the platform's rich-text structure when creating or materially rewriting a document: headings, tables, bullets, and named hyperlinks should be real document nodes, not plain Markdown pasted as body text. Use Markdown only when the target surface is Markdown-native or the user explicitly asks for it.
• In Feishu/Lark standards families, document references must be named hyperlinks, not quoted plain titles such as 《测试规范》. If a sibling doc is referenced more than once, verify the title once and reuse the same named link across the family.
• 断言写到证据等级为止。 交付文档里的结论按主张状态分「来源明确陈述 / 有证据支持的推论 / 作者判断」三态，不得混写成同一种口气；「来源明确陈述」是归因不是真实性——写成「来源 X 声称」，不得因有出处就用事实定论口气；作者判断句显式带「判断 / 预计 / 我认为」类标记，证据只到推论级就用分级句式写（如「机制可证、参数不可证」）。三态管解释性/推断性主张；直接观测豁免只限原始计数/测量值（如「本次查询返回 N 行」按本来面目写，不强套归因句式）——工具生成的分类/评分/裁决仍须标状态并写明工具权威边界。状态沿用实质 owner 或证据表已定的等级：润色时不得自行升降格；owner 未定状态的断言不改文、按既有通道标 discrepancy 交还 owner——已生效的决定、门槛、验收标准不因缺状态标签而被标「待确认」降级（调研类交付物的状态产出由 multi-perspective-research 合成简报持有，本条管所有交付文档的表达面）。
• 外部基线 / 标准值入文档 = 独立标注 + 命名来源 + 内部门（若有）仍权威。 引用外部 benchmark、行业阈值、标准默认值（评测目标、性能预算、参考 SLO 等）时，放成独立的列 / 行 / 标注并配命名来源超链，别和本系统自己的验收门 / 阈值混写成同一个数。当本系统有自己的验收门时显式声明本系统门为准、外部值只作对标参考（反模式：把外部基线直接当验收标准，读者误以为外部数就是上线门）；若文档本身即标准 / 评测报告 / 无内部门，则标清来源 / 范围 / 权威，别杜撰一个内部门。评自己的稿是这条的另一半：评自己产出的文档的可实测呈现属性（加粗密度、句长、结构层级）时，或为可发现性词汇（包 / 仓库的 description、keywords、tags / topics、搜索面标题词、产品定位名词）选词时，先按事先冻结的抽样框取同体裁公开样本建实测基准，再下判断 / 选词——这两类只是已知实例：其他属性只要问的是「相对同类如何」且有同体裁公开样本，同样适用，不得因没被点名就放过；但内部验收门、硬限额与对错 / 安全的直接核验照门判、不记「未对标」；门里若含「同类怎么做」的前提，它仍欠本条；没测就在用它之前记「未对标 + 原因」，成本 / 限流不是豁免，只是把结论降级；待发布 / 未公开的名字与定位词不拿去外部检索（查询即送出，按 product-rd-workflow artifact-egress 门处理）。分布定位只是描述、不是裁决，自己的审美不是分布。触发本条即先读 references/self-benchmark-baseline.md 并照它执行——抽样框冻结与纳排、不得挑样、中英分开、阈值核源、词频读法、frontmatter 归属都在那。
• No inline ｜ / pipe-delimited lists (RACI / 分工) — break into bullets or a table.
• Short sentences, one point per line, enumerations as tables.
• 表达形式匹配内容：分支关系 / 状态迁移复杂到文字难扫时优先图（mermaid 等）；字段对比、分桶属性、owner/gate/证据矩阵优先表；线性步骤用编号列表；一两点判断一句话或 bullet。别为单个判断加装饰性多桶图，但桶间有不同 owner / 阈值 / 例外 / 后果时（该结构别压成一句）。，文字版流程为准、图只作辅助。：callout 塞成多点密块（"一坨"）就拆开或降到正文 / 表。（有事件触发→状态机 / 消息序→时序 / 随完成流转→流程）；；。余下见 。

RESTRAINT

• If one sentence says it, don't pile modifiers.
• Delete only when nothing is lost (compression ≠ deleting decisions).
• Generic process docs should carry rules, gates, owners, and acceptance logic; project evidence should live in launch notes, evaluation reports, appendices, or linked child docs. Do not make a general SOP unreadable by embedding code paths, source evidence tables, or full implementation proof unless the doc is explicitly an audit/report.
• Compression ≠ compressing past comprehension. Over-tightening collapses a rule into a bare noun-pile with no verb/object (a list of nouns where each item names a thing but not what to DO with it), so the reader can't act. That noun-pile is the over-compression signal — readability > terseness. Fix by restoring verb+object (who does what to which, by when), not by compressing more. After a 干练/简化 pass, re-read each item as a stranger: if you can't tell the action from the phrase, it went too far.
• Prefer the plainer word: "负责到完成" not "负责到完成定义"; drop jargon the audience won't parse.

执行卡精简范式 (domain/execution cards only)

For a 域卡/执行卡 (a card that sets WHAT a domain must achieve + who owns it), the converged skeleton is: 目标(决策化) · 负责人(owner+RACI) · 关键规则(红线/后果/NO-GO/0容忍) · 里程碑(动作+gate) · 验收(过关条件,brief) · 最小可交付 · 每周怎么跑/依赖/兜底 · 相关文档.

• DROP: 术语/白话 gloss section, build-vs-buy / 自营不外包 rationale walls (keep the one-line decision, cut the why-wall), 硬指标 numeric blocks, 枚举/机制 implementation detail, per-item evidence/threshold columns — 数值阈值、验证步骤、工具清单 are the owner's to decide, not the card's. Also the 默认流程动作 (回填某表/提工单), self-referential / process-aside parens (（边界已划不重叠）（其余降独立验收）). Also ceremony controls — 签字/签收, 版本号戳 (v0.1/v1 stamped on every deliverable), 「列…清单」mechanism wrappers — are the owner-accountability (single-A RACI) model's job, not card substance: cut unless the user explicitly keeps them, and state the rule directly instead of wrapping it in its list/sign-off mechanism (a 红线 is "X 未到位 = 不得 Y", not "列一张写着『无 X 不得 Y』的清单").
• KEEP verbatim: 红线、后果论据(severity不用"死")、NO-GO/0容忍、关键可证伪判定定义 (a load-bearing N-criteria pass definition), 锁定决议, owner/RACI, 砍清单. Promote a load-bearing judgment list to its own short section rather than burying it.
• 目标/红线/验收 = a define-once ladder, never restated down the card. 目标 stays at goal-noun altitude (don't gloss it with the concrete bar). 红线 carries the 0容忍 rule + falsifiable definition once. 验收 = "红线全部达标" plus only the verification-specific items red lines don't state (test method / adversarial cases / exportable / a feature-works check / rollback-rehearsed) — never a verbatim re-list of red-line field lists. A downstream gate references, never restates (公测门 = "验收全过", not a re-enumeration of the bars). When 验收 or a milestone gate repeats a red line's exact clause/field-list, that is DELETE #6 — collapse to the reference.
• Cross-card consistency. When optimizing one card in a family, the owner-line format (1 人（X 线），1 周内定，…) and the section skeleton must not drift per-card: aggressive per-card trimming can silently regress one card below its siblings (owner loses 线+1周内定, the ## 验收 section gets dropped). On a per-card pass, diff its owner line + section list against a sibling and restore parity. When a family of cards shares the same broken framing premise, converge ONE card to the corrected skeleton first (get it reviewed + published), then re-derive each sibling to mirror that reference skeleton — do not independently re-invent each sibling.
• Global boilerplate-strip + retitle = per-card guarded, never a blanket replace fallback. When deleting a globally-duplicated line and retitling its section across N docs: (1) check the line isn't that doc's substance — a line that is boilerplate in most docs may be the entire point of one doc; stripping there destroys content. (2) the new header must name all sub-blocks still in the section, not just the first — a blanket replace fallback will mis-title a doc whose section held more than the stripped part. Per-doc compute the remaining content and title to it; exclude any doc the user flagged as do-not-touch.

句子层（吸收 Strunk 与 Google Tech Writing，仅取中文交付文档适用项）

英文文档：用完整 Strunk 规则（含被本节剔除的语法/标点条），本节只是中文交付子集。

• 主动语态、点名施动者：写"谁做什么"，不写"被…/由…完成"（呼应 DELETE #4 无动作语气词）。
• 肯定式陈述：直接说"必须 X"，不绕"不是不 X / 并非没有"。
• 具体优于空泛：用 数字/对象/阈值，删"全面提升/大力推进/高度重视/至关重要"这类空话（呼应 KEEP 的数值阈值）。
• 删冗词的定式：把"是否…的问题/在…的情况下/做出…的决定/关于…方面"压成 "是否…/…时/决定…/…"。
• 歧义代词消歧：它 / 它们 / 其 必须先有名词、后有代词，指代名词离得远或中间插入另一名词就直接重复名词；指示词 这 / 那 / 该 / 此 要么换成名词，要么后接名词（「这会拖慢构建」→「这次全量扫描会拖慢构建」）。
• 相关词靠拢、少套从句：修饰语紧挨被修饰对象，长定语拆短句，避免一句里多层"的…的…"。
• 强调位放句首或句尾：最该被记住的词别埋在句子中间。
• 结论前置（BLUF / 倒金字塔，业内通行做法）：bullet、段落开头先放结论 / 动作 / 信息词，例子和非结论性背景后置——读者扫读，埋在后面的结论会被跳过。但会改变结论的条件不算"例子"：凡是改变结论、适用范围、红线 / NO-GO / 阈值 / 例外 / 责任边界的条件，必须与结论同句同屏，不得降级到后面或塞进括号弱化（如「满足 A、B、C 时，做 X」，不要用括号把条件视觉降级）。作用范围：bullet/段落级，区别于上一条词级"强调位"；只重排各 bullet/段落内部，不得为前置结论删除或降级 KEEP 项，执行卡仍按固定骨架排序。
• 防分词歧义：中文动宾或多义连写串可能被切成另一个意思——「门禁止血」会读成「门 / 禁止 / 血」。加分隔、连接词或重排消歧（「门禁来止血」）。只改真实会误读、误切后动作/对象/责任会变的词组；通行术语、项目内已定义术语、读者熟悉的短词不为消歧而重写，避免 churn。

中文自然表达（吸收 humanizer-cn 的交付文档子集）

目标不是"更像人"，而是去掉 AI 腔/广告腔/假深度，让读者一眼看清事实、动作、边界。

• 删宏大意义词：彰显、标志着、里程碑、树立标杆、重新定义、开启新篇章。改成实际变化、对象、结果。
• 删动词堆砌：致力于、旨在、聚焦于、依托于、围绕、基于、着眼于。改成"谁为谁做什么"。
• 删广告口吻：精心打造、匠心、领先、一站式、全链路、赋能、助力。保留能力、边界、验收条件。
• 删模糊归因：业内认为、专家表示、相关人士透露、多方消息显示。要么给真实来源，要么改成"未验证"。
• 删套路结尾：未来可期、任重道远、砥砺前行、让我们拭目以待。结尾只留下一步动作、风险或决定。
• 不强行书面化：保留用户认可的短句、白话、紧凑 / 和 + 枚举；只修元语、重复、空泛、病句。
• 不引入创作向技巧：不要为了"有人味"加入第一人称、幽默、情绪、跑题插入语；交付文档以清楚、可执行为准。

COMMENT-SAFE EDITING (hard rule)

Never destroy collaborative comments. Before editing a collaborative doc, fetch its real title and count comments.

• 0 team comments on a doc you own: full overwrite can be safe after title/body checks.

• 0 team comments: do not overwrite the whole doc. Use a platform-safe targeted edit, or return a read-only audit for the user to apply.

• A restructure that deletes, renames, merges, or reorders a section must re-resolve every internal reference that points into the changed area. The reference-label residual-scan verifies a pointer's wording (the old title/label is gone), but a Rewrite that removes or renames a target leaves an [title](#anchor), a "见〔X 域卡〕", a "see the Y section", or a numbered-section cross-reference dangling even when its text is untouched — and a moved KEEP/decided-point a pointer no longer reaches is a silent drop. After a structural edit, list the document's internal cross-references/anchors and confirm each still resolves to a present target (repoint or remove otherwise) — the prose-navigation counterpart of the comment-anchor integrity rules below.

  • Inbound references must be re-resolved too — that half is what link checkers miss. The re-resolve above is intra-document, but a deleted/renamed section is just as often named from other artifacts, including non-Markdown files a doc linter never opens (install/build scripts, CI configs, Makefile help, code comments); a prose pointer (见 README 的「X」段) is invisible to a link checker anyway, since those resolve the file and commonly discard the #fragment. So on any heading you delete or rename, run git grep -F --untracked -- "$old_heading" repo-wide, then repeat for its anchor slug (install-and-update) — [x](README.md#install-and-update) carries the slug, not the heading text, and the link checker strips the fragment, so the literal search alone misses every anchored link. -F -- keeps a --leading heading from parsing as an option; --untracked keeps a new unstaged file from reading as clean. Read the exit code: 0 = repoint the hits, 1 = clean, ≥2 = the scan failed and proves nothing. Neither pass sees a paraphrase — that needs a read. Failure shape: a README section is dropped, and a sibling doc plus a shell script keep telling readers to go read it — each pointer's own wording is untouched, so every residual-scan and link gate stays green until a human reads both files.

• If changing a quoted/commented string, preserve anchors deliberately or delete/re-add only your own comment at the new text.

WORKFLOW

0. 读者批注：判根因类、全文修同类（references/annotation-driven-revision.md）。
1. Extract the decided-points checklist from the current text.
2. Apply the DELETE list; keep everything in KEEP.
3. Rewrite to FORM; confirm every decided point still present.
4. Dirty-scan = 0 (no internal codes / agent names / meta / Day-Week tokens, no bare-URL refs, no AI腔/广告腔/假深度, no ｜). A keyword grep is a fixed-token prefilter, not sufficient — the 元语自证 / 修辞尾 / 废话-prefix / 跨节重复 classes aren't fixed tokens, so dirty-scan-0 needs the grep plus a human read against the DELETE/FORM rubric. "脏扫 0" claimed from grep alone is the false-clean failure.
5. Push back, respecting the COMMENT-SAFE rule.

交付前 closeout checklist（阻断项索引，不是通过证书）。 报「已优化」仍需跑完 Workflow 1-4 + KEEP / decided-point 保全 + 下方 closeout-sweep 全量；本清单只把高频阻断项收敛成可判定的最后一道闸，逐项标 ✓ / N-A、任一未过即不得报已优化（每项指向下方 / FORM 的 canonical 规则，不在此复述全部语义）。发布、同步、commit 前离开生成态，把改过的块当"刚被粘进来"逐行读一遍再判：

1. callout / 图内文字 = 一个要点：无多点密块（一坨）就拆或降正文 / 表；图的形态项过 figure-and-table-craft.md。
2. 管理 / 业务 jargon 对目标读者已 plain-name / gloss（协议 / API / 字段 / 契约名 + 用户认可的紧凑 / + 枚举保留；保留项里读者不熟的首次解释）。
3. 编号连续、父子号同步；族内同义术语 / label 漂移全族扫 = 0。
4. 图 ↔ 文字无双写（图承流程、文字留 KEEP 项）；外部基线 / 标准值独立列 + 命名来源，门权威按「外部基线」条（有内部门则其为准，无则标清来源不杜撰）。
5. comment-safe：协作文档先取真实评论数，> 0 则定向编辑不整篇 overwrite + 改后复核锚点 / 条数；N-A 仅限非协作 / 本地件或已取 comments = 0。
6. 脏扫 = 0：grep 固定 token + 逐行 standalone-paste 人读（元语 / 修辞尾 / 跨节重复 / 假目标非固定 token，grep 会漏）。
7. 交付面逐面判定（走枚举，不是单个 ✓）：先列出本交付物的全部面——远端副本 / 各附件 / 各导出件 / 历史多代产物，列不出面的清单等于没跑——再逐面标四态之一（互斥、不叠加）：已投放（带回读到的标志，只写「已上传 / 命令成功」不算）/ 授权不投放+理由 / blocked+补救+下一步 / 待安全处置（命中删除要求即替代前三态，单独列不并进 blocked 或待投放；触发为客观命中——凭据 / 受删除请求约束的个人信息 / 已判定有害的错误说明——或有权 owner 的删除决定，拿不准按命中处理并问 owner）；多代并存另标当前版入口与退役方式；有交互源导出的另标已全展开再导并对照清点。有 blocked 或待安全处置面即不得报已优化 / 已同步。 三态定义、各自的绕过路径与转出规则见 references/delivery-face-closeout.md。

本清单是可判定下限，不替代下方 closeout-sweep 全量（改后重扫早期类、长散文转 bullet / 编号等）；用户还能单 paste 挑出同类缺陷 = 清单未真跑，是 firing 失败，不是"reactive 再补一处"。

• Review-completeness gate — a reactive single-point pass is not "optimized", and "脏扫 0" from it is a false claim. When a converged reference card already exists in the family, optimizing a sibling means a systematic full-card audit against that reference skeleton + the entire rubric in one pass: scan every section for the same defect classes the reference already shed (RACI/owner-枚举, 阈值机制 owner-detail, jargon/英文 token, 跨节重复, run-on +/、 mega-lines, 元语/why-wall) and fix them all at once before reporting done. Do not declare 已优化/脏扫0 while the user can still point at same-class defects you didn't sweep — that recurring "你不认真看么" is the compliant-but-weak defect. Proactively de-jargon for the product/biz/exec reader; do not wait to be asked "这是什么/看不懂" line by line.

• A jargon term/label rename is a family-wide sweep, not per-card. When plain-ifying a term or label that recurs across sibling cards (a gate name, a status word, an acronym), rename it across the whole card family in one pass and residual-scan the old term = 0 across all family cards; renaming only the card in hand causes intra-family term drift.

• Standards-family dirty scan must include cross-doc drift terms. For R&D standards, scan all sibling docs for old jargon, plain-text doc references, and bulk-replace artifacts before reporting done. Typical Chinese team-doc cleanup terms include owner, deadline, runbook, Bitable, lockfile 未漂移, 有限值, bare quoted sibling titles, and spacing artifacts like 负责人 和 or 截止时间 和. Preserve true protocol/field names when they are part of the technical contract, but rewrite management/action wording into reader-facing Chinese.

• Full-pass ≠ token-pass — every audited line must be parsed as if user just pasted it standalone. Full-card R1 / "逐行修改" / "整文档优化" 都让 attention 摊薄 across N lines → pattern-match 过快 → token-level defects 经常漏：同义词堆（"宁过度拒答不越界" + "不按比例" + "0 容忍" 三处同 threshold）、paren 重述前句（"AI 只读、只建议、只生成草稿" 第 3 项是 "只建议" 的子情况）、reorder 后 ordinal 错位（序换 "A 改为 B" → "B 不是 A" 但 "前者" 仍指 A）、单 sentence 内正反复述（"须给路径，不得只否决不给出路"）、severity paren 与 sibling rule verbatim subset（红线 L1 severity + 五前置 L2 同句）。规则：full-pass 每行必跑 standalone-paste-parse — 每 token 检 redundancy / 每 paren 与前句配对扫 echo / 每 "前者/后者/前一项" 在 reorder 后追位 / 每 sub-list 与 cross-section verbatim subset 配对查 R2 ladder。声明 "R1 clean" 而 user 单 paste 即可挑出问题 = evidence-depth overstatement；下一句 single-line paste 必破。

• New drafts don't escape the rubric. Any newly-drafted content during this workflow — premise-rejection re-derive, doc split / new sub-card creation, family-wide refactor, or skeleton-from-scratch — must run steps 1–4 (decided-points → DELETE → FORM → dirty-scan = 0) before push. "User approved the split / structure / premise core" approves the , not the content; the rubric still applies to every new draft. Skipping line-by-line audit on new content lets 元语 / cross-句正反复述 / label-self dup / R2 ladder verbatim subset / 假目标 slip through, and the next message will be "有用技能优化内容么".

When the user probes sentence-by-sentence ("这是废话么 / 什么意思 / 能精简么"), answer per this rubric, give the tightened version, and apply it — don't ask permission unless the comment-safe red line is triggered.

Reference Loading

• For Feishu/Lark comment preservation, range update mechanics, overwrite pitfalls, and cross-doc rename safety, read references/comment-safe-feishu.md.
• 「外部基线」条一触发就必读 references/self-benchmark-baseline.md：抽样、分布定位输出、可发现性语料与词频读法、两条边界。
• 交付面收尾（投放回读、三态定义与绕过路径、旧版退役与「被要求删除」的转出、静态导出全展开）展开在 references/delivery-face-closeout.md；closeout 第 7 项与「交付面」条都指向它。

CROSS-MODEL / CODEX CO-REVIEW CAVEAT

Cross-model agreement is a recommendation, not a decision: take only rubric hits, reject every 口语化→书面 rewrite and any re-expansion of a deliberately terse line, present its output verbatim, state what you took/rejected and why — references/cross-model-co-review.md.