monarchmaisuriya · January 7, 2026 08:30
diff --git a/.zshrc b/.zshrc
 # ==============================================
 # === Start of Gemini Diff-Based Code Review ===
 # ==============================================

 # Detailed review prompt (multi-line, neatly formatted)
 __gemini_prompt_text=$(
  cat <<'EOF'
 Thoroughly and critically review the proposed changes. Identify potential issues such as edge cases and failure modes, syntax or compilation errors, logical flaws, unintended side effects, performance bottlenecks, scalability risks, and violations of coding standards or architectural intent.
 Focus especially on complex, non-obvious, or high-impact logic; input validation boundaries; state management; and any change that could affect correctness, reliability, stability, or scalability. Provide a clear, structured, and actionable review report without modifying the code.
 Evaluate the changes against the following principles:
 SOLID Principles:
 Single Responsibility: Each class, module, or function should have one clear responsibility and one primary reason to change.
 Open/Closed: Designs should allow extension without requiring modification of existing behavior.
 Liskov Substitution: Subtypes must be safely substitutable for their base types without altering expected behavior or correctness.
 Interface Segregation: Prefer small, focused interfaces; avoid forcing consumers to depend on unused methods.
 Dependency Inversion: High-level logic should depend on abstractions, not concrete implementations or infrastructure details.
 General Design Principles:
 KISS: Favor the simplest design that correctly solves the problem.
 YAGNI: Avoid introducing functionality, abstractions, or flexibility that is not currently required.
 DRY: Remove unnecessary duplication while avoiding premature or speculative abstractions.
 Separation of Concerns: Ensure clear responsibility boundaries, high cohesion within components, and low coupling between them.
 Law of Demeter: Minimize knowledge of and interaction with internal details of other objects; avoid deep method chaining.
 Composition over Inheritance: Prefer composing behavior rather than extending through inheritance hierarchies.
 Principle of Least Astonishment: Code behavior and structure should match reasonable developer expectations.
 Also assess:
 Input validation and error handling, ensuring invalid states are prevented, failures are explicit, and errors are surfaced early and clearly.
 Performance and scalability, including algorithmic complexity, memory usage, I/O patterns, concurrency, and contention risks.
 Security considerations such as injection vectors, improper authorization or trust boundaries, secrets handling, and accidental data exposure.
 Testing quality, including coverage of critical paths and edge cases, test structure and readability, and strength of assertions.
 Observability, including logging, metrics, and tracing that aid diagnosis without leaking sensitive or excessive data.
 Compliance with language, framework, and team coding standards.
 Backward compatibility and migration impact for existing users, data, or integrations.
 Feature flag usage, rollout safety, and ability to quickly rollback or mitigate failures.
 Documentation and Comments:
 Do not add or recommend obvious, redundant, or narrational comments that restate what the code clearly expresses.
 Comments should exist only to explain non-obvious, ad-hoc, or highly contextual logic, constraints, or tradeoffs that cannot be inferred from the code itself.
 Prefer short-to-medium length docstrings that describe behavior, assumptions, side effects, invariants, and failure conditions.
 Identify cases where comments or documentation are misleading, outdated, overly verbose, or add noise rather than clarity.
 Deliverables:
 Findings grouped by severity (Critical, High, Medium, Low) with precise references to the affected code.
 Specific, actionable remediation recommendations without editing or rewriting the code.
 A risk assessment describing potential impacts on stability, scalability, data integrity, and failure scenarios.
 A concise summary of overall adherence to the listed principles, highlighting notable strengths, weaknesses, and systemic patterns.
 EOF
 )

 # Track last git action and its exit code
 LAST_GIT_CMD=""
 LAST_GIT_EXIT_CODE=""

 # Wrapper for git to detect commits
 git() {
  if [[ "$1" == "commit" ]]; then
    LAST_GIT_CMD="commit"
  else
    LAST_GIT_CMD=""
  fi

  command git "$@"
  LAST_GIT_EXIT_CODE=$?
  return $LAST_GIT_EXIT_CODE
 }

 # Hook runs before prompt display
 precmd() {
  if [[ "${LAST_GIT_CMD:-}" == "commit" ]] && [[ "${LAST_GIT_EXIT_CODE:-1}" -eq 0 ]]; then
    LAST_GIT_CMD=""
    LAST_GIT_EXIT_CODE=""

    echo
    read -r "REPLY?Do you want a code review (performed by Gemini CLI) on the committed changes? [y/n] "
    if [[ "$REPLY" =~ ^[Yy]$ ]]; then
      echo "Running Gemini CLI code review..."

      # Get changed files (handles initial commit too)
      if git rev-parse --verify HEAD~1 >/dev/null 2>&1; then
        files=$(git diff --name-only HEAD~1 HEAD)
      else
        files=$(git show --name-only --pretty="" HEAD)
      fi

      if [[ -z "${files//[[:space:]]/}" ]]; then
        echo "No files changed in the last commit."
        return
      fi

      for file in $files; do
        if [[ -f "$file" ]]; then
          echo "Reviewing changes in: $file"
          git diff HEAD~1 HEAD -- "$file" | \
            gemini -p "$__gemini_prompt_text"
        fi
      done
    fi
  fi
 }

 # ============================================
 # === End of Gemini Diff-Based Code Review ===
 # ============================================
	# ==============================================
	# === Start of Gemini Diff-Based Code Review ===
	# ==============================================

	# Detailed review prompt (multi-line, neatly formatted)
	__gemini_prompt_text=$(
	cat <<'EOF'
	Thoroughly and critically review the proposed changes. Identify potential issues such as edge cases and failure modes, syntax or compilation errors, logical flaws, unintended side effects, performance bottlenecks, scalability risks, and violations of coding standards or architectural intent.
	Focus especially on complex, non-obvious, or high-impact logic; input validation boundaries; state management; and any change that could affect correctness, reliability, stability, or scalability. Provide a clear, structured, and actionable review report without modifying the code.
	Evaluate the changes against the following principles:
	SOLID Principles:
	Single Responsibility: Each class, module, or function should have one clear responsibility and one primary reason to change.
	Open/Closed: Designs should allow extension without requiring modification of existing behavior.
	Liskov Substitution: Subtypes must be safely substitutable for their base types without altering expected behavior or correctness.
	Interface Segregation: Prefer small, focused interfaces; avoid forcing consumers to depend on unused methods.
	Dependency Inversion: High-level logic should depend on abstractions, not concrete implementations or infrastructure details.
	General Design Principles:
	KISS: Favor the simplest design that correctly solves the problem.
	YAGNI: Avoid introducing functionality, abstractions, or flexibility that is not currently required.
	DRY: Remove unnecessary duplication while avoiding premature or speculative abstractions.
	Separation of Concerns: Ensure clear responsibility boundaries, high cohesion within components, and low coupling between them.
	Law of Demeter: Minimize knowledge of and interaction with internal details of other objects; avoid deep method chaining.
	Composition over Inheritance: Prefer composing behavior rather than extending through inheritance hierarchies.
	Principle of Least Astonishment: Code behavior and structure should match reasonable developer expectations.
	Also assess:
	Input validation and error handling, ensuring invalid states are prevented, failures are explicit, and errors are surfaced early and clearly.
	Performance and scalability, including algorithmic complexity, memory usage, I/O patterns, concurrency, and contention risks.
	Security considerations such as injection vectors, improper authorization or trust boundaries, secrets handling, and accidental data exposure.
	Testing quality, including coverage of critical paths and edge cases, test structure and readability, and strength of assertions.
	Observability, including logging, metrics, and tracing that aid diagnosis without leaking sensitive or excessive data.
	Compliance with language, framework, and team coding standards.
	Backward compatibility and migration impact for existing users, data, or integrations.
	Feature flag usage, rollout safety, and ability to quickly rollback or mitigate failures.
	Documentation and Comments:
	Do not add or recommend obvious, redundant, or narrational comments that restate what the code clearly expresses.
	Comments should exist only to explain non-obvious, ad-hoc, or highly contextual logic, constraints, or tradeoffs that cannot be inferred from the code itself.
	Prefer short-to-medium length docstrings that describe behavior, assumptions, side effects, invariants, and failure conditions.
	Identify cases where comments or documentation are misleading, outdated, overly verbose, or add noise rather than clarity.
	Deliverables:
	Findings grouped by severity (Critical, High, Medium, Low) with precise references to the affected code.
	Specific, actionable remediation recommendations without editing or rewriting the code.
	A risk assessment describing potential impacts on stability, scalability, data integrity, and failure scenarios.
	A concise summary of overall adherence to the listed principles, highlighting notable strengths, weaknesses, and systemic patterns.
	EOF
	)

	# Track last git action and its exit code
	LAST_GIT_CMD=""
	LAST_GIT_EXIT_CODE=""

	# Wrapper for git to detect commits
	git() {
	if [[ "$1" == "commit" ]]; then
	LAST_GIT_CMD="commit"
	else
	LAST_GIT_CMD=""
	fi

	command git "$@"
	LAST_GIT_EXIT_CODE=$?
	return $LAST_GIT_EXIT_CODE
	}

	# Hook runs before prompt display
	precmd() {
	if [[ "${LAST_GIT_CMD:-}" == "commit" ]] && [[ "${LAST_GIT_EXIT_CODE:-1}" -eq 0 ]]; then
	LAST_GIT_CMD=""
	LAST_GIT_EXIT_CODE=""

	echo
	read -r "REPLY?Do you want a code review (performed by Gemini CLI) on the committed changes? [y/n] "
	if [[ "$REPLY" =~ ^[Yy]$ ]]; then
	echo "Running Gemini CLI code review..."

	# Get changed files (handles initial commit too)
	if git rev-parse --verify HEAD~1 >/dev/null 2>&1; then
	files=$(git diff --name-only HEAD~1 HEAD)
	else
	files=$(git show --name-only --pretty="" HEAD)
	fi

	if [[ -z "${files//[[:space:]]/}" ]]; then
	echo "No files changed in the last commit."
	return
	fi

	for file in $files; do
	if [[ -f "$file" ]]; then
	echo "Reviewing changes in: $file"
	git diff HEAD~1 HEAD -- "$file" \| \
	gemini -p "$__gemini_prompt_text"
	fi
	done
	fi
	fi
	}

	# ============================================
	# === End of Gemini Diff-Based Code Review ===
	# ============================================
No results found