best-practice
/best-practice
Take a code surface — by default the current branch's diff against main, optionally the whole repo — and align it with current coding best practices. The deliverable is a series of commits, not a report. Each commit applies one type of alignment (e.g. "add type hints to changed files", "replace broad excepts with specific handlers", "add tests for new endpoints") with tests staying green throughout.
The skill aligns to two things in priority order: (1) project conventions the codebase already establishes — naming, file layout, error-handling pattern, logging style, test style; (2) industry baseline — things any modern codebase should have (rigorous tests, no broad exception swallowing, no hardcoded secrets, validation at boundaries, types where the language and project support them). Project conventions trump industry defaults: if the codebase consistently uses positional arguments, alignment doesn't refactor to keyword arguments.
Grounded in .research/code-simplification.md §2 (heuristics), §4 (metrics), §5 (SOLID), §8 (anti-patterns).
When to use
- User says "/best-practice", "align this branch", "best practices pass", "bring this repo up to standard", "fix conventions across this branch", "make sure best practices are followed".
- A pull request is about to merge but the branch hasn't been aligned with conventions.
- A new contributor's branch needs to be brought into the codebase's style and discipline.
- Periodic codebase sweep: pick a quality dimension (tests, types, error handling, etc.) and align the whole repo to it.
- Onboarding a project: align everything to a consistent baseline before development continues.
When NOT to use
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.
9hunt
Aggressively debug, diagnose, or root-cause an issue. Drives a disciplined hunt — query telemetry, reproduce, bisect, instrument, hypothesize-test-confirm, and verify causation by reverting the fix. Refuses common anti-patterns (fix-without-repro, symptom suppression, multi-variable changes, theorize-without-running). Use when the user types /hunt or asks to debug, diagnose, root-cause, track down, or figure out a bug, crash, regression, flaky test, or unexplained behavior.
7worktree
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.
6