multi-capability-bug-closure-en

Unified bug investigation and closure by combining source code, database, server logs, and software platform query capabilities. Use when users require evide...

Security Scan

The skill's instructions legitimately require access to source code, databases, server logs, and platform APIs, but the package declares no required credentials or integrations and gives the agent open-ended permission to query external systems — the capabilities it needs are not documented or constrained, which is concerning.

Purpose & Capability

The name/description match the SKILL.md: it is meant to combine code, DB, logs, and platform queries. However, the skill declares no required env vars, credentials, or config paths while the runtime instructions assume direct access to databases, log directories, and platform skills. That mismatch (required capabilities implied but not declared) reduces transparency and is disproportionate to an instruction-only skill.

Instruction Scope

Instructions explicitly direct the agent to read source code, run read-only SQL queries, pull server logs, and call platform query capabilities. Those actions are in-scope for the stated purpose, but they are broad and potentially sensitive. The mandatory prompt encourages autonomous use of any available capability systems, which could cause the agent to access connected systems unless constrained externally.

Install Mechanism

No install spec and no code files (instruction-only). That minimizes disk-level risk because nothing is downloaded or written by the skill itself.

Credentials

SKILL.md expects access to credentials (databases, logs, platform APIs) and suggests using env vars or secret managers, but the registry metadata lists no required environment variables or primary credential. The skill gives no guidance on which specific secrets it will need or how they will be scoped, audited, or restricted.

Persistence & Privilege

always is false and the skill has no install actions or requests to persist itself or change other skills' config. Autonomous invocation is allowed but that is the platform default; nothing in the manifest requests elevated or persistent privileges.

Scan Findings in Context

[no-findings] expected: This is an instruction-only skill with no code files, so the regex-based scanner had nothing to analyze. The lack of findings is not evidence of safety.

What to consider before installing

This skill is coherent in intent but incomplete in its declarations: it expects the agent to access source code, databases, server logs, and business-platform APIs but does not list which connectors or credentials it will use. Before installing or enabling it: 1) Identify which database/log/platform connectors the agent will use and only provide least-privilege credentials (read-only DB accounts, scoped API tokens). 2) Require explicit user approval before the skill queries any new system or retrieves logs. 3) Ensure audit/logging is enabled so queries and data access are recorded. 4) Test the skill in a sandboxed environment first (with synthetic data) to verify it behaves as expected. 5) Prefer giving access via short-lived tokens or a secrets manager and require the skill to declare which env vars it needs. If you cannot confirm which external systems the skill will touch, treat it as high-risk and avoid giving it credentials or unrestricted access.

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.