
Hunt
Diagnose recurring or environmental bugs using named failure patterns instead of another one-off local syntax fix.
Overview
hunt is a journey-wide agent skill that catalogs recurring failure patterns and boundary checks—usable whenever a solo builder needs to systematic-debug runtime, cache, queue, or artifact issues before committing another
Install
npx skills add https://github.com/tw93/waza --skill huntWhat is this skill?
- Four documented failure archetypes: stale verifier/tool cache, worker queue/DB boundary, generated rebuild boundary, gua
- Each pattern lists signals, ordered checks, and boundary-focused regression guidance
- Explicit stale-path checks before clearing caches; re-run verifier from current repo root
- Enqueue-to-worker-to-UI trace for queue bugs; inspect artifact contents not only source diffs
- Four named failure pattern sections in the reference
Adoption & trust: 6.6k installs on skills.sh; 5.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
The same bug keeps resurfacing after a plausible code change because the real failure lives in caches, queues, generated output, or guard lifetime.
Who is it for?
Indie developers stuck on flaky verifiers, background workers, codegen drift, or permission races after the obvious diff failed.
Skip if: First-time syntax errors or greenfield features with no reproduction yet—use normal debugging first.
When should I use this skill?
A bug has repeated, a first fix did not hold, or the symptom smells like runtime state rather than local code syntax.
What do I get? / Deliverables
You match symptoms to a named pattern, run the listed boundary checks, and target regression tests at the correct pipeline edge.
- Matched failure pattern with completed boundary checklist
- Regression test targeted at enqueue, artifact, or guard boundary when applicable
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
CI verifier cites a deleted worktree path—run stale-cache checks before clearing tool cache.
API behavior unchanged after handler edit—inspect generated bundle and build watch rules.
Dashboard shows running jobs but nothing dequeues—trace enqueue, worker pickup, and persistence.
Permission guard works in dev but fails after relaunch—trace guard lifetime and invalidation paths.
How it compares
Pattern playbook for systemic bugs—not a linter or single-stack stack-trace explainer.
Common Questions / FAQ
Who is hunt for?
Solo builders and small teams who ship frequently and hit bugs that look environmental or intermittent rather than a single bad line.
When should I use hunt?
Use it during Ship testing when CI paths look stale, during Operate errors when workers desync from UI, during Build backend when generated artifacts lag source, and anytime a guard fails only after relaunch or delayed callbacks.
Is hunt safe to install?
It is read-only debugging guidance; review the Security Audits panel on this Prism page for the parent waza repository.
SKILL.md
READMESKILL.md - Hunt
# Failure Pattern Reference Use this when a bug has repeated, a first fix did not hold, or the symptom smells like runtime state rather than local code syntax. ## Stale Verifier Or Tool Cache Signals: verifier output points at deleted temp worktrees, old generated files, or paths outside the current repo; rerunning after a clean checkout changes the file path but not the current code. Checks: - Confirm the reported path exists. - Clear the tool cache only after proving the path is stale. - Re-run the same verifier from the current repo root. ## Worker Queue Or DB Boundary Signals: UI says work is running but no worker processes it; logs show scheduler activity but no queued row; retry fixes one item but not the pipeline. Checks: - Trace request -> enqueue -> worker pickup -> persistence -> UI refresh. - Inspect queue rows or job state directly. - Add a regression test around the enqueue boundary, not only the worker body. ## Generated Rebuild Boundary Signals: source changed but generated output, app bundle, CLI artifact, archive, checksum, or release package still contains old behavior. Checks: - Identify the source-to-artifact rule. - Verify the build system watches the source path. - Inspect the generated artifact contents, not just the source diff. ## Guard Lifetime Race Signals: permission, auth, or state guard looks correct locally but a delayed callback, app relaunch, or alternate entry point bypasses it. Checks: - Trace guard creation, retention, invalidation, and every alternate entry point. - Verify cold launch, warm launch, deep link/file open, and retry paths when applicable. - Prefer explicit durable state over transient flags when the guard must survive relaunch. ## Atomic Temp Filename Signals: concurrent runs collide, cleanup removes the wrong file, or a partially written output is observed. Checks: - Use unique temp directories or atomic rename. - Keep cleanup scoped to files created by the current run. - Test two concurrent or back-to-back runs when the tool supports it. ## Path, Cwd, Or Symlink Escape Signals: an operation intended for one root touches a sibling directory, follows a symlink unexpectedly, or behaves differently from another working directory. Checks: - Resolve and compare canonical roots before writing or deleting. - Reject paths outside the allowed root after symlink resolution. - Reproduce from a non-default cwd and through any UI entry point that supplies paths. ## CLI Effect Scope Drift Signals: preview, dry-run, size, count, or report output is computed from one predicate, but execution mutates a broader or different set. Checks: - Trace display, dry-run, and mutation predicates to the same source of truth. - Compare planned paths or records with executor input in a regression test. - Assert partial failures report the exact skipped and completed items. ## CLI Wrapper Or PATH Drift Signals: source-tree invocation works, but the installed command, package wrapper, PATH shim, completion, or package-manager install path runs old code or a different binary. Checks: - Inspect built package contents, shebang, executable bit, and wrapper target. - Reproduce through a temp prefix or package-manager install path, not only from source. - Check PATH order and use absolute system-tool paths where wrappers should not intercept. ## Interactive Stdin Or TTY Hang Signals: CI stalls, spinner never finishes, a subprocess reads from the script body, or an auth prompt appears in non-interactive mode. Checks: - Reproduce with stdin redirected and with TTY/non-TTY paths separated. - Add test-mode or no-auth guards around real prompts and system changes. - Stub external prompt tools through PATH when timeout wrappers exec real binaries. ## Signal Or Partial-Failure Mapping Signals: cancel, timeout, SIGINT, or SIGTERM is reported as success or as a normal business failure; temp files, locks, or operation logs make retries look complete. Checks: - Classify interrupted execution sep