Five-layer Go code review framework (Intent → Correctness → Scope → Quality → Post) with CRITICAL transaction context detection and mandatory inline comments. Use when reviewing Go code changes, PRs, or commits. Triggers on: 'review this PR', 'check my Go code', 'review my changes', '/go-code-reviewer', '/review-go', or when user asks for Go code quality assessment. Enforces research-backed quality gates from Google, Uber, and Razorpay standards with strict output guardrails (concise reviews under 300 lines, professional tone, 3-5 mandatory inline comments per review). Includes automated pattern detection for auth, database, API, and concurrency changes. NEW in v4.2: Executive summary with quality ratings, SOLID principles assessment, security risk levels, positive observations section, acceptance criteria, and structured next steps. v4.1: Mandatory inline comments and guardrails. v4.0: Transaction context bug detection (CRITICAL), comprehensive Razorpay reference guides.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Five-layer Go code review framework (Intent → Correctness → Scope → Quality → Post) with CRITICAL transaction context detection and mandatory inline comments. Use when reviewing Go code changes, PRs, or commits. Triggers on: 'review this PR', 'check my Go code', 'review my changes', '/go-code-reviewer', '/review-go', or when user asks for Go code quality assessment. Enforces research-backed quality gates from Google, Uber, and Razorpay standards with strict output guardrails (concise reviews under 300 lines, professional tone, 3-5 mandatory inline comments per review). Includes automated pattern detection for auth, database, API, and concurrency changes. NEW in v4.2: Executive summary with quality ratings, SOLID principles assessment, security risk levels, positive observations section, acceptance criteria, and structured next steps. v4.1: Mandatory inline comments and guardrails. v4.0: Transaction context bug detection (CRITICAL), comprehensive Razorpay reference guides.
Go Code Reviewer v4.2
Comprehensive five-layer Go code review framework with automated pattern detection, GitHub integration, and research-backed quality gates. Combines automation scripts with deep reference documentation from Google, Uber, and Razorpay best practices.
Version 4.2 Highlights
NEW in v4.2 - Enterprise-Grade Review Structure:
⭐ Executive Summary: Instant clarity with quality ratings (Excellent → Poor), production readiness, security risk level, and issue counts
⭐ SOLID Principles Assessment: Systematic architectural quality evaluation with checklist
Action: STOP if any gate fails - fix before proceeding
Layer 2: Scope Analysis (5-10 min)
Purpose: Assess PR size and focus, provide split recommendations if needed
CRITICAL - VERIFICATION REQUIRED:
Run scope analysis with automatic GitHub API verification
./scripts/check_pr_size.sh <pr-number>
Script automatically:
Uses GitHub API as source of truth
Verifies against local git diff
Warns if mismatch detected
If mismatch detected: Use GitHub API values shown in output, NOT git diff
Scope Analysis:
PR size metrics (LOC changed, files touched)
Scope appropriateness (single concern vs multiple)
Generated code detection
Recommendation: Split if >500 LOC or >10 files
Important: Scope issues (multiple concerns, large PRs) are architectural feedback, not merge blockers. They indicate process improvements but should not block well-implemented code.
Sanity Checks (MANDATORY):
Does file count match PR title/description?
Are cross-domain changes explained in PR description?
Does LOC seem reasonable for stated changes?
Red flags (require extra verification):
File count >3x expected from PR title
Cross-domain files in single-domain PR without explanation
LOC >500 for "simple" changes
Layer 3: Quality Review (20-40 min)
Purpose: Deep code quality assessment with pattern matching
When transaction code is detected, analyze_pr_patterns.sh now:
Flags transaction patterns in diff
Spawns database-reviewer with CRITICAL warnings
Provides specific patterns to check
References razorpay-transaction-context.md for details
Usage Examples
Example 1: Full PR Review
# Fetch PR
./scripts/fetch_pr.sh 123
# Check size and recommend split if needed
./scripts/check_pr_size.sh main
# Run Layer 1 gates (fail fast)
./scripts/run_layer1_gates.sh
# Analyze patterns and get agent recommendations
./scripts/analyze_pr_patterns.sh main
# Post review to GitHub
./scripts/post_review.sh 123 review-results.md approve
💡 Optional (P2): Nice to have - improves code quality
Variable naming improvements
Missing comments
Code organization
Speculative improvements (e.g., "consider adding rate limiting" when not proven needed)
Approval Decision Logic (Google Standards)
The Golden Rule (from Google Engineering Practices):
"Reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn't perfect."
When to APPROVE
✅ Approve if the change improves code health, even with minor imperfections:
Core functionality is correct and well-tested
No P0 (Critical) issues
P1/P2 issues exist but don't block the core improvement
Code is better than what it replaces
✅ Approve with Conditions if core is sound but needs non-blocking fixes:
Does this change improve code health?
├─ NO (makes it worse) → REQUEST CHANGES
└─ YES (improves it)
├─ Has P0 issues?
│ ├─ YES → REQUEST CHANGES
│ └─ NO → Continue
└─ Has only P1/P2 issues?
├─ Core feature is sound → APPROVE WITH CONDITIONS
│ Example: "Core logic excellent. P1: Split unrelated files."
└─ Core feature has issues → APPROVE WITH CONDITIONS
Example: "Good approach. P1: Add error handling before merge."
Handling Scope Issues (CRITICAL)
Scope issues are NOT merge blockers - they're architectural feedback:
❌ Wrong: "REQUEST CHANGES - PR has 55 files, should be 5"
✅ Right: "APPROVE WITH CONDITIONS - Core 5-file change is excellent. Recommend splitting 50 unrelated files to separate PR for clearer review and faster merge."
Why: Well-implemented code shouldn't be blocked by bundling decisions. The author can extract core changes or split the PR.
Balancing Velocity with Quality
Prioritize:
Enable progress: Approve improvements quickly
Maintain quality: Flag real issues with clear severity
Avoid perfectionism: Don't block on subjective preferences or speculative issues
Be constructive: Provide actionable feedback with specific suggestions
Remember: Code review is about continuous improvement, not perfection. Every approved PR should make the codebase better, but not every PR needs to be flawless.
Limitations
Requires Go codebase
Best with GitHub integration (scripts use gh CLI)
Pattern detection works on git diffs
Some checks require buildable code
Version History
v4.3 (2026-02-05) - Quality Fixes & Simplicity - CURRENT
Google Approval Decision Logic: "Favor approving a CL once it improves code health"
Pragmatic vs perfectionist approach to reviews
P2 observations are truly non-actionable (not "should fix")
