Claude Code से Pull Request की गुणवत्ता कैसे बढ़ाएं

Pull Request वह जगह है जहां टीम code change प्रस्तावित करती है, review करती है और merge करती है। GitHub की official documentation भी PR को collaboration का मुख्य workflow मानती है। Claude Code implementation को तेज कर देता है, लेकिन तेज code के साथ एक नया जोखिम आता है: PR description अधूरी, diff बहुत बड़ा, test evidence कमजोर, security impact अस्पष्ट, और reviewer comments बार-बार उसी जगह लौटते हैं। AI से लिखा code तभी उपयोगी है जब वह human review के लिए साफ पैकेज किया गया हो।

इस guide में Claude Code को सिर्फ PR text generator नहीं, बल्कि PR quality assistant की तरह इस्तेमाल करेंगे। diff का मतलब बदली हुई lines, CI का मतलब automated build और test gate, diff-size budget का मतलब PR size की सीमा, और handoff का मतलब अगले reviewer के लिए छोटा context note है। संबंधित workflow के लिए Claude Code code review और testing strategies भी देखें।

flowchart LR
  A["Claude Code से implement"] --> B["PR template भरें"]
  B --> C["CI में diff size रोकें"]
  C --> D["Test evidence जोड़ें"]
  D --> E["Reviewer handoff दें"]
  E --> F["Release notes बनाएं"]

इस article में उपयोग की गई official sources हैं GitHub Pull Requests, PR template बनाना, GitHub Actions workflow syntax, protected branches, GitHub Actions secrets, Claude Code docs, और commit categories के लिए Conventional Commits।

पहले PR standard को template में डालें

हर बार Claude Code से “अच्छा PR description लिखो” कहने पर output अलग होगा। बेहतर तरीका है repository में .github/pull_request_template.md रखना। GitHub PR बनाते समय इस template को body में दिखा सकता है, इसलिए review standard team memory के बजाय codebase में रहता है।

## क्या बदला
<!-- implementation, configuration, documentation और generated files अलग लिखें। -->

## बदलाव क्यों जरूरी है
<!-- issue, incident, user request या design decision link करें। -->

## Review focus
- [ ] Business logic
- [ ] UI/UX
- [ ] API या database contract
- [ ] Security और privacy

## Test evidence
- [ ] Automated tests:
- [ ] Manual checks:
- [ ] Screenshot या recording:

## Diff size
- Changed files:
- Added/deleted lines:
- Split न करने का कारण:

## Security और operations
- [ ] कोई secret, token या personal data नहीं
- [ ] logs credentials या personal data expose नहीं करते
- [ ] permissions, environment variables और feature flags checked
- [ ] rollback plan लिखा गया

## Reviewer handoff
<!-- पहले कौन सी files पढ़नी हैं, open decisions, risks और follow-up PRs। -->

सबसे उपयोगी fields हैं “split न करने का कारण” और “rollback plan”। ये खाली हों तो PR अक्सर बहुत बड़ा या production के लिए अधूरा समझाया गया होता है। Claude Code template भर सकता है, लेकिन template तय करता है कि PR review-ready है या नहीं।

Claude Code से facts के आधार पर PR body लिखवाएं

Template बनने के बाद Claude Code को diff पढ़ाकर वही fields भरवाएं। Prompt में साफ लिखें कि वह facts invent न करे। Test नहीं चला तो “not run” लिखे, “passed” नहीं।

git diff origin/main...HEAD | claude -p "
इस diff को पढ़कर .github/pull_request_template.md के format में Pull Request body हिंदी में लिखें।

Rules:
- diff में न दिखने वाले facts न बनाएं
- test evidence न हो तो 'not run' लिखें
- technical terms पहली बार आने पर छोटे वाक्य में समझाएं
- review focus को 3 files या areas तक सीमित रखें
- secrets, tokens, personal data और risky logs check करें
- अंत में human verification वाले unresolved items लिखें
"

इससे PR body summary नहीं, reviewer map बनती है। Reviewer सीधे authorization function, बदली हुई screen या migration file से शुरू कर सकता है। Claude Code diff जल्दी पढ़ता है, लेकिन अंतिम दावा इंसान को verify करना चाहिए।

CI में diff-size budget लगाएं

बड़ा PR review depth घटाता है। Claude Code एक ही session में rename, formatting, refactor, tests और docs कर सकता है। सुविधा अच्छी है, लेकिन इससे कई उद्देश्य एक PR में मिल जाते हैं। diff-size budget PR size पर measurable सीमा लगाता है।

