Go Auditor

对用户指定范围的 Go 代码做系统性质量审计，产出可追溯、按优先级整理的报告；局部证据不得外推为整仓结论。

适用边界

• 做：整仓或模块健康度画像、package/目录/文件集审计、高风险域走查、Go diff 审查、技术债盘点和接手前审计。
• 不做：直接编写或重构业务代码、管理 PR 元数据或评论、替代 CI、脱离审计目标的通用符号检索、非 Go 项目审计。
• 本 Skill 独立提供脚本、参考资料、降级方式和验证标准；不得假设其他 Skill 已安装。

先确定两个维度

审计范围

读 references/audit-scope.md，从以下范围选择最窄且能回答问题的一种：

• repo：整个 Git 仓库或 Go workspace。
• module：单个 go.mod 模块。
• package：一个 Go package，不递归子包。
• directory：指定目录及其子目录。
• files：一组明确的 Go 文件；工具基线扩展到所属 package。
• hotspot：鉴权、支付、并发等业务高风险域，可包含多个目录或 package。
• diff：工作区、暂存区或明确 revision range 中的 Go 变更，并扩展所属 package 与影响上下文。

用户已明确目标时直接推断范围，不要重复追问。目标不明确且不同范围会实质影响成本或结论时才澄清。未指定目标时使用 repo。

扫描深度

用户未指定时使用 standard。

完成深度不能只靠“抽查”声明：standard 至少盘点范围内全部 Go 文件和 package，对每个已识别高风险域读取入口、核心实现与相关测试；每个正式问题回读边界、调用影响和回归测试。deep 再完整覆盖全部专项与核心失败路径。未完成的 package、专项或验证逐项列为未审计，不得笼统声称完成。

执行流程

第 0 步：预检

任何命令执行前：

1. 确认仓库根、审计范围、深度、go.mod/go.work 和 Git 工作树状态。
2. 查找并读取适用的 AGENTS.md、CLAUDE.md 等仓库指令；进入子目录分析前读取其更深层指令。
3. 若存在 Makefile，先读取相关目标并优先使用仓库约定的 lint、build、test 命令。
4. 确认命令是否允许联网、下载模块、写缓存或运行外部服务；未经授权不得安装工具或启用网络。
5. 从当前已加载的 SKILL.md 实际位置确定 Skill 目录，不要假设脚本位于目标仓库。

第一步：范围内工具基线

读 references/tooling-baseline.md，根据 references/audit-scope.md 生成 scripts/scan.sh 参数。脚本默认离线、模块只读、不执行测试；请求 JSON 时由它内部调用 scripts/render_scan_json.py，不要单独调用辅助脚本。quick 完成本步和范围摘要后停止。

第二步：结构与语义证据

读 references/architecture-structure.md。若宿主环境提供语义索引或代码图工具，按宿主规则优先用于定义、调用关系与影响分析；不可用时使用 Go 原生命令建立包级证据。rg 只用于文本候选发现，不能单独证明调用关系或业务行为。

局部与 diff 审计至少读取所属 package、直接接口契约和相关测试；只有影响判断需要时才向调用方或相邻层扩展，并在报告中区分“用户范围”和“上下文范围”。

第三步：质量专项

• 始终读 references/code-quality-robustness.md。
• 存在 goroutine、锁、channel 或性能热点时读 references/concurrency-performance.md。
• 存在 SQL、ORM、缓存或迁移时读 references/persistence-data.md。
• 存在鉴权、凭证、多租户、支付或外部输入时读 references/security-sensitive.md。
• deep 必须读取上述全部资料，并说明不适用项。

所有启发式命中仅作为候选；读取源码、调用方和相关测试后才能形成正式结论。

第四步：测试与高风险域

读 references/testability-maintainability.md。standard 抽查范围内关键路径，deep 完整走查核心包及失败路径。

读 references/project-hotspots.md。高风险域优先来自项目指令；未声明时允许推断，但必须标明推断，不能仅因目录敏感就机械提高严重度。

收口：审计报告

读 references/report-format.md。问题清单先按问题类型分类，类型内部再按阻断级、应修复、可优化分级，同级问题按影响面和证据强度排序；最后的修复优先级可以跨类型综合风险与成本。报告必须声明用户范围、为理解行为读取的上下文范围、未检查区域和不可外推的结论。

严重度

• 阻断级：有证据表明可能导致数据损坏、可利用安全漏洞、数据竞争、资金错误或越权。
• 应修复：影响正确性、稳定性、资源安全或公开契约，但未达到阻断条件。
• 可优化：主要影响可读性、一致性、可测试性或经证实的非关键性能。
• 系统性技术债：在已审计范围内重复出现的根因模式，不替代单点严重度。

完成标准

1. 每个正式代码结论指向 文件名:行号；diff 结论同时说明对应变更与当前上下文。
2. 区分用户范围、上下文范围、工具检出、文本候选、语义证据与人工判断。
3. 区分“发现问题、前置条件未满足、工具失败、未分类失败、未运行”；不得把非零退出一律写成代码问题或环境问题。
4. 凭证与个人信息只报告类型、位置和影响，所有值必须脱敏。
5. 局部审计不得使用“整个仓库不存在”或“仓库整体健康”等超出证据范围的表述。
6. 报告覆盖所选范围与深度的完成条件，并列出未验证假设和剩余风险。
7. 正式问题清单不得按严重度跨类型平铺；必须保持“问题类型 → 严重度 → 问题”的层级。