hunt
/hunt — aggressive debugging
You are hunting a bug. The goal is the ultimate root cause, not the first plausible fix. Move fast, but never skip a phase. Evidence beats reasoning every time.
Hard rules (refuse these even if tempted)
- No fix without a deterministic repro. If you can't make it fail on demand, the bug is the non-determinism. Fix that first.
- No symptom suppression. Don't catch-and-swallow, don't add a retry, don't disable the failing test, don't lower the log level.
- One variable per experiment. Two changes at once = no signal.
- Don't theorize without running. Pattern-matching a likely cause is a tempting LLM trap. Instrument, then form hypotheses.
- First plausible cause ≠ root cause. "X could explain this" is not "X did cause this." Confirm causation explicitly (Phase 9).
- Don't trust assumptions. "It can't be the cache." Yes it can. Verify.
- Test failures mean the code is wrong. Default assumption when a test newly fails after a code change. Don't "fix" the test.
- Heisenbug ≠ fixed. Three passing re-runs is not a fix. Find the uncontrolled variable.
If the user proposes any of these as a shortcut, push back and explain which rule it violates.
Phases
More from patrickruddiman/skills
spec
Write a detailed, objective specification of WHAT a system does and WHY. No code, no file paths, no library picks, no implementation prescriptions of any kind. The spec is read by an AI coding agent that will produce its own plan; the spec exists to bound the problem completely — every user-visible behavior, persona task, lifecycle transition, and failure mode.
10slice
Produce a scoped design doc for one technical vertical of a parent spec. Researches the existing codebase first, surfaces implementation choices as questions one at a time, and only drafts the doc after the user resolves them. No code, no tasks — design only.
9create-tasks
Break a slice into AI-executable task files. Each task has a checkbox Tasks section (file paths, line numbers, technical detail — no code) and a strictly code-verifiable Acceptance criteria section that always includes a test command. The consuming AI must tick checkboxes as it works; create-tasks uses that to decide whether to edit a task in place on re-run or append a new one.
9worktree
Create or enter a git worktree for the current repo. New worktrees are named repo-<slug>, placed as a sibling of the repo root, and check out a branch (existing or new). Use when the user says "/worktree", "spin up a worktree", "branch off into a worktree", "hop into worktree X", or wants to work on a separate branch in parallel without disturbing the current checkout.
6schedule
Schedule a one-shot task (Windows/Linux/macOS) to run a command or prompt at a specific time or after a delay. Use when the user says "schedule", "/schedule", "in N minutes/seconds run", "at HH:MM run", "remind me to run", "queue this for later", or wants a task to fire reliably while they step away.
6best-practice
Align a repo or branch with current coding best practices — detect divergences from project conventions and the industry baseline (tests, types, error handling at boundaries, naming, security, observability, documentation), then apply alignment changes one type per commit with tests staying green throughout. Produces commits, not reports. Use when the user says "/best-practice", "align this branch", "best practices pass", "bring this repo up to standard", "fix conventions across this branch", "what's missing from best practices".
4