Token导航 LogoToken导航TokenDH.com
研究检索敏感数据github未标认证来源可访问clear审计提醒

intelligent-debugger智能调试器

Agent Skill

intelligent-debugger 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

374

周安装

15

GitHub Stars

公开资料未说明

下载量

121
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

3

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:intelligent-debugger(智能调试器)
来源仓库:https://github.com/sitechfromgeorgia/georgian-distribution-system
仓库路径:skills/intelligent-debugger
安装命令:
npx skills add https://github.com/sitechfromgeorgia/georgian-distribution-system --skill intelligent-debugger
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/sitechfromgeorgia/georgian-distribution-system --skill intelligent-debugger

简介

智能调试器提供系统化的技术问题排查方法,适用于跨前端、后端、API 或数据库的故障定位。

  • 适合在 Codex、Claude、Cursor、Gemini CLI 中处理错误、异常行为或复杂技术问题时使用。
  • 通过七步流程结合工具链进行根因分析,强调先理解后修复、全程记录和彻底验证。
  • 安装需确认权限范围和维护状态,注意可能触发联网、命令执行或文件读写操作。
  • 建议结合原始 README 核验具体用法,并关注 Gen Agent Trust Hub 的安全审计提示。

SKILL.md

Intelligent Debugger

Overview

The Intelligent Debugger is a systematic, methodical debugging agent that assists in diagnosing and resolving complex software issues across the entire technology stack. This skill employs proven debugging methodologies, forensic analysis techniques, and systematic investigation approaches to identify root causes and provide actionable solutions.

Core Debugging Philosophy

Systematic Investigation Over Random Fixes

  • Never guess or make random changes
  • Follow the scientific method: observe, hypothesize, test, conclude
  • Document every finding and decision
  • Root cause analysis is always the goal

Cross-Stack Awareness

  • Track error propagation from frontend to backend to database
  • Understand how failures cascade through system boundaries
  • Identify the original source, not just symptoms

Collaborative Problem Solving

  • Ask clarifying questions before diving in
  • Explain findings in clear, actionable terms
  • Provide learning opportunities during debugging

7-Step Systematic Debugging Process

Step 1: Reproduce the Issue

Goal: Establish consistent reproducibility

Actions:

  1. Gather reproduction details from user:

- Exact steps to trigger the bug - Environment details (OS, browser, versions) - Frequency (always, intermittent, specific conditions) - When did it start occurring? - Any recent changes to the system?

  1. Attempt to reproduce:

- Follow exact steps provided - Try variations to understand scope - Note any environmental factors

  1. Document reproduction criteria: BUG REPRODUCTION REPORT: - Trigger: [exact steps] - Environment: [OS/browser/version] - Frequency: [always/intermittent/conditional] - Prerequisites: [required state/data]

If not reproducible:

  • Collect more environmental details
  • Check for Heisenbugs (bugs that disappear when observed)
  • Look for race conditions or timing issues

Step 2: Gather Information

Goal: Collect comprehensive diagnostic data

Essential Information:

  1. Error Messages & Stack Traces

- Full error text (no truncation) - Complete stack trace with line numbers - Error codes and HTTP status codes - Console output

  1. System Context

- Application logs (use scripts/log_analyzer.py) - Server logs - Database logs - Browser console (for frontend) - Network tab (for API issues)

  1. Environment Details

- Framework versions - Dependencies and package versions - Configuration files - Environment variables (redact secrets)

  1. Recent Changes

- Recent commits (git log) - Recent deployments - Configuration changes - Dependency updates

Information Gathering Questions:

1. What error message(s) do you see? (exact text)
2. Where does the error occur? (file/line/function)
3. What were you trying to do when it failed?
4. What happened vs. what did you expect?
5. Does this work anywhere else? (different env/browser)
6. What changed recently? (code/config/deployment)
7. Can you share relevant logs?

Step 3: Understand the System

Goal: Build mental model before debugging

System Mapping:

  1. Trace the Request Flow

- User action → Frontend → API → Backend → Database - Identify all touch points - Map data transformations

  1. Component Inventory Frontend: [framework/libraries/version] Backend: [framework/language/version] Database: [type/version] APIs: [external services] Infrastructure: [hosting/containers]
  2. Key Questions

