एजेंट सिस्टम प्रॉम्प्ट्स लिखने की संपूर्ण गाइड — क्लॉड कोड की रिवर्स-इंजीनियरिंग से सीख

मैंने Claude Code का system prompt decompile किया, DeepAgents का source code पढ़ा, और scratch से अपना खुद का AI agent बनाया। ज़्यादातर prompt guides सिर्फ हवा-हवाई होती हैं।

Title: AI में अभी एक बहुत बड़ा भ्रम चल रहा है (सिस्टम प्रॉम्प्ट्स का सच)

Content: AI की दुनिया में अभी एक बहुत बड़ा भ्रम (mass delusion) चल रहा है।

हर ट्यूटोरियल आपको बताता है कि सिस्टम प्रॉम्प्ट ऐसे लिखें जैसे आप कोई जादू का मंत्र (spell) पढ़ रहे हों — बस सही मंत्र खोज लें और मॉडल आपकी बात मान लेगा। "You are an EXTREMELY TALENTED senior engineer with 20 years of experience..." कुछ सुना-सुना सा लग रहा है?

मैंने पिछले कुछ महीने VibeCom बनाने में बिताए हैं, जो एक AI स्टार्टअप एडवाइजर है। यह डीप मार्केट रिसर्च करता है और VC-ग्रेड की एनालिसिस जनरेट करता है। इस सफर के दौरान, मैंने क्लॉड कोड (Claude Code) के सिस्टम प्रॉम्प्ट को रिवर्स-इंजीनियर किया, DeepAgents के मिडलवेयर सोर्स कोड को पढ़ा, और इतने API क्रेडिट्स जलाए जितने मैं बताना भी नहीं चाहता। सबसे बड़ी सीख क्या मिली? सिस्टम प्रॉम्प्ट्स के बारे में लोग जिन चीज़ों को ज़रूरी मानते हैं, उनमें से ज़्यादातर मायने ही नहीं रखतीं। और जो चीज़ें असल में मायने रखती हैं, उनके बारे में कोई बात नहीं करता।

यह पोस्ट एक पूरा प्लेबुक है — कोई 5 मिनट का ओवरव्यू नहीं, बल्कि वह सब कुछ जो काश मुझे शुरुआत करने से पहले किसी ने बताया होता। अपनी कॉफी लेकर बैठ जाइए।

1. डिज़ाइन फिलॉसफी: मॉडल पर भरोसा करें

"एक एजेंट एक मॉडल है। कोई फ्रेमवर्क नहीं। कोई प्रॉम्प्ट चेन नहीं।" — shareAI-lab/learn-claude-code

इस एक विचार ने मेरे लिए सब कुछ बदल दिया। LLM पहले से ही जानता है कि कैसे तर्क (reason) करना है, प्लान करना है और एग्जीक्यूट करना है। आपका सिस्टम प्रॉम्प्ट उसे सोचना नहीं सिखा रहा है — वह बस उसके काम करने के लिए एक एनवायरनमेंट (environment) तैयार कर रहा है।

इसे एक सीनियर इंजीनियर को काम पर रखने जैसा समझें। आप उन्हें हर काम के लिए 20-स्टेप की चेकलिस्ट नहीं देते। आप उन्हें बताते हैं: हम कौन हैं, हमारी सीमाएँ क्या हैं, और एक अच्छा काम कैसा दिखता है। फिर आप उनके रास्ते से हट जाते हैं।

आपके सिस्टम प्रॉम्प्ट के ठीक चार काम होते हैं:

उसे बताएं कि वह कौन है — रोल और पहचान (identity)
उसे बताएं कि दीवारें कहाँ हैं — सुरक्षा सीमाएँ (safety constraints)
उसे बताएं कि अच्छा काम कैसा दिखता है — क्वालिटी स्टैंडर्ड्स
उसे टूल्स दें — क्षमताएँ और ज्ञान (capabilities and knowledge)

बस इतना ही। बाकी सब शोर (noise) है।

हार्नेस (Harness) माइंडसेट

Harness = Tools + Knowledge + Observation + Action Interfaces + Permissions

आपका सिस्टम प्रॉम्प्ट इस हार्नेस का ऑपरेटिंग मैनुअल है। आप कोई कठोर पाइपलाइन डिज़ाइन नहीं कर रहे हैं — आप एक ऐसा एनवायरनमेंट डिज़ाइन कर रहे हैं जहाँ मॉडल ऑटोनोमस (autonomous) तरीके से अपना बेहतरीन काम कर सके।

अपने सिस्टम प्रॉम्प्ट को फ्लोचार्ट की तरह मत लिखिए। मॉडल खुद तय करेगा कि किस क्रम में काम करना है।

2. प्रॉम्प्ट स्ट्रक्चर और सेक्शन का क्रम (Order)

अनुशंसित लेआउट (Claude Code v2.0.14 से रिवर्स-इंजीनियर किया गया)

┌─────────────────────────────────────────────┐
│ 1. Identity                                  │  ← Read first, anchors behavior
│ 2. Security & Safety                         │  ← IMPORTANT markers, non-negotiable
│ 3. Tone & Style                              │  ← Controls output format
│ 4. Core Workflow                             │  ← How to do the work
│ 5. Tool Usage Policy                         │  ← Tool selection priorities
│ 6. Domain Knowledge                          │  ← On-demand, not pre-loaded
│ 7. Environment Info                          │  ← Runtime context, dynamically injected
│ 8. Reminders                                 │  ← Re-state critical rules
├─────────────────────────────────────────────┤
│ [Tool Definitions — system-injected]         │  ← Not editable, usually very long
├─────────────────────────────────────────────┤
│ [User Message]                               │
└─────────────────────────────────────────────┘

यह क्रम (Order) क्यों मायने रखता है

LLMs का अटेंशन कर्व U-शेप का होता है — वे आपके प्रॉम्प्ट की शुरुआत और अंत पर सबसे ज़्यादा ध्यान देते हैं, और बीच के हिस्से में उनका ध्यान भटक जाता है। इसे "Lost in the Middle" इफ़ेक्ट कहते हैं, और यह अच्छी तरह से डॉक्युमेंटेड है।

Identity + Safety सबसे ऊपर: मॉडल सबसे पहले अपना रोल और सीमाएँ तय करता है (primacy effect)
Core Workflow बीच के ऊपरी हिस्से में: आपका सबसे ज़रूरी सेक्शन — एजेंट अपना काम कैसे करता है
Tool Definitions आपके प्रॉम्प्ट के बाद सिस्टम द्वारा इंजेक्ट किए जाते हैं: क्लॉड कोड के टूल डेफिनिशन्स लगभग 11,438 टोकन्स खा जाते हैं। इसका मतलब है कि आपका कस्टम कंटेंट असल में शुरुआत के काफी करीब होता है — जो नियमों के पालन (adherence) में मदद करता है
Reminders सबसे नीचे: ज़रूरी नियमों को पक्का करने के लिए रीसेंसी बायस (recency bias) का फायदा उठाएं

