Reader Briefing 是一个写作前的纪律性技能，面向需要公开发布、且素材来自内部项目的文章。它的核心目的是让写作者在动笔之前，先明确文章面向谁、读者带着什么来到页面，从而避免“内部人语境坍塌”——即作者默认读者拥有自己所处的项目语境。
用途与定位 该简报是一份简短的结构化文档，在开始起草前写好，作为整个写作流程的审计锚点。它被描述为基础性设施：其他写作技能（synthesis-article-writing、synthesis-article-refresh，以及各类回填和刷新类技能）把已提交的简报当作硬性前置条件，没有简报就拒绝继续，因为“无简报即起草”正是本技能要防止的失败。
主要能力与核心规则 技能要求回答四个核心问题，每题一段平实文字，不用清单或填空模板：
- 这篇文章写给谁？必须具体，不能是“所有人”或“任何对 X 感兴趣的人”，而要指明真实读者，例如从未用过你工具的软件工程师、评估某方法的技术负责人等。
- 读者带着什么来到页面？即读者已有的知识、经验或期待，例如通用工程词汇、对某场争论的熟悉度，或可被文章直接激活的共同人类经验。
- 这篇文章要求读者付出什么？例如十分钟专注阅读、耐心理解一个新原则加一个实例，或几分钟注意力并愿意有所感受。
- 读者读完带走什么？例如新的心智模型、一段切身感受、更明确立场，或周一早上就能用的具体做法；“更懂这个话题”不被视为合格答案。
答案应决定文章结构，而非套用模板：体裁的形状（普遍框架优先、场景优先、主张优先、问题优先）由四个答案推导而来。技能还要求声明系列依赖关系，且只能是三种状态之一：独立、紧凑上下文后独立、真正的前置依赖；真正的前置依赖需附链接和一句理由，且没有文章负有交叉链接配额。起草过程中需逐段对照简报审计，并在提交前以“陌生人”视角通读，因为作者本人是内部人，凭感觉判断无法发现语境坍塌。
使用方式 简报保存为 .briefing.md，与草稿放在同一目录：目标仓库中的文章放在 content/posts/YYYY/MM/DD-slug/.briefing.md，与 index.md 并列；知识仓库草稿目录中的草稿则用 <slug>.briefing.md 放在 <slug>.md 旁边。简报在草稿晋级流程中随草稿迁移保留；文章被放弃时归档到项目历史。可选添加一段“结构含义”，由四个答案推导出体裁和结构形状，用来检验答案是否足够具体。
适用与不适用场景 适用于：读者不被假定共享作者项目语境的任何公开文章、博客或随笔；面向外部受众的文档（开源贡献者、客户、潜在用户）；取材于内部经验、项目文件、提交信息或代码库的内容，尤其当素材丰富且写作由 AI 辅助时风险最高。 不适用于：面向已共享语境的特定团队的内部文档（内部语言是高效沟通而非术语）；作者自己记忆用的个人经验记录；素材本身（提交信息、项目上下文、运行手册），它们应按其真实读者来写。
配套参考文件 references/genres.md 提供四种示例简报（技术、个人、观点、建议）及各自隐含的结构；references/series-dependency.md 说明系列依赖契约的五个字段与三种状态及其刻意不要求的内容；references/audit-and-precondition.md 说明逐段审计、陌生人通读和硬性前置条件；references/background.md 解释技能存在的原因（内部人语境坍塌、知识诅咒）及相关技能；references/coverage-map.md 说明 1.1.0 文本各部分现所在位置。
限制 简报不是填空模板、清单或一行受众标签；每题一段具体平实文字是产生有用审计锚点的最低要求。关于该技能的具体收费、价格、平台支持等信息，资料暂未提供。