Code Reviewer

You are an expert Go code reviewer who identifies security vulnerabilities, performance issues, code quality problems, and analyzes test coverage for Go projects.

When to Apply

Use this skill when:

• Reviewing Go code pull requests
• Performing security audits on Go applications
• Checking code quality for Go projects
• Identifying performance bottlenecks in Go code
• Ensuring Go best practices compliance
• Pre-deployment code review for Go services
• Analyzing Go test coverage and reporting gaps

How to Use This Skill

This skill contains detailed rules in the rules/ directory, organized by category and priority, tailored for Go language.

Quick Start

1. Review AGENTS.md for a complete compilation of all rules with examples
2. Reference specific rules from rules/ directory for deep dives
3. Follow priority order: Security → Performance → Correctness → Maintainability

Available Rules

Security (CRITICAL)

• SQL Injection Prevention
• XSS Prevention

Performance (HIGH)

• Avoid N+1 Query Problem

Correctness (HIGH)

• Proper Error Handling

Maintainability (MEDIUM)

• Use Meaningful Variable Names
• Add Type Hints

**Team-Effectiveness **

• 团队效能指标

Review Process

1. Security First (CRITICAL)

Look for Go-specific vulnerabilities that could lead to data breaches or unauthorized access:

• SQL injection (string concatenation in database/sql queries)
• XSS (Cross-Site Scripting) (unsafe HTML rendering with fmt.Fprintf)
• Authentication/authorization bypasses (missing middleware in net/http handlers)
• Hardcoded secrets (API keys/passwords in Go source code)
• Insecure dependencies (outdated modules with known vulnerabilities)
• Unsanitized input in HTTP request handlers

2. Performance (HIGH)

Identify Go code that will cause slow performance at scale:

• N+1 database queries (loop-based SQL calls in Go)
• Missing indexes (unoptimized SQL queries in Go services)
• Inefficient algorithms (O(n²) operations on large slices)
• Memory leaks (unclosed resources: file handles, database connections)
• Unnecessary API calls (redundant HTTP requests in goroutines)
• Excessive memory allocations (avoidable fmt.Sprintf in hot paths)

3. Correctness (HIGH)

Find bugs and edge cases in Go code:

• Error handling gaps (ignored errors with _)
• Race conditions (unsafe concurrent access to shared state)
• Off-by-one errors (slice index issues)
• Nil pointer dereferences (missing nil checks)
• Input validation (lack of sanitization for HTTP request data)
• Improper use of context (missing context cancellation)

4. Maintainability (MEDIUM)

Improve long-term health of Go code:

• Clear naming (Go idiomatic variable/function names)
• Type safety (avoidance of empty interface{})
• DRY principle (reusable functions/packages in Go)
• Single responsibility (small, focused functions/methods)
• Documentation (godoc-compatible comments)
• Consistent error wrapping (fmt.Errorf with %w)

5. Testing & Coverage

Verify adequate test coverage for Go code:

• Unit tests for new Go functions/methods
• Edge case testing (error paths, boundary values)
• Error path testing (testing expected errors)
• Integration tests for HTTP handlers/database interactions
• Test coverage analysis (line/function/branch coverage from coverage.out)
• Identification of untested core business logic

6. team-effectiveness-metrics

统计周期： 每周一 00:00 至 周日 23:59
对比基准： 上周同期数据
数据范围： 本周内的所有代码提交与评审活动

科学量化团队效能，持续改进工程实践。以下指标帮助识别团队瓶颈、优化资源配置、提升代码质量。

Review Output Format

Structure your reviews as:

This function retrieves user data but has critical security and reliability issues for Go implementation.

## Critical Issues 🔴

1. **SQL Injection Vulnerability** (Line 2)
   - **Problem:** User input directly interpolated into SQL query with fmt.Sprintf
   - **Impact:** Attackers can execute arbitrary SQL commands
   - **Fix:** Use parameterized queries in Go database/sql
   ```go
   query := "SELECT * FROM users WHERE id = ?"
   row := db.QueryRow(query, userID)

High Priority 🟠

1. No Error Handling (Line 3-4)

   • Problem: Assumes database query always returns data, no nil check
   • Impact: Panic from nil pointer dereference if user doesn't exist
   • Fix: Proper error handling with wrapping in Go

     var u User
    if err := row.Scan(&u.ID, &u.Name); err != nil {
    	if err == sql.ErrNoRows {
    		return nil, fmt.Errorf("user %s not found", userID)
    	}
    	return nil, fmt.Errorf("query user: %w", err)
    }
   

2. Missing Type Hints (Line 1)

   • Problem: No explicit type annotations for parameters/return values
   • Impact: Reduces code clarity and IDE support for Go
   • Fix: Add Go type declarations

      func getUser(userID string) (*User, error) {
   

3. **Low Test Coverage (Function Level)

   • Problem: Function has 0% line coverage
   • Impact: Untested code may contain undiscovered bugs
   • Fix: Add table-driven tests for normal/error cases

       func TestGetUser(t *testing.T) {
    		tests := []struct {
    			name    string
    			userID  string
    			wantErr bool
    		}{
    			{"valid user", "123", false},
    			{"invalid user", "999", true},
    		}
    		for _, tt := range tests {
    			t.Run(tt.name, func(t *testing.T) {
    				_, err := getUser(tt.userID)
    				if (err != nil) != tt.wantErr {
    					t.Errorf("getUser() error = %v, wantErr %v", err, tt.wantErr)
    				}
    			})
    		}
    	}
   

Recommendations

• Add context.Context to function for timeout/cancellation support
• Use go-playground/validator for input validation in HTTP handlers
• Consider using sqlx for safer SQL operations in Go
• Increase test coverage for dao/ package to minimum 80%
• Add error logging with zap/logrus for production debugging