3. हर सेक्शन को कैसे लिखें

3.1 Identity — यह एजेंट कौन है?

लक्ष्य: 1-3 वाक्यों में मॉडल का रोल तय करें।

You are Claude Code, Anthropic's official CLI for Claude.
You are an interactive agent that helps users with software engineering tasks.

गाइडलाइन्स:

इसे संक्षिप्त रखें — अधिकतम 1-3 वाक्य
रोल का नाम स्पष्ट रूप से दें (इससे मॉडल को कॉन्टेक्स्ट समझने में मदद मिलती है)
मुख्य ज़िम्मेदारी बताएं ("helps with X"), न कि कोई गोलमोल बात जैसे "you're a helpful assistant"
अगर लागू हो तो SDK/प्लेटफॉर्म का ज़िक्र करें ("built on Anthropic's Claude Agent SDK")

एंटी-पैटर्न्स (Anti-patterns):

"You are a helpful, harmless, and honest AI assistant" — बहुत ही जेनेरिक, कोई स्पष्ट रोल नहीं
बैकस्टोरी और कहानियों का पूरा पैराग्राफ — टोकन्स की बर्बादी, मॉडल को कैरेक्टर डेवलपमेंट की ज़रूरत नहीं है

3.2 Security & Safety — सख्त सीमाएँ (The Hard Boundaries)

लक्ष्य: न टूटने वाले व्यावहारिक प्रतिबंध (behavioral constraints) सेट करें।

IMPORTANT: Assist with defensive security tasks only.
Refuse to create, modify, or improve code that may be used maliciously.
IMPORTANT: You must NEVER generate or guess URLs for the user.

गाइडलाइन्स:

IMPORTANT: प्रीफिक्स का इस्तेमाल करें — क्लॉड की इंस्ट्रक्शन हायरार्की ट्रेनिंग इसे अतिरिक्त महत्व देती है
स्पष्ट और सख्त भाषा का इस्तेमाल करें: NEVER, MUST NOT, Refuse to
क्या अनुमति है और क्या मना है, दोनों बताएं (दोनों तरफ की सीमाएँ ज़्यादा स्पष्ट होती हैं)
इसे बिल्कुल ऊपर रखें, बीच में कहीं न दबाएं
ज़रूरी सुरक्षा नियमों को अंत में दोहराएं — क्लॉड कोड बिल्कुल यही करता है

दोहराना क्यों ज़रूरी है? प्राइमेसी इफ़ेक्ट (शुरुआत) + रीसेंसी इफ़ेक्ट (अंत) = डबल रीइन्फोर्समेंट। क्लॉड कोड का सिक्योरिटी डिक्लेरेशन प्रॉम्प्ट की शुरुआत और अंत दोनों जगह होता है। इसलिए नहीं कि इंजीनियर भुलक्कड़ थे — बल्कि इसलिए क्योंकि वे U-शेप्ड अटेंशन कर्व को समझते हैं।

3.3 Tone & Style — आउटपुट को कंट्रोल करना

लक्ष्य: आउटपुट के फॉर्मेट और टोन को कंट्रोल करें।

## Tone and style

- Your responses should be short and concise.
- Only use emojis if the user explicitly requests it.
- Use Github-flavored markdown for formatting.
- NEVER create files unless absolutely necessary.

गाइडलाइन्स:

विशिष्ट व्यवहारों की सूची बनाएं, न कि गोलमोल बातें जैसे "be professional"
हर नियम को true/false के रूप में टेस्ट किया जा सकने वाला होना चाहिए ("short and concise" बनाम "try to be brief")
आउटपुट फॉर्मेट की ज़रूरतें शामिल करें (markdown? JSON? plain text?)
क्या 'नहीं' करना है, यह भी शामिल करें — कई स्टाइल से जुड़ी समस्याएँ किसी व्यवहार को रोकने के बारे में होती हैं

क्लॉड कोड का मास्टरस्ट्रोक — प्रोफेशनल ऑब्जेक्टिविटी (Professional Objectivity):

Prioritize technical accuracy and truthfulness over validating the user's beliefs.
Focus on facts and problem-solving, providing direct, objective technical info
without any unnecessary superlatives, praise, or emotional validation.

यह पैराग्राफ बहुत ज़रूरी है: यह मॉडल की चापलूसी (sycophancy) करने की आदत को रोकता है। अगर आपके एजेंट को निष्पक्ष फैसले (कोड रिव्यू, आइडिया इवैल्यूएशन, आर्किटेक्चर डिसीजन) देने हैं, तो आपको बिल्कुल ऐसे ही एक क्लॉज़ की ज़रूरत है।

3.4 Core Workflow — सबसे ज़रूरी सेक्शन

लक्ष्य: मॉडल को सिखाएं कि काम कैसे करना है — कार्यप्रणाली (methodology), न कि कठोर प्रक्रियाएँ।

यह अच्छी तरह से लिखने के लिए सबसे मुश्किल सेक्शन है, और जब आप इसे सही कर लेते हैं, तो इसका असर भी सबसे ज़्यादा होता है।

मूल सिद्धांत: प्रक्रिया (procedures) नहीं, सिद्धांत (principles) दें।

LLM को बताएं कि एक अच्छा आउटपुट कैसा दिखता है और वह अच्छा क्यों है — उसे खुद यह तय करने दें कि वहाँ तक कैसे पहुँचना है। सटीक फील्ड काउंट्स, स्टेप सीक्वेंस, या फॉर्मेट तय करने से बचें, जब तक कि आउटपुट को आगे किसी मशीन द्वारा कंज्यूम न किया जाना हो।

क्लॉड कोड का तरीका:

## Doing tasks

The user will primarily request software engineering tasks.
For these tasks the following steps are recommended:

- Use the TodoWrite tool to plan the task if required

ध्यान दें "recommended" (अनुशंसित) शब्द पर — यह नहीं कहा गया कि "you must follow these exact steps." यह एक शब्द का चुनाव मॉडल को खुद को ढालने (adapt) की आज़ादी देता है।

एक अच्छी वर्कफ़्लो परिभाषा:

1. Understand first — read existing code before modifying it
2. Plan first — break complex tasks into steps before executing
3. Minimal changes — only change what's necessary, don't "refactor while you're in there"
4. Verify — confirm your changes work (run tests, lint, etc.)

हर नियम में एक छिपा हुआ "क्यों" है — मॉडल इसके पीछे के इरादे को समझ सकता है और नई स्थितियों में इसे लागू कर सकता है।

