用途
notebook-explanation 是一项面向技术系统讲解的技能。当用户想理解某个技术系统，而非只想要一个成品答案时使用。写作方式模仿“某人为让自己看清系统而记下的私人工作笔记”，核心是压缩：term = meaning、boundary = owner、flow = step by step、rule = durable takeaway。若一个设计无法在这种格式下存活，说明设计本身可能混乱。
结构
先提问：Question 写明想理解什么，Short answer 用一句话作答，再用小代码块搭建模型，包括 Notebook model（term = meaning）、Flow（A -> B -> C）、Good/Bad 具体例子，以及 Rule 长期可复用的要点。
风格规则
命名归属、状态、流程、边界或权衡时，优先用代码块而非长段落；短段落仅用于衔接代码块；图前先用极小定义；边界易漂移时展示 good 与 bad；例子要具体，用真实包名、文件名、作用域、路由名或类型名；避免抽象架构语言，除非立即用一个小例子落地；不要一开始就讲所有边缘情况，先教核心模型，边缘情况仅在改变模型时再提；避免大量加粗，结构由笔记块承担。
架构讲解
先展示归属：apps/server 拥有什么、apps/cloud 拥有什么、module 拥有 routes/schemas/scope names、network 拥有 domain/records/policy、token 拥有 identity proof/audience/scopes、policy 拥有 exact product rule，再展示流程，如 private draft -> explicit publish -> network API -> public record。
Zoom Out 讲解
从文件上升一层抽象：当前文件的路径与角色、周边模块为何存在、调用者需要什么、相邻概念如何不同、该文件拥有什么与不该拥有什么。有项目领域词汇表时使用它，目标是让用户建立心智地图，能安全修改文件而不迷路。若架构讲解将用于文章，第一遍回答四个问题：Old model、Tell、New model、Rule。
图表选择
先写要点，再只画能证明它的图。按读者问题选择图形：Journey/evolution、Layer、Flow、Composition tree、Comparison。Journey 图用于决策如何变化，Layer 图用于归属层级，Flow 图用于移动，Composition tree 用于委托关系，Comparison 表用于三个以上稳定列的权衡。默认用缩进箭头图，成本低且适合工作笔记；box art 留给文章、精炼总结或规格等交付物。图表保持在一个抽象层级，混用产品概念、路由、数据库表和实现辅助函数时应拆分。箭头关系不明显时要标注。可用 ┌ ┐ └ ┘ ─ │ ├ ┤ ┬ ┴ ┼ ▼ ▲ ◀ ▶ ──→ ←── 等字符。
API 与鉴权讲解
区分 where、what、policy：audience 是令牌生效范围，scope 是客户端可尝试的操作，policy 是当前用户此刻能否做这件事。避免把 scope 写成过长的条件串。
代码拆解
用文件夹树表达归属，再展示最小有用的类型或函数。
何时停止
当读者能回答“这是什么、谁拥有它、数据流向哪里、经验法则是什么、诱人的错误版本是什么”时即可停止，不要因主题大而不断加章节。