Using the Bot in Team Chat

These are the interaction patterns that proved to work when the Context Skills run behind a team chat Bot. They apply whether you build your own Bot or use the one planned for this site.

Status. The community edition does not ship a Bot; this site's own Bot is planned. The patterns below come from running the Context Skills behind a team chat Bot.

Messages: start, progress, result

• A task replies with three kinds of messages: start, progress and final result. Keep updating the same progress message instead of posting many.
• The Bot asks only when someone must decide — confirming a work-start report, confirming publication, choosing a scope — and offers selectable options. Nobody should have to reply with a code word or review code.
• When a reviewer finishes the diff report on the website, the workflow continues from there; there is no need to come back to chat to confirm.
• Maintainers should not have to think about committing the knowledge repository or publishing the package and site. These complete silently by default; the Bot interrupts only for a diff review, a permission problem or a disagreement.

Answers people can check

• Every answer carries clickable sources: knowledge pages, code lines with their commit, and original documents. "According to the knowledge package" alone is too abstract to verify.
• Each answer has thumbs-up and thumbs-down ratings. Ratings and the conversation are used together to improve retrieval and prompts.

Capturing knowledge while you talk

• When an answer is worth keeping, ask the Bot to capture it. The chat, a document you just shared, or a specific piece of code or merge request can all become sources; the Bot first proposes a plan, then runs the update flow. See Capturing from Conversations.
• You can also ask for an update of the whole knowledge base or part of it. The Bot analyzes what changed upstream in documents and code since the last update, presents an update plan, then a diff report against the website baseline.
• Scheduled patrols trigger at fixed times, track upstream changes and capture knowledge. A patrol prompt must state its scope, what to do when nothing changed, and which situations need a person. See Scheduled Updates.

Speed

• Cold start is the main reason a first answer is slow. Preinstall the CLI, the knowledge packages and the Context knowledge workspace in the runtime so that sessions do not install and clone each time.
• Read knowledge first, and read originals remotely only when the evidence is not enough — fetch code by commit through Source Graph instead of cloning repositories in the sandbox. Measured effects are in Knowledge Retrieval Benchmark.
• Simple questions still have room to improve; the target is an answer within a minute.

Boundaries for a public Bot

• Public visitors may only ask questions. Production, updates and publication are open to maintainers only, enforced by the service layer.
• The Bot reads only registered public sources. Credentials stay on the server and never enter knowledge, prompts or replies.
• Prefer a long-connection event subscription to connect the chat platform; it needs no public callback address.

在团队聊天中使用 Bot

以下是在团队聊天 Bot 背后运行 Context Skills 时被证明有效的交互模式。无论你自建 Bot，还是使用本站规划中的 Bot，都同样适用。

状态。 社区版不提供 Bot；本站自有的 Bot 尚在规划中。下面的模式来自在团队聊天 Bot 背后运行 Context Skills 的实践。

消息：开始、进度、结果

• 一个任务会回复三类消息：开始、进度和最终结果。持续更新同一条进度消息，而不是发很多条。
• Bot 只在需要有人决定时才提问——确认开工报告、确认发布、选择范围——并提供可选的选项。谁都不应该需要回复暗号或审核代码。
• 审核人在网站上看完 Diff 报告后，工作流会从那里继续；不必再回到聊天里确认。
• 维护者不应该操心提交知识仓库或发布知识包和站点。这些默认静默完成；只有遇到 Diff 审核、权限问题或意见分歧时，Bot 才会打断。

可供核查的回答

• 每个回答都带有可点击的来源：知识页面、带提交号的代码行，以及原始文档。只说“根据知识包”太抽象，无从核实。
• 每个回答都有点赞和点踩评价。评价和对话会一起用于改进检索和提示词。

边聊边采集知识

• 当某个回答值得保留时，让 Bot 把它采集下来。聊天内容、你刚分享的文档，或者某段具体代码、某个合并请求，都可以成为来源；Bot 会先提出计划，再运行更新流程。参见从对话中采集。
• 你也可以要求更新整个知识库或其中一部分。Bot 会分析自上次更新以来上游文档和代码的变化，给出更新计划，再给出相对网站基线的 Diff 报告。
• 定时巡检在固定时间触发，跟踪上游变化并采集知识。巡检提示词必须写明范围、没有变化时怎么做，以及哪些情况需要人介入。参见定时更新。

速度

• 冷启动是首次回答慢的主要原因。在运行时中预装 CLI、知识包和 Context 知识工作区，让会话不必每次都安装和克隆。
• 先读知识，只有证据不够时才远程读取原文——通过 Source Graph 按提交获取代码，而不是在沙箱里克隆仓库。实测效果见知识检索测评。
• 简单问题仍有提升空间；目标是一分钟内给出回答。

公开 Bot 的边界

• 公开访客只能提问。生产、更新和发布只对维护者开放，由服务层强制执行。
• Bot 只读取已登记的公开来源。凭据保留在服务端，绝不进入知识、提示词或回复。
• 接入聊天平台时优先使用长连接事件订阅；它不需要公网回调地址。