एंटी-पैटर्न्स:

एक कठोर 20-स्टेप की प्रक्रिया — मॉडल इसे मशीन की तरह एग्जीक्यूट करेगा और अनपेक्षित इनपुट मिलने पर फ्रीज़ हो जाएगा
"First do A, then do B, then do C" — यह एक प्रॉम्प्ट चेन है, एजेंट प्रॉम्प्ट नहीं
जिन चीज़ों में LLM पहले से ही अच्छा है, उनके लिए बहुत ज़्यादा गाइड करना — टोकन्स की बर्बादी

VibeCom बनाते समय मैंने यह बात धक्के खाकर सीखी। शुरुआती वर्जन्स में 10-स्टेप का रिसर्च वर्कफ़्लो था। मॉडल पूरी ईमानदारी से सभी 10 स्टेप्स को एग्जीक्यूट करता था, भले ही स्टेप 3 में ही यूज़र के सवाल का जवाब मिल गया हो। जब मैंने इसे सिद्धांतों ("research until you have sufficient evidence, then synthesize") में बदला, तो क्वालिटी बढ़ गई और टोकन कॉस्ट कम हो गई।

अपवाद (The exception): जब आउटपुट को आगे किसी मशीन द्वारा कंज्यूम किया जाना हो (इंटर-एजेंट कम्युनिकेशन, API रिस्पॉन्स फॉर्मेट), तो आपको सख्त फॉर्मेट परिभाषित करने चाहिए। सिद्धांत व्यवहार के लिए होते हैं; स्कीमा (schemas) इंटरफेस के लिए होते हैं।

3.5 Tool Usage Policy — कन्फ्यूज़न दूर करना

लक्ष्य: जब कई टूल्स एक ही काम कर सकते हों, तो मॉडल को बताएं कि किसे प्राथमिकता देनी है।

## Tool usage policy

- Use specialized tools instead of bash commands:
  - Read for reading files instead of cat/head/tail
  - Edit for editing instead of sed/awk
  - Grep for searching instead of grep/rg
- You can call multiple tools in a single response. If independent, call in parallel.
- Use the Task tool for file search to reduce context usage.

गाइडलाइन्स:

प्राथमिकता बताने के लिए "instead of" का इस्तेमाल करें (A instead of B)
समझाएं कि कुछ टूल्स को प्राथमिकता क्यों देनी है ("provides a better user experience", "reduces context usage")
पैरेललिज़्म (parallelism) स्ट्रेटेजी तय करें (independent → parallel, dependent → sequential)
टूल के इस्तेमाल के लिए सुरक्षा सीमाएँ (security constraints) बताएं (path validation, permission checks)

टूल्स और प्रॉम्प्ट्स के बीच का अहम रिश्ता:

टूल डेफिनिशन्स आमतौर पर सिस्टम द्वारा इंजेक्ट किए जाते हैं और आप उन्हें सीधे एडिट नहीं कर सकते। क्लॉड कोड के टूल डेफिनिशन्स लगभग 11,438 टोकन्स के होते हैं। इसका मतलब है:

जो जानकारी पहले से टूल डेफिनिशन्स में है, उसे न दोहराएं
सिस्टम प्रॉम्प्ट का इस्तेमाल रणनीतिक (strategic) मार्गदर्शन के लिए करें: किस टूल का इस्तेमाल कब करना है, एक को दूसरे पर प्राथमिकता क्यों देनी है, प्रायोरिटी ऑर्डर क्या है
टूल डेफिनेशन की क्वालिटी का सीधा असर एजेंट की प्रभावशीलता पर पड़ता है — अगर आप अपना खुद का एजेंट बना रहे हैं, तो बेहतरीन टूल डिस्क्रिप्शन लिखने में समय लगाएँ

3.6 Domain Knowledge — ऑन-डिमांड लोड करें, पहले से नहीं

लक्ष्य: मॉडल को वह विशेष ज्ञान (specialized knowledge) प्रदान करें जो उसके ट्रेनिंग डेटा में न हो।

मूल सिद्धांत: प्रोग्रेसिव डिस्क्लोज़र (progressive disclosure), नॉलेज डंप (knowledge dumps) नहीं।

❌ Paste all 200 API endpoints into the system prompt → token explosion
✅ Give the model a tool to look things up → "Load knowledge when you need it"

यह रणनीति क्लॉड कोड के Skills सिस्टम और DeepAgents के Progressive Disclosure मिडलवेयर दोनों द्वारा इस्तेमाल की जाती है। दोनों सब कुछ पहले से लोड करने के बजाय टूल कॉल्स के ज़रिए ऑन-डिमांड नॉलेज लोड करते हैं।

लागू करने के तरीके:

सिस्टम प्रॉम्प्ट में पॉइंटर्स दें: "Use the get_api_docs tool to retrieve documentation when needed"
प्रोजेक्ट कॉन्टेक्स्ट के लिए CLAUDE.md / AGENTS.md का इस्तेमाल करें — जो रनटाइम पर लोड होते हैं, हार्डकोड नहीं होते
कैपेबिलिटी डिस्कवरी के लिए Skills / SKILL.md का इस्तेमाल करें — मॉडल को उपलब्ध स्किल्स का एक मेनू दिखता है, और ज़रूरत पड़ने पर वह पूरी जानकारी फेच कर लेता है

3.7 Environment Info — रनटाइम कॉन्टेक्स्ट

लक्ष्य: मॉडल को उसके एग्जीक्यूशन एनवायरनमेंट की जानकारी दें।

<env>
Working directory: /Users/fengliu/Desktop/tfm/vibecom
Is directory a git repo: true
Platform: darwin
Today's date: 2026-03-21
</env>
You are powered by the model named Claude Opus 4.6.

गाइडलाइन्स:

इसे डायनामिक रूप से जनरेट करें, कभी हार्डकोड न करें
इसमें शामिल करें: वर्किंग डायरेक्टरी, प्लेटफॉर्म, तारीख, मॉडल का नाम, गिट स्टेटस
आसानी से पार्स करने के लिए स्ट्रक्चर्ड फॉर्मेट (XML टैग्स या कोड ब्लॉक्स) का इस्तेमाल करें
तारीख मायने रखती है — जानकारी कितनी ताज़ा है, यह तय करने के लिए मॉडल को "आज" का पता होना चाहिए

3.8 Reminders — आखिरी रिमाइंडर

लक्ष्य: प्रॉम्प्ट के अंत में सबसे ज़रूरी नियमों को फिर से बताएं।

क्लॉड कोड अपने सुरक्षा प्रतिबंधों और TodoWrite की ज़रूरत को सबसे नीचे दोहराता है:

IMPORTANT: Assist with defensive security tasks only. [repeated]
IMPORTANT: Always use the TodoWrite tool to plan and track tasks. [repeated]

गाइडलाइन्स:

केवल 2-3 सबसे ज़रूरी नियमों को ही दोहराएं — सब कुछ डुप्लीकेट न करें
रीसेंसी बायस (recency bias) का फायदा उठाएं — मॉडल हाल ही में पढ़ी गई चीज़ों को बेहतर याद रखता है
सबसे अच्छे विकल्प: सुरक्षा सीमाएँ, सबसे ज़्यादा तोड़े जाने वाले नियम, कोर वर्कफ़्लो रिमाइंडर्स

4. टोकन बजट और कॉन्टेक्स्ट मैनेजमेंट

बजट एलोकेशन रेफरेंस

सेक्शन (Section)	अनुशंसित टोकन्स (Recommended Tokens)	नोट्स (Notes)
Identity + Safety	200-500	संक्षिप्त लेकिन गैर-समझौतावादी
Tone & Style	300-800	नियम स्पष्ट होने चाहिए, लेकिन लंबी बातें नहीं
Core Workflow	500-2,000	सबसे ज़रूरी सेक्शन, इसमें इन्वेस्ट करना बनता है
Tool Usage Policy	300-1,000	टूल्स की संख्या पर निर्भर करता है
Domain Knowledge	0-1,000	ऑन-डिमांड लोडिंग बेहतर है
Environment Info	100-300	डायनामिक रूप से जनरेट किया गया
Reminders	100-300	केवल ज़रूरी बातें दोहराएं
आपका कुल (Your total)	1,500-6,000
Tool Definitions (system)	5,000-15,000	आपके कंट्रोल में नहीं है

कॉन्टेक्स्ट डिग्रेडेशन कर्व (Context Degradation Curve)

कम्युनिटी टेस्टिंग (Reddit u/CodeMonke_) ने रियल-वर्ल्ड में नियमों के पालन में आने वाली गिरावट (adherence degradation) को मैप किया है:

< 80K टोकन्स: प्रॉम्प्ट का पालन स्थिर रहता है
80K - 120K टोकन्स: निर्देशों का पालन कम होने लगता है
> 120K टोकन्स: भारी गिरावट — मॉडल शुरुआती निर्देशों को "भूल" जाता है
> 180K टोकन्स: गंभीर गिरावट

आपका 200K कॉन्टेक्स्ट विंडो ≠ 200K का इफेक्टिव कॉन्टेक्स्ट। इसके हिसाब से प्लानिंग करें।

बचाव की रणनीतियाँ (Mitigation strategies):

अपने सिस्टम प्रॉम्प्ट को छोटा रखें (आपके हिस्से के लिए < 6,000 टोकन्स)
कन्वर्सेशन हिस्ट्री को कंप्रेस करने के लिए समराइज़ेशन (summarization) का इस्तेमाल करें (DeepAgents ~80K कैरेक्टर्स पर ट्रिगर होता है)
ज़रूरी नियमों को प्रॉम्प्ट के दोनों सिरों पर रखें (U-शेप्ड अटेंशन)
बातचीत के बीच में <system-reminder> टैग्स इंजेक्ट करें (इसके बारे में सेक्शन 8 में और जानकारी है)

5. लिखने के सिद्धांत (Writing Principles)

5.1 प्रक्रिया (Procedures) नहीं, सिद्धांत (Principles) दें

❌ "Step 1: Read the file. Step 2: Find the bug. Step 3: Fix it. Step 4: Run tests."
✅ "Always understand existing code before modifying it. Verify your changes work."

सिद्धांत (Principles) हर स्थिति में काम आते हैं। प्रक्रियाओं (Procedures) को केवल मशीन की तरह फॉलो किया जा सकता है। जब मॉडल के सामने कोई ऐसी स्थिति आती है जिसके बारे में आपने नहीं सोचा था, तो सिद्धांत उसे सही फैसला लेने में मदद करते हैं। प्रक्रियाएँ नहीं।

अपवाद: जब आउटपुट को मशीनों द्वारा कंज्यूम किया जाना हो (इंटर-एजेंट कम्युनिकेशन, API फॉर्मेट), तो सख्त स्कीमा (schemas) परिभाषित करें।

5.2 सख्त सीमाओं के लिए स्पष्ट भाषा का इस्तेमाल करें

सख्ती (Strength)	भाषा (Language)	किसके लिए इस्तेमाल करें (Use For)
पूर्ण प्रतिबंध	`NEVER`, `MUST NOT`	सुरक्षा, न बदले जा सकने वाले काम
सख्त ज़रूरत	`ALWAYS`, `MUST`	कोर वर्कफ़्लो नियम
अनुशंसा (Recommendation)	`recommended`, `prefer`	बेस्ट प्रैक्टिसेस (अपवादों के साथ)
सुझाव (Suggestion)	`consider`, `you may`	वैकल्पिक ऑप्टिमाइज़ेशन

क्लॉड कोड के उदाहरण:

NEVER update the git config — पूर्ण प्रतिबंध
ALWAYS prefer editing an existing file — सख्त, लेकिन अपवाद मौजूद हैं
The following steps are recommended — सुझाया गया वर्कफ़्लो

5.3 स्पष्टीकरण (Explanations) के बजाय उदाहरण (Examples) दें

## Code References

When referencing specific functions or pieces of code include
the pattern `file_path:line_number`.

<example>
user: Where are errors from the client handled?
assistant: Clients are marked as failed in the `connectToServer`
function in src/services/process.ts:712.
</example>

एक उदाहरण 100 शब्दों के स्पष्टीकरण से ज़्यादा सिखाता है:

मॉडल्स अमूर्त (abstract) विवरणों की तुलना में उदाहरणों से पैटर्न ज़्यादा भरोसेमंद तरीके से सीखते हैं
नियमों से अलग करने के लिए <example> टैग्स का इस्तेमाल करें
सकारात्मक ("यह करें") और नकारात्मक ("यह न करें") दोनों तरह के उदाहरण दें
असली और विशिष्ट उदाहरणों का इस्तेमाल करें — "foo/bar" जैसे प्लेसहोल्डर्स का नहीं

5.4 दोनों तरफ की सीमाएँ (Bidirectional Constraints)

✅ "Use dedicated tools: Read for reading files, Edit for editing files."
✅ "Do NOT use bash for file operations (cat, head, tail, sed, awk)."

सिर्फ "यह करें" कहने से → मॉडल को यह नहीं पता चलता कि उसे कब क्या 'नहीं' करना है। सिर्फ "यह न करें" कहने से → मॉडल को उसका विकल्प नहीं पता चलता। दोनों तरफ की सीमाएँ (Bidirectional) → स्पष्ट और बिना किसी कन्फ्यूज़न के।