- What components are involved? - How do they communicate? - What dependencies exist? - Where is data stored/cached? - What authentication/authorization is used?

Create System Diagram:

[User] → [Browser] → [Load Balancer] → [API Server]
                                           ↓
                                      [Database]
                                           ↓
                                      [Cache Layer]

Step 4: Form and Test Hypotheses

Goal: Systematically narrow down the cause

Hypothesis Formation:

  1. Based on symptoms and gathered data, list possible causes
  2. Rank by likelihood (most probable first)
  3. Consider multiple categories:

- Logic errors - Data issues - Configuration problems - Integration failures - Performance bottlenecks - Race conditions - Security/permissions

Hypothesis Testing:

FOR EACH HYPOTHESIS:
1. State hypothesis clearly: "Bug is caused by [X]"
2. Predict what evidence would support/refute it
3. Design minimal test to validate
4. Execute test
5. Observe results
6. Update hypothesis based on findings

EXAMPLE:
Hypothesis: Database query timeout causing 500 error
Test: Check database logs for slow queries
Result: Found query taking 30+ seconds
Conclusion: Hypothesis confirmed → optimize query

Isolation Techniques:

  • Binary Search: Comment out half the code, test, repeat
  • Rubber Duck Debugging: Explain code line-by-line
  • Minimal Reproduction: Create smallest example that shows bug
  • Add Logging: Insert strategic debug statements
  • Use Debugger: Set breakpoints, inspect variables

Step 5: Implement Solution

Goal: Fix root cause, not symptoms

Solution Development:

  1. Understand Root Cause

- Why did the bug occur? - What was the flawed assumption? - How did it pass initial testing?

  1. Design Fix

- Address root cause directly - Consider edge cases - Ensure no side effects - Check performance impact

  1. Implementation Checklist [] Fix addresses root cause, not symptom [] Code follows project standards [] No new bugs introduced [] Handles edge cases [] Includes error handling [] Maintains performance [] Documented/commented

Step 6: Test and Verify

Goal: Confirm fix works and doesn't break anything

Verification Steps:

  1. Reproduce Original Bug

- Confirm bug still occurs in unfixed code - Document current behavior

  1. Apply Fix and Test

- Bug should no longer occur - Original functionality preserved - Edge cases handled

  1. Regression Testing

- Run existing test suite - Test related functionality - Check for side effects

  1. Performance Validation

- Run scripts/performance_check.py - Compare before/after metrics - Ensure no degradation

Testing Matrix:

Scenario          | Before Fix | After Fix | Status
------------------|------------|-----------|-------
Original bug      | Fails      | Passes    | ✅
Edge case 1       | ?          | Passes    | ✅
Edge case 2       | ?          | Passes    | ✅
Related feature A | Passes     | Passes    | ✅
Performance       | Baseline   | +5%       | ✅

Step 7: Document and Learn

Goal: Capture knowledge for future debugging

Debugging Summary Template:

DEBUGGING POSTMORTEM:
Date: [DATE]
Bug: [BRIEF DESCRIPTION]
Severity: [Critical/High/Medium/Low]

SYMPTOMS:
- [Error message or behavior]
- [Where it manifested]

ROOT CAUSE:
[Fundamental issue that caused the bug]

INVESTIGATION PATH:
1. [What we tried first]
2. [What led us to the answer]
3. [Key insight that solved it]

FIX:
[Description of solution]
File: [PATH]
Changes: [SUMMARY]

PREVENTION:
[ ] Added test case
[ ] Updated documentation
[ ] Added monitoring/alerting
[ ] Code review process updated
[ ] Linter rule added

LESSONS LEARNED:
- [What we learned]
- [How to prevent similar bugs]

Debugging Techniques by Category

Frontend Debugging

Browser Developer Tools:

  1. Console Tab

- Check for JavaScript errors - Look for warnings - Examine console.log output

  1. Network Tab

- Inspect API calls - Check request/response headers - Verify payload data - Check status codes - Look for failed requests

  1. Elements Tab

- Inspect DOM structure - Check CSS styles - Look for layout issues - Verify element visibility

  1. Application Tab

- Check localStorage/sessionStorage - Inspect cookies - Review service workers - Check cache

Common Frontend Issues:

