systematic-debugging
系统化调试技能，遵循‘无根因调查不修复’的铁律，通过四阶段流程（根因调查、模式分析、假设测试、实施）定位并修复问题，强调避免症状修补。
适合修复测试失败
调试、测试与代码评审
把系统化排查、TDD、完成前验证和代码评审串成闭环，适合修复杂 bug、减少回归和交付前自检。
- 收录
- 6 个 Skill
- 顺序
- 按专题推荐流程
从第一项开始使用
专题内 Skills
6 个结果
test-driven-development
一套强制纪律的测试驱动开发（TDD）工作流技能：先写一个最小失败测试（RED），必须亲眼看到它以预期原因失败，再写刚好通过测试的最简代码（GREEN），并运行整个项目测试套件确认全绿，最后在保持绿灯的前提下重构（REFACTOR），循环重复。核心铁律是“没有失败测试，就不写生产代码”，先写实现再补测试被视为需删除代码重来；同时列出常见合理化借口、红旗信号、验证清单，以及测试难以编写时的设计排错建议。适用于新功能、Bug 修复、重构与行为变更，一次性原型、生成代码、配置文件等例外需征得人类搭档同意。
适合Agent 实现新功能时，需要先写失败测试再写实现
requesting-code-review
来自 obra/superpowers 的技能，用于在完成任务、实现主要功能或合并前请求代码审查。它要求先取 git SHA（如 BASE_SHA=$(git rev-parse HEAD~1) 或 git merge-base origin/main HEAD，HEAD_SHA=$(git rev-parse HEAD)），再派发一个 general-purpose 审查子代理，并填写 code-reviewer.md 模板，提供 DESCRIPTION、PLAN_OR_REQUIREMENTS、BASE_SHA、HEAD_SHA 四个占位符信息，只给审查者精确构造的上下文，不给整个会话历史。技能列出必须审查的时机（子代理驱动开发中每个任务后、完成主要功能后、合并到 main 前）与可选时机（卡住时、重构前、修复复杂 bug 后），并规定对反馈的处理方式（Critical 立即修、Important 继续前修、Minor 记录、可基于技术理由反驳），另附常见借口对照表与红旗清单。
适合子代理驱动开发中，每完成一个任务后请求审查
verification-before-completion
该技能要求在声称任务完成、修复或通过之前，必须先运行验证命令并确认输出，始终遵循“证据先于声明”的原则。
适合在提交代码或创建 PR 之前确保验证已执行
fix
在提交前集中处理 lint、格式化和基础错误，避免因低级问题阻断 CI 或返工。
适合适合提交前的代码整理和校验。
verify
在提交前核对改动是否满足 React 要求，并确认测试结果和约束都已过关。
适合适合提交前验证改动是否可交付。