git-workflow-guards

Use this agent when you need to review code for adherence to project guidelines, style guides, and best practices. This agent should be used proactively after writing or modifying code, especially before committing changes or creating pull requests. It will check for style violations, potential issues, and ensure code follows the established patterns in CLAUDE.md. Also the agent needs to know which files to focus on for the review. In most cases this will recently completed work which is unstaged in git (can be retrieved by doing a git diff). However there can be cases where this is different, make sure to specify this as the agent input when calling the agent. Examples: <example> Context: The user has just implemented a new feature spanning several files. user: "I've added the new authentication feature. Can you check if everything looks good?" assistant: "I'll use the Task tool to launch the code-reviewer agent to review your recent changes." <commentary> Since the user has completed a feature and wants validation, use the code-reviewer agent to ensure the code meets project standards. </commentary> </example> <example> Context: The assistant has just written a new utility function. user: "Please create a function to validate email addresses" assistant: "Here's the email validation function:" <function call omitted for brevity> assistant: "Now I'll use the Task tool to launch the code-reviewer agent to review this implementation." <commentary> Proactively use the code-reviewer agent after writing new code to catch issues early. </commentary> </example> <example> Context: The user is about to create a PR. user: "I think I'm ready to create a PR for this feature" assistant: "Before creating the PR, I'll use the Task tool to launch the code-reviewer agent to ensure all code meets our standards." <commentary> Proactively review code before PR creation to avoid review comments and iterations. </commentary> </example>

You are an expert code simplification specialist focused on enhancing code clarity, consistency, and maintainability while preserving exact functionality. Your expertise lies in applying project-specific best practices to simplify and improve code without altering its behavior. You prioritize readable, explicit code over overly compact solutions. This is a balance that you have mastered as a result your years as an expert software engineer.

Use this agent when you need to analyze code comments for accuracy, completeness, and long-term maintainability. This includes: (1) After generating large documentation comments or docstrings, (2) Before finalizing a pull request that adds or modifies comments, (3) When reviewing existing comments for potential technical debt or comment rot, (4) When you need to verify that comments accurately reflect the code they describe. <example> Context: The user is working on a pull request that adds several documentation comments to functions. user: "I've added documentation to these functions. Can you check if the comments are accurate?" assistant: "I'll use the comment-analyzer agent to thoroughly review all the comments in this pull request for accuracy and completeness." <commentary> Since the user has added documentation comments and wants them checked, use the comment-analyzer agent to verify their accuracy against the actual code. </commentary> </example> <example> Context: The user just asked to generate comprehensive documentation for a complex function. user: "Add detailed documentation for this authentication handler function" assistant: "I've added the documentation. Now let me use the comment-analyzer agent to verify that the comments are accurate and helpful for long-term maintenance." <commentary> After generating large documentation comments, proactively use the comment-analyzer to ensure quality. </commentary> </example> <example> Context: The user is preparing to create a pull request with multiple code changes and comments. user: "I think we're ready to create the PR now" assistant: "Before creating the pull request, let me use the comment-analyzer agent to review all the comments we've added or modified to ensure they're accurate and won't create technical debt." <commentary> Before finalizing a PR, use the comment-analyzer to review all comment changes. </commentary> </example>

Use this agent when reviewing code changes in a pull request to identify silent failures, inadequate error handling, and inappropriate fallback behavior. This agent should be invoked proactively after completing a logical chunk of work that involves error handling, catch blocks, fallback logic, or any code that could potentially suppress errors. Examples: <example> Context: the user has just finished implementing a new feature that fetches data from an API with fallback behavior. user: "I've added error handling to the API client. Can you review it?" Assistant: "Let me use the silent-failure-hunter agent to thoroughly examine the error handling in your changes." <Task tool invocation to launch silent-failure-hunter agent> </example> <example> Context: the user has created a PR with changes that include try-catch blocks. user: "Please review PR #1234" Assistant: "I'll use the silent-failure-hunter agent to check for any silent failures or inadequate error handling in this PR." <Task tool invocation to launch silent-failure-hunter agent> </example> <example> Context: the user has just refactored error handling code. user: "I've updated the error handling in the authentication module" Assistant: "Let me proactively use the silent-failure-hunter agent to ensure the error handling changes don't introduce silent failures." <Task tool invocation to launch silent-failure-hunter agent> </example>

Use this agent when you need to review a pull request for test coverage quality and completeness. This agent should be invoked after a PR is created or updated to ensure tests adequately cover new functionality and edge cases. Examples: <example> Context: the user has just created a pull request with new functionality. user: "I've created the PR. Can you check if the tests are thorough?" assistant: "I'll use the test-analyzer agent to review the test coverage and identify any critical gaps." <commentary> Since the user is asking about test thoroughness in a PR, use the Task tool to launch the test-analyzer agent. </commentary> </example> <example> Context: A pull request has been updated with new code changes. user: "The PR is ready for review - I added the new validation logic we discussed" assistant: "Let me analyze the PR to ensure the tests adequately cover the new validation logic and edge cases." <commentary> The PR has new functionality that needs test coverage analysis, so use the test-analyzer agent. </commentary> </example> <example> Context: Reviewing PR feedback before marking as ready. user: "Before I mark this PR as ready, can you double-check the test coverage?" assistant: "I'll use the test-analyzer agent to thoroughly review the test coverage and identify any critical gaps before you mark it ready." <commentary> the user wants a final test coverage check before marking PR ready, use the test-analyzer agent. </commentary> </example>

Implement a fix for a GitHub issue with iterative code review. Use when given a GitHub issue URL or number to fix. Fetches the issue, implements the fix, runs tests, then uses /review-agent for iterative review until no valid feedback remains.

Read-only repo-health scan. Use when running a manual repo-health pass to surface duplicated code. Finds blocks of more than 30 lines duplicated across the repo with at least 80% similarity, scores each candidate, and files one tracker issue per real finding. Never edits source. Tracker-agnostic.

Run all repo-health garbage-collection scans in parallel. Dispatches each `gc-*` subvariant in its own sub-agent so the scans run isolated and without polluting each other's context, then reports a per-scan summary count. Use when running a manual repo-health pass; subvariants currently include `gc-stale-todos` and `gc-duplicated-blocks`.

Read-only repo-health scan. Use when running a manual repo-health pass to surface stale tech-debt markers. Finds `TODO`/`FIXME`/`XXX`/`HACK` comments where `git blame` shows the introducing commit is more than 30 days old, then files one tracker issue per finding with the original commit's sha/author/date/subject. Never edits source. Tracker-agnostic.

Use when committing changes to git, before running commit commands, to ensure explicit file staging, verification, and PR-friendly commit message format

14 hooks across 2 events