// Issue: Variable is undefined
// Debug: Check if element exists before accessing
const element = document.getElementById('myId');
if (element) {
  element.textContent = 'Updated';
}

// Issue: Async timing problem
// Debug: Use proper async/await
async function fetchData() {
  try {
    const response = await fetch('/api/data');
    const data = await response.json();
    return data;
  } catch (error) {
    console.error('Fetch failed:', error);
  }
}

// Issue: State not updating
// Debug: Check immutability in React/Vue
// BAD: state.items.push(newItem)
// GOOD: setState({ items: [...state.items, newItem] })

Backend Debugging

Logging Strategy:

import logging

# Configure proper logging levels
logging.basicConfig(
    level=logging.DEBUG,
    format='%(asctime)s [%(levelname)s] %(name)s: %(message)s'
)

def process_request(data):
    logging.info(f"Processing request: {data['id']}")
    try:
        result = perform_operation(data)
        logging.debug(f"Operation result: {result}")
        return result
    except Exception as e:
        logging.error(f"Operation failed: {e}", exc_info=True)
        raise

API Debugging:

  1. Test endpoints with curl/Postman
  2. Check request headers
  3. Verify authentication tokens
  4. Inspect request/response bodies
  5. Check HTTP status codes
  6. Review API logs

Common Backend Issues:

HTTP 400: Bad Request → Validate input data
HTTP 401: Unauthorized → Check auth tokens
HTTP 403: Forbidden → Verify permissions
HTTP 404: Not Found → Check route/resource exists
HTTP 500: Server Error → Check server logs
HTTP 503: Service Unavailable → Check dependencies

Database Debugging

Query Analysis:

-- Enable query logging
SET log_statement = 'all';

-- Explain query performance
EXPLAIN ANALYZE
SELECT * FROM users
WHERE created_at > '2025-01-01'
AND status = 'active';

-- Check for slow queries
SELECT query, calls, total_time, mean_time
FROM pg_stat_statements
ORDER BY total_time DESC
LIMIT 10;

-- Check for locking issues
SELECT * FROM pg_locks
WHERE NOT granted;

Connection Issues:

# Debug database connectivity
try:
    connection = psycopg2.connect(
        host="localhost",
        database="mydb",
        user="myuser",
        password="mypass",
        connect_timeout=5
    )
    print("✅ Database connected")
except psycopg2.OperationalError as e:
    print(f"❌ Connection failed: {e}")
    # Check: host reachable, credentials, firewall, DB running

Performance Debugging

Profiling:

# Use cProfile for performance analysis
import cProfile
import pstats

profiler = cProfile.Profile()
profiler.enable()

# Code to profile
expensive_function()

profiler.disable()
stats = pstats.Stats(profiler)
stats.sort_stats('cumulative')
stats.print_stats(10)  # Top 10 slowest functions

Memory Debugging:

# Track memory usage
import tracemalloc

tracemalloc.start()

# Code to analyze
process_large_dataset()

current, peak = tracemalloc.get_traced_memory()
print(f"Current: {current / 1024 / 1024:.2f} MB")
print(f"Peak: {peak / 1024 / 1024:.2f} MB")
tracemalloc.stop()

Integration Debugging

API Integration Issues:

  1. Network Problems

- Use curl to test endpoint - Check DNS resolution - Verify SSL certificates - Test with timeout

  1. Authentication Failures

- Verify API keys/tokens - Check expiration dates - Test in API documentation/Postman - Review authentication headers

  1. Data Format Mismatches

- Compare expected vs actual payload - Check content-type headers - Validate JSON schema - Test with sample data


Error Pattern Recognition

Stack Trace Analysis

Reading Stack Traces:

Example Stack Trace:
Traceback (most recent call last):
  File "app.py", line 45, in process_order
    result = calculate_total(items)
  File "utils.py", line 23, in calculate_total
    price = item['price'] * item['quantity']
KeyError: 'quantity'

ANALYSIS:
1. Error Type: KeyError - missing dictionary key
2. Root Location: utils.py, line 23
3. Call Chain: app.py (45) → utils.py (23)
4. Problem: item dict missing 'quantity' key
5. Solution: Validate item structure or use item.get('quantity', 1)

Common Error Patterns:

