Bug Hunter — Structured Debugging Protocol
Version: 1.1.0 | Author: Shadows Company | License: MIT
WHEN TO TRIGGER
- - Runtime errors, exceptions, stack traces
- UI rendering issues or visual bugs
- Regression after recent changes
- User says "debug", "fix this bug", "it's broken", "not working"
- Test failures with unclear root cause
- Performance degradation
WHEN NOT TO TRIGGER
- - Feature requests (use brainstorming skill)
- Code style / formatting issues
- Simple typos with obvious fix
PREREQUISITES
Required:
- -
git — Used in Triage step to inspect recent changes via git log --oneline -10. Detection: which git or git --version.
Optional (auto-detected per project):
- -
pytest — Python test runner, used in Technique 4. Detected via python -m pytest --version or presence of pytest.ini / pyproject.toml [tool.pytest]. - INLINECODE8 — JavaScript test runner, used in Technique 4. Detected via
npx jest --version or presence of jest.config.*. - INLINECODE11 — Vite-based test runner, used in Technique 4. Detected via
npx vitest --version or presence of vitest.config.*.
If no test runner is detected, Technique 4 (Test-Driven Fix) is limited to writing the test file — execution must be deferred.
PROTOCOL — 4 TECHNIQUES
Before choosing a technique, run Triage first:
Triage (MANDATORY — 60 seconds max)
- 1. Read the error message completely — what does it actually say?
- When did it start? Check recent git changes: INLINECODE14
- Is it reproducible? Try the failing action once
- Classify severity: Crash / Wrong result / Visual / Performance
Based on triage, select the most appropriate technique:
Technique 1 — LOG INJECTION (Best for: backend, data flow, async issues)
- 1. Add strategic
console.log / print() at key decision points - Log inputs AND outputs of suspected functions
- Run the failing scenario
- Read logs to identify where expected != actual
- Fix the root cause
- CLEANUP: Remove ALL debug logs before committing
CODEBLOCK0
WARNING: This technique temporarily modifies source files. All injected debug code MUST be removed before any commit. See CLEANUP GUARANTEE below.
Technique 2 — SCREENSHOT ANALYSIS (Best for: UI bugs, layout issues)
- 1. Capture or describe the current (broken) state
- Identify what SHOULD be displayed vs what IS displayed
- Inspect the component tree top-down
- Check: CSS specificity, z-index, overflow, flexbox/grid alignment
- Fix the styling or rendering logic
- Verify at breakpoints: 375px, 768px, 1024px, 1440px
Technique 3 — MANUAL TRACE (Best for: logic errors, algorithm bugs)
- 1. Read the failing function line by line
- Manually compute expected values at each step
- Identify the exact line where expectation diverges from reality
- Check edge cases: null, undefined, empty array, zero, negative
- Fix the logic and add a test for the edge case
Technique 4 — TEST-DRIVEN FIX (Best for: regressions, complex interactions)
- 1. Write a failing test that reproduces the bug FIRST
- Run the test to confirm it fails:
python -m pytest {test_file} -x -q or npx jest {test_file} or INLINECODE19 - Fix the code until the test passes (green)
- Run the full test suite to check for regressions:
python -m pytest -x -q or npx jest or INLINECODE22 - Refactor if needed (refactor)
NOTE: Technique 4 executes the project's test suite, which runs repository code. Only use on trusted repositories or within a sandboxed environment.
PROCESS
CODEBLOCK1
Verification Checklist (after fix)
- - [ ] The original bug is fixed
- [ ] No new errors introduced
- [ ] Existing tests still pass
- [ ] Debug artifacts removed (logs, console.log, print, TODO)
- [ ] Edge cases covered
CLEANUP GUARANTEE
After every fix, the agent MUST perform a final verification pass:
- 1. Search modified files for debug markers: INLINECODE23
- Remove any remaining debug artifacts
- Confirm the working tree is clean of injected debug code before reporting completion
This step is non-negotiable and applies to all techniques, not just Technique 1.
RULES
- 1. Read before guessing — always read the actual error, never assume
- One fix at a time — change ONE thing, test, repeat
- Root cause, not symptoms — fix WHY it broke, not just the surface
- No shotgun debugging — don't change random things hoping it works
- Clean up — remove ALL debug code before committing
- Regression test — add a test to prevent the same bug from returning
SECURITY CONSIDERATIONS
- - Commands executed:
git log (read-only). Technique 4 runs project test suites (pytest, jest, vitest) which execute repository code. - Data read: Source files in the local repository.
- File modification: Technique 1 (Log Injection) temporarily modifies source files to inject debug statements. All injected code MUST be removed before commit (see CLEANUP GUARANTEE).
- Network access: None.
- Persistence: None.
- Credentials: None required.
- Sandboxing: Recommended when using Technique 4 on untrusted repositories, as test execution runs arbitrary project code.
OUTPUT FORMAT
CODEBLOCK2
Published by Shadows Company — "We work in the shadows to serve the Light."
Bug Hunter — 结构化调试协议
版本: 1.1.0 | 作者: Shadows Company | 许可证: MIT
触发时机
- - 运行时错误、异常、堆栈跟踪
- UI渲染问题或视觉缺陷
- 近期变更后的回归问题
- 用户说调试、修复这个bug、它坏了、不工作
- 测试失败且根本原因不明确
- 性能下降
不触发的情况
- - 功能请求(使用头脑风暴技能)
- 代码风格/格式问题
- 有明显修复方案的简单拼写错误
前置条件
必需:
- - git — 在分类步骤中用于通过 git log --oneline -10 检查近期变更。检测方式:which git 或 git --version。
可选(按项目自动检测):
- - pytest — Python测试运行器,用于技术4。通过 python -m pytest --version 或检测 pytest.ini / pyproject.toml [tool.pytest] 来检测。
- jest — JavaScript测试运行器,用于技术4。通过 npx jest --version 或检测 jest.config. 来检测。
- vitest — 基于Vite的测试运行器,用于技术4。通过 npx vitest --version 或检测 vitest.config. 来检测。
如果未检测到测试运行器,技术4(测试驱动修复)将仅限于编写测试文件——执行必须推迟。
协议 — 4种技术
在选择技术之前,必须先执行分类:
分类(强制 — 最多60秒)
- 1. 完整阅读错误信息 — 它实际说了什么?
- 何时开始出现? 检查最近的git变更:git log --oneline -10
- 是否可以复现? 尝试执行一次失败的操作
- 分类严重程度:崩溃 / 错误结果 / 视觉问题 / 性能问题
根据分类结果,选择最合适的技术:
技术1 — 日志注入(最适合:后端、数据流、异步问题)
- 1. 在关键决策点添加策略性 console.log / print()
- 记录疑似函数的输入和输出
- 运行失败场景
- 读取日志以识别期望值与实际值不符的位置
- 修复根本原因
- 清理:在提交前删除所有调试日志
[LOG] function_name() 被调用,参数为:{params}
[LOG] function_name() 返回:{result}
[LOG] condition_check: variable = {value}
警告:此技术会临时修改源文件。所有注入的调试代码必须在提交前删除。请参见下方的清理保证。
技术2 — 截图分析(最适合:UI缺陷、布局问题)
- 1. 捕获或描述当前(损坏的)状态
- 识别应该显示的内容与实际显示的内容
- 自上而下检查组件树
- 检查:CSS特异性、z-index、溢出、flexbox/grid对齐
- 修复样式或渲染逻辑
- 在断点处验证:375px、768px、1024px、1440px
技术3 — 手动追踪(最适合:逻辑错误、算法缺陷)
- 1. 逐行阅读失败函数
- 手动计算每一步的期望值
- 识别期望值与实际情况出现偏差的确切行
- 检查边界情况:null、undefined、空数组、零、负数
- 修复逻辑并为边界情况添加测试
技术4 — 测试驱动修复(最适合:回归问题、复杂交互)
- 1. 首先编写一个复现该缺陷的失败测试
- 运行测试以确认其失败:python -m pytest {testfile} -x -q 或 npx jest {testfile} 或 npx vitest run {test_file}
- 修复代码直到测试通过(变绿)
- 运行完整测试套件以检查回归:python -m pytest -x -q 或 npx jest 或 npx vitest run
- 如有需要则进行重构
注意:技术4会执行项目的测试套件,该套件会运行仓库代码。仅在受信任的仓库或沙盒环境中使用。
流程
分类 → 选择技术 → 调查 → 假设 → 修复 → 验证 → 清理
验证检查清单(修复后)
- - [ ] 原始缺陷已修复
- [ ] 未引入新错误
- [ ] 现有测试仍然通过
- [ ] 调试产物已移除(日志、console.log、print、TODO)
- [ ] 边界情况已覆盖
清理保证
每次修复后,代理必须执行最终的验证检查:
- 1. 搜索修改过的文件中的调试标记:grep -n \\[LOG\\]\|console\\.log\|print(\|debugger\|# DEBUG\|// DEBUG {modified_files}
- 移除任何剩余的调试产物
- 在报告完成前确认工作树中不包含注入的调试代码
此步骤不可协商,适用于所有技术,而不仅仅是技术1。
规则
- 1. 先读后猜 — 始终阅读实际错误,切勿假设
- 一次只修复一个问题 — 改变一件事,测试,重复
- 根本原因,而非症状 — 修复它为什么坏了,而不仅仅是表面问题
- 不要散弹式调试 — 不要随意更改东西期望它能工作
- 清理 — 在提交前删除所有调试代码
- 回归测试 — 添加测试以防止同一缺陷再次出现
安全考虑
- - 执行的命令:git log(只读)。技术4运行项目测试套件(pytest、jest、vitest),这些套件会执行仓库代码。
- 读取的数据:本地仓库中的源文件。
- 文件修改:技术1(日志注入)会临时修改源文件以注入调试语句。所有注入的代码必须在提交前删除(参见清理保证)。
- 网络访问:无。
- 持久性:无。
- 凭据:无需。
- 沙盒化:建议在不受信任的仓库上使用技术4时进行沙盒化,因为测试执行会运行任意项目代码。
输出格式
markdown
缺陷报告
- - 错误:[确切的错误信息]
- 严重程度:[崩溃/错误结果/视觉问题/性能问题]
- 可复现性:[是/否 + 步骤]
根本原因
[解释缺陷发生的原因]
已应用的修复
[修复描述,包含文件:行引用]
验证
- - [x] 原始缺陷已解决
- [x] 测试通过
- [x] 无调试产物残留
由 Shadows Company 发布 — 我们隐于暗影,服务于光明。