Node project में scripts/check-pr-size.mjs जोड़ें। यह lockfiles और generated output को ignore करके reviewable बदलाव गिनता है।

#!/usr/bin/env node
import { execFileSync } from "node:child_process";

const [range = "origin/main...HEAD", maxLinesRaw = "700", maxFilesRaw = "35"] =
  process.argv.slice(2);
const maxLines = Number(maxLinesRaw);
const maxFiles = Number(maxFilesRaw);

const ignored = [
  /^package-lock\.json$/,
  /^pnpm-lock\.yaml$/,
  /^yarn\.lock$/,
  /^dist\//,
  /^coverage\//,
];

function numeric(value) {
  const parsed = Number(value);
  return Number.isFinite(parsed) ? parsed : 0;
}

const output = execFileSync("git", ["diff", "--numstat", range], {
  encoding: "utf8",
}).trim();

let files = 0;
let lines = 0;

for (const row of output.split(/\r?\n/).filter(Boolean)) {
  const [added, deleted, file] = row.split("\t");
  if (ignored.some((pattern) => pattern.test(file))) continue;
  files += 1;
  lines += numeric(added) + numeric(deleted);
}

if (files > maxFiles || lines > maxLines) {
  console.error(
    `PR is too large: ${files} files / ${lines} changed lines. ` +
      `Budget is ${maxFiles} files / ${maxLines} lines.`,
  );
  console.error("Split formatting, generated files, and behavior changes into separate PRs.");
  process.exit(1);
}

console.log(`PR size OK: ${files} files / ${lines} changed lines.`);

अब इसे GitHub Actions में चलाएं। Workflow file .github/workflows में रहती है। बाद में protected branch में इस job को required status check बना सकते हैं।

name: PR quality

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

permissions:
  contents: read
  pull-requests: read

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: actions/setup-node@v4
        with:
          node-version: 22

      - name: Install dependencies
        run: npm ci

      - name: Run project checks
        run: |
          npm run lint --if-present
          npm test --if-present

      - name: Enforce PR size budget
        run: node scripts/check-pr-size.mjs "origin/${{ github.base_ref }}...HEAD" 700 35

700 lines और 35 files शुरुआत के लिए ठीक सीमा है। Migration या mechanical refactor में exception हो सकता है, लेकिन PR body में कारण लिखा होना चाहिए। उद्देश्य बड़ा PR रोकना नहीं, बल्कि बड़ा PR समझाना है।

Test evidence reproducible बनाएं

“Tests pass” पर्याप्त नहीं है। Reviewer को command, result, manual check, UI screenshot और unchecked items चाहिए। Claude Code section बना सकता है, पर unrun command को pass नहीं लिखना चाहिए।

claude -p "
इस branch के Pull Request के लिए test evidence section तैयार करें।

Format:
## Automated tests
- Command:
- Result:
- Failure reason, if any:

## Manual checks
- Screen, API या job checked:
- Input data:
- Expected result:
- Actual result:

## Not verified
- Items not checked yet:
- Merge से पहले कौन verify करेगा:

सिर्फ facts लिखें। जो command नहीं चली उसे passed न लिखें।
"

तीन common use cases याद रखें। UI PR में screenshot, viewport size और accessibility notes चाहिए। API PR में compatibility, error response और logging behavior चाहिए। Migration या batch PR में dry run, rollback और runtime estimate चाहिए। इस classification से reviewer अपनी expertise वाली जगह से शुरू कर सकता है।

Security और privacy checklist जोड़ें

AI generated code कई बार उम्मीद से ज्यादा files छूता है। Secrets examples, logs, fixtures या screenshots में आ सकते हैं। GitHub Actions secrets workflow values के लिए हैं, लेकिन उन्हें logs या PR body में print करना सुरक्षित नहीं है।

इस diff को security और privacy angle से review करें।

Checklist:
1. Secrets, tokens, API keys, cookies, session IDs
2. Logs, fixtures, screenshots या errors में personal data
3. Permission checks server-side हैं या सिर्फ UI में छिपाए गए हैं
4. GitHub Actions permissions बहुत wide तो नहीं
5. Failure responses internal paths या credentials leak तो नहीं करते
6. Feature flags या environment variables rollout बदलते हैं या नहीं

High/Medium/Low severity दें और exact file names लिखें।
जो suspicious areas confirm नहीं हो पा रहे, उन्हें भी अलग लिखें।

