Claude Code टीम सहयोग गाइड: हैंडऑफ, समीक्षा और अनुमति सीमा

Claude Code अकेले डेवलपर के लिए तेज़ मददगार है। कोड समझना, सुधार करना और टेस्ट लिखना जल्दी हो जाता है। लेकिन टीम में अपनाने पर असली कठिनाई बदल जाती है। किसने कौन सा कमांड मंज़ूर किया, Claude ने कौन सी फाइलें देखीं, कौन सा जोखिम अभी सत्यापित नहीं है, और AI की सलाह को इंसान ने सच में स्वीकार किया या नहीं, यह सब रिकॉर्ड करना पड़ता है।

यह गाइड छोटी और मध्यम विकास टीमों के लिए व्यावहारिक तरीका देती है। इसमें टीम हैंडऑफ, PR की शुरुआती समीक्षा, CLAUDE.md नियम, अनुमति सीमा, नए सदस्य की शुरुआत, घटना के समय जिम्मेदारी बदलना और संचार की गलतियां शामिल हैं। अनुमति सीमा का मतलब है Claude Code किन फाइलों को पढ़, बदल या किन कमांड को चला सकता है। समीक्षा रसीद का मतलब है PR में छोड़ा गया छोटा रिकॉर्ड कि AI की सलाह पर टीम ने क्या किया।

flowchart LR
  A["डेवलपर का अनुरोध"] --> B["CLAUDE.md और नियम"]
  B --> C["Claude Code का काम"]
  C --> D["टेस्ट और diff जांच"]
  D --> E["समीक्षा रसीद"]
  E --> F["इंसानी PR समीक्षा"]

पहले चार साझा जगह तय करें

टीम प्रक्रिया इस बात पर निर्भर नहीं होनी चाहिए कि किसी एक व्यक्ति को अच्छे prompts याद हैं। नियम repository में साझा फाइलों में रहने चाहिए।

