Claude Code के 10 खतरनाक Prompt Patterns | क्या न करें और सुरक्षित विकल्प

क्या आप यह सोचकर prompts लिखते हैं कि “इसे समझ जाएगा”? Claude Code निर्देशों को शाब्दिक रूप से execute करता है। अस्पष्ट या खतरनाक निर्देश अनचाहे परिणाम देते हैं।

इस लेख में 10 खतरनाक prompt patterns हैं जिन्होंने वास्तविक घटनाओं को जन्म दिया है, साथ ही प्रत्येक के लिए सुरक्षित विकल्प भी। पढ़ने के बाद अगर आप इनमें से कोई pattern पहचानें, तो तुरंत बदलें।

---

Pattern 1: “सब कुछ पढ़ो और पूरा project समझो”

यह खतरनाक क्यों है

❌ "इस पूरे repository को पढ़ो और समझो, फिर implement करो"

सैकड़ों files वाले repository पर यह चलाने से context explosion होता है। दसियों हजार tokens खप जाते हैं और Prompt is too long error से processing रुक जाती है। बीच में रुकने पर अधूरी समझ से implementation होती है।

इसके अलावा, अगर .env या secret keys वाली files हैं, तो वे भी context में load हो जाती हैं।

सुरक्षित विकल्प

✅ "src/api/ directory की structure देखो और केवल auth-संबंधित files पढ़ो"
✅ "पहले केवल package.json और README पढ़ो, project का overview समझो"
✅ "पढ़ने से पहले Grep से authentication-संबंधित files खोजो"

मुख्य बात: पढ़ने की range स्पष्ट रूप से सीमित करें। बिना specification के Claude Code व्यापक रूप से पढ़ने की कोशिश करता है।

---

Pattern 2: “Error आने पर automatically retry करो”

यह खतरनाक क्यों है

❌ "External API call में error आए तो automatically retry करते रहो जब तक सफल न हो"

अगर external service down है, तो infinite loop में API को hit करता रहेगा। एक घंटे में दसियों हजार calls के real incidents हैं, जहाँ bills हजारों रुपये तक पहुँच गए। रात के batch jobs में सुबह तक बिना notice के चलते रहना आम है।

सुरक्षित विकल्प

✅ "Error आने पर अधिकतम 3 बार retry करो।
   पहले retry से पहले 1 सेकंड, दूसरे से पहले 4 सेकंड, तीसरे से पहले 16 सेकंड प्रतीक्षा।
   तीनों fail होने पर error log करके processing बंद करो"

✅ "Retry के लिए यह code use करो:
   withRetry(fn, { maxAttempts: 3, baseDelayMs: 1000 })"

---

Pattern 3: “Production DB से सीधे connect होकर देखो”

यह खतरनाक क्यों है

❌ "DATABASE_URL पर production DB से connect होकर users की संख्या देखो, फिर fix करो"

“सिर्फ देखना” की नीयत से शुरू होने पर भी बाद की fix queries production DB पर execute होने का खतरा रहता है। SELECT के बाद गलती से DELETE या UPDATE आ जाए तो production data खत्म। Production से connect होने पर intended scope से परे operations आसानी से trigger होते हैं।

सुरक्षित विकल्प

✅ "Dev DB (DATABASE_URL_DEV) से connect होकर users की संख्या देखो।
   Production से connect मत करो"

✅ "Query बनाओ लेकिन execute मत करो।
   मैं खुद review करके execute करूँगा"

✅ CLAUDE.md में लिखें:
"Production DATABASE_URL पर queries execute करना prohibited है।
 पहले staging पर verify करो, user approval के बाद ही execute करो"

---

Pattern 4: Prompt में API keys सीधे paste करना

यह खतरनाक क्यों है

❌ "QIITA_TOKEN=abc123def456 use करके Qiita पर post करो"
❌ "sk-ant-api03-xxxxx use करके Anthropic API call करो"

Prompt में लिखी सामग्री conversation history के रूप में save होती है। Sub-agents को delegate करते समय वैसे ही pass होती है। Local .claude/ directory के logs में रहती है और backup tools या code sharing से अनजाने में बाहर जा सकती है।

सुरक्षित विकल्प

✅ ".env की QIITA_TOKEN use करके scripts/qiita-publish.mjs run करो"
   ← Token की value केवल .env में है; prompt में केवल variable का नाम लिखो

✅ Script में environment variables से पढ़ें:
   const token = process.env.QIITA_TOKEN;
   if (!token) throw new Error("QIITA_TOKEN set नहीं है");

---

Pattern 5: “Conflict resolve करके production पर push करो”

यह खतरनाक क्यों है

❌ "main branch के साथ conflict है। Resolve करके production पर push करो"

“Conflict resolve” के लिए git push --force का चुनाव हो सकता है। इससे team members के commits delete होने का खतरा है। साथ ही “production पर push” का मतलब CI/CD bypass करके direct push हो सकता है।

सुरक्षित विकल्प

✅ "main के साथ conflict देखो और merge strategy सुझाओ।
   Actually merge और push करने से पहले मेरी approval लो"

✅ CLAUDE.md में लिखें:
"git push --force prohibited है।
 Force जरूरी हो तो --force-with-lease use करो और user से confirm करो"

// .claude/settings.json
{
  "permissions": {
    "deny": [
      "Bash(git push --force *main*)",
      "Bash(git push --force *master*)"
    ]
  }
}

---

Pattern 6: “सभी पुरानी files delete करके clean करो”

यह खतरनाक क्यों है

❌ "dist/, .cache/ और सभी पुरानी log files delete करके clean करो"

