This is the fourth post in my Waza skill design series, and probably the last major one. I have already touched on /read and /learn, so this time I want to talk about /hunt, the engineer skill for debugging and problem investigation.
One thing that really separates serious AI coding from shallow usage is how people use AI to work through problems that have stayed unresolved for a long time. The difference in debugging approach is usually very obvious. It is also one of the reasons experienced engineers can use AI to solve much more complex problems than people who do not have the same technical depth.
I kept running into the same pattern before. Claude Code would hit a problem and produce a patch. You would say it did not work, and it would offer another one. Four or five rounds later, new issues would appear. It was patching without ever diagnosing the real cause, which felt a lot like how junior engineers debugged before AI existed.
The core rule in /hunt is simple: until the AI can explain the root cause in one clear sentence, it is not allowed to touch the code. That sentence also has to be precise. It cannot be vague. It has to identify the cause in a concrete way.
I also built a “self-deception checklist” to stop the model from falling into common forms of self-justification. Each pattern has its own rule, and the gotchas section contains real cases. I keep updating and abstracting those examples from issues I have investigated over the past month.
The hypothesis validation stage also has real work attached to it. The model is expected to add new observation methods, such as logs, assertions, or a minimal failing test case. If the issue still remains after a fix, it should switch approaches quickly. Instead of trying endless patches, it should prepare a handoff that clearly states what was checked, which directions were investigated, and what is still unknown, so the user can decide how to proceed.
The output is structured as well: where the root cause is file:line, what changed file:line, what evidence shows the issue is fixed, and what the test results look like. The final status has only three valid outcomes: resolved, resolved with caveats, or blocked.
That is really what /hunt is trying to become: something closer to an experienced engineer. When a problem shows up, it does not guess. It slows down, finds the actual cause, diagnoses it clearly, and then solves it in one focused pass. In practice, that usually saves a lot of time.
And if you have better debugging methods, I would love to hear them, or see a PR.
显示更多