5.5 सिर्फ 'क्या' नहीं, 'क्यों' भी समझाएं

❌ "Don't use git commit --amend."
✅ "Avoid git commit --amend. ONLY use --amend when either
   (1) user explicitly requested amend OR
   (2) adding edits from pre-commit hook.
   Reason: amending may overwrite others' commits."

क्यों समझाने से मॉडल एज केसेस (edge cases) में सही फैसले ले पाता है। क्लॉड कोड का गिट सेफ्टी प्रोटोकॉल इसका एक बेहतरीन उदाहरण है — हर नियम के पीछे उसका कारण छिपा होता है।

5.6 पैराग्राफ से बेहतर है स्ट्रक्चर (Structure Over Prose)

मार्कडाउन हेडर्स (##, ###) — मॉडल्स हायरार्की (hierarchy) को पहचानते हैं
बुलेट लिस्ट्स पैराग्राफ से बेहतर हैं — हर नियम को अलग से टेस्ट किया जा सकता है
XML टैग्स स्पेशल कंटेंट के लिए: <example>, <env>, <system-reminder>
टेबल्स (Tables) तुलना और मैपिंग के लिए
कभी भी बिना स्ट्रक्चर वाला टेक्स्ट न डालें — स्ट्रक्चर्ड प्रॉम्प्ट्स हमेशा नियमों के पालन में सामान्य भाषा (natural language) वाले प्रॉम्प्ट्स से बेहतर परफॉर्म करते हैं

6. आपके टोकन्स बर्बाद करने वाले एंटी-पैटर्न्स

एजेंट्स के भेष में प्रॉम्प्ट चेन्स (Prompt Chains)

"First call tool A to get data.
Then call tool B with the result.
Then format the output as JSON.
Then save to file."

यह कोई एजेंट प्रॉम्प्ट नहीं है — यह एक पाइपलाइन स्क्रिप्ट है। मॉडल इसे मशीन की तरह एग्जीक्यूट करेगा और अपनी ऑटोनोमस प्लानिंग की क्षमता खो देगा।

समाधान: मॉडल को लक्ष्य और सीमाएँ बताएं। उसे खुद स्टेप्स तय करने दें।

चापलूसी वाली इंजीनियरिंग (Flattery Engineering)

"You are an EXTREMELY TALENTED and INCREDIBLY EXPERIENCED
senior software engineer with 20 years of experience..."

तारीफें और बढ़ा-चढ़ाकर बोले गए शब्द आउटपुट की क्वालिटी में सुधार नहीं करते। मॉडल के पास कोई ईगो नहीं है जिसे आपको बूस्ट करना पड़े। उन 15 टोकन्स को किसी असली नियम के लिए बचाकर रखें।

नॉलेज डंप्स (Knowledge Dumps)

"Here is the complete API documentation for our 200 endpoints..."

यह आपके कॉन्टेक्स्ट विंडो को खा जाता है और कॉन्टेक्स्ट रॉट (context rot) को तेज़ करता है। इसकी जगह ऑन-डिमांड लोडिंग का इस्तेमाल करें:

"Use the get_api_docs tool to retrieve API documentation when needed."

टूल डिस्क्रिप्शन्स को दोहराना

अगर टूल डेफिनेशन पहले से ही कहता है कि "Read tool reads a file from the filesystem," तो इसे अपने सिस्टम प्रॉम्प्ट में दोबारा न कहें। केवल रणनीतिक (strategic) मार्गदर्शन जोड़ें जो टूल डेफिनेशन में नहीं है — इसका इस्तेमाल कब करना है, इसे प्राथमिकता क्यों देनी है, प्रायोरिटी ऑर्डर क्या है।

फेलियर हैंडलिंग का न होना

अगर आप स्पष्ट निर्देश नहीं देंगे, तो मॉडल्स फेल हुए टूल कॉल्स को इनफिनिट लूप (infinite loop) में बार-बार ट्राई करते रहेंगे। हमेशा यह शामिल करें:

"If a tool call is denied, do not re-attempt the exact same call.
Think about why it was denied and adjust your approach."

कॉन्टेक्स्ट विंडो के खराब होने को नज़रअंदाज़ करना

200K कॉन्टेक्स्ट विंडो ≠ 200K का इफेक्टिव कॉन्टेक्स्ट। रियल-वर्ल्ड टेस्टिंग दिखाती है कि 80K के बाद गिरावट शुरू हो जाती है। आपको एक समराइज़ेशन (summarization) स्ट्रेटेजी की ज़रूरत है।

7. इंजेक्शन पॉइंट्स और प्रायोरिटी (Priority)

क्लॉड कोड के तीन कस्टमाइज़ेशन तरीके

तरीका (Method)	किसे रिप्लेस करता है (Replaces)	कहाँ रखा जाता है (Placement)	किसके लिए बेस्ट है (Best For)
Output Styles	"Tone and style" + "Doing tasks" सेक्शन्स	टूल डेफिनिशन्स से ठीक पहले	बातचीत का स्टाइल बदलने के लिए
--append-system-prompt	कुछ नहीं (जुड़ जाता है)	आउटपुट स्टाइल के बाद, टूल डेफिनिशन्स से पहले	विशिष्ट व्यवहार जोड़ने के लिए
--system-prompt	पूरा सिस्टम प्रॉम्प्ट	टूल डेफिनिशन्स + एक आइडेंटिटी लाइन रखता है	पूरा कस्टमाइज़ेशन (न्यूक्लियर ऑप्शन)

अगर आप कई तरीकों का इस्तेमाल करते हैं: Output Style → Append Prompt → Tool Definitions

इंस्ट्रक्शन हायरार्की (Instruction Hierarchy)

क्लॉड को विशेष रूप से एक इंस्ट्रक्शन हायरार्की के साथ ट्रेन किया गया है:

1. User's explicit instructions (CLAUDE.md, direct requests)  ← Highest priority
2. Custom system prompt additions                               ← High
3. Default system prompt                                        ← Medium
4. Tool definitions                                             ← Reference level

इसका मतलब है:

CLAUDE.md के नियम डिफ़ॉल्ट सिस्टम प्रॉम्प्ट के व्यवहार को ओवरराइड करते हैं
यूज़र की सीधी रिक्वेस्ट्स (direct requests) हर चीज़ को ओवरराइड करती हैं
आपका कस्टम प्रॉम्प्ट डिफ़ॉल्ट प्रॉम्प्ट को ओवरराइड करता है

डायनामिक इंजेक्शन मैकेनिज़्म

<system-reminder> — बातचीत के बीच में किसी भी मैसेज में इंजेक्ट करें ताकि मॉडल को ज़रूरी नियम याद दिलाए जा सकें
CLAUDE.md / AGENTS.md — रनटाइम पर फाइल्स से लोड होते हैं, सिस्टम प्रॉम्प्ट में जुड़ जाते हैं
Skills / SKILL.md — टूल कॉल्स के ज़रिए ऑन-डिमांड लोड होते हैं, सिस्टम प्रॉम्प्ट में कोई जगह नहीं घेरते

8. मिड-कन्वर्सेशन इंजेक्शन — एक सीक्रेट हथियार

सिस्टम प्रॉम्प्ट केवल एक बार दिखाई देता है, मैसेजेस ऐरे (messages array) की बिल्कुल शुरुआत में। लेकिन LLMs पूरे मैसेजेस ऐरे (यूज़र / असिस्टेंट / टूल मैसेजेस का क्रम) को इनपुट के रूप में स्वीकार करते हैं, और आप यूज़र मैसेजेस और टूल रिज़ल्ट्स में भी प्रॉम्प्ट्स इंजेक्ट कर सकते हैं। क्लॉड कोड प्रोडक्शन में इस तकनीक का भारी इस्तेमाल करता है।

यह क्यों ज़रूरी है

कॉन्टेक्स्ट रॉट (context rot) से लड़ना। जैसे-जैसे बातचीत लंबी होती है, सिस्टम प्रॉम्प्ट के निर्देशों का पालन करने की मॉडल की क्षमता कम होने लगती है (80K+ टोकन्स पर यह साफ़ नज़र आता है)। बातचीत के बीच में रिमाइंडर्स इंजेक्ट करना = रीसेंसी बायस के ज़रिए नियमों को ताज़ा (refresh) करना।

मेंटल मॉडल:

सिस्टम प्रॉम्प्ट = संविधान (the constitution) (एक बार बनता है, लंबे समय तक चलता है)
यूज़र मैसेज रिमाइंडर्स = मेमो (memos) (समय-समय पर भेजे जाते हैं, नियमों को याद दिलाने के लिए)

मैसेजेस ऐरे में तीन इंजेक्शन पॉइंट्स

Messages Array:
┌─────────────────────────────────────┐
│ System Prompt                       │ ← Appears once, primacy effect
│   (identity, safety, workflow...)   │
├─────────────────────────────────────┤
│ User Message 1                      │
│ Assistant Message 1                 │
│ User Message 2 + <system-reminder>  │ ← Mid-conversation injection
│ Assistant Message 2                 │
│ Tool Result + <system-reminder>     │ ← Can inject into tool results too
│ ...                                 │
│ User Message N + <system-reminder>  │ ← Latest message, strongest recency
└─────────────────────────────────────┘

लोकेशन (Location)	फायदा (Advantage)	नुकसान (Disadvantage)
System prompt	प्राइमेसी इफ़ेक्ट, सबसे पहले पढ़ा जाता है	एक बार आता है, लंबी बातचीत में "भूल" जाया जाता है
User message injection	रीसेंसी बायस, समय-समय पर रिफ्रेश	हर इंजेक्शन में टोकन्स खर्च होते हैं
Tool result injection	सबसे नैचुरल इंजेक्शन पॉइंट	केवल तभी काम करता है जब टूल्स कॉल किए जाते हैं

क्लॉड कोड असल में इसका इस्तेमाल कैसे करता है

पहली शर्त — सिस्टम प्रॉम्प्ट में टैग्स को डिक्लेयर करें:

Tool results and user messages may include <system-reminder> tags.
<system-reminder> tags contain useful information and reminders.
They are automatically added by the system, and bear no direct
relation to the specific tool results or user messages in which they appear.

यह स्टेप बहुत ज़रूरी है: यह मॉडल को बताता है कि ये टैग्स सिस्टम द्वारा इंजेक्ट किए गए हैं, न कि यूज़र ने बोले हैं।

इस्तेमाल 1: बिहेवियरल रिमाइंडर्स (नियमों को समय-समय पर रिफ्रेश करना)

<system-reminder>
The task tools haven't been used recently. If you're working on tasks
that would benefit from tracking progress, consider using TaskCreate...
</system-reminder>

क्लॉड कोड इसका इस्तेमाल मॉडल को TodoWrite के साथ प्लान करने की याद दिलाने के लिए करता है — क्योंकि मॉडल्स अक्सर प्लानिंग करना "भूल" जाते हैं और सीधे कोडिंग शुरू कर देते हैं।

इस्तेमाल 2: मोड स्विचिंग (Plan Mode)

<system-reminder>
Plan mode is active. The user indicated that they do not want you to
execute yet -- you MUST NOT make any edits, run any non-readonly tools,
or otherwise make any changes to the system.
</system-reminder>

प्लान मोड (Plan mode) सिस्टम प्रॉम्प्ट में लागू नहीं किया गया है। यह अगले यूज़र मैसेज में इंजेक्ट किया गया एक टैग है। यह आपको सिस्टम प्रॉम्प्ट को बदले बिना डायनामिक रूप से मोड टॉगल करने की सुविधा देता है। शानदार।

इस्तेमाल 3: फाइल चेंज नोटिफिकेशन्स

<system-reminder>
Note: /path/to/file.ts was modified, either by the user or by a linter.
This change was intentional, so make sure to take it into account.
</system-reminder>

जब कोई बाहरी प्रोसेस (लिंटर, फॉर्मेटर, मैनुअल एडिट) किसी फाइल को बदलता है, तो सिस्टम रिमाइंडर के ज़रिए मॉडल को नोटिफाई करता है — जिससे पुरानी फाइल के आधार पर फैसले लेने से बचा जा सके।

इस्तेमाल 4: डायनामिक कॉन्टेक्स्ट (तारीखें, प्रोजेक्ट के नियम)

<system-reminder>
Today's date is 2026-03-21.
Current branch: dev
claudeMd: [CLAUDE.md content injected here]
</system-reminder>

रनटाइम कॉन्टेक्स्ट (तारीख, गिट स्टेटस, प्रोजेक्ट के नियम) यूज़र मैसेजेस के ज़रिए इंजेक्ट किए जाते हैं, सिस्टम प्रॉम्प्ट में हार्डकोड नहीं किए जाते।

रिमाइंडर्स लिखने के लिए गाइडलाइन्स

XML टैग्स में रैप करें (<system-reminder>) — मॉडल सिस्टम इंजेक्शन और यूज़र की बातों के बीच फर्क कर सकता है
सिस्टम प्रॉम्प्ट में टैग्स को पहले से डिक्लेयर करें — वरना मॉडल रिमाइंडर का जवाब देने की कोशिश कर सकता है
हर मैसेज में इंजेक्ट न करें — हर इंजेक्शन में टोकन्स खर्च होते हैं, केवल ज़रूरत पड़ने पर ही इंजेक्ट करें
इसे छोटा रखें — रिमाइंडर कोई दूसरा सिस्टम प्रॉम्प्ट नहीं है, बस 1-2 ज़रूरी नियम हैं
सिस्टम प्रॉम्प्ट का विरोध न करें — रिमाइंडर्स सपोर्ट करते हैं और नियमों को पक्का करते हैं, वे ओवरराइड नहीं करते
डायनामिक टॉगलिंग के लिए इस्तेमाल करें — प्लान मोड, रीडओनली मोड, फीचर फ्लैग्स

सिस्टम प्रॉम्प्ट बनाम यूज़र मैसेज रिमाइंडर का इस्तेमाल कब करें

स्थिति (Scenario)	System Prompt	User Message Reminder
रोल तय करना	✅	❌
सुरक्षा सीमाएँ	✅ पहली घोषणा	✅ समय-समय पर दोहराना
वर्कफ़्लो कार्यप्रणाली	✅	❌
मोड स्विचिंग (प्लान मोड)	❌	✅
फाइल चेंज नोटिफिकेशन्स	❌	✅
तारीख / एनवायरनमेंट इन्फो	✅ शुरुआती वैल्यू	✅ अपडेटेड वैल्यू
बिहेवियरल करेक्शन	❌	✅
टूल इस्तेमाल के रिमाइंडर्स	✅ नियम की परिभाषा	✅ एग्जीक्यूशन के लिए याद दिलाना

9. प्रॉम्प्ट कैश (Prompt Cache) — रिपीट टोकन्स पर 90% बचाएं

Anthropic का प्रॉम्प्ट कैशिंग आपको अपने मैसेजेस ऐरे के स्टैटिक प्रीफिक्स (static prefix) को कैश करने की सुविधा देता है। जब बाद की रिक्वेस्ट्स उसी प्रीफिक्स को शेयर करती हैं, तो वे कैश को हिट करती हैं — जिससे पैसे बचते हैं और लेटेंसी (latency) कम होती है।

एजेंट्स के लिए, यह बहुत मायने रखता है: आप एक बातचीत के भीतर हर LLM कॉल पर सिस्टम प्रॉम्प्ट + टूल डेफिनिशन्स को बार-बार भेज रहे होते हैं।

प्रमुख आंकड़े (Key Numbers)

मेट्रिक (Metric)	वैल्यू (Value)
कैश हिट कॉस्ट	सामान्य कीमत का 10% (90% की बचत)
कैश राइट कॉस्ट	सामान्य कीमत का 125% (पहली बार लिखने पर 25% प्रीमियम)
कैश TTL	5 मिनट (अगर कोई रिक्वेस्ट न आए तो एक्सपायर हो जाता है)
न्यूनतम कैश योग्य लंबाई	1,024 टोकन्स (Claude 3.5+)
कैश ग्रैन्युलैरिटी	प्रीफिक्स मैचिंग — शुरुआत से लेकर एक तय ब्रेकपॉइंट तक
अधिकतम ब्रेकपॉइंट्स	4

यह प्रॉम्प्ट डिज़ाइन को कैसे बदलता है

मूल सिद्धांत: स्टैटिक कंटेंट पहले, डायनामिक कंटेंट बाद में।

✅ Cache-friendly layout:
  System prompt (static)      ← Cache breakpoint 1
  Tool definitions (static)   ← Cache breakpoint 2
  CLAUDE.md / project rules   ← Cache breakpoint 3 (changes occasionally)
  Conversation history         ← Breakpoint 4 for rolling window

❌ Cache-destroying layout:
  System prompt
  DYNAMIC TIMESTAMP            ← Changes every request, everything after = cache miss
  Tool definitions
  Conversation history

वह जाल जिसके बारे में कोई आपको चेतावनी नहीं देता: अगर आप अपने सिस्टम प्रॉम्प्ट के बीच में कोई डायनामिक टाइमस्टैम्प डालते हैं, तो उसके बाद की हर चीज़ कैश मिस (cache miss) बन जाती है। हर। एक। रिक्वेस्ट। गलत जगह पर एक टाइमस्टैम्प और आप हज़ारों टोकन्स की पूरी कीमत चुका रहे होते हैं।

API का इस्तेमाल

const response = await anthropic.messages.create({
  model: "claude-sonnet-4-6",
  system: [
    {
      type: "text",
      text: "You are a startup advisor...",
      cache_control: { type: "ephemeral" }  // ← marks a cache breakpoint
    }
  ],
  messages: [...]
});

मल्टी-ब्रेकपॉइंट स्ट्रेटेजी

Breakpoint 1: System prompt           ← Almost never changes
Breakpoint 2: Tool definitions         ← Almost never changes
Breakpoint 3: Project rules / CLAUDE.md ← Changes occasionally
Breakpoint 4: First N history messages  ← Rolling window cache

भले ही कन्वर्सेशन हिस्ट्री बदल जाए, पहले 3 ब्रेकपॉइंट्स फिर भी हिट होते हैं। 10-टर्न की बातचीत में इनपुट टोकन कॉस्ट पर लगभग 40-60% की बचत होती है।

डिज़ाइन के लिए सुझाव

सिस्टम प्रॉम्प्ट में कोई हाई-फ्रीक्वेंसी डायनामिक वैल्यू न रखें — तारीख ठीक है (रोज़ बदलती है), लेकिन सटीक टाइमस्टैम्प्स नहीं
डायनामिक कॉन्टेक्स्ट (गिट स्टेटस, आदि) को यूज़र मैसेज इंजेक्शन में रखें — सिस्टम प्रॉम्प्ट में नहीं, वरना आप कैश को बर्बाद कर देंगे
टूल डेफिनिशन्स को स्थिर (stable) रखें — रनटाइम पर डायनामिक रूप से टूल्स को जोड़ें/हटाएं नहीं
कन्वर्सेशन हिस्ट्री के लिए रोलिंग विंडो का इस्तेमाल करें — पहले N मैसेजेस को कैश करें, केवल सबसे नया मैसेज ही कैश मिस होगा

10. चेकलिस्ट

अपना सिस्टम प्रॉम्प्ट लिखने के बाद, इस चेकलिस्ट से उसे रिव्यू करें:

स्ट्रक्चर (Structure)

क्या Identity बिल्कुल ऊपर है?
क्या सुरक्षा सीमाओं (Safety constraints) को IMPORTANT के साथ मार्क किया गया है और अंत में दोहराया गया है?
क्या हेडर्स के साथ सेक्शन्स को स्पष्ट रूप से अलग किया गया है?
क्या उदाहरणों को <example> टैग्स में रैप किया गया है?

टोकन बजट (Token Budget)

क्या आपका हिस्सा < 6,000 टोकन्स का है?
क्या आप वह जानकारी नहीं दोहरा रहे हैं जो पहले से टूल डेफिनिशन्स में है?
क्या डोमेन नॉलेज ऑन-डिमांड लोड हो रहा है, न कि पहले से?
क्या कोई लंबी-चौड़ी कहानी या कैरेक्टर बैकस्टोरी तो नहीं है?

नियमों की क्वालिटी (Rule Quality)

क्या हर नियम को true/false के रूप में टेस्ट किया जा सकता है?
क्या सख्त सीमाओं के लिए स्पष्ट भाषा (NEVER/MUST) का इस्तेमाल किया गया है?
क्या हल्के सुझावों के लिए अनुशंसा वाली भाषा (recommended/prefer) का इस्तेमाल किया गया है?
क्या ज़रूरी नियमों में सिर्फ क्या नहीं, बल्कि क्यों भी समझाया गया है?
क्या दोनों तरफ की सीमाएँ (यह करें + यह न करें) दी गई हैं?

एजेंट का व्यवहार (Agent Behavior)

क्या सिद्धांत दिए गए हैं, न कि कठोर स्टेप-बाय-स्टेप प्रक्रियाएँ?
क्या "tool call denied" वाली स्थिति को हैंडल किया गया है?
क्या "obstacle encountered" स्ट्रेटेजी को हैंडल किया गया है (बार-बार एक ही चीज़ ट्राई न करना)?
क्या कॉन्टेक्स्ट मैनेजमेंट स्ट्रेटेजी लागू है (समराइज़ेशन थ्रेशोल्ड)?

क्या 'नहीं' करना है (What NOT to Do)

कोई चापलूसी या बढ़ा-चढ़ाकर बोले गए शब्द तो नहीं हैं?
कोई फालतू "you are a helpful AI" वाली घोषणा तो नहीं है?
क्या इसे प्रॉम्प्ट चेन की तरह तो नहीं लिखा गया है?
कोई ओवर-इंजीनियरिंग (ऐसे फीचर्स जो किसी ने नहीं मांगे) तो नहीं है?

अगर मैं आज शुरुआत कर रहा होता

यहाँ बताया गया है कि मैं बिल्कुल क्या करता:

शुरुआती 3 लाइनों में Identity + Safety से शुरुआत करें। एजेंट कौन है, इसके लिए दो वाक्य। NEVER/MUST के साथ सख्त सीमाएँ। सुरक्षा नियमों को अंत में दोहराएं।
अपने कोर वर्कफ़्लो को सिद्धांतों (principles) के रूप में लिखें, स्टेप्स के रूप में नहीं। अधिकतम 4-5 बुलेट पॉइंट्स। हल्के नियमों के लिए "recommended" और "prefer" का इस्तेमाल करें, सख्त नियमों के लिए "NEVER" और "MUST" का।
अपने हिस्से के लिए 1,500-6,000 टोकन्स का बजट रखें। टूल डेफिनिशन्स 5,000-15,000 और जोड़ देंगे। अगर आप 6K से ऊपर हैं, तो शायद आप वह नॉलेज डंप कर रहे हैं जिसे ऑन-डिमांड लोड किया जाना चाहिए।
हर चीज़ को स्ट्रक्चर करें। मार्कडाउन हेडर्स, बुलेट लिस्ट्स, उदाहरणों के लिए XML टैग्स। एक स्ट्रक्चर्ड प्रॉम्प्ट हमेशा सामान्य भाषा (natural language) वाले प्रॉम्प्ट से बेहतर परफॉर्म करता है।
पहले दिन से ही मिड-कन्वर्सेशन रिमाइंडर्स को शामिल करें। अपने सिस्टम प्रॉम्प्ट में <system-reminder> डिक्लेयर करें। ज़रूरी नियमों, मोड स्विच और कॉन्टेक्स्ट अपडेट्स के लिए रिमाइंडर्स इंजेक्ट करें।
कैश (cache) के लिए डिज़ाइन करें। स्टैटिक कंटेंट पहले, डायनामिक कंटेंट बाद में। कभी भी अपने सिस्टम प्रॉम्प्ट की बॉडी में बदलने वाली वैल्यूज़ न डालें।

इस सब की सबसे बड़ी विडंबना क्या है? सबसे बेहतरीन सिस्टम प्रॉम्प्ट्स छोटे होते हैं। क्लॉड कोड के कस्टम इंस्ट्रक्शन्स (टूल डेफिनिशन्स को छोड़कर) आश्चर्यजनक रूप से संक्षिप्त हैं। हर लाइन अपनी जगह डिज़र्व करती है।

मैं पहले सोचता था कि प्रॉम्प्ट इंजीनियरिंग का मतलब कुछ चालाक ट्रिक्स खोजना है। अब मुझे लगता है कि यह अनुशासन (discipline) का खेल है — कम बोलना, सटीक बोलना, और बाकी चीज़ें समझने के लिए मॉडल पर भरोसा करना। मॉडल आपके प्रॉम्प्ट से ज़्यादा स्मार्ट है। बिहेवियर को नहीं, एनवायरनमेंट को डिज़ाइन करें।

संदर्भ (References)

स्रोत (Source)	मुख्य सीख (Key Insight)
Claude Code v2.0.14 System Prompt	फुल प्रोडक्शन एजेंट प्रॉम्प्ट स्ट्रक्चर रेफरेंस
Reddit: Understanding Claude Code's 3 System Prompt Methods	Output Styles / --append / --system-prompt डीप डाइव, कॉन्टेक्स्ट रॉट रियल-वर्ल्ड डेटा
shareAI-lab/learn-claude-code	"मॉडल ही एजेंट है" फिलॉसफी, हार्नेस इंजीनियरिंग कार्यप्रणाली
Anthropic Prompt Engineering Docs	ऑफिशियल प्रॉम्प्ट बेस्ट प्रैक्टिसेस
DeepAgents Framework	समराइज़ेशन मिडलवेयर, स्किल्स प्रोग्रेसिव डिस्क्लोज़र

Excerpt: सिस्टम प्रॉम्प्ट्स के बारे में लोग जिन चीज़ों को ज़रूरी मानते हैं, उनमें से ज़्यादातर मायने ही नहीं रखतीं। क्लॉड कोड (Claude Code) को रिवर्स-इंजीनियर करने और VibeCom बनाने के बाद, यहाँ वह सब कुछ है जो आपको ऑटोनोमस AI एजेंट्स के लिए सिस्टम प्रॉम्प्ट लिखने के बारे में जानना चाहिए — टोकन बजट से लेकर मिड-कन्वर्सेशन इंजेक्शन तक।