Skip to content

Instantly share code, notes, and snippets.

@gabrielbuzziv

gabrielbuzziv/codereview.md

Created November 26, 2025 17:35
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save gabrielbuzziv/2acc2bc112bc7dfebaa8e4c9a288839a to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save gabrielbuzziv/2acc2bc112bc7dfebaa8e4c9a288839a to your computer and use it in GitHub Desktop.
Download ZIP
Raw
codereview.md

Code Review

Perform a comprehensive code review of changes in the current branch or a specified GitHub PR.

Instructions

You are performing a code review. Follow these steps carefully:

  1. Determine the review scope:

    • If a GitHub PR URL is provided, use gh pr view <number> --json title,body,url,files to get PR details
    • If no PR URL is provided, review the current branch changes using git diff and git status

  2. Gather context:

    • Read the PR description (if reviewing a PR) to understand the intended changes
    • If a task/issue URL is provided, fetch and analyze the task requirements
    • Run git log to see commit messages and understand the change history
    • Run git diff [base-branch]...HEAD to see all changes in the branch

  3. Review all changed files:

    • Use the Read tool to examine each modified file
    • Analyze the code for:
      • Bugs and logic errors
      • Code quality and best practices
      • Performance issues
      • Security vulnerabilities
      • Test coverage
      • Documentation completeness
      • Consistency with existing codebase patterns
      • Edge cases and error handling

  4. Cross-reference with requirements:

    • Verify changes align with the PR description
    • If a task URL was provided, confirm all requirements are met
    • Check if any requirements are missing or incomplete

  5. Provide structured feedback:

    • Organize findings by severity: Critical, High, Medium, Low
    • For each issue, provide:
      • File name and line number reference (e.g., src/app.ts:42)
      • Clear description of the problem
      • Suggested fix or improvement
    • Highlight what was done well
    • Provide an overall assessment

Review Output Format

# Code Review Summary

## Overview
[Brief summary of what was reviewed and overall assessment]

## PR/Task Alignment
- ✅ Meets requirements: [Yes/No/Partial]
- [List any missing or incomplete requirements]

## Critical Issues
[Issues that must be fixed before merging]

## High Priority
[Important issues that should be addressed]

## Medium Priority
[Issues that would improve code quality]

## Low Priority / Suggestions
[Nice-to-have improvements and suggestions]

## Positive Observations
[What was done well]

## Overall Recommendation
[Approve / Request Changes / Needs Discussion]

Important Notes

  • Be thorough but constructive in your feedback
  • Always reference specific file paths and line numbers
  • If reviewing a GitHub PR, use gh pr view and gh pr diff commands
  • For task URLs, use WebFetch to retrieve and analyze requirements
  • Consider the broader context of the codebase, not just isolated changes
  • Balance finding issues with acknowledging good practices
Raw
commit.md
allowed-tools description
Bash(git *)
Create a git commit

Conventional Commit

Create a conventional commit message following the Conventional Commits specification and execute the commit with atomic changes.

Allowed Tools

  • exec
  • read_file
  • list_directory

Instructions

Analyze the current git status, select related changes for an atomic commit, stage them, and create a conventional commit message following these strict rules:

1. ATOMIC COMMITS FIRST

  • Run git status and git diff to see all changes
  • Identify logically related changes that should be committed together
  • Stage ONLY related files using git add <specific-files>
  • Create ONE focused commit per logical change
  • If multiple unrelated changes exist, ask which to commit first
  • DO NOT use git add . or git add -A

2. FORMAT (mandatory)

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

3. TYPE (choose ONE that best fits)

  • feat: A new feature for the user
  • fix: A bug fix
  • docs: Documentation only changes
  • style: Changes that don't affect code meaning (white-space, formatting, missing semi-colons)
  • refactor: Code change that neither fixes a bug nor adds a feature
  • perf: Code change that improves performance
  • test: Adding missing tests or correcting existing tests
  • build: Changes to build system or external dependencies (example scopes: gulp, broccoli, npm)
  • ci: Changes to CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
  • chore: Other changes that don't modify src or test files
  • revert: Reverts a previous commit

4. SCOPE (optional but recommended)

  • Use lowercase
  • Be specific to the affected component/module/area
  • Examples: api, parser, auth, database, ui, config

