首页
结构化调试会话——复现、隔离、诊断和修复。可通过错误消息或堆栈跟踪触发，例如“这在预发布环境中能正常运行，但在生产环境中却不行”、“部署后出现故障”，或者当行为与预期不符且原因不明时。
...展开全部关于debug
debug 技能旨在引导用户在软件行为出现异常、不明或退化时，遵循结构化的debug流程。 该技能适用于以下情况：当错误信息、堆栈跟踪或意外行为表明存在无法立即诊断的问题时。通过将debuging流程划分为清晰的阶段，它能帮助用户以系统化的方式从观察症状过渡到识别根本原因，而非依赖猜测。
该技能遵循四步法：复现、隔离、诊断和修复。在复现阶段，重点在于厘清预期行为与实际行为的差异，并建立可靠的步骤以复现问题。隔离阶段通过审查近期变更（如部署、配置更新或依赖项变更），同时分析日志和错误输出，从而缩小受影响组件的范围。 在诊断阶段，该流程强调提出并验证假设、追踪执行路径，以及识别潜在的根本原因，而非仅关注表面症状。最后，修复阶段侧重于提出纠正性变更方案，同时考虑副作用，并建议进行预防性测试以避免回归问题。
该技能主要面向经常排查生产环境和开发环境问题的开发人员、DevOps工程师、质量保证（QA）测试人员以及站点可靠性工程师。它在以下场景中尤为有用：部署回归、特定环境下的错误（例如，预发布环境与生产环境之间的差异），或近期变更后出现的无法解释的故障。 通过实施一套规范的debuging结构，可以减少试错式debuging，并提高事件解决工作流的一致性。
常见问题
使用此debug技能时，我应提供哪些信息？
您应提供错误消息、堆栈跟踪、异常行为的描述、重现步骤，或上下文信息（如最近的更改或日志）。信息越精确，debugging 流程就越有效。
该技能是否需要访问外部工具或连接器？
如果已连接，该技能可选地利用现有的连接器，例如监控系统、源代码控制或项目跟踪工具。不过，仅凭您提供的描述、日志和背景信息，它仍可正常运行。
该技能不适用于哪些类型的问题？
该技能不适用于纯粹的理论问题或一般性解释。它专门针对具有可观察到的异常行为的具体软件问题进行诊断和解决。
/debug
If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.
Run a structured debugging session to find and fix issues systematically.
Usage
/debug $ARGUMENTSHow It Works
┌─────────────────────────────────────────────────────────────────┐│ DEBUG │├─────────────────────────────────────────────────────────────────┤│ Step 1: REPRODUCE ││ ✓ Understand the expected vs. actual behavior ││ ✓ Identify exact reproduction steps ││ ✓ Determine scope (when did it start? who is affected?) ││ ││ Step 2: ISOLATE ││ ✓ Narrow down the component, service, or code path ││ ✓ Check recent changes (deploys, config changes, dependencies) ││ ✓ Review logs and error messages ││ ││ Step 3: DIAGNOSE ││ ✓ Form hypotheses and test them ││ ✓ Trace the code path ││ ✓ Identify root cause (not just symptoms) ││ ││ Step 4: FIX ││ ✓ Propose a fix with explanation ││ ✓ Consider side effects and edge cases ││ ✓ Suggest tests to prevent regression │└─────────────────────────────────────────────────────────────────┘What I Need From You
Tell me about the problem. Any of these help:
- Error message or stack trace
- Steps to reproduce
- What changed recently
- Logs or screenshots
- Expected vs. actual behavior
Output
## Debug Report: [Issue Summary]### Reproduction- **Expected**: [What should happen]- **Actual**: [What happens instead]- **Steps**: [How to reproduce]### Root Cause[Explanation of why the bug occurs]### Fix[Code changes or configuration fixes needed]### Prevention- [Test to add]- [Guard to put in place]
If Connectors Available
If ~~monitoring is connected:
- Pull logs, error rates, and metrics around the time of the issue
- Show recent deploys and config changes that may correlate
If ~~source control is connected:
- Identify recent commits and PRs that touched affected code paths
- Check if the issue correlates with a specific change
If ~~project tracker is connected:
- Search for related bug reports or known issues
- Create a ticket for the fix once identified
Tips
- Share error messages exactly — Don't paraphrase. The exact text matters.
- Mention what changed — Recent deploys, dependency updates, and config changes are top suspects.
- Include context — "This works in staging but not prod" or "Only affects large payloads" narrows things fast.
