Claude Code First PR Review Rubric: style से पहले असली risk पकड़ें

अगर rubric के बिना Claude Code से PR review कराते हैं, तो production regression और naming suggestion समान वजन से आ सकते हैं। output ज्यादा दिखता है, पर merge रोकने वाला risk साफ नहीं होता।

यह guide पहला PR review rubric बनाती है। Claude Code को diff पढ़ाने से पहले P0 से P3 severity, evidence, comment format और retry rules तय करें।

साथ में पढ़ें: claude-code-code-review-checklist, claude-code-prompt-library-maintenance, claude-code-pull-request-quality. आधिकारिक दस्तावेज़ आधार: Anthropic Claude Code docs.

पहले command से पहले यह क्यों तय करें

style feedback से पहले regression, permission risk, data loss और missing tests पकड़ना

मुख्य बात है कि पहली request छोटी रहे। पढ़ने का scope, protected areas, पहला action और proof command पहले लिखें, ताकि Claude Code अनावश्यक बदलावों में न फैले।

वे developers जो Claude Code से review करते हैं और sharp findings चाहते हैं

व्यावहारिक workflow

1. diff से पहले goal और changed files paste करें
2. review शुरू होने से पहले P0 से P3 define करें
3. evidence बिना speculative comments रोकें
4. test, build या reproduction proof मांगें
5. P3 style notes अंत में रखें

स्थिति	Claude Code को दिया काम	मानव द्वारा जांचा proof
Auth PR	token storage और permission boundary को पहले P0 मानें	build, diff, URL
UI fix	broken clicks और mobile layout को P1 देखें	build, diff, URL
Refactor	behavior proof और missing tests को P2 में अलग करें	build, diff, URL

इस proof के साथ Claude Code को भरोसेमंद वाक्य से नहीं, दिखने वाले काम से परखा जा सकता है।

कॉपी करने योग्य prompt और code

इस PR diff को P0/P1/P2/P3 severity से review करें। P0 security, data loss, payment, auth या production outage है। हर finding में line, failure scenario, needed evidence और fix दें। style-only feedback अंत में रखें।

const reviewRubric = {
  P0: "security, data loss, payment, auth, production outage",
  P1: "user-visible regression or broken release path",
  P2: "test gap, unclear edge case, maintainability risk",
  P3: "style, naming, or optional cleanup"
};

function classifyReviewFinding(finding) {
  const text = finding.toLowerCase();
  if (/auth|token|payment|delete|secret|production/.test(text)) return "P0";
  if (/regression|broken|crash|deploy/.test(text)) return "P1";
  if (/missing test|edge case|unclear/.test(text)) return "P2";
  return "P3";
}

console.log(classifyReviewFinding("missing test for failed payment retry"));

वास्तविक उदाहरण और असफलताएं

स्थिति	Claude Code को दिया काम	मानव द्वारा जांचा proof
Auth PR	token storage और permission boundary को पहले P0 मानें	build, diff, URL
UI fix	broken clicks और mobile layout को P1 देखें	build, diff, URL
Refactor	behavior proof और missing tests को P2 में अलग करें	build, diff, URL

• अगर naming और formatting पहले आते हैं, Claude Code low-risk notes से review भर देता है।
• severity बिना payment bug और punctuation एक list में मिल जाते हैं।
• proof requirement बिना plausible पर untested comments बढ़ते हैं।

मुख्य बात है कि पहली request छोटी रहे। पढ़ने का scope, protected areas, पहला action और proof command पहले लिखें, ताकि Claude Code अनावश्यक बदलावों में न फैले।

Proof pack में क्या रखें

style feedback से पहले regression, permission risk, data loss और missing tests पकड़ना की value तब बढ़ती है जब इसे one-off chat नहीं, proof pack के रूप में रखा जाता है। original request, Claude Code ने कौन सी files पढ़ीं, कौन से areas नहीं छुए, कौन से commands चले, public URL या screenshot, और कौन सा decision अभी uncertain है, यह सब छोटा लिखें। अगली session वही judgment reuse कर सकती है।

वे developers जो Claude Code से review करते हैं और sharp findings चाहते हैं के लिए पहले दिन heavy operating manual बनाना जरूरी नहीं है। pattern को एक PR, एक note या एक deploy पर आजमाएं। fail हो तो failure को checklist में वापस डालें और छोटी version फिर चलाएं। build proof, diff review, URL check, CTA check और rollback owner दिखने के बाद ही Claude Code access बढ़ाएं। proof से पहले permission बढ़ाना तेज लगता है, पर verification cost अगले human review में जाती है।

revenue path भी यही rule मानता है। reader basic commands पर अटका है तो free PDF सही step है। अगर वही prompt shape हर week दोहराता है तो Gumroad उपयोगी है। team या production decisions हों तो consultation बेहतर है। यह article सबको खरीदने के लिए नहीं धकेलता; केवल जिन्हें PR review prompts और repeatable rubric चाहिए उन्हें paid guide पर भेजता है और बाकी को free PDF या related articles पर लौटाता है।

मुफ्त PDF, Gumroad और consultation से जोड़ना

अगर basic commands अभी साफ नहीं हैं, तो free cheatsheet से daily pattern पक्का करें। PR review prompts और repeatable rubric को गहराई से सीखने के लिए Gumroad guide अगला कदम है। team rollout, review rules या revenue path design चाहिए तो consultation पर जाएं। product comparison products से शुरू करें।

CTA केवल अंत में रखने की चीज नहीं है। शुरुआत में मुफ्त PDF friction घटाता है। implementation example के बाद Gumroad guide सही है। team rollout या production risk पर consultation स्वाभाविक अगला कदम है।

publish के बाद देखने वाली संख्याएं

publish के बाद इस review article से Prompt Templates, future Code Review System और consultation clicks देखें।

सिर्फ PV न देखें। intro reads, internal link clicks, free PDF starts, Gumroad clicks और consultation visits अलग-अलग देखें। HTTP 200, h1, canonical, heroImage, CTA और localized body को उसी slug पर होना चाहिए।