文档提示工程人工智能【免费下载链接】claude-code-system-promptsAll parts of Claude Codes system prompt, 27 builtin tool descriptions, sub agent prompts (Plan/Explore/Task), utility prompts (CLAUDE.md, compact, statusline, magic docs, WebFetch, Bash cmd, security review, agent creation). Updated for each Claude Code version.项目地址https://gitcode.com/gh_mirrors/cl/claude-code-system-prompts点击查看免费下载导读本篇文章聚焦 Claude Code 内置 Background Monitor后台监视器工具的ws 数据源——一项无需启动 shell 进程、直接建立 WebSocket 连接并把每个到达的文本帧当作一条通知事件流式推送的能力。你将掌握Monitor({ ws: … })的完整配置写法、文本帧与二进制帧的事件语义、socket 关闭与限流机制以及何时用 ws 数据源、何时退回 bash websocat的选型准则。文中证据均来自本仓库 claude-code-system-prompts 中提取的 Claude Code 系统提示原文可对照源码级提示逐条核验。背景Background Monitor 的事件流模型在深入 ws 数据源之前先建立背景。Claude Code 的 Background Monitor 是一种启动一个长期运行的监视器、持续把事件流进聊天的工具监视器脚本的stdout 每一行就是一条事件事件按自己的节奏到达即使你正在等待用户回答问题事件也不是用户的回复。其基础语义记录在 tool-description-background-monitor-streaming-events.md 中监视器按你需要的通知数量来选择形态每次出现都通知tail -f、inotifywait -m、while true这类无界命令或每次出现直到已知终点输出若干行后自行退出的命令。stdout 200ms 内的多行会被合并为一条通知所以单个事件产生的多行输出会自然分组。监视器脚本运行在与 Bash 相同的 shell 环境中脚本退出即结束监视退出码会被上报可以用 TaskStop 提前取消。输出量受控每行 stdout 都是一条对话消息过滤器应当精确到你会采取行动的那些行产生过多事件的监视器会被自动停止。ws 数据源正是这条事件流模型的第二种事件来源它不运行 shell 命令而是直接打开一个 WebSocket把服务器推来的帧变成事件。ws 数据源打开连接把每个文本帧流成事件关联文档 tool-description-background-monitor-websocket-source.md对应 Claude Code 2.1.195 版本该特性于 2.1.193 引入见 CHANGELOG.md 中 Tool Description: Background monitor WebSocket source 一条给出的核心定义是ws source— open a WebSocket and stream each incoming text frame as an event. No shell, no polling: the server pushes, you get notified.翻译过来就是打开一个 WebSocket把每个到达的文本帧流式转换为一条事件。没有 shell没有轮询——服务器主动推送你被动接收通知。它与 bash 数据源的定位差异一句话即可概括bash 数据源由你的脚本去拉取/监听tail -f、轮询 API、inotifywaitws 数据源由服务端主动推送给监视器。这是事件驱动push与轮询/订阅poll/watch两种模型在 Monitor 工具内的自然分工。最小配置示例文档给出了可以直接照抄使用的调用形态Monitor({ ws: {url: wss://events.example.com/stream, protocols: [v1]}, description: deploy events, })各字段的含义与取值要点字段含义说明ws.urlWebSocket 服务端地址使用wss://加密协议示例为wss://events.example.com/stream这是监视器唯一连接的目标不经过任何 shell 命令中转ws.protocols客户端声明的子协议列表示例为[v1]用于在握手阶段向服务端声明希望使用的子协议对应 WebSocket 协议的Sec-WebSocket-Protocol协商机制按需传递可参考具体服务端的协议要求description监视器用途描述与 bash 数据源的规范一致写一条具体的描述deploy events 而不是 watching logs因为它会出现在每一条通知里见 tool-description-background-monitor-streaming-events.md 中 Write a specificdescription 一条需要说明Monitor、ws这两个字段的 JSON 形态直接取自系统提示原文Claude Code 在运行时会对该调用进行解析并建立连接protocols数组会原样参与 WebSocket 握手协商。本仓库是提示原文的提取仓库不包含 Monitor 工具的实现源码字段的更底层校验逻辑无法从本仓库进一步确认。事件语义文本帧、多行帧与二进制帧文档对什么样的帧变成什么样的事件给出了三条明确规则这是使用 ws 数据源时最容易踩坑、也最需要准确理解的部分每个文本帧 一条通知。帧与事件一一对应不做拆分。多行文本帧仍保持为一条事件。即使一个帧内包含换行符例如服务端一次性推送一段多行 JSON 或日志它依然作为一条整体通知送达而不会被按行拆开。这与 bash 数据源每行 stdout 就是一条事件、200ms 内的多行自动合并的语义不同——ws 源的分割粒度是帧不是行。二进制帧不直接透传。收到的二进制帧会被报告为[binary frame, N bytes]其中 N 为帧的字节数而不是把二进制内容本身塞进对话。也就是说你可以感知收到了一条二进制消息、它有多大但不会在聊天流里看到原始二进制载荷。这三条合起来意味着帧边界就是事件边界。如果你需要把服务端推送的大帧拆成多条通知或者需要把二进制帧解码成可读文本那就要落到下一节讲的 bash 方案里去加工。生命周期socket 关闭与错误暴露监视器不是无限期的它的结束路径在文档中有明确交代Socket 关闭会结束监视且 close code 会被暴露。WebSocket 连接关闭时无论是服务端主动关闭、网络断开还是协议层关闭监视随之结束关闭码close code会呈现在结果中方便你判断关闭原因。错误先于关闭被暴露。如果连接过程中先发生了错误例如握手失败、网络异常错误会被呈现出来之后才是关闭。从源码提示看这与 bash 数据源脚本退出即结束监视退出码被上报的生命周期模型一致退出/关闭即是终结信号终结时伴随一个可读的结束原因。结合 tool-description-background-monitor-streaming-events.md 的说明监视结束后如果还需要继续等待事件应当重新武装re-arm监视器而不是假设它会永久存活。限流与 bash 相同的消防水管保护文档特别强调ws 数据源采用与 bash 相同的限流机制Same rate limiting as bash — a firehose will be suppressed and eventually stopped, so subscribe to a filtered feed where one exists.即如果服务端推送得过于密集一条接一条的消防水管式流量监视器会先被抑制suppressed最终被停止stopped。因为每一条通知都是一条对话消息无节制的推送会淹没会话。这与 bash 数据源产生太多事件的监视器会被自动停止请用更紧的过滤器重启的规则见 tool-description-background-monitor-streaming-events.md 的 Output volume 一节是同一套保护逻辑。由此文档给出的直接建议是subscribe to a filtered feed where one exists优先订阅服务端已经过滤好的 feed。很多事件平台部署事件、CI 状态、监控告警等本身支持按条件订阅子集流如果服务端提供了过滤能力应当订阅那个更窄的流而不是拉下全量流再靠客户端扛。这与 bash 数据源过滤器应当精确到你会采取行动的那些行的指导原则是同构的——把噪声挡在源头。选型指南ws 数据源 vs bash websocat文档在最后给出了一段关键的选型建议它同时回答了什么时候用 ws 源和什么时候不该用Prefer this overcommand: websocat wss://…— it avoids the extra process and line-buffering pitfalls. Use bash when you need to transform or filter frames with shell tools before they become events.拆开来看优先 ws 数据源的理由相对command: websocat wss://…省掉一个额外进程。ws 源由监视器直接建立连接不再需要拉起websocat这样的 CLI 转发进程也就少了一层进程生命周期管理websocat 意外退出、被信号杀死、退出码含义模糊等。避开行缓冲陷阱。管道式方案里websocat ... | grep这类链路的每一级都必须逐行 flush否则输出会积压在缓冲区里迟迟不被感知bash 数据源的脚本质量要求里对此有完整警告grep需要--line-bufferedawk需要fflush()而head根本不能 flush见 tool-description-background-monitor-streaming-events.md。ws 源以帧为事件边界天然绕开了行什么时候才算完整的缓冲问题。退回 bash 方案的理由当你需要在帧变成事件之前用 shell 工具对帧做转换或过滤。典型场景包括把二进制帧解码/转成可读文本ws 源只报告[binary frame, N bytes]不落地内容对文本帧做格式转换、字段抽取、按关键字过滤后再推给会话需要把一个大帧拆成多条独立通知时在管道里按行或按块拆分。一句话总结选型需要原样接收推送就用 ws 源需要加工后再接收就用 bash 管道。实战建议把事件变成值得推送的通知最后补一条与 ws 数据源配合使用的实践建议。后台监视器的事件到达后并不是每一条都值得打扰用户——tool-description-background-monitor-push-notification-guidance.md 对此有明确指引When an event lands that the user would want to act on now — an error appeared, the status they were waiting on flipped — send a push notification. Not every event is worth a push; the ones that change what theyd do next are.结合 ws 数据源落地时推荐的组合拳是订阅/过滤在源头优先订阅服务端已过滤的 feed或选择足够窄的 topic避免触发限流保护。帧即事件描述写具体为每个监视器写一条能说明这是什么流的description让聊天里的每一条通知自带上下文。只对改变用户下一步行动的事件发推送收到错误、等待的状态翻转这类关键帧才推送普通事件留在聊天流里即可防止通知轰炸。处理终结socket 关闭后监视结束close code 会随结果暴露需要持续跟踪时记得重新武装或在脚本内处理订阅中断重连的逻辑。小结Claude Code Background Monitor 的 ws 数据源把事件驱动推送以最直接的方式接入了聊天流Monitor({ ws: {url, protocols}, description })一次调用即可建立一个 WebSocket 订阅文本帧按帧成事件、多行帧不拆分、二进制帧以字节数摘要呈现、关闭码与错误完整暴露、限流保护与 bash 数据源一致。当帧需要 shell 加工时再退回command: websocat …管道其余场景优先使用 ws 源以换取更少的进程、更少的缓冲坑和更干净的帧边界语义。相关仓库资料ws 数据源文档、流式事件主文档、推送通知指引、CHANGELOG该特性引入记录、仓库说明。赞分享文档提示工程人工智能【免费下载链接】claude-code-system-promptsAll parts of Claude Codes system prompt, 27 builtin tool descriptions, sub agent prompts (Plan/Explore/Task), utility prompts (CLAUDE.md, compact, statusline, magic docs, WebFetch, Bash cmd, security review, agent creation). Updated for each Claude Code version.项目地址https://gitcode.com/gh_mirrors/cl/claude-code-system-prompts点击查看免费下载相关推荐告别轮询Reflex服务端事件实现毫秒级实时数据推送告别轮询Reflex服务端事件实现毫秒级实时数据推送 Reflex是一个允许开发者用纯Python构建Web应用的框架。在实时数据推送方面传统的轮询方式存在后端前端Web框架告别轮询Alamofire WebSocket实现实时消息推送的完整指南告别轮询Alamofire WebSocket实现实时消息推送的完整指南 在移动应用开发中实时消息推送是提升用户体验的关键功能。传统的轮询方式不仅效率低下网络通信后端WarcraftHelper彻底解决魔兽争霸III在现代PC上的5大兼容性问题WarcraftHelper彻底解决魔兽争霸III在现代PC上的5大兼容性问题 还在为经典游戏《魔兽争霸III》在现代电脑上频繁崩溃、画面变形、地图无法加载而教程文档上一篇Duplicati日志聚合平台ELK Stack部署与配置完整指南下一篇Spring库性能监控集成指南第三方工具配置创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考