Claude Code review workflow checklist: release से पहले PR risk पकड़ें

पहली तीन लाइनें review की गहराई तय करती हैं

अगर Claude Code review हल्का लगता है, तो अक्सर model नहीं बल्कि input कमजोर होता है। Request में यह नहीं बताया जाता कि क्या बदला, क्या नहीं टूटना चाहिए, कौन से checks चले, और इंसान को कौन सा decision लेना है।

यहां review workflow का मतलब है repeatable process: diff छोटा करना, risk को नाम देना, evidence जोड़ना, findings पहले मांगना, और final approval इंसान के पास रखना। Beginner भाषा में, diff वह change है जो PR में आया। Review gate release से पहले की अनिवार्य जांच है। Verification receipt वह छोटा record है जिसमें command, result, screenshot, log और remaining risk लिखा जाता है।

Official references के लिए Claude Code overview, common workflows, GitHub pull request reviews और npm scripts देखें। Site के अंदर इसे Claude Code code review checklist और verification receipt workflow के साथ इस्तेमाल करें।

Claude Code को diff देने से पहले context तैयार करें

अच्छे review के लिए Scope, Risk, Evidence और Handoff चाहिए। इनके बिना Claude Code summary दे सकता है, पर release रोकने वाला असली issue छूट सकता है।

Input	काम	कमजोर version	मजबूत version
Scope	change limit करना	कई चीजें सुधारीं	सिर्फ article CTA, copy और mobile spacing
Risk	impact बताना	ठीक लग रहा है	product, consultation और internal links revenue path पर असर डालते हैं
Evidence	verification दिखाना	local देखा	npm run build passed, 360px पर CTA click checked
Handoff	output तय करना	review कर दो	P1/P2/P3 findings, residual risk और next checks

flowchart LR
  A["Diff"] --> B["Scope and risk"]
  B --> C["Claude Code review"]
  C --> D["Human decision"]
  D --> E["Fix, verify, or ship"]
  E --> F["Review receipt"]

Boundary साफ रखें: Claude Code approver नहीं है। यह missed issues घटाता है, tests suggest करता है और weak assumptions दिखाता है। Ship करना, fix करना या फिर से verify करना PR owner का decision है।

Review से पहले checklist

पहले working tree और verification commands इकट्ठा करें। यह Node project example है; दूसरे stack में pytest, go test ./..., bundle exec rspec या team CI command लगाएं।

git status --short
git diff --stat
git diff --name-only
npm run build
npm run test -- --runInBand

इस checklist को PR description, .github/review-checklist.md या team wiki में रख सकते हैं।

# Claude Code Review Checklist

## Scope
- [ ] This PR has one clear purpose.
- [ ] Changed files match the stated purpose.
- [ ] No unrelated formatting, dependency, or generated files are mixed in.

## Risk
- [ ] Risk level is marked as low, medium, or high.
- [ ] User-facing routes, forms, auth, billing, analytics, and CTA paths are named.
- [ ] Rollback or recovery steps are written for high-risk changes.

## Evidence
- [ ] Build, test, lint, or typecheck commands are listed with results.
- [ ] Manual checks include browser width, account state, and actual URL when relevant.
- [ ] Screenshots, logs, or console output are attached for UI and integration changes.

## Review output
- [ ] Findings come first, ordered by severity.
- [ ] Each finding has file reference, reproduction condition, and expected fix.
- [ ] Residual risk is written even when no blocker is found.

Checklist का goal code की तारीफ नहीं, release risk पकड़ना है।

Copy-paste review prompt

Prompt छोटा हो सकता है, लेकिन output strict रखें। bug-finding mindset, findings first और do not rewrite code yet ज़रूर रखें।

Review this diff with a bug-finding mindset.

Scope:
- Only review the files changed in this PR.
- Do not rewrite code yet.

Prioritize:
1. behavioral regressions
2. security, privacy, or permission mistakes
3. missing tests or weak verification
4. broken mobile layout, internal links, product CTA, or training CTA

Return:
- Findings first, ordered by P1/P2/P3 severity
- File and line references when possible
- Why each issue matters to users or revenue
- Checks I should run next
- Residual risk if no blocker is found