Error TypeLikely CauseInvestigationSolution
NullPointerExceptionVariable not initializedCheck assignmentInitialize properly
IndexOutOfBoundsArray access beyond sizeVerify array lengthAdd bounds check
TimeoutErrorOperation too slowProfile performanceOptimize or increase timeout
MemoryErrorMemory exhaustedCheck object sizesOptimize memory usage
ConnectionRefusedService not runningCheck service statusStart service/fix network
SyntaxErrorCode typoReview syntaxFix typo
TypeErrorWrong data typeCheck typeConvert/validate type
ImportErrorMissing moduleCheck installationInstall package
PermissionErrorAccess deniedCheck file permissionsUpdate permissions

Cross-Stack Error Propagation

Tracking Errors Across Boundaries:

SCENARIO: 500 Internal Server Error on frontend

INVESTIGATION PATH:
1. Frontend Console: 500 error on POST /api/orders
2. Backend Logs: Exception in order_handler
3. Database Logs: Deadlock detected
4. Root Cause: Concurrent transactions on same order

PROPAGATION CHAIN:
Database Deadlock → Backend Exception → API 500 → Frontend Error

SOLUTION LEVEL: Database (add proper transaction isolation)

Debugging Tools & Commands

Essential Tools

Git Bisect (Find bug-introducing commit):

# Start bisect
git bisect start
git bisect bad HEAD
git bisect good v1.2.0

# Test each commit
# Git automatically checks out commits
# Mark as good/bad until bug commit found
git bisect good  # if bug not present
git bisect bad   # if bug present

# Automate with test script
git bisect run ./test_script.sh

# Reset when done
git bisect reset

Debugger Breakpoints:

# Python debugger
import pdb; pdb.set_trace()  # Breakpoint

# Commands in debugger:
# n (next) - execute next line
# s (step) - step into function
# c (continue) - continue execution
# l (list) - show code context
# p variable - print variable value
# pp variable - pretty print

Node.js Debugging:

// Use debugger statement
function problematicFunction() {
  debugger;  // Execution pauses here in dev tools
  const result = someComputation();
  return result;
}

// Or use console methods
console.log('Value:', value);
console.error('Error:', error);
console.table(arrayOfObjects);  // Nice table view
console.trace();  // Print stack trace

Log Analysis

Use provided log analyzer:

# Analyze log file for errors and patterns
python scripts/log_analyzer.py /path/to/app.log

# Output shows:
# - Error frequency
# - Common error patterns
# - Timeline of issues
# - Anomaly detection

Performance Tools

Run performance checks:

# Check performance metrics
python scripts/performance_check.py

# Outputs:
# - Response time analysis
# - Memory usage patterns
# - CPU utilization
# - Bottleneck identification

Debugging Workflow Examples

Example 1: Frontend Not Displaying Data

Problem: Page loads but no data appears

Investigation:

  1. Open browser DevTools → Network tab
  2. Check if API call is made
  3. Inspect API response
  4. Check Console for errors

Findings:

  • API returns 200 OK
  • Response body contains data
  • Console error: "Cannot read property 'map' of undefined"

Root Cause: Component tries to map data before it's loaded

Solution:

// Before (broken)
return data.map(item => <Item key={item.id} {...item} />);

// After (fixed)
return data ? data.map(item => <Item key={item.id} {...item} />) : <Loading />;
// or
return data?.map(item => <Item key={item.id} {...item} />) || <Loading />;

Example 2: API Timeout

Problem: Endpoint times out after 30 seconds

Investigation:

  1. Check backend logs → Shows slow database query
  2. Run EXPLAIN ANALYZE on query
  3. Check database indexes

Findings:

-- Query takes 45 seconds
SELECT * FROM orders
WHERE customer_id = 123
AND created_at > '2024-01-01'
ORDER BY created_at DESC;

-- EXPLAIN shows sequential scan (bad)
-- Missing index on customer_id

Solution:

-- Add compound index
CREATE INDEX idx_orders_customer_date
ON orders(customer_id, created_at);

-- Query now takes 50ms

Example 3: Intermittent Crashes

Problem: Application crashes randomly, no clear pattern

Investigation:

  1. Enable detailed logging
  2. Monitor for several hours
  3. Analyze crash dumps
  4. Look for common factors

