ECC C 钩子体系实战指南构建提交前质量闸门与 CI 流水线【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本指南以 ECCEverything Claude Code仓库中 docs/ja-JP/rules/cpp/hooks.md 为骨架系统讲解如何在 C 项目中落地提交前检查 CI 质量流水线的钩子机制。你将掌握 clang-format / clang-tidy / cppcheck / CMake / CTest 五件套的完整命令与编排顺序理解 ECC 的通用钩子类型PreToolUse / PostToolUse / Stop如何在真实的 hooks/hooks.json 与 rules/cpp 规则体系中生效并能直接复制一套可运行的质量闸门方案。文档定位与适用范围该文档是 ECC 规则体系中 C 语言子规则的一部分位于 docs/ja-JP/rules/cpp/hooks.md属于对通用规则 rules/common/hooks.md 的 C 专属扩展。文档头部通过paths字段声明了规则的适用文件范围paths: - **/*.cpp - **/*.hpp - **/*.cc - **/*.hh - **/*.cxx - **/*.h - **/CMakeLists.txt这七个 glob 模式覆盖了 C 常见的源码扩展名.cpp、.cc、.cxx与头文件扩展名.hpp、.hh、.h并额外包含构建脚本CMakeLists.txt。这意味着任何涉及这些文件的改动都应触发本钩子规则中的质量检查而不只是针对某一种特定的编译器方言。在 ECC 的规则体系里同目录还配套了 rules/cpp/coding-style.md编码风格、rules/cpp/patterns.md设计模式、rules/cpp/security.md安全规范、rules/cpp/testing.md测试规范钩子规则与它们共同构成完整的 C 开发约束闭环——钩子负责何时检查其余规则负责检查什么。通用钩子系统三种核心钩子类型在深入 C 具体命令之前先明确 ECC 所基于的钩子模型。根据 rules/common/hooks.md钩子系统包含三种核心类型PreToolUse工具执行之前触发用于参数校验、输入验证、权限拦截PostToolUse工具执行之后触发用于自动格式化、结果检查Stop会话一次 Agent 响应结束时触发用于最终验证。从 hooks/hooks.json 可以看到这套模型在 ECC 仓库中的真实落地PreToolUse阶段注册了 Bash 预检分发器pre:bash:dispatcher、文档文件警告、配置保护pre:config-protection、事实强制门pre:edit-write:gateguard-fact-force等钩子PostToolUse阶段通过posttooluse-dispatcher.js同步/异步分发器执行检查Stop阶段则批量执行格式化与类型检查stop:format-typecheck、会话状态持久化stop:session-end、成本追踪stop:cost-tracker等。把这一模型映射到 C 开发场景可以这样理解钩子类型时机C 场景示例PreToolUse执行任何工具/命令之前拦截对src/*.cpp的写入先提示运行 clang-formatPostToolUse工具执行完成后自动对刚编辑的头文件运行格式校验Stop一轮修改结束时汇总本轮改动的所有文件统一跑 clang-tidy 与测试这种分阶段检查的设计目的是把反馈前移越早发现问题修复成本越低。C 钩子文档建议把检查放在提交之前commit 前本质上是把 PostToolUse/Stop 阶段的质量闸门前移到版本控制边界上。提交前钩子四条命令构建本地质量闸门文档给出的核心实操是四条在提交 C 改动前必须运行的检查命令# 格式检查 clang-format --dry-run --Werror src/*.cpp src/*.hpp # 静态分析 clang-tidy src/*.cpp -- -stdc17 # 构建 cmake --build build # 测试 ctest --test-dir build --output-on-failure逐条拆解各命令的语义与关键参数1. 格式检查clang-format --dry-run --Werror src/*.cpp src/*.hpp--dry-run只输出需要格式化的差异不实际改写文件属于检查模式--Werror将格式问题视为错误使命令以非零退出码结束从而让钩子/CI 能够拦截参数src/*.cpp src/*.hpp明确检查范围。实际项目中建议改用仓库根目录下的.clang-format配置文件驱动风格这样所有开发者使用同一套格式标准避免风格争论。对照 rules/cpp/coding-style.md 的格式规范使用 clang-format不要争论风格提交前运行clang-format -i file——-i是就地改写模式用于修复--dry-run --Werror是校验模式用于门禁。两者一修一验配合使用。2. 静态分析clang-tidy src/*.cpp -- -stdc17clang-tidy是 LLVM 官方的 C 静态分析工具能检测现代 C 的错误、性能问题与风格问题--之后的部分是传给编译器的参数-stdc17声明以 C17 标准解析代码。若项目使用 C20/23应相应调整详见 rules/cpp/coding-style.md 中的 Modern C (C17/20/23) 说明更严格的用法可以显式指定检查集例如 agents/cpp-reviewer.md 中给出的clang-tidy --checks*,-llvmlibc-* src/*.cpp -- -stdc17启用全部检查并排除 LLVM libc 相关规则。3. 构建cmake --build build前提是已用cmake -B build或传统写法cmake ..完成配置生成build目录cmake --build build是跨平台、跨生成器的构建入口无论底层是 Makefile 还是 Ninja 都无需关心具体工具链命令。4. 测试ctest --test-dir build --output-on-failurectest是 CMake 自带的测试驱动--test-dir build指定测试目录--output-on-failure让失败的测试输出详细诊断信息便于定位问题。这四条命令的编排顺序是有讲究的先做零成本的格式与静态分析秒级再编译分钟级最后跑测试。按照 rules/cpp/testing.md 的规范C 测试框架采用 GoogleTestgtest/gmock配合 CMake/CTest因此ctest是这套框架的标准测试入口。推荐 CI 流水线五阶段检查文档给出了推荐的 CI 流水线编排将本地钩子扩展为持续集成中的固定阶段clang-format— 格式检查clang-tidy— 静态分析cppcheck— 追加分析cmake 构建— 编译ctest— 使用 sanitizer 运行测试前四阶段与本地钩子一一对应新增的cppcheck是第三个工具它是一款独立的开源静态分析工具擅长检测未定义行为、空指针解引用、内存泄漏等缺陷与 clang-tidy 形成互补clang-tidy 偏重 LLVM 生态与现代 C 规则cppcheck 偏重跨编译器的通用缺陷模式。关于 cppcheck 的用法rules/cpp/security.md 提供了参考命令cppcheck --enableall src/--enableall会开启包括性能、可移植性、风格在内的全部检查类别。而 agents/cpp-reviewer.md 给出的实战变体是cppcheck --enableall --suppressmissingIncludeSystem src/增加了--suppressmissingIncludeSystem来抑制系统头文件缺失导致的误报更适合在 CI 中无噪声运行。最后一步使用 sanitizer 运行测试运行 sanitizer 的 ctest是 CI 流水线与本地钩子最大的差异点其配置方式在下一节展开。深入 C 测试与 sanitizer 配置流水线第五步要求用 sanitizer 运行测试这需要在 CMake 配置阶段注入编译/链接标志。根据 rules/cpp/testing.md标准做法是cmake -DCMAKE_CXX_FLAGS-fsanitizeaddress,undefined ..这条命令同时启用了AddressSanitizer检测越界访问、use-after-free、内存泄漏和UndefinedBehaviorSanitizer检测有符号整数溢出、空指针解引用、未定义行为与 rules/cpp/security.md 中Always initialize variables / Avoid signed integer overflow / Never dereference null or dangling pointers的安全规范一一对应——sanitizer 正是把这些规范从纸面约定变成机器可判定的失败。如果把 sanitizer 与覆盖率结合起来rules/cpp/testing.md 还给出了完整的覆盖率采集流程cmake -DCMAKE_CXX_FLAGS--coverage -DCMAKE_EXE_LINKER_FLAGS--coverage .. cmake --build . ctest --output-on-failure lcov --capture --directory . --output-file coverage.info--coverage标志等价于 gcc/g 的-fprofile-arcs -ftest-coverage让编译器生成覆盖率数据测试跑完后用lcov捕获并输出coverage.info再配合genhtml即可生成可视化报告。推荐在 CI 中分两个 job 并行执行一个 job 跑普通构建 ctest快速反馈另一个 job 跑 sanitizer 构建 ctest深度检查避免 sanitizer 的运行时开销拖慢主流水线。规则体系的源码级印证上述钩子规则并非孤立文档而是 ECC 仓库中可运行机制的一部分。以下证据链可以说明钩子规则与 Agent 的联动专用审查 Agent agents/cpp-reviewer.md 的职责定义中明确要求在评审 C 改动时运行git diff -- *.cpp *.hpp *.cc *.hh *.cxx *.h查看变更、运行clang-tidy和cppcheck若可用并给出了与 rules/cpp/security.md 一致的诊断命令集。其Approve / Warning / Block三级审批标准CRITICAL/HIGH 问题即 Block正是把钩子检查结果转化为决策依据的体现。钩子配置文件真实存在仓库根目录的 hooks/hooks.json 展示了 PreToolUse、PostToolUse、Stop、SessionStart、SessionEnd 等钩子生命周期的完整注册方式。C 钩子文档所倡导的提交前检查可以在此基础上通过自定义 matcher如*.cpp注册为 PreToolUse 钩子实现 Agent 每次触碰 C 文件前的自动校验。构建解析 Agent 支持仓库还提供cpp-build-resolverAgent 与cpp-build命令见 commands/cpp-build.md与 CMake/CTest 构建链路配套说明 C 支持是仓库中被工程化对待的一等公民。多语言文档一致性docs/ja-JP/rules/cpp/hooks.md 与英文原版 rules/cpp/hooks.md 内容一一对应规则在全球化文档体系如 docs/zh-CN/rules/cpp/hooks.md中同步维护保证不同语言环境下的 Agent 行为一致。落地建议与适用前提将本指南落地到实际项目时注意以下前提与边界工具链依赖上述命令依赖 LLVM 工具链clang-format、clang-tidy、CMake≥3.0 以支持--test-dir、CTest 与可选的 cppcheck需在开发机与 CI 环境中预先安装若使用 GCC 工具链clang 系工具仍可单独安装使用但clang-tidy对部分 GCC 专属扩展的解析可能受限。版本参数调整-stdc17需与项目实际标准匹配若项目已用 C20/23请同步修改否则 clang-tidy 可能误报或漏报。本地钩子与 CI 的分工本地钩子提交前四命令追求快速反馈CI 流水线五阶段 sanitizer追求完整覆盖两者共用同一组命令保证本地能过、CI 必过。sanitizer 的取舍sanitizer 会显著增加运行时开销通常 1.52 倍且有内存占用放大建议在 CI 独立 job 中运行而非默认本地调试构建。规则联动钩子只管何时执行检查标准由 rules/cpp/coding-style.md、rules/cpp/security.md、rules/cpp/patterns.md 定义配置项目时建议四份规则一起导入避免有门禁无标准。通过以上配置你将获得一条从本地提交前校验到CI 五阶段质量流水线的完整 C 质量防线格式、静态分析、编译、测试、内存安全五个维度层层把关且全部由可复制、可审计的命令驱动。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ECC C++ 钩子体系实战指南：构建提交前质量闸门与 CI 流水线
ECC C 钩子体系实战指南构建提交前质量闸门与 CI 流水线【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本指南以 ECCEverything Claude Code仓库中 docs/ja-JP/rules/cpp/hooks.md 为骨架系统讲解如何在 C 项目中落地提交前检查 CI 质量流水线的钩子机制。你将掌握 clang-format / clang-tidy / cppcheck / CMake / CTest 五件套的完整命令与编排顺序理解 ECC 的通用钩子类型PreToolUse / PostToolUse / Stop如何在真实的 hooks/hooks.json 与 rules/cpp 规则体系中生效并能直接复制一套可运行的质量闸门方案。文档定位与适用范围该文档是 ECC 规则体系中 C 语言子规则的一部分位于 docs/ja-JP/rules/cpp/hooks.md属于对通用规则 rules/common/hooks.md 的 C 专属扩展。文档头部通过paths字段声明了规则的适用文件范围paths: - **/*.cpp - **/*.hpp - **/*.cc - **/*.hh - **/*.cxx - **/*.h - **/CMakeLists.txt这七个 glob 模式覆盖了 C 常见的源码扩展名.cpp、.cc、.cxx与头文件扩展名.hpp、.hh、.h并额外包含构建脚本CMakeLists.txt。这意味着任何涉及这些文件的改动都应触发本钩子规则中的质量检查而不只是针对某一种特定的编译器方言。在 ECC 的规则体系里同目录还配套了 rules/cpp/coding-style.md编码风格、rules/cpp/patterns.md设计模式、rules/cpp/security.md安全规范、rules/cpp/testing.md测试规范钩子规则与它们共同构成完整的 C 开发约束闭环——钩子负责何时检查其余规则负责检查什么。通用钩子系统三种核心钩子类型在深入 C 具体命令之前先明确 ECC 所基于的钩子模型。根据 rules/common/hooks.md钩子系统包含三种核心类型PreToolUse工具执行之前触发用于参数校验、输入验证、权限拦截PostToolUse工具执行之后触发用于自动格式化、结果检查Stop会话一次 Agent 响应结束时触发用于最终验证。从 hooks/hooks.json 可以看到这套模型在 ECC 仓库中的真实落地PreToolUse阶段注册了 Bash 预检分发器pre:bash:dispatcher、文档文件警告、配置保护pre:config-protection、事实强制门pre:edit-write:gateguard-fact-force等钩子PostToolUse阶段通过posttooluse-dispatcher.js同步/异步分发器执行检查Stop阶段则批量执行格式化与类型检查stop:format-typecheck、会话状态持久化stop:session-end、成本追踪stop:cost-tracker等。把这一模型映射到 C 开发场景可以这样理解钩子类型时机C 场景示例PreToolUse执行任何工具/命令之前拦截对src/*.cpp的写入先提示运行 clang-formatPostToolUse工具执行完成后自动对刚编辑的头文件运行格式校验Stop一轮修改结束时汇总本轮改动的所有文件统一跑 clang-tidy 与测试这种分阶段检查的设计目的是把反馈前移越早发现问题修复成本越低。C 钩子文档建议把检查放在提交之前commit 前本质上是把 PostToolUse/Stop 阶段的质量闸门前移到版本控制边界上。提交前钩子四条命令构建本地质量闸门文档给出的核心实操是四条在提交 C 改动前必须运行的检查命令# 格式检查 clang-format --dry-run --Werror src/*.cpp src/*.hpp # 静态分析 clang-tidy src/*.cpp -- -stdc17 # 构建 cmake --build build # 测试 ctest --test-dir build --output-on-failure逐条拆解各命令的语义与关键参数1. 格式检查clang-format --dry-run --Werror src/*.cpp src/*.hpp--dry-run只输出需要格式化的差异不实际改写文件属于检查模式--Werror将格式问题视为错误使命令以非零退出码结束从而让钩子/CI 能够拦截参数src/*.cpp src/*.hpp明确检查范围。实际项目中建议改用仓库根目录下的.clang-format配置文件驱动风格这样所有开发者使用同一套格式标准避免风格争论。对照 rules/cpp/coding-style.md 的格式规范使用 clang-format不要争论风格提交前运行clang-format -i file——-i是就地改写模式用于修复--dry-run --Werror是校验模式用于门禁。两者一修一验配合使用。2. 静态分析clang-tidy src/*.cpp -- -stdc17clang-tidy是 LLVM 官方的 C 静态分析工具能检测现代 C 的错误、性能问题与风格问题--之后的部分是传给编译器的参数-stdc17声明以 C17 标准解析代码。若项目使用 C20/23应相应调整详见 rules/cpp/coding-style.md 中的 Modern C (C17/20/23) 说明更严格的用法可以显式指定检查集例如 agents/cpp-reviewer.md 中给出的clang-tidy --checks*,-llvmlibc-* src/*.cpp -- -stdc17启用全部检查并排除 LLVM libc 相关规则。3. 构建cmake --build build前提是已用cmake -B build或传统写法cmake ..完成配置生成build目录cmake --build build是跨平台、跨生成器的构建入口无论底层是 Makefile 还是 Ninja 都无需关心具体工具链命令。4. 测试ctest --test-dir build --output-on-failurectest是 CMake 自带的测试驱动--test-dir build指定测试目录--output-on-failure让失败的测试输出详细诊断信息便于定位问题。这四条命令的编排顺序是有讲究的先做零成本的格式与静态分析秒级再编译分钟级最后跑测试。按照 rules/cpp/testing.md 的规范C 测试框架采用 GoogleTestgtest/gmock配合 CMake/CTest因此ctest是这套框架的标准测试入口。推荐 CI 流水线五阶段检查文档给出了推荐的 CI 流水线编排将本地钩子扩展为持续集成中的固定阶段clang-format— 格式检查clang-tidy— 静态分析cppcheck— 追加分析cmake 构建— 编译ctest— 使用 sanitizer 运行测试前四阶段与本地钩子一一对应新增的cppcheck是第三个工具它是一款独立的开源静态分析工具擅长检测未定义行为、空指针解引用、内存泄漏等缺陷与 clang-tidy 形成互补clang-tidy 偏重 LLVM 生态与现代 C 规则cppcheck 偏重跨编译器的通用缺陷模式。关于 cppcheck 的用法rules/cpp/security.md 提供了参考命令cppcheck --enableall src/--enableall会开启包括性能、可移植性、风格在内的全部检查类别。而 agents/cpp-reviewer.md 给出的实战变体是cppcheck --enableall --suppressmissingIncludeSystem src/增加了--suppressmissingIncludeSystem来抑制系统头文件缺失导致的误报更适合在 CI 中无噪声运行。最后一步使用 sanitizer 运行测试运行 sanitizer 的 ctest是 CI 流水线与本地钩子最大的差异点其配置方式在下一节展开。深入 C 测试与 sanitizer 配置流水线第五步要求用 sanitizer 运行测试这需要在 CMake 配置阶段注入编译/链接标志。根据 rules/cpp/testing.md标准做法是cmake -DCMAKE_CXX_FLAGS-fsanitizeaddress,undefined ..这条命令同时启用了AddressSanitizer检测越界访问、use-after-free、内存泄漏和UndefinedBehaviorSanitizer检测有符号整数溢出、空指针解引用、未定义行为与 rules/cpp/security.md 中Always initialize variables / Avoid signed integer overflow / Never dereference null or dangling pointers的安全规范一一对应——sanitizer 正是把这些规范从纸面约定变成机器可判定的失败。如果把 sanitizer 与覆盖率结合起来rules/cpp/testing.md 还给出了完整的覆盖率采集流程cmake -DCMAKE_CXX_FLAGS--coverage -DCMAKE_EXE_LINKER_FLAGS--coverage .. cmake --build . ctest --output-on-failure lcov --capture --directory . --output-file coverage.info--coverage标志等价于 gcc/g 的-fprofile-arcs -ftest-coverage让编译器生成覆盖率数据测试跑完后用lcov捕获并输出coverage.info再配合genhtml即可生成可视化报告。推荐在 CI 中分两个 job 并行执行一个 job 跑普通构建 ctest快速反馈另一个 job 跑 sanitizer 构建 ctest深度检查避免 sanitizer 的运行时开销拖慢主流水线。规则体系的源码级印证上述钩子规则并非孤立文档而是 ECC 仓库中可运行机制的一部分。以下证据链可以说明钩子规则与 Agent 的联动专用审查 Agent agents/cpp-reviewer.md 的职责定义中明确要求在评审 C 改动时运行git diff -- *.cpp *.hpp *.cc *.hh *.cxx *.h查看变更、运行clang-tidy和cppcheck若可用并给出了与 rules/cpp/security.md 一致的诊断命令集。其Approve / Warning / Block三级审批标准CRITICAL/HIGH 问题即 Block正是把钩子检查结果转化为决策依据的体现。钩子配置文件真实存在仓库根目录的 hooks/hooks.json 展示了 PreToolUse、PostToolUse、Stop、SessionStart、SessionEnd 等钩子生命周期的完整注册方式。C 钩子文档所倡导的提交前检查可以在此基础上通过自定义 matcher如*.cpp注册为 PreToolUse 钩子实现 Agent 每次触碰 C 文件前的自动校验。构建解析 Agent 支持仓库还提供cpp-build-resolverAgent 与cpp-build命令见 commands/cpp-build.md与 CMake/CTest 构建链路配套说明 C 支持是仓库中被工程化对待的一等公民。多语言文档一致性docs/ja-JP/rules/cpp/hooks.md 与英文原版 rules/cpp/hooks.md 内容一一对应规则在全球化文档体系如 docs/zh-CN/rules/cpp/hooks.md中同步维护保证不同语言环境下的 Agent 行为一致。落地建议与适用前提将本指南落地到实际项目时注意以下前提与边界工具链依赖上述命令依赖 LLVM 工具链clang-format、clang-tidy、CMake≥3.0 以支持--test-dir、CTest 与可选的 cppcheck需在开发机与 CI 环境中预先安装若使用 GCC 工具链clang 系工具仍可单独安装使用但clang-tidy对部分 GCC 专属扩展的解析可能受限。版本参数调整-stdc17需与项目实际标准匹配若项目已用 C20/23请同步修改否则 clang-tidy 可能误报或漏报。本地钩子与 CI 的分工本地钩子提交前四命令追求快速反馈CI 流水线五阶段 sanitizer追求完整覆盖两者共用同一组命令保证本地能过、CI 必过。sanitizer 的取舍sanitizer 会显著增加运行时开销通常 1.52 倍且有内存占用放大建议在 CI 独立 job 中运行而非默认本地调试构建。规则联动钩子只管何时执行检查标准由 rules/cpp/coding-style.md、rules/cpp/security.md、rules/cpp/patterns.md 定义配置项目时建议四份规则一起导入避免有门禁无标准。通过以上配置你将获得一条从本地提交前校验到CI 五阶段质量流水线的完整 C 质量防线格式、静态分析、编译、测试、内存安全五个维度层层把关且全部由可复制、可审计的命令驱动。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考