auditlisted

# 审计仓库健康度 输出有证据的治理清单。审计阶段只调查、运行安全诊断、调研和报告，不修改仓库文件或外部系统。 ## 开始 完整读取 `../../references/governance-standard.md`。用户指定了范围或关注点时，以它为边界；没有指定时广泛检查仓库，但只能报告真实覆盖范围，不能声称逐文件审完。 ## 工作流程 1. **建立上下文**：检查仓库规则和工作区状态。还原项目目标、用户、公开行为、技术栈、入口、模块和数据流、测试、构建、部署及活跃开发区域。 2. **建立基线**：运行现有检查和安全的定向诊断。把失败结果作为证据，同时区分环境问题和无关的原有失败。 3. **选择维度**：从治理标准中选择相关维度。明确跳过无关维度，不为凑齐类别制造问题。 4. **验证候选**：追踪代码和数据链路，尽可能复现行为；涉及视觉和交互时检查真实运行界面；无法证明影响的候选必须排除或降为待调查。 5. **调查现成方案**：发现重复建设、低效方案或可以复用的通用能力时，按照治理标准中的“方案检索与外部验证”执行。先用 GitHub MCP 找相关仓库并读取对应源码，再用官方资料核对版本、漏洞、规范和兼容性。 6. **比较并寻找根因**：结合当前仓库约束比较保留、自研和外部方案，评估适配度与迁移成本；合并重复症状，识别处理顺序，并记录应当保留的健康设计。 7. **确定优先级**：只对调查后仍成立的问题，按照实际影响、可能性、范围、紧迫性、置信度、成本和可逆性排序。 ## 输出 开头直接说明： - 仓库画像和审计范围； - 影响最大的已确认问题； - 最值得立即进行的下一项治理； - 可能改变结论的覆盖盲区。 然后按照治理标准中的“发现条目”输出优先清单，把待调查候选与已确认、强证据问题分开。还要包含： - 已执行的检查和复现； - 使用的外部来源及其支持的时效性结论； - 被排除的假设和有意义的健康信号； - 未覆盖区域，以及最能降低不确定性的下一次定向审计。 如果没有证明存在高价值问题，就直接说明，不用代码风格偏好或理论优化填充报告。结尾列出可以交给 `/repo-guardian:improve` 的问题 ID，但本 skill 不开始修改实现。