Findings:

  • Crashes correlate with high traffic
  • Memory usage spikes before crash
  • Error logs show "Out of Memory"

Root Cause: Memory leak in cache implementation

Solution:

# Before (leaking)
cache = {}
def get_user(user_id):
    if user_id not in cache:
        cache[user_id] = fetch_from_db(user_id)
    return cache[user_id]
# Cache grows indefinitely!

# After (fixed with LRU cache)
from functools import lru_cache

@lru_cache(maxsize=1000)  # Limits cache size
def get_user(user_id):
    return fetch_from_db(user_id)

Special Debugging Scenarios

Race Conditions

Symptoms:

  • Bug occurs sometimes, not always
  • Different behavior in development vs production
  • Issues with concurrent operations

Investigation:

# Add logging with thread IDs to track concurrency
import threading

logging.info(f"[Thread {threading.current_thread().ident}] Processing order {order_id}")

Common Solutions:

  • Use proper locking mechanisms
  • Implement atomic operations
  • Use database transactions correctly

Heisenbug (Disappears When Debugging)

Characteristics:

  • Bug stops when debugger attached
  • Different behavior with logging enabled
  • Timing-dependent issues

Investigation Approach:

  • Use minimal logging (timestamps only)
  • Add delays/sleep strategically
  • Check for timing assumptions in code
  • Look for uninitialized variables
  • Review async/await patterns

Production-Only Issues

Investigation Strategy:

  1. Cannot Reproduce Locally

- Check environment differences - Compare configuration files - Review production-specific data - Check scaling/load factors

  1. Limited Access to Production

- Use observability tools - Analyze aggregated logs - Check monitoring dashboards - Review recent deployments

  1. Data-Dependent Bugs

- Request sample production data (sanitized) - Use production data snapshots - Test with edge case data


Communication During Debugging

User Communication Template

Initial Response:

Thank you for reporting this issue. I'll help you debug it systematically.

CURRENT UNDERSTANDING:
- Issue: [brief description]
- Impact: [severity/who affected]
- Frequency: [how often]

TO INVESTIGATE:
I need to gather some information:
1. [specific question 1]
2. [specific question 2]
3. [specific question 3]

I'll keep you updated as I investigate.

Progress Updates:

DEBUGGING UPDATE:

INVESTIGATED:
✅ Checked [component A]
✅ Reviewed [logs/traces]
✅ Tested [hypothesis 1]

FINDINGS:
- [Key observation 1]
- [Key observation 2]

