用途：把项目启动会（kickoff）的文字记录稿转换成面向构建者（builder）的参考文档。记录稿是原始素材，文档不是会议摘要，而是对讨论中所规划“领域”的还原。
开始前需询问用户：主要读者是谁（通常是负责实现的构建者）；还有哪些其他输入（视觉稿、截图、mockup、breadboard 等）。
组织原则：按领域而非时间线。记录稿是顺序化的，会出现回溯、跑题。应按所构建的东西组织，每个小节完整描述系统的一个区域，便于构建者按“某功能怎么工作”一处查全；不要按构建顺序组织，若团队划分了切片（按顺序实现的垂直切片），这些另行管理，不放进本文档。
结构：顶层两个 ## 章节：Frame 与 Shape，其子节为 ###。
Frame：战略背景与边界条件，供构建者在遇到模糊时做判断。包含 ### Problem（为什么做这个项目、现在为什么做、哪里坏或缺失）与 ### Outcome（预期具体成果、成功的样子）。
Shape：每个系统区域一个 ### 小节，描述该区域是什么、屏幕上有哪些可供性/组件/展示数据，与其他区域的关系，属于本区域的设计决策（内联，不单列），被指出的边缘情况或标记，哪些是临时的/占位与哪些是真实承诺。不要包含 Build Sequence 小节。
语气：用他们的话。用会上实际用词；把散落讨论综合成更清晰表述；记录决策理由。不要替人表达新想法或结论，不要加入未表达的激励性框架或对重要性的主观评论。检验标准：每句话应能指向记录稿中某人说过或明确表达之处，否则删除或标注为自身综合。澄清或综合式表述可接受，但不应添加自己的结论。
设计决策：垂直而非水平。不要建立笼统的“Design Decisions”小节，而应把每条决策放在它相关的区域小节内，例如存储选择放在匹配小节，候选物化放在附件小节，按 ICP 的匹配数据作为值对象放在匹配结果小节。
流程：读完整份记录稿再开始；识别讨论到的系统区域作为 ## Shape 下的 ### 小节；从开头附近的框架/成果讨论起草 Frame；写各 Shape 小节时从记录稿各处取材；把设计决策内联到所属小节；最后对照记录稿复核每处说法。
限制：资料未提供具体安装方式、命令、平台或收费信息。