XIN

Review code changes as a careful senior engineer for correctness defects, quality cost (reuse, simplification, efficiency, altitude), and design cost (API contracts, component responsibility, readability), then report findings as a structured list; with `fix`, apply the safe ones; `simplify`, not `/simplify` command, runs the quality angle alone and fixes. Automatically picks the review scope — working diff, PR, branch, or file — from the user's words and repo state. Use for "review my changes", "check this diff for bugs", "review this PR", "code review this branch", "simplify my changes", "clean this up".

Turn the current conversation into a spec — no interview, just synthesis of what you've already discussed.

Review a spec through three lenses — is the feature needed, is the spec complete, does the implementation plan hold up. Use when the user asks to review, critique, or sanity-check a spec or draft spec.

Review the changed code for reuse, simplification, efficiency, and altitude cleanups, then apply the fixes. Quality only — it does not hunt for bugs.

Survey the codebase for high-leverage architecture improvements — misplaced state, awkward file structure, blurry module boundaries — and report the few changes worth making. Use when the user asks whether the architecture or file organization could be better, where some state should live (local vs global/store), or wants refactoring direction beyond a single diff.

Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.

Verify a completed implementation against a spec's Acceptance Criteria and Verification Plan. Use after implementation or any later code change.

Create a GitHub pull request for the current branch with a conventional-commit title and this repo's PR body template (What changed / Why / User impact / Validation). Use whenever the user asks to open, create, submit, or send a PR, or to "push this up for review" — including right after finishing a feature or fix, even if they don't say "pull request" explicitly.

Create git commits with conventional commit messages and split broad diffs into multiple logical commits when needed. Use when the user asks to commit, or when a diff must be inspected, grouped into logical commits, staged safely, and committed with messages such as `feat(scope): summary` or `fix(scope): summary` instead of creating one unfocused commit.

Investigate a question with cited evidence, going wherever the answer is observable first-hand — market landscape, community sentiment, a specific code repository, or anything else external. Use when the user asks to research, look into, or validate something about a market, competitors, what people are saying, or an external repo.

Adversarially validate a product idea against reality — two parallel agents build the strongest evidenced case for and against it, then the main thread rules on evidence quality. Use when the user asks whether an idea is actually worth building, wants it validated with real evidence rather than conversation, or a big idea emerges from /talk-about-an-idea with stakes high enough to justify two research agents.

Think through a product idea in open conversation — develop it, don't judge it. Use when the user floats an idea, asks "what do you think about…", or wants a sounding board before anything is planned or built.