“पुराना” की definition अस्पष्ट होने से जरूरी files भी delete हो सकती हैं। विशेष रूप से .cache/ में OS या tool-specific महत्वपूर्ण data हो सकता है। एक साथ कई directories specify करने पर rm -rf dist .cache logs/ बन जाता है जो अनचाहे paths तक फैल सकता है।

सुरक्षित विकल्प

✅ "केवल site/dist/ directory की contents delete करो।
   Directory खुद रहने दो। दूसरी directories मत छुओ"

✅ "Delete करने से पहले delete होने वाली files की list दिखाओ ताकि मैं confirm कर सकूँ।
   Approval के बाद delete करो"

---

Pattern 7: “सब approvals automatically OK करके एक साथ execute करो”

यह खतरनाक क्यों है

❌ "बीच के सभी confirmations skip करके एकदम आखिर तक execute करो"
❌ "--dangerously-skip-permissions option लगाकर run करो"

Approval flow एक safety mechanism है। Skip करने पर Claude Code जो “सबसे efficient” समझे उससे proceed करता है। वह rm -rf, force push या production DB पर writes हो सकता है—बिना confirmation के।

सुरक्षित विकल्प

✅ "पहले इस task के steps bullet points में लिखो।
   Approval के बाद एक-एक step execute करो, हर step पर result confirm करो"

✅ Automation के लिए केवल trusted operations allow करें:
   "allow": ["Read(**)", "Glob(**)", "Bash(npm run test)"]

---

Pattern 8: “Migrations update करके DB clean करो”

यह खतरनाक क्यों है

❌ "Migration files बिखरी हुई हैं। Clean करके latest state में लाओ"

“Clean करना” की interpretation पुरानी migration files delete करना हो सकती है। Migration history चली जाए तो नए environments setup करना या rollback करना असंभव हो जाता है। migrate reset जैसा command execute हो तो production data खत्म होने का खतरा है।

सुरक्षित विकल्प

✅ "Migration files की list दिखाओ और duplicates या problems सिर्फ बताओ।
   कोई बदलाव मत करो"

✅ "Pending migrations देखो और जो SQL execute होगी वह दिखाओ।
   Approval के बाद execute करो"

✅ CLAUDE.md में लिखें:
"Migration files delete मत करो।
 ALTER/DROP वाली migrations execute करने से पहले हमेशा user confirmation लो"

---

Pattern 9: “सभी packages latest version पर update करो”

यह खतरनाक क्यों है

❌ "npm packages पुराने हैं। सब कुछ latest version पर update करो"

npm update या npm install package@latest major versions bump कर सकता है। Breaking changes होने पर local build pass हो सकता है लेकिन production deploy के बाद service down हो सकती है। Dependencies का cascading breakage भी आम है।

सुरक्षित विकल्प

✅ "npm outdated run करो और update हो सकने वाले packages की list दिखाओ।
   Major version जो bump होते हैं उन्हें अलग से review करूँगा"

✅ "केवल security vulnerabilities वाले packages update करो (npm audit से detected)"

✅ "केवल react और next.js को latest minor version पर update करो।
   Major version मत बढ़ाओ"

---

Pattern 10: “पहले deploy करो, tests बाद में होंगे”

यह खतरनाक क्यों है

❌ "Tests बाद में लिखूँगा, अभी पहले deploy करो"
❌ "CI slow है, --no-verify से skip करके push करो"

Tests और CI “slow” नहीं हैं—“protect” करते हैं। Skip करने के बाद production में पहली बार bugs पकड़ना सबसे बुरा pattern है। --no-verify git hooks सहित सब disable कर देता है, इसलिए secret scanning और lint भी skip हो जाते हैं।

सुरक्षित विकल्प

✅ "पहले tests लिखो, pass होने के बाद deploy करो।
   Coverage कम भी हो तो main paths भी OK हैं"

✅ "CI slow क्यों है यह investigate करो और caching use करके speed बढ़ाओ।
   Skip मत करो"

✅ CLAUDE.md में लिखें:
"--no-verify prohibited है।
 CI skip करने का कोई भी तरीका इस्तेमाल मत करो"

---

सारांश: Safe Prompts लिखने के 3 Principles

Principle 1: Scope स्पष्ट रूप से specify करो “सब”, “सभी”, “पूरा” खतरनाक शब्द हैं। क्या पढ़ना है, क्या बदलना है, क्या delete करना है—सब स्पष्ट रूप से बताओ।

Principle 2: Confirmation steps रखो “Execute करो” से पहले “confirm करो”, “suggest करो”, “list दिखाओ” जोड़ो। खासकर production को affect करने वाले operations में।

Principle 3: Secrets कभी prompt में मत लिखो API keys, passwords, connection strings .env में रखो। Prompt में केवल variable names लिखो।

खतरनाक phrase	सुरक्षित विकल्प
”सब पढ़ो"	"केवल [X] directory पढ़ो"
"Automatically retry करो"	"अधिकतम 3 बार retry करो, फिर रुको"
"Production DB से connect करो"	"Dev DB पर verify करो, production मैं run करूँगा"
"सब delete करके clean करो"	"केवल [X] delete करो, पहले list दिखाओ"
"एक साथ सब execute करो"	"पहले steps confirm कराओ, फिर proceed करो”

Claude Code केवल instructions follow करता है—उसकी कोई बुरी नीयत नहीं है। खतरा उस इंसान में है जो अस्पष्ट निर्देश देता है। Specific और clearly scoped instructions लिखने की आदत बनाना incidents रोकने का सबसे तेज़ रास्ता है।

संबंधित लेख

• Claude Code के साथ हुए 7 Real Production Incidents और पूरी Recovery Procedures
• Claude Code Security Best Practices की Complete Guide
• Claude Code Permissions की Complete Guide

References

• Claude Code Official Security Guide
• OWASP LLM Application Security