为文档做出贡献

OpenSquilla 欢迎来自用户与贡献者的文档改进。优秀的文档更改可以帮助人们安装产品、选择正确的功能，并在不依赖维护者上下文的情况下从常见问题中恢复。

可以改进什么

有价值的文档 pull request 包括：

• 更清晰的安装或配置步骤；
• 可直接运行的命令示例；
• 让 Web UI 更易理解的截图或措辞；
• 缺失的 provider、channel、memory、skill 或 tool 工作流；
• 针对常见故障的排障说明；
• 当某个命令、选项或行为发生变化时的修正。

让功能指南聚焦于用户价值与用法。除非这些细节是帮助用户使用产品所必需的，否则不要加入过深的运行时内部细节。

如何编辑

1. 如果问题较小，在 GitHub 上打开受影响的 Markdown 页面，并使用铅笔编辑流程来提出更改。没有仓库写入权限的贡献者将通过 fork 与 pull request 来提交。
2. 如果你不确定如何修复，请创建一个 文档 issue，附上受影响的页面与期望结果。
3. 对 main 分支发起文档 pull request。在分支切换期间，已有的 dev pull request 仍可继续。
4. 让文档更改小而聚焦于单一主题。
5. 对仓库内页面使用相对链接。
6. 优先使用具体的命令与示例，而非抽象描述。
7. 如果某个页面描述了一条 CLI 命令，请对照本地 CLI 或现有参考页面核对命令名。

关于通用贡献规则，参见 ../CONTRIBUTING.md。

仅文档变更的检查项

对于仅涉及文档的更改，至少要检查：

• 链接指向已存在的仓库文件；
• Markdown 代码围栏成对闭合；
• 示例中不包含私有路径、secret 或真实的 provider key；
• 截图或 UI 措辞与当前产品接入面一致；
• 产品声明保持面向用户，不暴露不必要的实现细节。

如果某个文档更改还修改了代码、测试、打包、provider 行为、gateway 行为、channels 或浏览器 UI 行为，请遵循 ../CONTRIBUTING.md 中的完整项目清单。

页面结构

大多数面向用户的页面应回答：

1. 该功能用于做什么？
2. 我应该在什么时候使用它？
3. 我该如何配置或运行它？
4. 当它无法工作时，我应该检查什么？
5. 接下来我应该去哪里？

相互独立的功能应当保持在独立的页面上。例如，memory、skills、meta-skills、SquillaRouter、tool compression、compaction、channels 与 artifacts 不应被合并到一个宽泛的机制页面里。

文档索引 · 产品指南 · 反馈文档问题 · 贡献指南