razorback

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 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 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 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 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 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 starting any conversation, before any response or action including clarifying questions.

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

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

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 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 executing an approved implementation plan in the current session and the harness can launch subagents.

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

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 wants two models to check each other's work until clean — "have codex verify my findings and find more", "go back and forth until clean", "loop until you both agree there are no problems left" — when an audit should run to convergence under /loop or another goal-driven runner, or when a design decision needs adversarial challenge before building: "doubt this", "challenge this decision", or architecture risk rated medium/high.

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

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

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

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

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 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 explicitly asks to use Cursor Agent, Cursor CLI, Composer, Composer 2.5, or to delegate implementation work to Cursor from another harness.