vgv-wingspan

Analyzes implementation plans for scope and recommends splitting large plans into multiple independently-mergeable PRs. Use during plan technical review to catch oversized plans before development begins. <examples> <example> Context: Developer runs /plan-technical-review on a large feature plan. user: "Review this plan for the new authentication flow — it touches API client, repository, state management, and three screens." assistant: "I'll run the plan-splitting agent to assess whether this should be split across multiple PRs." <commentary> Plans spanning multiple layers (data, domain, presentation) with new packages are strong candidates for splitting. </commentary> </example> <example> Context: Developer runs /plan-technical-review on a small bug fix. user: "Review this plan for fixing the cart total calculation." assistant: "I'll include the plan-splitting agent — it will confirm this is small enough for a single PR." <commentary> Small, focused plans should pass through quickly with a "no split needed" assessment. </commentary> </example> <example> Context: Developer has a large but tightly coupled plan. user: "Review this plan — it adds a single complex component with its state management, repository, and API client, all interdependent." assistant: "I'll run the plan-splitting agent to check if this can be split, or if the coupling means it should stay as one PR." <commentary> Not all large plans can be split. The agent should recognize tight coupling and recommend keeping as a single PR with a scope warning rather than forcing an awkward split. </commentary> </example> </examples>

Analyzes specifications and feature descriptions for user flow completeness and gap identification. Use when a spec, plan, or feature description needs flow analysis, edge case discovery, or requirements validation.

Final review pass to ensure code is as simple and minimal as possible. Use after implementation is complete to identify YAGNI violations and simplification opportunities.

Conducts a thorough review of the given codebase, ensures code quality standards are met, and validates that the codebase uses consistently the same patterns. <examples> <example> Context: User wants to understand the codebase structure and conventions before contributing. user: "I need to understand how this project is organized and what patterns they use" assistant: "I'll use the codebase-review-agent to conduct a thorough analysis of the repository structure and patterns." <commentary> Since the user needs comprehensive codebase research, use the codebase-review-agent to examine all aspects of the project. </commentary> </example> <example> Context: User is preparing to create a GitHub issue and wants to follow project conventions. user: "Before I create this issue, can you check what format and labels this project uses?" assistant: "Let me use the codebase-review-agent to examine the repository's issue patterns and guidelines." <commentary> The user needs to understand issue formatting conventions, so use the codebase-review-agent to analyze existing issues and templates. </commentary> </example> <example> Context: User is implementing a new feature and wants to follow existing patterns. user: "I want to add a new service object - what patterns does this codebase use?" assistant: "I'll use the codebase-review-agent to search for existing implementation patterns in the codebase." <commentary> Since the user needs to understand implementation patterns, use the codebase-review-agent to search and analyze the codebase. </commentary> </example> </examples>

Reviews code against Very Good Ventures engineering standards. Use after implementing features, modifying code, creating new packages, or before opening PRs. Enforces architecture, state management conventions, testing quality, and code simplicity. <examples> <example> Context: The user has just implemented a new feature with state management and wants it reviewed. user: "I just finished implementing the authentication feature with a new service and state management" assistant: "I'll use the VGV review agent to evaluate this implementation against our engineering standards." <commentary> New state management implementations should be reviewed for proper design, layer separation, test coverage, and adherence to VGV conventions. </commentary> </example> <example> Context: The user has added state management that deviates from the project pattern. user: "I added a different state management approach for managing the shopping cart state" assistant: "Let me invoke the VGV review agent to analyze this architectural decision." <commentary> Using a different state management pattern than the project standard is an architectural deviation that should be reviewed critically. </commentary> </example> <example> Context: The user has created a new package in the monorepo. user: "I've created a new package under packages/ for the payments feature" assistant: "I'll have the VGV review agent check the package structure, layering, and conventions." <commentary> New packages should follow the project's monorepo conventions, layer separation, linting setup, and testing scaffolding. </commentary> </example> <example> Context: The user has refactored existing code and wants a quality check. user: "I refactored the user profile feature to reduce code duplication" assistant: "Let me run the VGV review agent to ensure the refactor maintains our quality bar and doesn't introduce regressions." <commentary> Refactors to existing code should be reviewed strictly for regressions, clarity improvements, and whether the changes actually simplify rather than shift complexity. </commentary> </example> </examples>

Explores requirements and approaches through collaborative dialogue before planning implementation.

Executes an implementation plan — writes code and tests, runs quality review, and ships a pull request.

Sets up a workspace branch or worktree before writing artifacts.

Propose and create conventional commit messages for staged changes. Follows Conventional Commits spec and VGV workflow.

Stage, commit, push, and open a pull request following project conventions and the Conventional Commits spec. Accepts optional skip-checks argument to bypass validation when called from /build.

1 hook across 1 event