Claude Code टीम हैंडऑफ नियम: review proof, permissions, rollback और revenue path

टीम handoff क्यों जरूरी है

अकेले Claude Code इस्तेमाल करते समय कई बातें याददाश्त से संभल जाती हैं। टीम में ऐसा नहीं चलता। जब AI से बना patch किसी दूसरे व्यक्ति को review करना हो, तो सिर्फ यह देखना काफी नहीं कि diff ठीक दिखता है या नहीं। टीम को यह भी पता होना चाहिए कि risky command किसने approve किया, कौन सा public URL check हुआ, कौन सा proof दोबारा चलाया जा सकता है, और कौन सा revenue path सुरक्षित रखा गया।

यह बात article, landing page, product copy, Gumroad link और consultation form में और ज्यादा महत्वपूर्ण हो जाती है। Build pass हो सकता है, लेकिन free PDF button गलत page पर जा सकता है। Copy बेहतर लग सकती है, लेकिन price promise बदल सकता है। Form दिखने में ठीक हो सकता है, लेकिन submit करने पर thank-you page टूट सकता है।

इस handoff का लक्ष्य लंबी activity diary बनाना नहीं है। लक्ष्य है एक छोटा review contract: क्या बदला, proof क्या है, कौन सी permission इस्तेमाल हुई, rollback कैसे होगा, क्या नहीं छूना है, और free PDF/Gumroad/consultation path check हुए या नहीं।

इसे session handoff template, Permission Budget Loop और review workflow checklist के साथ पढ़ें। Claude Code की basic जानकारी के लिए official documentation भी उपयोगी है।

टीम handoff के failure examples

पहली common failure है सिर्फ work log देना: “article बढ़ाया”, “links ठीक किए”, “build चलाया”। इससे reviewer को यह नहीं पता चलता कि किस proof पर भरोसा करना है, कौन सा URL खोलना है, और कौन सा conversion path सच में check हुआ है। Review को process की कहानी नहीं, repeatable evidence चाहिए।

दूसरी failure है approval rules को बोलकर छोड़ देना। किसी को लगता है कि यह छोटी copy edit है, लेकिन Claude Code price copy, CTA destination, deployment setting या public form छू देता है। Permission boundary लिखी नहीं है, तो reviewer को diff देखकर intent guess करना पड़ता है।

तीसरी failure है rollback न लिखना। अगर AI change publish होने के बाद page तोड़ता है, टीम को restore point, revert command और recovery order पता होना चाहिए। इनके बिना शुरुआती मिनट responsibility तय करने में निकलते हैं, page या purchase path restore करने में नहीं।

चौथी failure है revenue path को “कोई और देख लेगा” मान लेना। Content operation में traffic अंत नहीं है। Reader को free PDF मिलना चाहिए, Gumroad material खरीदना चाहिए, या consultation form भेजना चाहिए। ये path article की functional surface का हिस्सा हैं।

Masa के workflow में भी सिर्फ thin article समस्या नहीं थी। बड़ी समस्या यह थी कि reviewer जल्दी नहीं देख पाता था कि article सही learning path और buying path से जुड़ा है या नहीं। जब proof, permission, rollback और revenue checks handoff में आए, review comments “क्या देखना है?” से बदलकर “यह proof काफी है” या “Gumroad अभी check नहीं हुआ” हो गए।

Review में कौन सा proof देना चाहिए

अच्छा proof specific और repeatable होता है। Reviewer वही command चला सके, वही URL खोल सके, और वही risk boundary समझ सके। Article task में आम तौर पर body length, h2 count, internal link, external link, code block, heroImage, localization quality और CTA destination देने चाहिए।

Product page में mobile view, form submission, price copy, purchase link, canonical और thank-you page शामिल करें। Development task में tests, type check, build output, affected files और known gaps लिखें। Checklist task के हिसाब से बदलेगी, लेकिन सवाल वही रहेगा: reviewer बिना guess किए क्या verify कर सकता है?

छोटा command record भी पर्याप्त शुरुआत है:

npm run build
node scripts/check-updated-article-quality.mjs

अगर कोई command नहीं चली, तो केवल “not checked” मत लिखें। कारण लिखें: dependencies नहीं थीं, API key local में नहीं थी, check केवल CI में हो सकता है, या online preview चाहिए। इससे missing proof भी reviewable gap बन जाता है।

Screenshot मदद करता है, लेकिन अकेला proof नहीं है। Screenshot सिर्फ दिखाता है कि एक समय पर एक viewport ठीक था। वह link target, purchase flow या rollback prove नहीं करता। Screenshot को URL, command result और short risk note के साथ दें।

कॉपी-पेस्ट के लिए शुरुआती किट

इस Markdown block को PR description, Issue, Slack या Notion में डालें। यह जानबूझकर छोटा है, क्योंकि daily workflow में भारी form नहीं टिकता।

# Claude Code team handoff

## Change made
- 

## Proof
- build:
- public URL:
- screenshot:

## Revenue path checked
- free PDF:
- Gumroad:
- consultation:

## Next owner
- reviewer:
- decision needed:
- do not touch:

Permission rules को machine-readable रखना बेहतर है। यह JSON अपने आप security system नहीं है, लेकिन Claude Code और human reviewer को same boundary language देता है।