NEXT STEPS:
- [What I'm checking next]

ETA: [time estimate]

Resolution Report:

ISSUE RESOLVED

ROOT CAUSE:
[Clear explanation of what caused the bug]

FIX APPLIED:
[Description of the solution]

VERIFICATION:
✅ Bug no longer occurs
✅ Original functionality preserved
✅ Tests passing

PREVENTION:
[What we're doing to prevent recurrence]

DEPLOYMENT:
[When/how fix will be deployed]

Best Practices

Do's

Reproduce First - Never attempt a fix before consistent reproduction ✅ Document Everything - Keep notes on what you tried and found ✅ Ask Questions - Clarify unclear requirements or symptoms ✅ Think Before Acting - Form hypothesis before making changes ✅ Test Thoroughly - Verify fix works and doesn't break anything ✅ Use Version Control - Make debugging changes in branches ✅ Keep It Simple - Start with simplest explanation ✅ Add Logging Strategically - Place logs at key decision points ✅ Review Recent Changes - Check what changed before bug appeared ✅ Consider Edge Cases - Think about unusual inputs/states

Don'ts

Don't Guess - Random changes waste time and may hide real issue ❌ Don't Skip Reproduction - You can't verify a fix without it ❌ Don't Change Multiple Things - Isolate what actually fixed the bug ❌ Don't Ignore Error Messages - They're clues, not obstacles ❌ Don't Debug in Production - Use staging/dev environments ❌ Don't Assume - Verify your assumptions ❌ Don't Rush - Systematic debugging is faster than random fixes ❌ Don't Fix Symptoms - Find and fix the root cause ❌ Don't Delete Debugging Code - Comment it out for future use ❌ Don't Work Alone on Hard Bugs - Get fresh perspective

Debugging Mindset

Cultivate These Attitudes:

  • Curiosity: "Why does this happen?"
  • Patience: Complex bugs take time
  • Skepticism: Question assumptions
  • Thoroughness: Check every angle
  • Humility: Ask for help when stuck

Avoid These Traps:

  • "It worked on my machine" - investigate environment differences
  • "This should work" - what *should* happen doesn't matter
  • "I'll try random things" - systematic > random
  • "It's probably X" - don't commit to hypothesis too early

Quick Reference Commands

Diagnostic Commands

# System information
uname -a                    # OS information
df -h                       # Disk space
free -m                     # Memory usage
top                         # Process monitoring
htop                        # Better process monitoring

# Network debugging
ping example.com            # Test connectivity
curl -v https://api.com     # Test HTTP endpoint
netstat -tuln               # Check listening ports
traceroute example.com      # Trace network path
nslookup domain.com         # DNS lookup

# Log inspection
tail -f /var/log/app.log    # Follow log in real-time
grep "ERROR" app.log        # Find errors
grep -A 5 "error" log       # Show 5 lines after match
awk '{print $1, $5}' log    # Extract specific columns

# Process debugging
ps aux | grep app           # Find process
lsof -p PID                 # List open files for process
strace -p PID               # Trace system calls
kill -SIGTERM PID           # Gracefully stop process

# Git debugging
git log --oneline -10       # Recent commits
git diff HEAD~1 HEAD        # Show last changes
git blame file.py           # See who changed what
git log -S "function_name"  # Find when code was added/removed

Resources

Scripts

Run helper scripts for automated debugging:

  • scripts/log_analyzer.py - Analyze log files for patterns
  • scripts/performance_check.py - Check performance metrics
  • scripts/stack_trace_parser.py - Parse and explain stack traces
  • scripts/error_frequency.py - Count error occurrences
  • scripts/dependency_checker.py - Verify dependencies

References

For deep dive debugging knowledge:

  • references/DEBUGGING_PATTERNS.md - Common bug patterns and solutions
  • references/ERROR_CODES.md - Complete error code reference
  • references/PERFORMANCE_GUIDE.md - Performance debugging guide
  • references/DATABASE_DEBUGGING.md - Database-specific debugging
  • references/FRONTEND_DEBUGGING.md - Frontend debugging techniques

Debugging Decision Tree

START: Bug Reported
  │
  ├─→ Can you reproduce it?
  │    NO → Gather more info, check environment
  │    YES ↓
  │
  ├─→ Do you have logs/stack trace?
  │    NO → Enable logging, reproduce again
  │    YES ↓
  │
  ├─→ Is error message clear?
  │    YES → Research error, form hypothesis
  │    NO → Add more logging at failure point
  │
  ├─→ Test hypothesis
  │    CONFIRMED → Implement fix
  │    REJECTED → Form new hypothesis
  │
  ├─→ Fix implemented
  │    │
  │    ├→ Does it work?
  │    │   NO → Debug the fix
  │    │   YES ↓
  │    │
  │    └→ Any side effects?
  │        YES → Refine fix
  │        NO → Test & Deploy
  │
  └─→ END: Document findings

Summary

The Intelligent Debugger skill provides a comprehensive, systematic approach to debugging across the full technology stack. By following the 7-step process, using appropriate tools and techniques, and maintaining a methodical mindset, you can efficiently identify root causes and implement reliable solutions.

Remember:

  • Be Systematic - Follow the process, don't skip steps
  • Think First - Understand before fixing
  • Document Everything - Knowledge compounds
  • Ask Questions - Clarification prevents wasted effort
  • Test Thoroughly - Verify the fix works

Use this skill whenever you encounter bugs, errors, unexpected behavior, or need to investigate issues across frontend, backend, APIs, or databases. The systematic approach will save time and lead to better, more permanent solutions.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Claude Code

30.81%
按下载量换算37

windsurf

21.8%
按下载量换算26

OpenCode

17.01%
按下载量换算21

Gemini CLI

13.14%
按下载量换算16

Cursor

7.38%
按下载量换算9

Codex

3.62%
按下载量换算4

安全审计

Gen Agent Trust Hub

可疑

Socket

通过

Snyk

通过

权限和风险

敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。

来源信息

继续浏览同类 Skills