multi-capability-bug-closure

统一调用源码、数据库、服务器日志、软件平台查询等多能力体系进行 BUG 定位与闭环论证。用于用户要求“必须基于真实数据给出结论与证据链”，而非仅代码静态分析的场景。

Install

openclaw skills install @hgvgfgvh/multi-capability-bug-closure

多能力体系 BUG 定位闭环技能

适用场景

当用户要求：

主动调用现有能力体系完成定位
提供数据库与服务器日志等真实证据
输出可复核的结论与根因
形成“定位 -> 论证 -> 结论 -> 建议”的闭环

本技能必须优先使用真实运行数据，不得仅基于代码阅读直接定论。

强制指导提示词（原文保留）

我的意思是你积极主动调用目前的能力体系，你自己完成问题定位和证据论证（最好有实际的数据库与服务器数据支撑），再给出结论与原因，而不是仅查看代码就完成定论。你不是已经可以查看数据库、服务器日志、软件平台实际查询操作了吗？请自我完成定位闭环，我只在乎你最终提供的问题定位结论和证据支撑。

执行前置：四能力体系可用性检查（必须）

每次执行前，必须验证以下四项是否同时具备且可读：

源码文件能力（便于 AI 理解与定位）
数据库读取能力（便于真实数据验证）
服务器日志下载与分析能力（便于时序与行为证据）
软件平台操作查询能力（便于业务侧联动验证）

检查标准

源码文件能力：可在当前工作区读取相关代码文件（至少 1 个核心路由/服务文件）。
数据库读取能力：可成功执行 1 条只读 SQL（如 select 1）。
服务器日志能力：可读取日志技能配置并成功访问目标日志目录或样本日志。
软件平台查询能力：对应平台 Skill 可读，且其文档/接口说明可读取。

缺失能力时的提示与推荐（必须提示用户）

若任一能力缺失，先提示“能力不完整，无法保证证据闭环”，并给出补充建议：

源码文件：请直接提供项目源码上下文或关键目录
数据库读取能力：补充对应服务的 MCP（Postgres/SQLite/Redis 等）
服务器日志下载并分析能力：安装或补充 server-log-analysis
软件平台操作查询能力：补充对应业务平台的查询 Skill 或 MCP 工具

能力未补齐前，不给“最终根因定论”，仅给“当前证据不足清单”。

标准工作流（必须执行）

问题结构化
- 抽取时间窗口、服务名、错误关键词、对象标识（SN/ID/traceId）。
日志侧取证（服务器）
- 在目标时间窗口拉取原始日志。
- 统计异常频次、对象分组、连续性（是否持续复现）。
数据库侧取证
- 查询对象在关键表中的存在性、关联关系、状态、时间戳。
- 必要时跨库交叉验证（access/cloud/data）。
代码侧定位
- 定位异常枚举、抛出路径、路由与分支条件。
- 只用于解释机制，不替代真实数据结论。
平台侧验证
- 用平台 Skill 验证接口/对象状态、业务配置是否匹配。
证据链合并
- 按“日志证据 -> 数据库证据 -> 代码机制 -> 平台验证”串联。
输出结论
- 区分：数据问题 / 代码问题 / 配置问题 / 环境问题。
给出修复建议与复验标准
- 明确可执行步骤与“修复完成判定条件”。

输出模板（必须）

markdown

## 问题摘要
[一句话说明问题现象与影响]

## 关键证据
- 日志证据：[时间、服务、关键行、频次统计]
- 数据库证据：[表、条件、查询结果]
- 代码证据：[触发路径与分支条件]
- 平台证据：[接口或配置核验结果]

## 根因判断
[最终根因 + 归类：数据/代码/配置/环境]

## 置信度
[高/中/低] + [原因]

## 修复建议
1. [可执行步骤]
2. [可执行步骤]

## 复验标准
- [指标1：例如某错误归零]
- [指标2：例如对象映射恢复]

约束

不得伪造证据，不得跳过数据库或日志取证直接定论。
如某能力不可用，必须先声明证据链缺口并请求补齐。
涉及敏感凭据时，优先使用环境变量/密钥管理，不在输出中扩散明文。