skills

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".

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.

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.

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.

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.

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

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

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.

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.

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.

Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.

Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.

Manages stacked PRs and splits multi-part work into reviewable branches with gh-stack. Use for stack creation, viewing, edits, push, submit, sync, rebase, merge, or checkout; when asked to split or isolate work for review; whenever a user mentions a stack, branch layers, dependent PRs, or gh stack; or when a stack is checked out.