对于文档团队来说，“文字写完了”和“可以发布了”是两个不同的判断。一篇指南可能已经读起来很顺畅，但标题、导航位置或者最后一次审查还没有完成。
独立的发布步骤让这种区别变得明确。下面是一个简单的使用流程。
和了解主题的人一起写
连接仓库，在 Space 中选择内容 Collection，打开指南，让合适的成员参与维护。Owner、Admin 和 Editor 计入编辑席位，只读成员不计入。
普通内容可以使用可视化编辑器。需要检查完整文件或不支持的语法时，切换到 Source。在说明仍然不断完善的过程中，将工作保存为草稿。
不只检查段落，也检查文件
发布之前，检查 diff。除了正文，也要审查页面属性。如果 Collection 已确认支持的原生导航绑定，还应一起检查相关的导航变更。
审查也适合确认媒体链接，并检查文章是否清楚说明读者需要做什么。上传的媒体与保存在 Git 中的文字单独管理。
选择适合团队的发布方式
当内容已经符合仓库工作流要求时，可以直接发布 commit。如果需要团队通过 GitHub 审查，再进入发布分支，则创建 pull request。
文件进入 Git 后，继续由现有流程构建和部署网站。Prosefly 不会替代它。在仓库外部修改内容后，需要明确执行扫描来刷新工作区，而不是假设所有修改都会自动同步。