该技能用于指导开发者为 cti-expert 仓库贡献代码。仓库包含 6 条硬性规则和一套 vendored 引擎，违反规则时通常不会导致测试失败，而是产生静默故障，因此技能的目标是让改动通过 scripts/audit.sh 以及全部测试，同时不降低安全护栏。
用途 面向需要直接修改 cti-expert 的贡献分支场景：在遵守仓库规则的前提下提交变更，并通过统一的门禁脚本与测试验证。文档说明该文件与 01–08 号文件相互独立，但建议先阅读 04，因为此处需要更新的 DISPATCH 表正是 04 所描述的内容。
开发环境安装 安装命令为： git clone https://github.com/7onez/cti-expert.git && cd cti-expert bash scripts/install-hooks.sh uv venv && uv pip install -r requirements.txt 说明：install-hooks.sh 会安装 git pre-commit 钩子并指向 leakcheck.sh，每个新克隆都必须执行，因为 .git/hooks/ 不被跟踪；缺少该钩子时 RULE 1 仅剩一层防护。venv 用于 audit 第 9 节和需要 SDK 的引擎测试。
唯一门禁：scripts/audit.sh 命令：bash scripts/audit.sh 在没有 .venv 的情况下实际运行会输出 AUDIT: clean，rc=0。该脚本门禁 9 项： §1 泄漏检查（RULE 1），分 diff（本次提交新增行）与 tree（所有已跟踪文本文件）两轮； §2 每个 DISPATCH op 都能解析到真实存在的脚本（RULE 3）； §3–4 collector shim 仍为 re-export，未被反转成副本（RULE 4）； §5 @tool 数量与 CLAUDE.md 记录一致； §6 仓库根目录 py_compile 与测试； §7 hooks.json 注册的所有 hook 路径仍然存在； §8 vendored 引擎测试，仅标准库子集（15 个文件）； §9 需要 claude_agent_sdk 的引擎测试，没有 .venv 时 SKIP。 文档解释 §1 分两轮的原因：diff 轮只能看到刚被触碰的行，而早已潜伏在无人打开文件中的泄漏值会长期存活，文中提到曾有 4 个值以这种方式存活数月；diff 轮也只检查新增行，拒绝删除行曾导致门禁自我锁死。§9 被 SKIP 是真实的陷阱，本地会打印 SKIPPED 提示；CI 在 .github/workflows/audit.yml 中有独立的 engine-tests job，一旦出现 SKIPPED 行即失败。
手动运行测试 命令： for t in tests/test_*.py; do python3 "$t" >/dev/null 2>&1 && echo "PASS $t" || echo "FAIL $t"; done 仓库根目录 10 个测试文件均为零依赖（不需要 pytest），实际运行全部 rc=0。文档逐一列出各测试断言内容，例如 test_hooks.py 有 58 项检查、test_references.py 有 580 项检查、test_indicator_classification.py 覆盖 RULE 5 的分类场景。vendored 引擎另有 intel_engine/tests/ 测试集，run_eval.py 将两个目录都加入路径。
六条规则 RULE 1：绝不将案件数据放入 skill。已跟踪文件只含代码与 tradecraft，不含真实人名、案件基础设施、真实 GA4/GTM/GSC、case ID 或 operator PII，包括注释、fixture、示例中；调查数据只存放在 intel_engine/cases/、knowledge/、MEMORY/、.env（均 gitignore）。唯一例外是经 /reference add 的 FP 记账。需要示例时使用 example.com、G-XXXXXXXXXX、CASE-0001 等占位值；通用公共常量可以保留。 RULE 2：只有一个 case store，位于 $INTEL_HOME/cases/<CASE-ID>/；不要在仓库根目录创建 cases/。 RULE 3：新增工具必须注册到 MCP 表面，需完成四步：在 intel_engine/harness/tools.py 中用 @tool 包装；在 scripts/backend/intel.py 的 DISPATCH 中加一行；更新 CLAUDE.md 中的 @tool 数量（当前 78）；若为 SKILL.md §3 新命令，须映射到真实 DISPATCH op 或 @tool。给既有工具加模式不新建 @tool，只扩展 description。可用 .venv/bin/python intel_engine/harness/mcp_server.py 做 smoke check 或使用 /mcp。 RULE 4：wrapper/collector 漂移必须自愈。5 个 collector 各有一个 canonical 文件和一个 9 行 re-export shim（Windows 安全，不用符号链接），文档给出各 collector 的 canonical 与 shim 对应表。不要反转 shim；移动目录要修正相对深度。harness wrapper 会探测 --help 并过滤不支持的标志，被丢弃的标志会在结果中说明。 RULE 5：修改指示器分类必须带测试。涉及 intel_engine/tools/kb/noise_filters.py（MANAGED_DNS_SUFFIXES、favicon parking、host parking）和 hypothesize.py（_tier() 分类）。uses_nameserver 是有条件的：托管 DNS 授权算 noise，自建 nameserver 属归因证据。任何改动须附分类检查，至少覆盖一个托管 provider 和一个自建 nameserver。 RULE 6：harness 层是 skill 的一部分。leakguard.py 不得自行复制正则，必须 shell 调 leakcheck.sh；新增出站能力要往 hooks/references/outbound_actions.json 加一行；不要为关闭提示而放宽护栏，优先收紧 flag_required 或精确匹配。
同步 vendored 引擎 上游为 intelligence_assist（GitHub 0xdefh/Intelligence-AS），单向同步，cti-expert 从不写回。不能简单复制，因为 vendored 树含十几个 cti-expert 有意打补丁的文件，覆盖会造成静默故障（文中举了 wp_common 查找 .env 的层级、pivot_extract 的 reverse-WHOIS 默认值两个例子）。方法是按 blob 身份找分叉：hash 每个 vendored 文件，与上游同路径的 blob 比对，分为纯副本（可安全覆盖）、cti-expert 补丁（需三方合并）、仅 cti-expert 存在（必须保留，禁止 rsync --delete）。对每个补丁按历史 blob 距离最小的 diff 选 merge base，再 git merge-file。另有三点注意：排除 .venv、pycache、cases/、knowledge/、MEMORY/、.env；各组件 SKILL.md 改名为 SKILL.reference.md，仓库根目录只保留一个 SKILL.md；zsh 不对未加引号的参数做分词，排除列表须妥善处理。同步后需验证 audit.sh、两套测试、mcp_server.py tools/list 以及 pipeline open 命令。
适用场景与限制 适用于直接参与 cti-expert 仓库开发的贡献者，覆盖环境搭建、规则约束、门禁审计、测试运行、引擎同步和 PR 前检查。文档仅说明本地脚本与 CI 工作流的检查方式，未提供其他平台、收费或效果方面的信息；具体功能行为以仓库实际代码与文档为准，本文所述部分测试数量与工具计数（如 78 个 @tool）为资料中给出的数值。