Claude Code से नए इंजीनियर का onboarding 2 हफ्तों में कैसे करें

नए इंजीनियर का onboarding सिर्फ laptop देने से पूरा नहीं होता। Onboarding का मतलब है किसी नए व्यक्ति को “मैं repository खोल सकता हूं” से “मैं टीम के नियमों के साथ छोटा, reviewable change PR में भेज सकता हूं” तक लाना। देरी अक्सर setup के दोहराए जाने वाले सवालों, बड़े codebase, अस्पष्ट review expectations और ऐसे tribal knowledge से होती है जो केवल पुराने लोगों को पता होता है।

Claude Code mentor की जगह लेने के लिए नहीं है। इसका बेहतर उपयोग एक सुरक्षित काम करने का ढांचा बनाना है: CLAUDE.md में project instructions, repeatable setup script, permissions, first task checklist, PR template और CI को समझने का साफ तरीका। आसान भाषा में, codebase पूरे application का source code है, PR review के लिए change request है, और CI वह automated system है जो merge से पहले tests और build चलाता है।

Claude Code बदल सकता है, इसलिए official docs को source of truth रखें: Claude Code setup, CLI reference, memory, और settings। संबंधित गाइड के लिए codebase navigation, code review और CLAUDE.md templates देखें।

flowchart LR
  A["Day 1: setup"] --> B["Day 2: codebase map"]
  B --> C["Day 3-5: first task"]
  C --> D["Week 2: PR review"]
  D --> E["Retrospective and docs update"]

1. शुरुआत CLAUDE.md से करें

CLAUDE.md वह project memory है जिसे Claude Code shared instruction की तरह पढ़ता है। Onboarding के लिए इसमें abstract बातें नहीं, बल्कि commands, boundaries और escalation rules लिखें।

cat > CLAUDE.md <<'EOF'
# Project instructions for Claude Code

## Goal
Help new engineers make small, reviewable changes without bypassing tests or team rules.

## Daily commands
- Install: npm ci
- Type check: npm run typecheck
- Unit tests: npm test -- --runInBand
- Lint: npm run lint
- Build: npm run build

## Boundaries
- Do not edit files under migrations/ without human approval.
- Do not read .env, .env.*, secrets/, or production credentials.
- Do not push, commit, deploy, or publish packages.
- Prefer small diffs under 150 lines for first tasks.

## First PR rules
- Explain the intent before editing.
- Reuse existing patterns before adding dependencies.
- Add or update tests for behavior changes.
- Include command output in the PR description.

## When stuck
Ask the engineer to provide:
1. What they tried
2. The exact error
3. The file or command involved
4. What Claude Code inferred and what still needs human judgment
EOF

लक्ष्य Claude Code को जादुई senior बनाना नहीं है। लक्ष्य scope छोटा करना है ताकि नया engineer team standard सीखे और reviewer को साफ diff मिले।

2. Setup को repeatable बनाएं

पहला blocker अक्सर Node version, dependencies, local env vars, test data और “कौन सा command बताएगा कि सब ठीक है” से जुड़ा होता है। Script इसे साफ रास्ते में बदल देती है।

mkdir -p scripts
cat > scripts/onboarding-setup.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

echo "== Checking required tools =="
node --version
npm --version
git --version

if ! command -v claude >/dev/null 2>&1; then
  echo "Claude Code is not installed."
  echo "Install with: npm install -g @anthropic-ai/claude-code"
  exit 1
fi

echo "== Installing dependencies =="
npm ci

if [ ! -f .env ] && [ -f .env.example ]; then
  cp .env.example .env
  echo "Created .env from .env.example. Fill in local-only values before running the app."
fi

echo "== Running baseline checks =="
npm run lint
npm run typecheck
npm test -- --runInBand

echo "== Ask Claude Code for a local map =="
claude -p "Read README.md, package.json, and CLAUDE.md. Explain how to start this project locally, which checks just ran, and what a new engineer should verify before opening the first PR."
EOF
chmod +x scripts/onboarding-setup.sh

Typical npm project में यह script copy-paste करके चल सकता है। pnpm, Yarn, Docker Compose या Makefile वाले teams commands बदल सकते हैं। Structure वही रखें: setup, verification और Claude Code से explanation।

3. Permissions से risk कम करें

Claude Code files पढ़ सकता है, code search कर सकता है, commands चला सकता है और अनुमति मिलने पर edit भी कर सकता है। यह onboarding में उपयोगी है, लेकिन .env पढ़ने, dangerous commands चलाने या बहुत बड़ा diff बनाने का risk भी है।

mkdir -p .claude
cat > .claude/settings.json <<'EOF'
{
  "permissions": {
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Bash(npm run lint)",
      "Bash(npm run typecheck)",
      "Bash(npm test:*)"
    ],
    "ask": [
      "Edit",
      "Write",
      "Bash(npm install:*)",
      "Bash(git checkout:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push:*)",
      "Bash(git commit:*)",
      "Bash(rm:*)",
      "Bash(curl:*)",
      "Bash(npm publish:*)"
    ]
  }
}
EOF

