
文档提示工程人工智能【免费下载链接】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 系统提示集中定义“Hook 执行成功”回执消息的模板文件 system-reminder-hook-success.md 展开剖析当项目配置的 hook 命令成功执行后Claude Code 如何通过系统提醒System Reminder把执行结果注入模型上下文。读完本文你将掌握 hook 成功消息的模板变量结构与来源、它与 hook 错误类提醒的区别、如何利用转录transcript中的hook_success记录排查慢 hook以及如何通过 hook 的 JSON 输出字段控制成功消息的呈现方式。一、模板文件概览一段两行的“成功回执”关联文档全文极短完整内容如下!-- name: System Reminder: Hook success description: Success message from a hook ccVersion: 2.1.18 variables: - ATTACHMENT_OBJECT -- ${ATTACHMENT_OBJECT.hookName} hook success: ${ATTACHMENT_OBJECT.content}这份位于 system-prompts/system-reminder-hook-success.md 的文件与仓库内其他system-reminder-*.md一样属于 Claude Code 运行时注入的系统提醒模板它并不直接面向用户阅读而是作为结构化消息格式在 hook 命令成功结束这一事件发生时被填充并追加到会话上下文中让模型感知“某个 hook 刚刚成功完成以及它输出了什么”。模板的前置元数据frontmatter透露了三个关键信息字段取值含义nameSystem Reminder: Hook success该模板在系统中的唯一标识也即转录日志中对应 attachment 的类型名称来源descriptionSuccess message from a hook一句话说明该模板的用途ccVersion2.1.18该模板随 Claude Code 版本维护的引入版本说明成功回执提醒自 2.1.18 起以该格式存在variablesATTACHMENT_OBJECT模板唯一依赖的运行时变量对象hook 事件的所有回执数据都通过它传入模板正文只有一行插值表达式${ATTACHMENT_OBJECT.hookName} hook success: ${ATTACHMENT_OBJECT.content}其渲染结果形如MyLintHook hook success: 3 files formatted, no errors这行消息会以系统提醒的形式进入上下文让模型得知某个命名 hook 成功完成并附带了它的输出内容content。二、成功回执何时产生hook 生命周期中的触发点要理解“Hook success”提醒先要理解 hook 本身。根据仓库中的 system-prompt-hooks-configuration.mdhooks 是在 Claude Code 生命周期特定节点自动运行的命令。Hook 通过 settings 文件用户级~/.claude/settings.json→ 项目级.claude/settings.json→ 本地级.claude/settings.local.json→ 托管策略中的hooks键配置基本结构如下{ hooks: { EVENT_NAME: [ { matcher: ToolName|OtherTool, hooks: [ { type: command, command: your-command-here, timeout: 60, statusMessage: Running... } ] } ] } }仓库文档列出的 hook 事件system-prompt-hooks-configuration.mdEventMatcherPurposePermissionRequestTool nameRun before permission promptPreToolUseTool nameRun before tool, can blockPostToolUseTool nameRun after successful toolPostToolUseFailureTool nameRun after tool failsNotificationNotification typeRun on notificationsStop-Run when Claude stops (including clear, resume, compact)PreCompactmanual/autoBefore compactionPostCompactmanual/autoAfter compaction (receives summary)UserPromptSubmit-When user submitsSessionStart-When session startsHook 类型有三种command执行 shell 命令、prompt调用 LLM 评估条件仅限 PreToolUse/PostToolUse/PermissionRequest、agent运行带工具的 agent同样仅限上述三个工具事件。其中command类型是最常见、也是唯一会产生“成功/失败”回执差异的类型——“Hook success”提醒针对的就是一个 command hook 以退出码 0 正常结束的场景。作为对照prompt/agent类型 hook 的结果由 LLM 评估或 agent 执行决定而非命令退出码。三、ATTACHMENT_OBJECT 变量解析成功回执的数据来源模板正文只使用一个变量对象ATTACHMENT_OBJECT。结合仓库中 skill-doctor-slash-command.md 对转录日志结构的描述hook 运行记录在转录中的形态为{ type: attachment, attachment: { type: hook_success | hook_non_blocking_error | hook_error_during_execution | hook_cancelled, hookName: ..., hookEvent: ..., command: ..., durationMs: ... } }也就是说ATTACHMENT_OBJECT实际由运行时填充的 hook 回执数据构成其中与本模板直接相关的字段包括字段含义在本模板中的用途hookNamehook 的配置名称用于在多个 hook 中区分来源渲染为... hook success: ...的前缀contenthook 命令成功执行后的输出内容stdout被拼接到提醒正文渲染为hook success:之后的完整内容hookEvent触发该 hook 的生命周期事件如PostToolUse未在本模板中使用但存在于回执对象中供诊断command实际执行的命令字符串未在本模板中使用供错误排查与审计durationMshook 执行耗时毫秒未直接渲染但被 /doctor 等诊断流程采集特别注意content只是“成功回执”专属的插值字段对照仓库中其他三个 hook 类提醒模板可以发现每个模板渲染的字段不同system-reminder-hook-blocking-error.md渲染hookName与blockingError.command、blockingError.blockingError对应hook_error_during_execution一类阻塞错误system-reminder-hook-additional-context.md渲染hookName与content.join(\n)多行内容逐行拼接对应 hook 通过 JSON 输出hookSpecificOutput.additionalContext向模型回注额外上下文system-reminder-hook-stopped-continuation.md渲染hookName与message对应 hook 通过continue: false停止模型继续执行的情况。由此可见“Hook success”模板在整个系统提醒体系中扮演“正向回执”角色成功与失败、阻塞、停止、附加上下文等不同结局各自由独立模板承载模型据此区分 hook 事件的不同性质避免把失败消息误读为成功也避免把成功输出误判为错误。四、控制成功消息的呈现hook 的 JSON 输出字段Hook 成功执行时其 stdout 如果是一段 JSONClaude Code 会解析其中的控制字段来改变“成功回执”的呈现与后续行为。仓库中的 system-prompt-hooks-configuration.md 给出了完整的输出契约{ systemMessage: Warning shown to user in UI, continue: false, stopReason: Message shown when blocking, suppressOutput: false, decision: block, reason: Explanation for decision, hookSpecificOutput: { hookEventName: PostToolUse, additionalContext: Context injected back to model } }各字段对“成功回执”的影响systemMessage所有 hook 可用在 UI 中向用户显示一条消息。成功 hook 若返回该字段用户的终端界面会出现提示但不会改变模型的回执模板内容continue默认true置为false表示阻塞/停止——此时不再走“hook success”提醒而是触发 system-reminder-hook-stopped-continuation.md 的停止提醒suppressOutput默认false置为true可隐藏 stdout使成功输出不出现在转录中——这解释了/doctor文档中“成功但空输出的 hook 从不持久化到转录”的另一面即使有输出只要 hook 主动抑制转录中也不会有痕迹hookSpecificOutput.additionalContext成功 hook 借此把额外文本回注模型上下文此时除 success 提醒外还会触发 system-reminder-hook-additional-context.md 的附加上下文提醒。因此对同一次 hook 成功执行模型可能同时看到多条提醒标准的hook success回执 用户可见的systemMessage 注入的additionalContext。区分这三者正是解读这些模板文件的关键。五、转录与诊断视角hook_success 记录如何被复用成功回执不仅进入当前上下文还会以hook_success类型的 attachment 条目持久化到会话转录文件~/.claude/projects/sanitized-cwd/*.jsonl中。仓库中的 skill-doctor-slash-command.md 的“Check 5 — slow hooks”章节展示了这套数据的实际用途耗时聚合按hookName/hookEvent聚合转录中 attachment 条目的durationMs典型值与最差值用于定位“频繁且缓慢”的 hook经验阈值对每个工具调用/每次提示都会触发的 PreToolUse、PostToolUse、UserPromptSubmit 类事件典型耗时超过 2 秒即视为慢SessionStart 或 Stop 类低频事件阈值放宽到 10 秒空输出不入转录成功且无输出的 hook 不会在转录中留下任何记录因此“转录中零记录”不等于“hook 从未触发”——排查静默 hook 需要直接检查 settings 中配置的command字符串而非依赖转录超时判定若 hook 因执行超时被取消对应条目类型为hook_cancelled且携带timedOut: true与timeoutMs此时durationMs约等于timeoutMs可视作耗时下限——即使它从未记录过一次hook_success反复超时的 hook 仍是“最坏的阻塞型 hook”。这意味着 Hook Success 提醒模板不仅是上下文消息其背后的ATTACHMENT_OBJECT数据结构hookName、hookEvent、command、durationMs同时构成 Claude Code 自我诊断的重要数据源。六、实战配置一个能产生成功回执的 hook以“代码写入后自动格式化”为例取自 system-prompt-hooks-configuration.md 的 Common Patterns将如下配置写入.claude/settings.json{ hooks: { PostToolUse: [{ matcher: Write|Edit, hooks: [{ type: command, command: jq -r .tool_response.filePath // .tool_input.file_path | { read -r f; prettier --write \$f\; } 2/dev/null || true }] }] } }每次Write/Edit工具成功执行后该 hook 都会运行若prettier输出格式化结果你便会在下一轮上下文看到类似这样的 success 回执PostToolUseFormatter hook success: /path/to/file.ts 120ms若想给用户一个明确的进度提示而非静默执行可结合statusMessage字段若希望格式化输出被抑制、避免污染转录可让命令输出{suppressOutput: true}。要验证 hook 是否真的触发可用claude doctor或/doctor技能的 Check 5扫描转录中的hook_success条目按hookName/hookEvent查看执行次数与耗时。七、小结Claude Code 的 Hook Success 系统提醒system-reminder-hook-success.md是一张简洁的“成功回执”模板以${ATTACHMENT_OBJECT.hookName}标识来源、以${ATTACHMENT_OBJECT.content}携带输出配合仓库中的 system-prompt-hooks-configuration.md 可知其完整生命周期契约对照 system-reminder-hook-blocking-error.md、system-reminder-hook-additional-context.md、system-reminder-hook-stopped-continuation.md 可厘清成功、失败、附加上下文与停止四类回执的边界最后借助 skill-doctor-slash-command.md 的转录 schema 与慢 hook 诊断逻辑可将成功回执背后的hook_success记录用于实际的性能排查。理解这一模板等于理解 Claude Code 钩子体系的“正向反馈通道”——它是 hook 从“只管执行”走向“可观测、可诊断、可交互”的关键一环。赞分享文档提示工程人工智能【免费下载链接】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点击查看免费下载相关推荐Worktrunk Hook 系统实践Git Worktree 生命周期钩子的配置、模板引擎与执行原理Worktrunk Hook 系统实践Git Worktree 生命周期钩子的配置、模板引擎与执行原理 Worktrunk 的 Hook 是在 worktre开发工具CLI版本控制AI Agent人工智能Claude Code /loop tick 机制深度解析从 loop.md 任务执行到动态自步调循环的系统提示词设计Claude Code /loop tick 机制深度解析从 loop.md 任务执行到动态自步调循环的系统提示词设计 /loop tick 是 Claude文档提示工程人工智能Claude Code Artifact 评论快速确认机制解析系统提示词如何实现秒级回执与异步回复流水线Claude Code Artifact 评论快速确认机制解析系统提示词如何实现秒级回执与异步回复流水线 导读 本文围绕 system prompts/sys文档提示工程人工智能创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考