技能版本 1.0.0
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
价格
免费
- 安装:免费
在组织开通时一次性收取;再次读取清单或下载不重复收费。
以上为公开标价。你的组织可能有协议价,以控制台显示的价格为准。
如何使用
为组织安装
开通即安装:组织固定使用开通时的版本(当前为 1.0.0)。升级到新版本需要取消后重新开通。
创建凭证
客户端使用组织凭证读取;绑定到数字人后,数字人使用绑定凭证按需加载。请求中携带:
Authorization: Bearer $ZGI_MARKET_KEY读取清单与安装包
清单列出版本、文件和校验值;安装包是一个 zip 文件。
读取清单 curl "https://market-api.zgi.im/v1/market/skills/systematic-debugging/manifest" \ -H "Authorization: Bearer $ZGI_MARKET_KEY"下载安装包 curl "https://market-api.zgi.im/v1/market/skills/systematic-debugging/package" \ -H "Authorization: Bearer $ZGI_MARKET_KEY" \ -o systematic-debugging.zip读取清单和下载安装包不计入用量。下载后请用响应头中的 SHA-256 校验文件。
技能说明
- 名称
- systematic-debugging
- 说明
- Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
会运行代码TypeScriptShell
技能包内含脚本文件,加载技能的运行时可能会执行它们,安装前请先阅读。
SKILL.md 节选
# Systematic Debugging
## Overview
Random fixes waste time and create new bugs. Quick patches mask underlying issues.
**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
**Violating the letter of this process is violating the spirit of debugging.**
## The Iron Law
```
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
```
If you haven't completed Phase 1, you cannot propose fixes.
## When to Use
Use for ANY technical issue:
- Test failures
- Bugs in production
- Unexpected behavior
- Performance problems
- Build failures
- Integration issues
**Use this ESPECIALLY when:**
- Under time pressure (emergencies make guessing tempting)
- "Just one quick fix" seems obvious
- You've already tried multiple fixes
- Previous fix didn't work
- You don't fully understand the issue
**Don't skip when:**
- Issue seems simple (simple bugs have root causes too)
- You're in a hurry (rushing guarantees rework)
- Manager wants it fixed NOW (systematic is faster than thrashing)
## The Four Phases
You MUST complete each phase before proceeding to the next.
### Phase 1: Root Cause Investigation
**BEFORE attempting ANY fix:**
1. **Read Error Messages Carefully**
- Don't skip past errors or warnings
- They often contain the exact solution
- Read stack traces completely
- Note line numbers, file paths, error codes
2. **Reproduce Consistently**
- Can you trigger it reliably?
- What are the exact steps?
- Does it happen every time?
- If not reproducible → gather more data, don't guess
3. **Check Recent Changes**
- What changed that could cause this?
- Git diff, recent commits
- New dependencies, config changes
- Environmental differences
4. **Gather Evidence in Multi-Component Systems**
**WHEN system has multiple components (CI → build → signing, API → service → database):**
**BEFORE proposing fixes, add diagnostic instrumentation:**
```
For EACH component boundary:
- Log what data enters component
- Log what data exits component
- Verify environment/config propagation
- Check state at each layer
Run once to gather evidence showing WHERE it breaks
THEN analyze evidence to identify failing component
THEN investigate that specific component
```
**Example (multi-layer system):**
```bash
# Layer 1: Workflow
echo "=== Secrets available in workflow: ==="
echo "IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}"
# Layer 2: Build script
echo "=== Env vars in build script: ==="
env | grep IDENTITY || echo "IDENTITY not in environment"
# Layer 3: Signing script
echo "=== Keychain state: ==="
security list-keychains
security find-identity -v
# Layer 4: Actual signing
codesign --sign "$IDENTITY" --verbose=4 "$APP"
```
**This reveals:** Which layer fails (secrets → workflow ✓, workflow → build ✗)
5. **Trace Data Flow**
**WHEN error is deep in call stack:**
See `root-cause-tracing.md` in this directory for the complete backward tracing technique.
**Quick version:**
- Where does bad value originate?
- What called this with bad value?
- Keep tracing up until you find the source
- Fix at source, not at symptom
### Phase 2: Pattern Analysis
**Find the pattern before fixing:**
1. **Find Working Examples**
- Locate similar working code in same codebase
- What works that's similar to what's broken?
2. **Compare Against References**
- If implementing pattern, read reference implementation COMPLETELY
- Don't skim - read every line
- Understand the pattern fully before applying
3. **Identify Differences**
- What's different between working and broken?
- List every difference, however small
- Don't assume "that can't matter"
4. **Understand Dependencies**
- What other components does this need?
- What settings, config, environment?
- What assumptions does it make?
### Phase 3: Hypothesis and Testing
**Scientific method:**
1. **Form Single Hypothesis**SKILL.md 不止这些内容,安装后可阅读全文。
技能包内容
共 11 个文件,合计 39.8 KiB
- CREATION-LOG.md4.2 KiB
- SKILL.md9.7 KiB
- condition-based-waiting-example.ts4.9 KiB
- condition-based-waiting.md3.4 KiB
- defense-in-depth.md3.6 KiB
- find-polluter.sh1.5 KiB
- root-cause-tracing.md5.2 KiB
- test-academic.md653 B
- test-pressure-1.md1.9 KiB
- test-pressure-2.md2.2 KiB
- test-pressure-3.md2.6 KiB
来源与审核
- 审核状态
- 尚未审核,内容来自上游来源
- 许可证
- 未说明
审核状态是平台对上架信息的记录,不构成对上游服务质量或可用性的担保。