पहले हफ्ते में read, search, diff, log और tests काफी हैं। Edit confirmation मांग सकता है। Push, commit, deploy, publish और secret access onboarding path से बाहर रखें।

4. First PR checklist बनाएं

पहला PR बड़ा feature नहीं, team workflow सीखने का अभ्यास है। अच्छे examples हैं: existing behavior पर missing unit test, छोटा UI text fix, better error message या एक folder में duplicated helper logic हटाना। खराब first tasks हैं: auth, billing, permissions, migrations, broad formatting और dependency upgrades।

mkdir -p docs/onboarding
cat > docs/onboarding/first-task-checklist.md <<'EOF'
# First task checklist

## Before editing
- [ ] I can run `npm ci`.
- [ ] I can run `npm run lint`.
- [ ] I can run `npm run typecheck`.
- [ ] I can run the nearest test for the area I will touch.
- [ ] I understand the user-visible behavior being changed.

## Good first task examples
- [ ] Add a missing unit test around existing behavior.
- [ ] Fix a small UI copy typo with screenshot evidence.
- [ ] Replace duplicated helper logic in one folder.
- [ ] Improve one error message without changing API contracts.

## Not good for the first task
- [ ] Authentication, billing, permissions, or migrations.
- [ ] Broad formatting changes.
- [ ] Dependency upgrades.
- [ ] Refactors across multiple packages.

## PR evidence
- [ ] Summary of the change.
- [ ] Test commands and results.
- [ ] Screenshot or log if behavior changed.
- [ ] Open question for reviewer, if any.
EOF

इस workflow से कम से कम चार practical use cases cover होते हैं: self-service setup, codebase reading, first task selection और PR से पहले self-review।

5. Review request template standard करें

कई first PR इसलिए वापस आते हैं क्योंकि reviewer को पता नहीं होता कि क्या verify किया गया। Template intent, safety, verification और reviewer focus को साफ करता है।

mkdir -p .github
cat > .github/pull_request_template.md <<'EOF'
## Summary
- TODO

## Why this is safe for a first PR
- Scope:
- Files changed:
- Behavior changed:

## Verification
- [ ] `npm run lint`
- [ ] `npm run typecheck`
- [ ] `npm test -- --runInBand`

## Claude Code self-review prompt used
Ask Claude Code:
"Review git diff origin/main...HEAD for naming, tests, security, and consistency with CLAUDE.md. Return only actionable issues."

## Reviewer focus
- TODO

## Screenshots or logs
- TODO
EOF

Mentor के लिए भी यह आसान है। वह जल्दी देख सकता है कि review design, tests, behavior, screenshots या workflow confidence पर है।

6. CI पहले दिन से समझाएं

CI यानी Continuous Integration। यह PR merge से पहले checks चलाने वाला automated system है। नए engineer को red status देखकर रुकना नहीं चाहिए; उसे यह समझना चाहिए कि कौन सा command fail हुआ और local machine पर कैसे reproduce करना है।

name: onboarding-checks

on:
  pull_request:
    branches: [main]

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "npm"
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm test -- --runInBand
      - run: npm run build

अगर team कोई और CI use करती है, तब भी ये commands onboarding doc में रखें। Claude Code से failing log पढ़वाकर पहला local reproduction command निकलवाएं।

Common pitfalls

पहला pitfall है business judgment Claude Code को देना। वह code और history से infer कर सकता है, लेकिन customer commitments, exceptions और compliance decisions humans के पास ही रहने चाहिए।

दूसरा pitfall है पहला PR बहुत बड़ा बनाना। संभव हो तो 150 lines से कम, tests के साथ और rollback-friendly change रखें।

तीसरा pitfall है secrets expose करना। settings में .env, credentials और production files deny करें और docs में sample values ही रखें।

चौथा pitfall है human questions को बहुत रोकना। “पहले Claude से पूछो” तभी अच्छा है जब पहले दो हफ्तों में frequent mentor check-ins भी हों।

CTA

Team rollout के लिए CLAUDE.md, permissions, PR evidence और CI checks को साथ standard करें। Individual developers free cheatsheet से daily commands शुरू कर सकते हैं। Reusable templates के लिए ClaudeCodeLab products देखें। Team training, permission design और real repository rollout के लिए Claude Code training and consultation उपयोगी है।

वास्तव में आजमाने पर नतीजा

ClaudeCodeLab के article updates और छोटे code changes में सबसे बड़ा सुधार तब आया जब implementation से पहले rules लिखे गए। CLAUDE.md, limited permissions, verification commands और PR template होने पर diff review करना आसान हुआ। जब Claude Code गलत निकला, तो saved assumptions और command trail से यह जल्दी पता चल गया कि misunderstanding कहां से शुरू हुई।