thaapasa

Review code changes from a specific angle or do a general pass. Use when the user wants a code review of their current branch or specific changes. For a thorough review covering all checks, use the @agent-review subagent instead. To review changes against a spec/source of truth (with doc-coverage and duplication checks), use /scoped-review instead.

Scoped code review — determines the change scope (explicit, discussion, or git), picks a source of truth (discussion, new docs, or code), then reviews the changes for correctness, doc agreement, doc coverage, convention adherence, duplicated shapes that want a shared abstraction, hand-rolled complex logic that wants a named/shared function, and unit-test coverage of complex logic.

Create a git commit with a well-crafted message. Use proactively whenever the user asks to commit changes or amend a commit.

Review documentation for accuracy against the current implementation. Use when documentation files are modified, when code changes may have made docs outdated, or when the user asks about documentation accuracy.

Refactor outdated patterns in the codebase based on user input

Refactor frontend components to follow Mantine coding conventions. Use when asked to refactor, modernize, or clean up UI code.

Periodic documentation review — checks docs/ hygiene, verifies features.md / planned.md / architecture.md / README.md / CLAUDE.md match implementation, and audits the mdbook manual against actual CLI flags, keybindings, and shipped file-type support.

Analyze a target — a crate, a module within a crate, or a single file — for its surface within peek, its place in the architecture, its API, its correctness, and its efficiency. Produces an overview followed by findings. Catches obvious bugs, not a deep edge-case bug hunt.

Periodic architectural review — critically re-examines existing design choices, hunts duplication, flags refactor candidates, checks conventions

Scoped code review — determines the change scope (explicit, discussion, or git), picks a source of truth (discussion, new docs, or code), then reviews the changes for correctness, doc agreement, doc coverage, convention adherence, duplicated shapes that want a shared abstraction, hand-rolled complex logic that wants a named/shared function, and unit-test coverage of complex logic.

Generate a 1-3 sentence user-facing highlight blurb for the next release. Reads commits since the last tag, filters out internal refactors / docs / tests / CI / chores, summarises only what a peek user would notice. Output is text the user pastes into the release workflow input after review. Use when user says "release highlight", "highlight for next release", "what's new", "release notes blurb", "/release-highlight".

Creative brainstorming persona. TRIGGER when: user says "Hey Joe", "Joe", "Bishop", or asks for feature ideation, brainstorming, user experience thinking, creative problem-solving, "what if" questions, visionary ideas, requirements, or product direction. Joe is the non-technical ideas guy.

Documentation guardian persona. TRIGGER when: user says "Hey Simms", "Simms", "Jennifer", or asks for documentation cleanup, README updates, doc maintenance, cross-reference checks, markdown formatting, documentation audits, or keeping docs in sync with code changes.

Technical implementation persona. TRIGGER when: user says "Hey Skippy", "Skippy", or asks for code implementation, debugging, performance optimization, architecture decisions, code review, or figuring out what's technically possible. Skippy determines feasibility and does the actual work.

Scoped code review — determines the change scope (explicit, discussion, or git), picks a source of truth (discussion, new docs, or code), then reviews the changes for correctness, doc agreement, doc coverage, convention adherence, duplicated shapes that want a shared abstraction, hand-rolled complex logic that wants a named/shared function, and unit-test coverage of complex logic.