Menu
Use when fixing a bug, refactoring existing code without changing its behavior, or adding a feature that extends existing behavior — any code change that needs a verifiable foundation before the change is made.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | problem-solver |
| description | Use when fixing a bug, refactoring existing code without changing its behavior, or adding a feature that extends existing behavior — any code change that needs a verifiable foundation before the change is made. |
Whatever the task, build a verifiable foundation first, make the change on top of it, then have a fresh-eye reviewer validate — and repeat until it holds.
Core principle: Never change code you cannot verify. Establish the check (a reproduction, or solid tests) before touching anything.
Before anything, collect:
If any of this is unclear: stop and ask, do not guess. Use AskUserQuestion with targeted questions, then restate the problem before proceeding.
Then route to the matching track and follow that file:
| Task | Read |
|---|---|
| Fix a bug / unexpected behavior / error | references/bug-fix.md |
| Refactor existing code (behavior preserved) | references/refactoring.md |
| Add a feature (behavior extended) | references/feature-addition.md |
Every track gates each phase with an independent review. REQUIRED for all tracks: references/third-party-evaluation.md.
Use when the user explicitly runs /setup-precommit to install or refresh a quiet, staged-only git pre-commit hook (secretlint → oxlint → oxfmt) wired through package.json "prepare". User-invoked command only, never auto-triggered.
Use when the user asks to create, make, or start a new branch (e.g. `/branch`), or wants a conventional-commit-style branch name generated from the current work.
Use when auditing or improving an agent skill package before it ships or is handed off.
Use when the user is working on their own PR — drafting/creating it, handling reviewer comments, verifying fixes, or requesting re-review.
Use when reviewing someone else's PR at any stage of the review lifecycle — digest a PR, write a review, or verify follow-up changes.
Use when the user wants to A/B test prompts or workflows, validate behavioral equivalence, or stress-test non-deterministic outputs at scale via repeated multi-agent runs.