{
  "approval_rules": {
    "safe": ["read files", "search", "small copy edit"],
    "review_required": ["pricing", "CTA links", "deployment"],
    "blocked": ["secrets", "force push", "delete customer data"]
  }
}

Reviewer prompt भी fixed रखें। Scope साफ न हो तो review style preference, पुराने product debate या unrelated refactor में फैल जाता है।

You are receiving a Claude Code handoff.
Check the proof first.
Then review only:
1. whether the stated goal was met
2. whether protected links still work
3. whether the next owner has one clear action

Permission, rollback और revenue path template

Team workflow में permission, rollback और revenue path एक ही template में रखें। Incident अक्सर तब होता है जब risky change verbal approve हो जाता है, restore point नहीं लिखा जाता, और सब मान लेते हैं कि CTA अभी भी काम कर रहा है।

handoff:
  owner: "Masa"
  reviewer: "team-reviewer"
  permission:
    safe:
      - "copy edit inside the article body"
      - "run local quality checks"
    needs_review:
      - "price copy"
      - "CTA destination"
      - "deployment setting"
    blocked:
      - "secrets"
      - "customer data"
      - "force push"
  rollback:
    restore_point: "commit or branch before Claude Code work"
    command: "git revert <commit>"
    priority_path:
      - "public article page"
      - "free PDF signup"
      - "Gumroad purchase"
      - "consultation form"
  revenue:
    free_pdf: "checked"
    gumroad: "checked"
    consultation: "checked"

यह template bureaucracy नहीं है। छोटी article edit के लिए इसे पांच मिनट में भरा जा सकता है। अगर change price, purchase, form, customer data या deploy छूता है, तो review मांगने से पहले ये fields भरना चाहिए।

तीन से ज्यादा real use cases

पहला use case article publishing है। Writer Claude Code से article expand करता है, फिर editor या engineer quality script, public page, internal link, external link, heroImage और free PDF CTA check करता है। Reviewer को पूरी site दोबारा पढ़ने की जरूरत नहीं, वह promised improvement और conversion path verify करता है।

दूसरा use case product copy है। PM Claude Code से Gumroad material की description rewrite करवा सकता है, लेकिन price, refund terms, CTA destination और purchase link review_required में रहते हैं। इससे copy बेहतर होने के साथ commercial promise बिना approval बदले नहीं जाता।

तीसरा use case consultation page cleanup है। Claude Code headings tighten कर सकता है, intake questions rewrite कर सकता है और duplicate explanation हटा सकता है। फिर भी handoff में proof होना चाहिए कि form submit होता है, validation message दिखता है और thank-you page खुलता है।

चौथा use case permission policy maintenance है। Team lead अगर तय करता है कि read और search safe हैं, price और deploy review_required हैं, secrets और customer data blocked हैं, तो rule को meeting memory में नहीं, diff में रखें। अगली Claude Code session वही context इस्तेमाल कर सकेगी।

Reviewer handoff कैसे पढ़े

Reviewer को diff से पहले proof देखना चाहिए। Build या quality command check करें, preview या public URL खोलें, screenshot देखें और protected links test करें। Proof missing हो तो code से result guess करने के बजाय handoff incomplete मानकर वापस भेजें।

फिर permission scope देखें। अगर change safe area में है, normal review काफी है। अगर price, CTA, deploy, form या revenue copy बदली है, तो relevant owner confirm करे। अगर blocked area छुआ गया है, तो result अच्छा दिखने पर भी merge नहीं करना चाहिए।

अंत में rollback देखें। Rollback path के बिना handoff operationally complete नहीं है। Pure article edit में एक commit revert काफी हो सकता है। Product, checkout, tracking या consultation flow में recovery order लिखना जरूरी है: पहले public page, फिर free PDF signup, फिर Gumroad purchase, फिर consultation form।

Material और consultation की natural direction

Individual adoption के लिए free Claude Code cheatsheet से शुरू करें। अगर blocker command fluency और safe habits है, तो यह काफी है। जब review, debugging, article improvement या documentation prompts बार-बार दोहराने लगें, तब 50 Claude Code Prompt Templates उपयोगी हैं।

Team setup के लिए Claude Code Setup Guide CLAUDE.md, hooks, permissions, MCP और verification commands को standardize करने में मदद करती है। यह उन teams के लिए सही है जो process खुद implement कर सकती हैं, पर structure चाहती हैं।

अगर मुश्किल हिस्सा यह है कि approval कौन देगा, कौन से links protect होंगे, AdSense, Gumroad और consultation form कैसे जुड़ेंगे, तो English products page compare करें या consultation page देखें। Consultation single prompt नहीं, responsibility, evidence, rollback और revenue priority design करती है।

Natural path सरल है: habits के लिए free PDF, repeatable workflow के लिए Gumroad material, और team-specific rules के लिए consultation। इससे reader पर एक ही next step थोपना नहीं पड़ता।

इस article में मैंने क्या verify किया

इस article में Markdown handoff, JSON permission rules, reviewer prompt और permission/rollback/revenue YAML template शामिल हैं। उद्देश्य यह है कि Claude Code का काम दूसरे व्यक्ति के लिए reviewable बने, केवल session चलाने वाले व्यक्ति के लिए समझने योग्य नहीं। Team में Claude Code का लाभ तभी टिकता है जब अगला owner जल्दी बता सके: क्या बदला, proof कहां है, और कौन सा path protect करना है।