जगह	उद्देश्य	Git में
CLAUDE.md	प्रोजेक्ट नियम, मना काम, टेस्ट कमांड	हां
.claude/settings.json	साझा अनुमति, deny नियम, hooks	हां
.claude/settings.local.json	निजी sandbox URL और अस्थायी सेटिंग	नहीं
.claude/prompts/*.md	हैंडऑफ, समीक्षा और जांच टेम्पलेट	हां

आधिकारिक दस्तावेज़ Claude Code memory, settings, permissions और security की भूमिका समझाते हैं। इसी विषय पर CLAUDE.md best practices, Claude Code hooks guide और GitHub Actions advanced भी उपयोगी हैं।

उपयोग 1: डेवलपर से समीक्षक को हैंडऑफ

सबसे आम गलती है PR में सिर्फ “Claude ने ठीक कर दिया” लिख देना। समीक्षक को यह जानना चाहिए कि Claude ने कौन सी फाइलें पढ़ीं, कौन से कमांड मंज़ूर हुए, कौन से टेस्ट फेल हुए और कौन से निर्णय अभी इंसान को करने हैं।

.claude/prompts/handoff.md बनाएं:

# टीम हैंडऑफ नोट लिखें

मौजूदा diff पढ़ें और नीचे के format में हैंडऑफ लिखें।

## उद्देश्य
- यह बदलाव कौन सी समस्या हल करता है:

## दायरा
- बदली गई फाइलें:
- नहीं बदलीं, पर असर पड़ सकता है:

## सत्यापन
- चलाए गए कमांड:
- परिणाम:
- असफल log का सार:

## समीक्षक के लिए ध्यान
- उत्पाद निर्णय:
- सुरक्षा:
- प्रदर्शन:
- टेस्ट की कमी:

## अगले जिम्मेदार व्यक्ति के लिए
- पहले जांचें:
- बाद में हो सकता है:

diff तैयार होने के बाद चलाएं:

claude -p "git diff पढ़ें और .claude/prompts/handoff.md के format में टीम हैंडऑफ नोट बनाएं"

नतीजा PR के body में चिपकाएं। इससे समीक्षक सीधे जोखिम वाले हिस्सों से शुरुआत कर सकता है और संदर्भ दोबारा खोजने में समय नहीं जाता।

उपयोग 2: AI से PR की शुरुआती समीक्षा

Claude Code को इंसानी मंज़ूरी का विकल्प नहीं बनाना चाहिए। वह शुरुआती समीक्षा के लिए बेहतर है, जहां obvious bug, छूटे टेस्ट, सुरक्षा जोखिम और असंगत बदलाव पहले पकड़े जाते हैं।

.claude/prompts/pr-review.md बनाएं:

# PR शुरुआती समीक्षा

diff को इन बिंदुओं से जांचें:

1. branch, null/undefined और सीमा मान जो bug बन सकते हैं
2. अनुमति जांच, input validation और secret leak
3. N+1 query, अनावश्यक rerender और भारी synchronous काम
4. CLAUDE.md नियम का उल्लंघन
5. छूटे हुए test case

Output format:
- गंभीरता: उच्च / मध्यम / निम्न
- फाइल:
- line या function:
- कारण:
- सुधार सुझाव:

सिर्फ अनुमान वाले बिंदु पर “पुष्टि जरूरी” लिखें।

GitHub CLI के साथ local run:

gh pr diff 123 | claude -p "$(cat .claude/prompts/pr-review.md)"

GitHub Actions में automate करते समय उसे सिर्फ comment करने दें। merge का निर्णय इंसान करे।

name: Claude PR pre-review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  pre-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Install tools
        run: npm install -g @anthropic-ai/claude-code
      - name: Run Claude Code review
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR_NUMBER: ${{ github.event.pull_request.number }}
        run: |
          gh pr diff "$PR_NUMBER" > /tmp/pr.diff
          claude -p "$(cat .claude/prompts/pr-review.md)

          Diff:
          $(cat /tmp/pr.diff)" > /tmp/claude-review.md
          gh pr comment "$PR_NUMBER" --body-file /tmp/claude-review.md

आधिकारिक common workflows पेज में समीक्षा और टेस्ट workflows भी हैं। टीम नियम साफ होना चाहिए: AI comment सलाह है, approval इंसान देता है।

उपयोग 3: नए सदस्य की शुरुआत

नए सदस्य अक्सर syntax से कम और “कौन सा command सुरक्षित है”, “business rule कहां है”, “पहले कौन सी फाइल पढ़नी है” से ज्यादा अटकते हैं। Claude Code repository का पहला नक्शा बना सकता है।

claude -p "
इस repository को नए टीम सदस्य के लिए समझाएं।
इन चीजों को जरूर शामिल करें:
- मुख्य directories और जिम्मेदारियां
- local run, lint, test और build commands
- पहले पढ़ने वाली 3 files
- बदलाव से पहले जांचने वाले business rules
- आम गलतियां और बचाव
- 30 मिनट की practice task

अनुमान न लगाएं। जो स्पष्ट नहीं है उसे पुष्टि जरूरी लिखें।
"

AI output को सीधे publish न करें। किसी अनुभवी सदस्य को 30 मिनट देकर production constraints, पुराने निर्णय और संचालन जोखिम जोड़वाएं। बड़ी जांच में subagent patterns research और summary को अलग रखने में मदद करते हैं।

उपयोग 4: घटना और shift handoff

incident के समय Claude Code logs का सार और hypotheses व्यवस्थित कर सकता है। लेकिन जोखिम भी बड़ा होता है: secret paste हो जाना, अपुष्ट hypothesis को fact की तरह भेजना, या जिम्मेदार व्यक्ति बदलने पर “क्या try किया” खो जाना।

इसे .claude/prompts/incident-handoff.md में रखें:

# घटना हैंडऑफ

## लक्षण
- कब से:
- दायरा:
- user impact:

## देखे गए तथ्य
- logs:
- metrics:
- reproduce steps:

## अब तक कोशिश
- commands:
- परिणाम:
- गलत निकली hypotheses:

## बचा जोखिम
- data corruption:
- security impact:
- rollback स्थिति:

## अगले जिम्मेदार व्यक्ति के लिए
- पहले देखने वाली screen/log:
- कभी न चलाने वाले commands:

Claude Code को logs देने से पहले email, access token और customer ID छिपाएं। security docs भी permissions और prompt injection के जोखिम बताते हैं। logs को साधारण chat content नहीं, production data मानें।

उपयोगी CLAUDE.md नियम

CLAUDE.md में वही facts रखें जिन्हें टीम बार-बार समझाती है। नियम छोटे, ठोस और जांचने योग्य हों।

# Claude Code के लिए project instructions

## काम शुरू करने से पहले
- edit से पहले `git status --short` चलाएं।
- दूसरे लोगों के existing changes वापस न करें।
- product behavior unclear हो तो PR में “पुष्टि जरूरी” लिखें।

## code rules
- हर API input validate करें।
- database write में transaction boundary स्पष्ट करें।
- नया UI text जोड़ने से पहले existing translation key देखें।

## tests
- logic change पर unit test जोड़ें।
- bug fix पर एक regression test जोड़ें।
- test न चला सके तो कारण लिखें।

## PR
- summary, verification और remaining risk लिखें।
- Claude Code suggestion को human review के बाद ही अपनाएं।

यदि repository में पहले से AGENTS.md है, तो उसे duplicate करने के बजाय import करें।

@AGENTS.md

## Claude Code विशेष नियम
- billing, auth और delete flow में पहले plan mode से approach दें।
- `git push`, production deploy और migration इंसान करे।

settings से अनुमति सीमा तय करें

टीम में सबसे बड़ा जोखिम है सुविधा के लिए permissions बहुत खोल देना। पहले deny लिखें, फिर छोटा allow रखें।

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm test)",
      "Bash(git diff *)",
      "Bash(git status *)",
      "Edit(src/**)",
      "Edit(tests/**)"
    ],
    "ask": [
      "Bash(npm install *)",
      "Bash(git commit *)",
      "Write(.github/**)"
    ],
    "deny": [
      "Read(.env*)",
      "Read(**/secrets/**)",
      "Bash(git push --force*)",
      "Bash(rm -rf *)",
      "Bash(npm publish*)"
    ]
  }
}

hooks edit के बाद checks चला सकते हैं या खतरनाक commands रोक सकते हैं। अपनाने से पहले आधिकारिक hooks reference पढ़ें।

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npm run lint -- --quiet"
          }
        ]
      }
    ]
  }
}

यह example तभी सही है जब project में npm run lint मौजूद हो। बड़े monorepo में file-level check या CI बेहतर है।

PR में समीक्षा रसीद छोड़ें

AI review तब खतरनाक होती है जब कोई record नहीं रखता कि कौन सी सलाह मानी गई। PR template में यह जोड़ें:

## Claude Code समीक्षा रसीद

- इस्तेमाल prompt:
- Claude Code ने जो diff देखा:
- स्वीकार की गई सलाह:
- न मानी गई सलाह और कारण:
- अतिरिक्त human checks:
- चलाए गए tests:
- बचा risk:

अंतिम निर्णय लेने वाला:

Claude Code इस्तेमाल नहीं हुआ तो “इस्तेमाल नहीं” लिखें। उद्देश्य है कि AI-assisted काम सामान्य काम जितना या उससे अधिक पारदर्शी रहे।

ठोस गलतियां और उपाय

गलती	असर	उपाय
CLAUDE.md पुराना	पुराने commands और हटे API लौटते हैं	हर महीने वास्तविक failures से update
permissions बहुत चौड़ी	secrets और production action पास आ जाते हैं	पहले deny, फिर छोटा allow
सिर्फ AI approval	product decision और जिम्मेदारी गायब	PR approval हमेशा इंसान
मौखिक handoff	अगले दिन कारण नहीं मिलता	note को PR या Issue में चिपकाएं
/clear context मिटाता है	बदलाव का कारण खो जाता है	reset या compact से पहले summary बचाएं
hooks भारी	team workflow bypass करती है	file-level hooks या CI

संचार भी विफल होता है। “अच्छा कर दो” Claude Code को लक्ष्य अनुमान लगाने पर मजबूर करता है। बेहतर है: “सिर्फ यह function”, “schema न छुएं”, “पहले failing test log पढ़ें”।

न्यूनतम टीम checklist

• CLAUDE.md में commands, मना काम और PR नियम हैं
• .claude/settings.json में allow, ask और deny अलग हैं
• .claude/settings.local.json .gitignore में है
• handoff, PR review और incident prompts साझा हैं
• PR template में समीक्षा रसीद है
• अंतिम निर्णय लेने वाला व्यक्ति स्पष्ट है
• नए सदस्य के लिए 30 मिनट की practice task है

ClaudeCodeLab ऐसी AI टीम विकास templates को लगातार सुधारता है। अगर आप internal rollout तेज करना चाहते हैं, तो ClaudeCodeLab products भी देखें।

निष्कर्ष

Claude Code को टीम में अपनाना कोई जादुई prompt खोजने जैसा नहीं है। यह साझा instructions, छोटी permission boundary, टिकाऊ handoff और audit हो सकने वाली review receipt बनाने का काम है।

व्यक्तिगत काम में कुछ अच्छे prompts काफी हो सकते हैं। टीम में दूसरा व्यक्ति workflow दोहरा सके, failure trace कर सके और Claude Code की सलाह को इंसानी निर्णय से अलग देख सके, यह ज्यादा जरूरी है।

Masa ने छोटे validation repository में यह setup आजमाया। PR में handoff note और review receipt जोड़ने से reviewers ने “क्या check किया?” जैसे सवाल कम पूछे। हर edit के बाद पूरा lint चलाने वाला hook बहुत धीमा निकला, इसलिए CI बेहतर जगह रही। शुरुआत CLAUDE.md, PR pre-review prompt और review receipt से करें।