5. DESCRIPTION

  • Use imperative, present tense: "change" not "changed" nor "changes"
  • Don't capitalize first letter
  • No period (.) at the end
  • Keep under 50 characters if possible, max 72
  • Be clear and concise about WHAT changed

6. BODY (optional, use when needed)

  • Separate from description with blank line
  • Use imperative, present tense
  • Explain WHAT and WHY, not HOW
  • Wrap at 72 characters
  • Can include multiple paragraphs

7. FOOTER (optional, use for breaking changes or issue references)

  • BREAKING CHANGE: <description> (for breaking changes)
  • Fixes #123 (for issue references)
  • Refs #456 (for related issues)
  • Reviewed-by: Name
  • Multiple footers are allowed

8. BREAKING CHANGES

  • MUST be indicated by BREAKING CHANGE: in footer, OR
  • By appending an exclamation mark after type/scope (example: feat(api) with ! before colon)
  • Must include description of the breaking change

9. EXAMPLES

Simple feature:

feat(auth): add OAuth2 login support

Bug fix with scope:

fix(parser): handle null values in JSON input

Breaking change:

feat(api): remove deprecated endpoints

BREAKING CHANGE: /v1/users endpoint has been removed, use /v2/users instead

With body and footer:

refactor(database): migrate from MongoDB to PostgreSQL

Update ORM queries and connection logic to use PostgreSQL.
This improves query performance and adds better transaction support.

Refs #234

CRITICAL REQUIREMENTS

  1. Check git status and git diff to see all changes
  2. Identify which files form a logical, atomic unit of work
  3. Stage ONLY those specific files: git add path/to/file1 path/to/file2
  4. If there are multiple unrelated changes, present options and ask which to commit
  5. Analyze the staged changes carefully using git diff --staged
  6. Choose the most appropriate type based on what actually changed
  7. Write ONLY the commit message text - do NOT mention this is generated by Claude, AI, or any assistant
  8. Write as if you (the developer) are authoring this commit personally
  9. Use first-person perspective naturally ("add", "fix", "update") without attribution
  10. Keep it professional and focused on the technical changes
  11. After generating the message, execute the commit using: 
    git commit --no-verify -m "<your generated message>"
    Or for multi-line commits: 
    git commit --no-verify -m "<description>" -m "<body>" -m "<footer>"
  12. After committing, show remaining unstaged/uncommitted changes if any exist

IMPORTANT: Git Hooks

  • ALWAYS use --no-verify flag when committing
  • This skips pre-commit and commit-msg hooks
  • This is required to avoid potential conflicts or verification issues

Process

  1. Run git status to see all changed files
  2. Run git diff to see the actual changes
  3. Identify logically related changes (atomic commit)
  4. Stage only those specific files with git add <files>
  5. Run git diff --staged to confirm what will be committed
  6. Analyze the changes to determine the appropriate type and scope
  7. Generate the conventional commit message
  8. Execute git commit --no-verify with the generated message
  9. Confirm the commit was successful
  10. Show any remaining uncommitted changes and ask if another commit is needed
Raw
pr.md

Create Pull Request

Create a pull request following the team template using GitHub CLI.

Instructions

You are creating a pull request. Follow these steps:

  1. Run git status and git diff to understand the current branch changes
  2. Check if the current branch tracks a remote branch and if it needs to be pushed
  3. Run git log and git diff [base-branch]...HEAD to understand all commits in this branch
  4. Analyze ALL changes to draft a comprehensive PR description
  5. Push the branch to remote if needed (with -u flag for new branches)
  6. Create the PR using the template below

PR Template

## Description
<!-- Provide a clear and concise description of what this PR does -->

## Type of Change
<!-- Check the relevant option(s) -->
- [ ] Bug fix (non-breaking change that fixes an issue)
- [ ] New feature (non-breaking change that adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Documentation update
- [ ] Refactoring (no functional changes)
- [ ] Performance improvement
- [ ] Dependency update

## Changes Made
<!-- List the key changes in this PR -->
-
-
-

Important Notes

  • Fill in the Description section with a clear summary of what the PR accomplishes
  • Check the appropriate Type of Change checkbox(es) based on the changes
  • List specific changes in the Changes Made section (be comprehensive)
  • Use gh pr create with a HEREDOC for proper formatting
  • Return the PR URL when complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment