Token导航 LogoToken导航

Agent Skill · 研究检索

error-detective(错误侦探)

error-detective 用于记录任务执行中的错误、用户纠正、经验和能力缺口,适合在 Codex、Claude、Cursor、Gemini CLI 中希望让 Agent 持续沉淀问题、修正和最佳实践时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

error-detective 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为权限未标注;许可证为 MIT,暂无第三方扫描结果,按安装量在研究检索类的 73,675 个 Skill 里排第 70,604。

总安装 210周安装 9GitHub Stars 公开资料未说明下载 73核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT

安装方式

通过对话安装

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

请帮我安装这个 Agent Skill:error-detective(错误侦探)
来源仓库:https://github.com/autumnsgrove/claudeskills
仓库路径:skills/error-detective
安装命令:
npx skills add autumnsgrove/claudeskills --skill "error-detective"
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

AgentSkills.tonpx skills
npx skills add autumnsgrove/claudeskills --skill "error-detective"

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

用于记录任务执行中的错误、用户纠正和经验总结,持续优化 Agent 表现。适合在 Codex、Claude、Cursor、Gemini CLI 中沉淀最佳实践和问题模式。通过 npx skills add 命令从 GitHub 安装,需指定技能名称。调用前应确认日志存储位置和隐私保护策略。

建议查阅原始仓库了解错误分类和反馈闭环机制。

来源仓库内路径:skills/error-detective

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add autumnsgrove/claudeskills --skill "error-detective";命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    权限没有明确标注,第一次使用时只给一个无关紧要的任务,观察它到底读了哪些文件和网络。

常见问题

6 条

error-detective 怎么安装?

在终端执行 npx skills add autumnsgrove/claudeskills --skill "error-detective"。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

error-detective 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

error-detective 需要什么权限?

权限级别没有明确标注。第一次使用时建议只给无关紧要的任务,观察它实际读写了哪些内容。

error-detective 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

error-detective 用的人多吗?

公开数据是累计安装 210 次,近一周安装 9 次,下载 73 次。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

error-detective 安全吗?

没有查到第三方扫描结果,安全性无法从公开资料判断,安装前请自行审查源码、依赖和命令行为。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 许可证明确为 MIT,商用和分发边界好判断。

先想清楚的地方

  • 没有第三方扫描结果,安全性只能靠自己读源码判断。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 要求有安全扫描结论才肯安装的团队。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
error-detective

错误侦探 · 本页

210—权限未标注MIT未收录

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Error Detective - Systematic Debugging and Error Resolution

Overview

Error Detective is a comprehensive debugging skill that applies systematic methodologies to identify, analyze, and resolve errors efficiently. Using the TRACE framework and structured analysis techniques, this skill guides you through debugging from initial error discovery to verified resolution.

Core Capabilities

Stack Trace Analysis

  • Parse and interpret stack traces across multiple languages
  • Identify root cause vs. symptom errors
  • Extract relevant file paths and line numbers
  • Understand call chains and error propagation

Error Pattern Recognition

  • Categorize errors by type (syntax, runtime, logic, integration)
  • Identify common error patterns and anti-patterns
  • Recognize framework-specific errors
  • Map errors to likely root causes

Root Cause Analysis

  • Distinguish between symptoms and underlying issues
  • Follow error chains to original source
  • Identify environmental vs. code issues
  • Detect configuration and dependency problems

Debugging Workflow Management

  • Structured investigation process
  • Hypothesis generation and testing
  • Iterative refinement of understanding
  • Documentation of findings and solutions

The TRACE Framework

TRACE is a systematic five-step approach to debugging any error:

T - Trace the Error

Objective: Capture complete error information and context

  1. Collect the full error message

- Complete stack trace (not just first few lines) - Error type and message - Timestamp and occurrence frequency - Environment where error occurred

  1. Identify error location

- Exact file and line number - Function or method where error occurred - Code context (surrounding lines) - Call stack from entry point to error

  1. Gather reproduction steps

- Minimal steps to reproduce - Input data or parameters used - Expected vs. actual behavior - Consistency of reproduction (always, intermittent, rare)

R - Read the Error Message

Objective: Extract all information from the error itself

  1. Parse error components

- Error type/class (TypeError, ValueError, etc.) - Error message content - Suggested fixes (if provided) - Related errors or warnings

  1. Understand error semantics

- What the error type means in this language/framework - What conditions trigger this error - What the error message is specifically telling you - Any error codes or status codes

  1. Identify error category