पहला pass read-only रखें। अगर review के दौरान Claude Code code बदलने लगे, तो team को issue list और priority साफ नहीं दिखती।

चार practical use cases

पहला use case CTA और revenue path है। Article footer, product card, pricing copy या consultation link बदले तो target URL, product match, button order, mobile layout और analytics event देखें। Common failure है कि button “templates” कहता है लेकिन पुराने Gumroad product पर जाता है। Flow को /hi/products/ और /hi/training/ से सही तरीके से जोड़ें।

दूसरा use case auth, permission और private data है। UI में button छिपाना server authorization नहीं है। Claude Code से check करवाएं कि कौन action कर सकता है, किसे reject होना चाहिए, logs में email या payment ID तो नहीं, और rejected user path पर test है या नहीं।

तीसरा use case multilingual publishing है। एक locale natural लग सकता है, दूसरे में पुराना updatedDate, खुला code fence, missing product link या mojibake हो सकता है। Prompt में exact locale files, preserve metadata और required strings लिखें।

चौथा use case build या test failure triage है। बड़ा log paste न करें। failing command, last relevant lines, recent diff और already tried fixes दें। Pitfall है छोटा build fix करते हुए unrelated dependency update जोड़ देना।

Common failure cases

“सब review कर दो” बहुत broad request है। Claude Code फिर generic advice देता है। बेहतर है files, risk और out-of-scope चीजें लिखना।

दूसरी गलती evidence missing रखना है। npm run build, typecheck, browser path या mobile view चला या नहीं, यह साफ न हो तो review अनुमान बन जाता है। कोई check नहीं चला तो reason लिखें।

Revenue path में desktop-only check खतरनाक है। CTA wrapping, horizontal scroll, real destination और /products/ तथा /training/ order जरूर देखें।

Security में API keys, tokens, customer email, payment ID या private content prompt में न डालें। Logs को minimum reproducible part तक छोटा करें।

Verification receipt script

यह Node script check करता है कि review receipt में required sections और कम से कम एक checked command है। यह full QA नहीं है, लेकिन बिना evidence release करने की गलती कम करता है।

{
  "requiredSections": ["Scope", "Risk", "Checks run", "Findings", "Residual risk"]
}

#!/usr/bin/env node
const fs = require("node:fs");

const receiptPath = process.argv[2] || "review-receipt.md";
const policyPath = process.argv[3] || "review-policy.json";
const receipt = fs.readFileSync(receiptPath, "utf8");
const policy = fs.existsSync(policyPath)
  ? JSON.parse(fs.readFileSync(policyPath, "utf8"))
  : { requiredSections: ["Scope", "Risk", "Checks run", "Findings", "Residual risk"] };

const escapeRegExp = (value) => value.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
const missingSections = policy.requiredSections.filter((name) => {
  const heading = new RegExp(`^## ${escapeRegExp(name)}\\b`, "m");
  return !heading.test(receipt);
});

const hasCheckedCommand = /^- \[(x|X)\] `(npm|pnpm|yarn|node|pytest|go test|cargo test)/m.test(receipt);

if (missingSections.length || !hasCheckedCommand) {
  for (const section of missingSections) console.error(`Missing section: ${section}`);
  if (!hasCheckedCommand) console.error("Missing checked command evidence such as - [x] `npm run build`");
  process.exit(1);
}

console.log("Review receipt passed.");

# Review receipt

## Scope
Article CTA links and mobile layout only.

## Risk
Medium: product and training links affect revenue.

## Checks run
- [x] `npm run build` passed
- [x] mobile CTA path checked at 360px

## Findings
- P2: Product CTA text and destination mismatch on one locale.

## Residual risk
Analytics event names were not checked in production.

Same idea को PR template, Claude Code prompt या light CI check में डाल सकते हैं।

अगला कदम

Solo developer पहले free Claude Code cheatsheet से daily commands और safe prompts fix करें। अगर review, debugging और triage prompts बार-बार लिखने पड़ते हैं, तो Prompt Templates और /hi/products/ देखें।

Team के लिए असली काम एक clever prompt नहीं है। CLAUDE.md, permission boundary, review gate, verification receipt और approval responsibility तय करनी पड़ती है। Real repository में workflow लागू करना हो तो /hi/training/ से शुरू करें।