360 Secure SkillHub
360 安全技能中心

multi-capability-bug-closure-en

核心功能:需先验证源码、数据库、服务器日志、软件平台四类访问能力完备,再按标准流程整合多维度证据链,生成带实据的BUG根因结论、分类、修复建议及验证标准,不依赖静态代码分析。典型场景:用户需基于真实运行数据的BUG全闭环排查时使用。输入为BUG问题描述,输出为指定模板的Markdown报告;若能力缺失将告知补充方向。

hgvgfgvh
hgvgfgvh
热度 35.51
最近更新 2026-05-11 17:35:27
分类:开发依赖:读写文件 / MCP 服务 / 第三方 API / 内部调用大模型应用场景:调试排错 / 数据处理 / 报告撰写 / DevOps

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add multi-capability-bug-closure-en
Metadata
name
multi-capability-bug-closure
description
Unified bug investigation and closure by combining source code, database, server logs, and software platform query capabilities. Use when users require evidence-based conclusions from real data rather than static code analysis only.

Multi-Capability Bug Closure Skill

When to Use

Use this skill when the user requires:

  • Proactive use of available capability systems to complete bug investigation
  • Real evidence from databases and server logs
  • Verifiable conclusions and root-cause analysis
  • A full closure loop: locate -> prove -> conclude -> recommend

This skill must prioritize real runtime evidence and must not conclude from code reading alone.

Mandatory Guiding Prompt (Keep Original Intent)

Proactively use the currently available capability system. Complete problem localization and evidence-based reasoning by yourself (preferably with real database and server-side data), then provide conclusions and causes. Do not conclude based on code reading alone. Since you can query databases, server logs, and actual software platform operations, complete the full closed-loop investigation autonomously. I only care about final conclusions backed by evidence.


Prerequisite Check: Four Capability Systems (Required)

Before each investigation, verify all four capabilities are available and readable:

  1. Source code access capability (for understanding and localization)
  2. Database read capability (for deep validation)
  3. Server log download and analysis capability (for behavioral and timeline evidence)
  4. Software platform query capability (for business-side verification)

Validation Criteria

  • Source code capability: can read related code files in the workspace (at least one core router/service file).
  • Database capability: can execute at least one read-only SQL query (for example, select 1).
  • Server log capability: can read log-skill configuration and access a target log directory or sample logs.
  • Platform query capability: related platform skill is readable, and its docs/API description are readable.

If Any Capability Is Missing (Must Notify User)

If any capability is missing, first notify that evidence closure cannot be guaranteed, then provide supplementation recommendations:

  • Source code capability: provide relevant source context or key directories directly
  • Database capability: add MCP services for the target system (Postgres/SQLite/Redis, etc.)
  • Server log capability: install or add server-log-analysis
  • Platform query capability: add a query skill or MCP tools for the target business platform

Do not provide a final root-cause conclusion before capabilities are complete. Provide only an evidence-gap checklist.


Standard Workflow (Required)

  1. Structure the problem
    • Extract time window, service name, error keywords, and identifiers (SN/ID/traceId).
  2. Log-side evidence (server)
    • Pull raw logs in the target time window.
    • Measure frequency, grouping, and continuity of anomalies.
  3. Database-side evidence
    • Query object existence, relationships, status, and timestamps in key tables.
    • Cross-check across databases when needed.
  4. Code-side localization
    • Locate exception enums, throw paths, and routing branch conditions.
    • Use code only to explain mechanism, not to replace real-data conclusions.
  5. Platform-side validation
    • Validate object status and business configuration through platform queries.
  6. Merge the evidence chain
    • Connect evidence in this order: logs -> database -> code mechanism -> platform validation.
  7. Output final conclusion
    • Classify as data issue / code issue / configuration issue / environment issue.
  8. Provide fix recommendations and verification standards
    • Give executable steps and clear pass criteria for closure.

Output Template (Required)

## Problem Summary
[One-sentence summary of symptom and impact]

## Key Evidence
- Log evidence: [time, service, key lines, frequency stats]
- Database evidence: [tables, conditions, query results]
- Code evidence: [trigger path and branch conditions]
- Platform evidence: [API/config validation results]

## Root-Cause Assessment
[Final root cause + category: data/code/config/environment]

## Confidence
[High/Medium/Low] + [reason]

## Fix Recommendations
1. [Actionable step]
2. [Actionable step]

## Verification Criteria
- [Metric 1, e.g. error count reaches zero]
- [Metric 2, e.g. mapping restored]

Constraints

  • Do not fabricate evidence.
  • Do not skip database or log evidence and jump straight to conclusions.
  • If a capability is unavailable, explicitly declare the evidence gap and request supplementation.
  • For sensitive credentials, prefer environment variables or secret managers; do not expose plaintext in outputs.