- Syntax error (code won't parse) - Runtime error (code crashes during execution) - Logic error (wrong results, no crash) - Integration error (external system failure) - Performance error (timeout, resource exhaustion)

A - Analyze the Context

Objective: Understand the broader context around the error

  1. Code analysis

- Review the failing line and surrounding code - Check recent changes to this code - Examine function/method signature and usage - Review related code that calls or is called by failing code

  1. Data analysis

- Inspect input values at point of failure - Check data types and structures - Verify data meets expected format/constraints - Identify edge cases or unexpected values

  1. Environment analysis

- Check dependencies and versions - Review configuration files - Verify environment variables - Confirm required resources are available (files, network, memory)

  1. State analysis

- Application state at time of error - Previous operations that led to this state - Shared state or global variables involved - Database or external system state

C - Check for Root Cause

Objective: Identify the underlying issue, not just symptoms

  1. Follow the error chain

- Start at bottom of stack trace (first error) - Work up to find originating cause - Distinguish between error origin and error handlers - Identify wrapped or re-thrown errors

  1. Test hypotheses

- Generate specific, testable hypotheses - Isolate variables (change one thing at a time) - Use logging/debugging tools to verify assumptions - Document which hypotheses are confirmed or rejected

  1. Common root causes

- Null/undefined values: Missing initialization or validation - Type mismatches: Incorrect data type passed or returned - Off-by-one errors: Array/loop boundary issues - Race conditions: Timing-dependent failures - Resource exhaustion: Memory, disk, connections depleted - Configuration errors: Wrong settings or missing config - Dependency issues: Version conflicts or missing libraries - Permission errors: Insufficient access rights - Network errors: Connectivity, timeout, DNS issues - Data corruption: Invalid or unexpected data format

E - Execute the Fix

Objective: Implement and verify the solution

  1. Design the fix

- Address root cause, not symptoms - Consider side effects and edge cases - Plan for backward compatibility if needed - Choose most maintainable solution

  1. Implement carefully

- Make minimal, targeted changes - Add validation and error handling - Include logging for future debugging - Document the fix and reasoning

  1. Verify thoroughly

- Confirm original error is resolved - Test with reproduction steps - Test edge cases and related functionality - Verify no new errors introduced

  1. Document and prevent

- Document what caused the error - Document the solution and why it works - Add tests to prevent regression - Update documentation or add warnings if needed

Debugging Workflow

Initial Assessment (5 minutes)

1. Read complete error message
2. Identify error type and severity
3. Check if error is reproducible
4. Assess impact (blocking, degraded, cosmetic)
5. Decide investigation priority

Deep Investigation (15-30 minutes)

1. Apply TRACE framework systematically
2. Use debugging tools (see scripts/debug_helper.py)
3. Generate and test hypotheses
4. Document findings as you go
5. Narrow down to root cause

Solution Implementation (varies)

1. Design fix addressing root cause
2. Implement with proper error handling
3. Add logging and validation
4. Test thoroughly
5. Document solution

Verification and Prevention (10 minutes)

1. Verify fix with original reproduction steps
2. Test related functionality
3. Add regression tests
4. Update documentation
5. Deploy and monitor

Common Error Patterns by Language

Python

AttributeError: 'NoneType' has no attribute 'X'

  • Root cause: Variable is None when expecting object
  • Check: Initialization, function return values, API responses
  • Fix: Add null checks, ensure proper initialization

KeyError: 'key_name'

  • Root cause: Dictionary missing expected key
  • Check: Data source, parsing logic, key spelling
  • Fix: Use.get() with default, validate data structure

ImportError / ModuleNotFoundError

  • Root cause: Module not installed or not in path
  • Check: requirements.txt, virtual environment, PYTHONPATH
  • Fix: Install missing package, fix import path

IndentationError

  • Root cause: Inconsistent spacing (tabs vs spaces)
  • Check: Editor settings, copied code
  • Fix: Standardize to spaces (PEP 8), use linter

JavaScript/TypeScript

TypeError: Cannot read property 'X' of undefined

  • Root cause: Accessing property on undefined object
  • Check: Object initialization, async timing, API responses
  • Fix: Optional chaining (?.operator), null checks

ReferenceError: X is not defined

  • Root cause: Variable used before declaration or out of scope
  • Check: Variable declaration, scope, hoisting issues
  • Fix: Declare variable, fix scope, check imports

Promise rejection / Uncaught (in promise)

  • Root cause: Async operation failed without catch handler
  • Check: API calls, file operations, async/await usage
  • Fix: Add.catch() or try/catch with await

SyntaxError: Unexpected token

  • Root cause: Invalid syntax, often from parsing JSON or code
  • Check: JSON structure, bracket matching, semicolons
  • Fix: Validate JSON, fix syntax, check for copy/paste errors

Java

NullPointerException

  • Root cause: Method called on null object reference
  • Check: Object initialization, method return values
  • Fix: Add null checks, use Optional, ensure initialization

ClassNotFoundException

  • Root cause: Class not found in classpath
  • Check: Dependencies, build configuration, package structure
  • Fix: Add dependency, fix classpath, check package/class names

ConcurrentModificationException

  • Root cause: Collection modified during iteration
  • Check: Nested loops, multi-threading, iterator usage
  • Fix: Use iterator.remove(), CopyOnWriteArrayList, or synchronization

Error Severity Classification

Critical (Fix Immediately)

  • Application crashes or won't start
  • Data loss or corruption
  • Security vulnerabilities
  • Production outages
  • Payment or transaction failures

High (Fix Soon)

  • Major features broken
  • Degraded performance affecting users
  • Error affects multiple users
  • Workarounds are complex

Medium (Schedule Fix)

  • Minor features broken
  • Cosmetic issues with impact
  • Errors with easy workarounds
  • Edge case failures

Low (Backlog)

  • Cosmetic issues
  • Minor improvements
  • Rare edge cases
  • Non-critical warnings

Debugging Tools and Techniques

Logging Best Practices

import logging

# Configure structured logging
logging.basicConfig(
    level=logging.DEBUG,
    format='%(asctime)s - %(name)s - %(levelname)s - %(message)s'
)

# Log with context
logger = logging.getLogger(__name__)
logger.debug(f"Processing item: {item_id}, user: {user_id}")
logger.error(f"Failed to process: {error}", exc_info=True)

Strategic Breakpoints

  1. At error location: Catch exact state when error occurs
  2. Before error: Check inputs and preconditions
  3. After error: See how error propagates
  4. At decision points: Verify logic branches
  5. In loops: Check iteration variables

Print Debugging (Strategic)

# Add contextual debug prints
print(f"DEBUG: function_name called with {param1=}, {param2=}")
print(f"DEBUG: variable state before operation: {var=}")
print(f"DEBUG: condition check: {condition=}, result: {result=}")

Binary Search Debugging

When error location is unclear:

  1. Add checkpoint in middle of code path
  2. Determine if error before or after checkpoint
  3. Repeat in remaining half
  4. Converge on error location quickly

Rubber Duck Debugging

Explain code line-by-line to someone (or something):

  1. Forces you to examine assumptions
  2. Often reveals errors during explanation
  3. Clarifies complex logic
  4. Identifies knowledge gaps

Using the Debug Helper Script

The scripts/debug_helper.py utility provides automated assistance:

# Parse stack trace from file
python scripts/debug_helper.py parse-trace error.log

# Extract error patterns
python scripts/debug_helper.py analyze-log application.log

# Start debug session (creates log)
python scripts/debug_helper.py session start "Login error investigation"

# Add notes to session
python scripts/debug_helper.py session note "Tested with different users - same error"

# Close session with solution
python scripts/debug_helper.py session close "Fixed: Added null check for user.profile"

Best Practices

Do's

  • Read error messages completely: Don't skip details
  • Reproduce consistently: Ensure reliable reproduction before debugging
  • Change one thing at a time: Isolate what fixes the problem
  • Document as you go: Record hypotheses, tests, findings
  • Use version control: Commit before debugging, can revert if needed
  • Add tests: Prevent regression after fixing
  • Fix root cause: Don't just patch symptoms
  • Share knowledge: Document solutions for team

Don'ts

  • Don't assume: Verify your assumptions with data
  • Don't skip reading errors: Error messages contain crucial information
  • Don't make multiple changes: Can't tell what fixed it
  • Don't delete code impulsively: Comment out first, understand why it was there
  • Don't ignore warnings: Today's warning is tomorrow's error
  • Don't fix without understanding: May break something else
  • Don't forget to test: Verify fix works and doesn't introduce new issues

Common Debugging Scenarios

Scenario 1: "It Worked Yesterday"

Approach:

  1. Check recent changes (git diff, git log)
  2. Review dependency updates
  3. Check environment changes
  4. Look for time-dependent logic
  5. Compare configurations between environments

Common Causes:

  • Recent code changes
  • Updated dependencies
  • Configuration changes
  • Database schema changes
  • External API changes
  • Certificate expiration

Scenario 2: "Works on My Machine"

Approach:

  1. Compare environments (OS, dependencies, configs)
  2. Check environment variables
  3. Verify file paths and permissions
  4. Compare data between environments
  5. Look for hardcoded assumptions

Common Causes:

  • Different dependency versions
  • Missing environment variables
  • Different file paths
  • Database state differences
  • Operating system differences
  • Missing configuration files

Scenario 3: "Intermittent Failures"

Approach:

  1. Identify failure pattern (timing, frequency, conditions)
  2. Look for race conditions
  3. Check resource availability
  4. Review concurrent operations
  5. Add extensive logging
  6. Increase reproduction attempts

Common Causes:

  • Race conditions
  • Memory leaks
  • External service instability
  • Network issues
  • Timing-dependent logic
  • Resource exhaustion

Scenario 4: "Error in Production Only"

Approach:

  1. Check production-specific configuration
  2. Review production data characteristics
  3. Check production load/scale
  4. Examine production dependencies
  5. Review security/permission settings

Common Causes:

  • Production data edge cases
  • Scale/load issues
  • Production-specific configuration
  • Different security policies
  • Firewall or network restrictions
  • Production-only integrations

Advanced Techniques

Bisect Debugging (Git)

Find which commit introduced a bug:

git bisect start
git bisect bad                 # Current version has bug
git bisect good v1.2.0        # Version 1.2.0 was working
# Git checks out middle commit
# Test and mark as good/bad
git bisect good/bad
# Repeat until git identifies culprit commit
git bisect reset

Heisenbug (Observer Effect)

Errors that disappear when debugging:

Strategies:

  • Add logging without breakpoints
  • Use production-like environment for debugging
  • Review timing and concurrency issues
  • Check for initialization/timing dependencies
  • Use non-intrusive monitoring

Memory Profiling

For memory leaks and performance:

# Python memory profiling
import tracemalloc

tracemalloc.start()
# ... run code ...
snapshot = tracemalloc.take_snapshot()
top_stats = snapshot.statistics('lineno')

for stat in top_stats[:10]:
    print(stat)

Network Debugging

For API and integration errors:

Tools:

  • Browser DevTools Network tab
  • curl with verbose flag (-v)
  • Postman for API testing
  • Wireshark for packet inspection
  • Network proxy (Charles, Fiddler)

Check:

  • Request/response headers
  • Status codes
  • Request/response body
  • Timing (latency, timeout)
  • SSL/TLS issues

Quick Reference

TRACE Framework Quick Checklist

☐ T - TRACE
  ☐ Full error message captured
  ☐ Stack trace collected
  ☐ Reproduction steps documented
  ☐ Environment identified

☐ R - READ
  ☐ Error type identified
  ☐ Error message analyzed
  ☐ Error category determined
  ☐ Related errors checked

☐ A - ANALYZE
  ☐ Code reviewed
  ☐ Data inspected
  ☐ Environment verified
  ☐ State examined

☐ C - CHECK
  ☐ Error chain followed
  ☐ Hypotheses tested
  ☐ Root cause identified
  ☐ Assumptions verified

☐ E - EXECUTE
  ☐ Fix designed
  ☐ Fix implemented
  ☐ Fix verified
  ☐ Prevention measures added

Error Priority Matrix

Impact →     Low        Medium       High        Critical
Frequency ↓
High         Medium     High         Critical    Critical
Medium       Low        Medium       High        Critical
Low          Low        Low          Medium      High
Rare         Backlog    Low          Medium      High

Additional Resources

Examples

  • examples/debugging_workflow.md - Step-by-step debugging process examples
  • examples/common_errors.md - Catalog of frequent error patterns and solutions
  • examples/stack_traces.txt - Annotated stack trace examples with analysis

Scripts

  • scripts/debug_helper.py - Python debugging utilities for trace parsing and session management

Further Learning

  • Language-specific debugging documentation
  • Framework error handling guides
  • Profiling and performance analysis tools
  • Testing and quality assurance practices

Remember: Debugging is detective work. Be systematic, be patient, and let the evidence guide you to the truth. Every error message is a clue waiting to be understood.

平台分布

windsurf

28.77%
按下载量换算21

OpenCode

22.62%
按下载量换算17

weavefox

17.31%
按下载量换算13

Codex

10.76%
按下载量换算8

Claude Code

6.6%
按下载量换算5

Antigravity

3.33%
按下载量换算2

安全审计

暂无安全审计结果可展示。

权限和风险

权限未标注

当前来源未能明确判断权限范围,默认进入异常复核队列。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills