Claude Code पहली task runbook: सुरक्षित prompts, diff review और handoff

पहली task तय करती है कि Claude Code भरोसेमंद लगेगा या नहीं

Claude Code install करने के तुरंत बाद पूरी feature, बड़ा refactor, या “इस पूरे repo को ठीक कर दो” मांगना आकर्षक लगता है। लेकिन पहली session अक्सर यहीं बिगड़ती है। आम तौर पर समस्या यह नहीं होती कि Claude Code मदद नहीं कर सकता। समस्या यह होती है कि scope, verification, permissions और project context अभी तय नहीं हुए होते।

यह runbook real repository में पहली practical task के लिए है। Runbook का मतलब है ऐसी checklist जिसे एक जैसी स्थिति में बार-बार चलाया जा सके। यहां पहली task “feature बनाओ” नहीं है। यह छोटा workflow है: सही prompt देना, plan confirm करना, एक bounded change करना, diff review करना, और handoff note छोड़ना।

अगर basics अभी नए हैं, पहले Claude Code getting started guide पढ़ें। Project rules लिखने के लिए इसे Claude Code CLAUDE.md templates के साथ इस्तेमाल करें। Official references के लिए Claude Code overview, memory और CLAUDE.md, permission modes, common workflows, और CLI reference देखें।

flowchart LR
  A["Repository पढ़ना"] --> B["3 सुरक्षित options देना"]
  B --> C["1 task चुनना"]
  C --> D["Plan पहले review करना"]
  D --> E["सबसे छोटा diff बनाना"]
  E --> F["Tests और diff verify करना"]
  F --> G["Handoff note लिखना"]

अच्छी पहली task कैसी होती है

पहली task का मकसद बड़ा output लेना नहीं है। यह देखना है कि workflow भरोसे के साथ आगे बढ़ सकता है या नहीं। अच्छी first task में पांच बातें होती हैं।

बात	सरल अर्थ	अच्छा example
Local	Production, customer data या external sending नहीं छूती	README commands check करना या एक assertion जोड़ना
Bounded	Files और stop point साफ दिखते हैं	एक component, एक test, एक document
Verifiable	Command, page या diff से success साबित हो	npm.cmd run test, git diff --check
Reversible	गलत result जल्दी हटाया जा सके	Normal source files, generated exports नहीं
Explainable	इंसान समझ सके कि change क्यों है	Reason, risk और uncertainty लिखी हो

“पूरी authentication फिर से बनाओ”, “पूरे codebase को modernize करो”, या “CI ठीक करके deploy कर दो” खराब first tasks हैं। इनमें missing context, permission prompts, कमजोर tests और unreadable diff एक साथ आ जाते हैं।

सुरक्षित first-task menu

Team onboarding में task invent करने से पहले इस menu से चुनें।

Task	क्यों useful है	Success condition
Repository map बनाना	Edit से पहले understanding test होती है	Entry points, commands और risky areas मिलते हैं
एक failing test summarize करना	Debugging की granularity दिखती है	Failure point, hypothesis और smallest next step साफ हैं
पुराना README command ठीक करना	Low-risk real edit try होता है	Command चलता है और diff छोटा रहता है
Existing test में एक assertion जोड़ना	Intent और testing judgement दिखता है	Assertion clear behavior protect करती है
एक UI copy बदलना	Search और minimal edit check होता है	सिर्फ target component बदलता है
एक lint warning ठीक करना	Local change discipline दिखता है	एक warning हटती है, behavior नहीं बदलता
Minimal CLAUDE.md बनाना	Future sessions बेहतर होती हैं	Commands, boundaries और review rules छोटे लिखे हैं

मुख्य बात है “छोटी लेकिन real” task। यह onboarding, bug diagnosis, documentation, tests या review quality से जुड़नी चाहिए।

Copy-paste prompt templates

शुरू में Claude Code से पढ़ने और propose करने को कहें, edit करने को नहीं।

इस repository को पढ़ें और अभी edit न करें।

Return करें:
1. main entry points
2. common build/test/lint commands
3. risky directories या generated files
4. 30-minute first session के लिए 3 safe task options
5. हर option को verify और rollback कैसे करेंगे

Options आने के बाद एक चुनें और plan मांगें।

सिर्फ option 2 पर आगे बढ़ें। अभी edit न करें।
पहले बताएं कि कौन सी files touch होंगी, change का reason, expected diff,
verification command और risks क्या हैं। अगर scope बढ़ रहा है, छोटा alternative दें।

फिर ही edit allow करें।

Approved plan follow करें और smallest possible diff बनाएं।
Request के बाहर files न छुएं।
Edit के बाद verification commands run, failed या skipped checks,
और remaining risks summarize करें।

Commit से पहले review के लिए अलग prompt रखें।

Pre-commit review करें।

1. git diff पढ़ें और request के बाहर changes खोजें
2. missing tests या weak verification खोजें
3. security, data loss और config risks check करें
4. ऐसी files खोजें जिन्हें commit नहीं करना चाहिए
5. ऐसी decisions बताएं जिन्हें अभी human judgement चाहिए

End में सिर्फ एक verdict दें: "commit ready", "fix first", या "stop".

30-minute flow

पहले पांच मिनट current state freeze करने में लगाएं। Windows PowerShell में:

Get-Location
git status --short
git branch --show-current
rg --files | Select-Object -First 40

macOS या Linux में:

pwd
git status --short
git branch --show-current
rg --files | head -n 40

अगर worktree पहले से dirty है, साफ बताएं कि कौन से changes human-owned हैं और touch नहीं करने हैं। वरना final diff judge करना मुश्किल होगा।

अगले दस मिनट में एक task चुनें। अच्छे first choices हैं: stale README command, one test assertion, या one failing test summary। First session में new feature से बचें।

लगभग 20वें minute पर ज्यादा edits की जगह proof को priority दें। एक सही और explained change तीन unverified changes से बेहतर है।

git diff --stat
git diff --check
git diff
git status --short

Last five minutes handoff note के लिए रखें। Handoff note next person या next Claude Code session के लिए छोटा memo है। Long conversations में initial boundary धुंधली हो सकती है, इसलिए अगली session को clean starting point चाहिए।

चार concrete use cases

Use case 1: नए developer की onboarding

पहले दिन बड़ा issue न दें। Claude Code से repo map, key commands, dangerous directories और first files to read बनवाएं।

Prompt: “नए developer के लिए onboarding note बनाएं। Facts और guesses अलग रखें। जहां हो सके command output शामिल करें।” Success का मतलब है README से आगे practical context मिलना, जैसे generated files, local settings, या CI और local के differences।

Use case 2: visible bug के लिए reproduction note

अगर bug “कभी-कभी टूटता है” वाला है, fix से शुरू न करें। Conditions, expected result, actual result, relevant files और missing logs लिखवाएं। यह Claude Code bug report template के साथ अच्छा चलता है।

Success patch नहीं है। Success ऐसी note है जिसे human verify कर सके। अगर bug reproduce नहीं होता, output में यह साफ लिखा होना चाहिए और next logs या data की जरूरत बतानी चाहिए।

Use case 3: documentation या UI copy change

Marketing sites, admin tools और internal dashboards पहली session के लिए अच्छे होते हैं क्योंकि copy change visible और reversible होता है। Scope narrow रखें: एक CTA, एक settings explanation, या एक paragraph।

Success का मतलब है सिर्फ target files बदलीं, meaning वही रहा, और result local में check हो सकता है। Multilingual site में यह भी check करें कि सिर्फ एक locale update करके बाकी inconsistent न छोड़े गए हों।

Use case 4: छोटी test improvement

अगर project में tests हैं, feature जोड़ने से बेहतर एक assertion जोड़ना है। Boundary case, error-message expectation, या empty-list case अच्छे options हैं।

Tests pass होना ही काफी नहीं। Claude Code को explain करना चाहिए कि assertion कौन सा behavior protect करती है। जिसे explain नहीं किया जा सकता, ऐसी assertion future maintenance noise बनती है।

Commit से पहले diff review

Claude Code files edit करे तो human review पर वापस आएं। First task में automatic commit और push से बचें। Permission modes convenience और oversight के बीच tradeoff हैं, इसलिए normal review या plan mode से शुरू करें। bypass permissions जैसे strong modes सिर्फ isolated environment में use करें।

Pre-commit checklist

[ ] सिर्फ requested files बदली हैं
[ ] Generated files, secrets या local settings शामिल नहीं हैं
[ ] Test या substitute verification result recorded है
[ ] Failed या skipped checks बताए गए हैं
[ ] कोई unexplained diff नहीं बचा
[ ] Handoff note में next TODO है

पहले git diff --stat से spread देखें। फिर git diff --check whitespace और patch hygiene के लिए चलाएं। अंत में diff खुद पढ़ें और surprise refactors, naming changes, या tests के बिना behavior changes खोजें।

Common failure cases

पहली failure है oversized scope। “login ठीक करो” की जगह “login error message को एक test से verify करो” कहें। Autonomy छोटी tasks में trust बनने के बाद दें।

दूसरी failure है proof के बिना “done” accept करना। अगर tests नहीं हैं, substitute proof तय करें: rendered page, type check, git diff --check, log comparison, या README command।

तीसरी failure है permission prompts को casual approve करना। Prompt आए तो पूछें command क्या है, कौन से paths touch होंगे, और क्या network या deletion शामिल है। Prompt fatigue हो तो narrow commands approve करें, सब कुछ खुला न करें।

चौथी failure है context loss। Long conversations initial boundary को धुंधला कर देती हैं। Task boundary, commands run और remaining risk handoff note में रखें। Permanent CLAUDE.md rules और one-session notes को mix न करें।

पांचवीं failure है existing uncommitted work को नुकसान पहुंचाना। Shared repo में दूसरा developer या agent पहले से changes कर सकता है। git status --short से शुरू करें और unrelated changes को explicitly protect करें।

Handoff note template

First task के अंत में इसे paste करें।

## Handoff note

- Task:
- Changed files:
- Verification run:
- Verification not run:
- Important diff points:
- Remaining risks:
- Do not touch next time:
- Suggested next smallest task:

यह note commit message से broader है। Commit से पहले यह PR description material बनती है। Commit न हो तो यह next session का starting point बनती है।

Next steps और paid paths

First task सफल होने के बाद repeatability बनाएं। Solo users recurring rules को CLAUDE.md templates में बदलें। अगर approvals और sandbox अभी unclear हैं, Claude Code approval and sandbox guide पढ़ें।

Ready-to-use templates, checklists और onboarding material के लिए /products/ देखें। Team rollout, repository-specific onboarding, permission design और review workflows के लिए /training/ इस्तेमाल करें। एक safe first task इस article से हो सकती है। Team rollout के लिए usage बढ़ाने से पहले rules, proof और training चाहिए।

Masa के actual trial में सबसे stable pattern था: पहले repo पढ़ना, सिर्फ एक file edit करना, git diff साथ में review करना, और handoff note छोड़ना। जिन sessions की शुरुआत बड़े request से हुई, उनमें saved time से ज्यादा review work बना। 30-minute छोटी task सफल होने पर दूसरी task scope करना और team को समझाना काफी आसान हुआ।