用途：当 Infrahub 出现故障、报错、升级后异常、提案变更卡住或界面返回 500 时，本技能帮助用户用 OpsMill 官方工具 infrahub-collect 收集一致的诊断材料（日志、配置、版本信息、环境状态），交给 OpsMill 支持或高级工程师排查。它是围绕该二进制工具的操作指引，本身不做根因诊断、不提交 GitHub issue（应交由 infrahub-reporting-issues）、不修改 Infrahub 状态；该工具仅读取。
主要流程：1）先让用户用自己的话描述问题，留意产品名、版本号、报错信息与工作流上下文；2）检查工具是否可用：infrahub-collect version，缺失则按操作系统与架构安装后再验证；3）探测环境：infrahub-collect environment detect，若存在多个 Compose 项目或非默认 K8s 命名空间，则用 infrahub-collect environment list 并通过 --project=<name> 或 --k8s-namespace=<ns> 消歧，无需 Infrahub API token；4）创建诊断包：infrahub-collect create，可按症状附加标志，如性能或 OOM 用 --benchmark、慢或失败的数据库操作用 --include-queries、支持人员要求复现时用 --include-backup；5）分享前审查（用户确认环节）：工具只按已知密钥名（password/secret/token/key）替换为 ********，不会清理日志与查询内容或其他密钥名下的秘密，需引导用户检查 bundle/logs/ 与 bundle/server/ 中的主机名、IP、客户数据等，并获得明确确认；6）通过支持渠道（Discord、Slack、邮件）发送；如需公开提交 issue，转交 infrahub-reporting-issues；如需本地初步分析（堆栈、失败、已知问题匹配），使用 infrahub-analyzing-diagnostics。
限制与注意：降级部署中允许出现不完整的诊断包，create 仍以 0 退出并在清单中记录收集失败，应原样发送，不要手工补缺。禁止执行任何会修改状态的命令（如 docker compose down、kubectl delete），也不要用脚本手工收集日志。不要跳过用户审查环节，不要声称已定位根因。具体安装命令、完整标志说明与环境变量细节见其 reference.md，官方文档可参考 docs.infrahub.app。