该技能文档围绕“交换文件格式契约设计”展开，强调契约应以文档形式明确写出，而非依赖解析器恰好接受的内容。文档以一个包含 songs 和 playlists 两个键的 JSON 信封为例，从消费者拒绝做什么开始约束生产者，例如：“应用自身不做匹配；如果写入文件时轨道没有 id，则它完全不应出现在文件中。”
文档列举了多个陷阱：无分支的版本字段比没有更糟，宽松解析器会让它隐形；该格式故意没有版本和来源字段，因为消费者忽略未知键，生产者添加版本字段会被静默丢弃；演进应通过可选字段和默认值实现，真正不兼容的变更应引入新文件形状，若添加版本字段必须同提交添加拒绝分支。解析为空文件应作为错误信号而非空库，例如两个列表都为空时拒绝为“不是有效的导入文件”。位置对齐的并行数组需在文档中声明长度规则，并说明消费者防御行为和生产者的责任。应列出已知遗留坏值（如字面量 "Album"），避免生产者继续使用。枚举消费者自行填充的字段（如 liked 状态、可用性、播放次数等），生产者不得提供。文档说明容量上限及执行方（如 songs 10000 条、playlists 500 条，生产者执行）。说明重复导入行为：已存在歌曲不覆盖，播放列表总是新建。顺序作为字段需明确说明。对悬空引用按字段决定是否致命，示例中跳过并重新编号且报告跳过数量。当只拥有消费者时，应按有意义的键放置值而非位置，并使用比例容差匹配。拒绝过短文件而非填充。解析应锚定在不含分隔符的字段上。验证部分提供了 shell 命令和断言顺序，包括乱序解析一致、短文件被拒绝、空信封被拒绝等。该技能适用于需要设计或评审交换文件格式的开发者，尤其是处理 Kotlin 或类似后端场景。限制：文档未提供具体安装步骤、收费信息或平台支持细节，需结合原始项目使用。