razorback

Use when planning or reviewing non-trivial code changes, refactoring architecture, evaluating module boundaries, repeated findings reveal coupling, tests are hard to write because interfaces are unclear, or the user asks for codebase design improvements, complexity reduction, deduplication, or cleanup of existing code.

Use when starting any creative work - creating a feature, building a component, adding functionality, or changing designed behavior - before writing code or invoking any implementation skill. Small defect repairs and tweaks triage through razorback:fixing-small-issues first.

Use when the user says "ask claude", "fresh claude review", "second opinion from another claude", "have another claude look at this", "delegate to a fresh claude", or any variation naming Claude as the second perspective they want.

Use when the user says "ask codex", "get codex's take", "codex review", "have codex look at this", "delegate to codex", or any variation naming Codex/OpenAI as the perspective they want. Also use for a generic "second opinion from a different model" when no other model is named.

Use when the user explicitly asks to use Cursor Agent, Cursor CLI, Composer, Composer 2.5, or to delegate implementation work to Cursor from another harness.

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

Use when executing a written implementation plan single-agent — separate-session, single-task, or no-delegation runs.

Use when implementation is complete, branch verification passes, and you need to decide how to integrate the work

Use when a reported defect or requested tweak looks small and local — a button not disabled, a double-submit, an off-by-one, a wrong label, CSS/styling adjustments, copy changes, config value fixes — before invoking brainstorming, creating a worktree, or running any test suite.

Use when the user says "ask grok", "get grok's take", "grok review", "have grok look at this", "delegate to grok", or any variation naming Grok/xAI as the perspective they want.

Use when writing code against an external framework, library, or API — especially a version or feature newer than your training data, an unfamiliar dependency, or behavior that may have changed (new directives, breaking changes, renamed options, deprecations, changed defaults).

Use when the user says "razorback debt", "harvesting-debt", "debt ledger", "what did we defer", "list the shortcuts", or "what did we mark to do later" — any request to account for deliberate shortcuts marked with `razorback:` comments.

Use after all tasks are complete and branch verification passes, before finishing-a-development-branch, when a pre-merge external reviewer was chosen for the run (codex or claude).

Use when a design question resists discussion — a state model with more edge cases than fit in your head, a UI the user keeps flip-flopping on because nobody can picture it, or behavior only knowable by running it — before writing a design doc or implementation plan for that question.

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable

Use when the lead needs inline-review criteria during plan execution, or when reviewing work done outside an approved plan - ad-hoc features, baseline checks before a refactor, or when stuck. Not for planned pre-merge external review — that's razorback:pre-merge-review.

Use when running a security review, a secrets scan, or a dependency/CVE audit, when the branch gate needs its security scopes, when checking or declaring the external-model policy, or when asking "can I send this diff to codex/claude/grok/cursor".

Use when executing an approved implementation plan in the current session and the harness can launch subagents.

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Use when implementing any feature or bugfix, before writing implementation code

Use when starting feature work that needs isolation from the current workspace, or before executing implementation plans

Use when starting any conversation, before any response or action including clarifying questions.

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs

Use when you have a spec or requirements for a multi-step task, before touching code

Use when creating new skills, editing existing skills, or verifying skills work before deployment