अंतिम line जरूरी है। Security review में “कोई issue नहीं” से ज्यादा उपयोगी है “ये areas confirm नहीं हुए”।

Reviewer handoff और comments संभालें

Handoff कमजोर हो तो अगला reviewer पूरी discussion फिर से पढ़ता है। Distributed team, लंबा PR और rotation review में यह महंगा पड़ता है। PR comments और diff stat Claude Code को दें और छोटा status note बनवाएं।

PR_NUMBER=123
{
  gh pr view "$PR_NUMBER" --comments
  gh pr diff "$PR_NUMBER" --stat
} | claude -p "
इस Pull Request के लिए reviewer handoff note लिखें।

Include:
- उद्देश्य 2 sentences में
- पहले पढ़ने वाली अधिकतम 3 files
- already addressed review comments
- decision pending comments
- CI, manual test और release risks

Reviewer को 5 minutes में state समझ आनी चाहिए।
"

Review replies में भी “fixed” काफी नहीं है। अच्छी reply बताती है कि क्या बदला, किस file में बदला, कौन सा test cover करता है, और suggestion न लेने का कारण क्या है। Claude Code draft दे सकता है; final जवाब छोटा और factual रखें।

PR से release notes तक जाएं

PR merge होने पर काम खत्म नहीं होता। User-facing change, internal operation change और breaking change को release notes में जाना चाहिए। Conventional Commits grouping में मदद कर सकता है, लेकिन final note human language में होना चाहिए।

gh pr list --state merged --base main --limit 20 \
  --json number,title,body,mergedAt \
  | claude -p "
इन merged Pull Requests से हिंदी release notes draft करें।

Sections:
## नई सुविधाएं
## Fixes
## Performance
## Documentation
## Developer changes

Rules:
- PR numbers रखें
- internal-only changes छोटे रखें
- breaking changes, migrations और feature flags highlight करें
- PR body में evidence न हो तो impact invent न करें
"

अगर PR body release note में बदल ही नहीं सकती, तो review के लिए भी वह कमजोर है। शुरुआत में ही “इसे बाद में user को कैसे समझाएंगे” सोचने से PR साफ बनता है।

Noisy AI PR से बचें

सबसे common failure है noise। Unrequested formatting, बड़े rename, speculative refactor, duplicate comments, marketing जैसी description और unverified test claims review को slow बनाते हैं।

सरल नियम रखें। Formatting अलग PR में करें। Generated code का diff छोटा रखें। PR body में facts लिखें। Claude Code की suggestion क्यों ली, एक sentence में बताएं। Mechanical change, behavior change और tests को संभव हो तो अलग PR में रखें।

Noisy AI PR	Reviewable PR
“Claude ने module improve किया”	“authorization checks server/auth.ts में move किए”
Formatting और logic साथ	Formatting PR और feature PR अलग
Evidence बिना “सब ठीक”	Commands, results और gaps लिखे
Review focus खाली	Files और risks पहले बताए

ClaudeCodeLab की monetization flow में जोड़ें

यह topic templates, training और implementation consulting से जुड़ता है। Team को सिर्फ prompt नहीं चाहिए; PR template, CLAUDE.md rules, CI gates और review habits चाहिए। इस article को CLAUDE.md templates, team handoff rules और training/consulting से जोड़ें ताकि reader adoption step तक जाए।

Rollout धीरे करें। Week 1 में PR template, week 2 में diff-size gate, week 3 में reviewer handoff, week 4 में merged PRs से release notes। एक साथ बहुत नियम लाने से team quality से पहले process से चिढ़ सकती है।

मैंने इसे आजमाया तो क्या मिला

मैंने यह flow एक छोटे Node project में आजमाया। PR template और size gate का combination सबसे उपयोगी निकला। Claude Code अकेले लंबा लेकिन uneven PR text लिखता था; template ने missing tests, security check, priority files और rollback को सामने ला दिया। 700 lines और 35 files budget ने formatting और behavior changes को review से पहले अलग करने में मदद की।

निष्कर्ष

Claude Code से Pull Request quality बढ़ाने का मतलब AI से सुंदर description लिखवाना नहीं है। सही तरीका है strict template, CI diff-size budget, reproducible test evidence, security/privacy checklist, reviewer handoff और release notes की chain बनाना। तभी AI-assisted changes human review और production release के लिए भरोसेमंद बनते हैं।