Claude Code, MCP & Integration

स्क्रीन 1: अंत तक आप क्या कर पाएंगे

ORIENTATION · 2 MIN अंत तक आप क्या कर पाएंगे

Claude Code आपका terminal-native development partner है।

पिछले मॉड्यूल में, आपने आवश्यक API components सेट अप किए: prompts, tool schemas, context engineering, agent loops, और multimodal ingestion; यह मॉड्यूल सीधे उस foundation पर बनता है। Claude Code आपको अपने terminal environment में एक ही model को operate करने देता है, एक permission layer, configuration system, और team-oriented sharing features introduce करता है। MCP protocol external services के साथ secure integration को enable करता है। इस मॉड्यूल में, आप Claude Code और MCP को robust security और effective deployment के लिए configure करना सीखेंगे।

इस मॉड्यूल के अंत तक, आप निम्नलिखित कर पाएंगे: 1 Claude Code को explore, plan, और code loop के माध्यम से चलाएं और एक permission mode चुनें जो काम के risk level से मेल खाता हो, ताकि agent productive रहे बिना task के लिए आवश्यक से अधिक authority दिए। 2 AI-generated code को पढ़ें, calibrated trust के साथ output की समीक्षा करें, और उन findings पर कार्य करें जो reliable हैं, उन्हें verify करें जो नहीं हैं, और एक human review gate लगाएं जहां गलत निर्णय की cost अधिक हो। 3 CLAUDE. md, rules instruction files, hooks, और subagents का उपयोग करके Claude Code को durable project context दें। 4 एक workflow को skills, custom commands, और एक plugin के रूप में package करें। एक skill को एक बार author करें जो Claude Code, Messages API, और Agent SDK में एक ही तरीके से चले। 5 एक MCP server बनाएं जो tools, resources, और prompts को Claude के लिए उपलब्ध कराता है, एक transport चुनें जो client और server के communication से मेल खाता हो, और एक configuration scope सेट करें जो नियंत्रित करता है कि इसे कौन load करता है। 6 Claude को enterprise systems से जोड़ें, उन connections को patterns का उपयोग करके authenticate करें जो एक regulated customer स्वीकार करेगा, और एक code modernization engagement को scope करें ताकि काम एक security review के तहत टिका रहे।

यह मॉड्यूल उस Developer के लिए है जिसके पास पहले से Claude code में काम कर रहा है और अब उस काम को configurable, shareable, और real systems से जुड़ने के लिए safe बनाना है। आप practical, code-forward, और pattern-oriented हैं। यह मॉड्यूल मानता है कि आप Module 2 के API patterns के साथ comfortable हैं। यह agent loop, tool schemas, या context engineering को फिर से सिखाता नहीं है। यह engineering decisions सिखाता है जो एक working integration के चारों ओर बैठते हैं: कैसे Claude Code को अपने terminal में एक permission model के तहत चलाएं, कैसे इसे durable project context दें, कैसे एक workflow को package करें ताकि एक teammate इसे install कर सके, और कैसे Claude को external और enterprise systems से MCP के माध्यम से जोड़ें बिना credentials leak किए या एक security review fail किए।

"THE BUILD" इस मॉड्यूल में

इस मॉड्यूल में सब कुछ एक recurring problem के चारों ओर बनाया गया है: code जो आपकी machine पर, आपके session में, या staging में काम करता है अब production में hold up करना चाहिए, real company systems के विरुद्ध। आपकी machine पर permission mode safe लगा, project rules छोटे थे follow करने के लिए, skill ने अपनी script खोजी, credential config file में सही था, और connection staging test में काम किया। जिस moment काम आपकी machine से निकलता है, उनमें से प्रत्येक convenience एक failure बन सकता है: एक permission mode एक file delete करता है जो कभी scope में नहीं था, एक rule सैकड़ों lines के तहत दब जाता है, एक skill एक path की ओर इशारा करता है जो किसी अन्य machine पर exist नहीं करता है, एक committed key घंटों के भीतर leak हो जाता है, और एक staging-only configuration step production connection को down ले जाता है। इस मॉड्यूल में काम यह सीखना है कि कौन सा configuration decision कौन सी failure को prevent करता है, इससे पहले कि वे एक teammate या एक auditor के सामने दिखाई दें।

DISCLAIMER / NOTICE FOR EDUCATIONAL CONTENT

हमने यह Developer course Module 3: Claude Code, MCP & Integration Claude के साथ real work करने में आपकी मदद करने के लिए बनाया। इसे educational content के रूप में treat करें। यह legal, financial, या अन्य professional advice constitute नहीं करता है, इसलिए जो आप सीखते हैं उसे अपनी स्थिति के अनुसार adapt करें। हमारे products और services quickly evolve करते हैं, इसलिए कुछ content में errors हो सकते हैं या outdated हो सकते हैं; Anthropic की website या docs पर verify करना याद रखें। Examples और scenarios जो course में use किए गए हैं वे illustrative हैं और अक्सर fictitious हैं। अगर course material एक company या product का mention करता है, तो इसका मतलब यह नहीं है कि Anthropic उन्हें endorse करता है, वे Anthropic को endorse करते हैं, या कि हम affiliated हैं। यह भी note करें कि Anthropic products और services का आपका use हमारे terms, policies और documentation द्वारा covered है; अगर इस course में कुछ उनके साथ conflict करता है, तो वे control करते हैं।

स्क्रीन 2: Claude Code agent loop, permission modes, settings, और जहां एक human gate जाता है

TeachingPermission Modes & Human Gates·17 min Claude Code agent loop, permission modes, settings, और जहां एक human gate जाता है Module 2 ने स्थापित किया कि agent loop API level पर कैसे काम करता है: model tools को call करता है, results वापस पाता है, और जब तक task complete न हो जाए तब तक continue करता है। Claude Code उसी loop को अपने terminal में चलाता है लेकिन एक additional layer जोड़ता है: एक permission system जो agent के हर action को gate करता है। इससे पहले कि आप कुछ भी configure कर सकें, आपको यह समझना होगा कि loop कैसे चलता है और permission modes क्या control करते हैं।

कैसे Claude Code एक task के माध्यम से काम करता है: explore, plan, और code जब आप Claude Code को एक task देते हैं, तो यह तुरंत लिखना शुरू नहीं करता। यह files को read करता है, relevant logic को trace करता है, और पहले codebase का एक picture बनाता है; यह exploration phase है। फिर, एक बार जब यह change propose करने के लिए पर्याप्त समझ लेता है, तो यह एक plan बनाता है। एक plan edits का एक structured description है जो यह करने का इरादा रखता है। केवल आपके द्वारा plan को review और approve करने के बाद ही यह code phase में जाता है, जहां यह changes को write और execute करता है। यह sequence दो कारणों से मायने रखता है। पहला, यह better output produce करता है: Claude Code codebase को कुछ भी touch करने से पहले समझता है, इसलिए यह कम assumptions बनाता है और अधिक downstream effects को catch करता है। दूसरा, यह वह जगह है जहां permission modes plug in करते हैं: plan mode Claude Code को explore phase में hold करता है, सभी file edits और shell commands को block करता है जब तक आप इसे release न करें, इसे unfamiliar codebases या high-stakes work के लिए एक useful default बनाता है।

Permission modes: approvals, gates, और constraints Permission modes नियंत्रित करते हैं कि Claude Code कितनी बार confirmation के लिए रुकता है। प्रत्येक mode speed और oversight के बीच एक अलग tradeoff बनाता है। सही choice इस बात पर निर्भर करता है कि आप codebase को कितनी अच्छी तरह जानते हैं और changes कितने reversible हैं। प्रत्येक tab को select करें कि वह mode क्या auto-approve करता है, क्या अभी भी gate करता है, और इसकी limitations क्या हैं।

default acceptEdits plan auto dontAsk bypassPermissions

क्या auto-approve करता है: Reads only। लगभग हर edit या command से पहले prompt करता है। क्या अभी भी gate करता है: सभी file edits और shell commands को confirmation की आवश्यकता है। Limitations: Trusted work पर safe लेकिन slow। किसी भी नई project या unfamiliar codebase के लिए baseline।

क्या auto-approve करता है: Reads, file edits, और common filesystem commands (mkdir, touch, rm, rmdir, mv, cp, और sed) working directory के अंदर। Auto-approval working directory के अंदर paths तक scoped है, और protected paths अभी भी prompt करते हैं। क्या अभी भी gate करता है: सभी अन्य shell commands; working directory के बाहर writes; protected paths को writes। Limitations: Trusted local work जहां shell execution को अभी भी एक human eye की आवश्यकता है। अगर agent को scripts चलाने चाहिए तो appropriate नहीं है।

क्या auto-approve करता है: Reads only। Research और propose करता है; कोई edits नहीं बनाता है। क्या अभी भी gate करता है: सभी file edits और shell commands जब तक आप एक plan को approve न करें। Limitations: Sensitive या unfamiliar codebases पर exploration और planning। Tasks के लिए appropriate नहीं जो output write करने चाहिए।

क्या auto-approve करता है: सब कुछ, लेकिन एक अलग classifier हर action को पहले review करता है और कुछ भी block करता है जो आपके request से beyond escalate करता है, unrecognized infrastructure को target करता है, या hostile या inappropriate content द्वारा driven प्रतीत होता है। क्या अभी भी gate करता है: Production deploys और migrations, mass deletes, credential exfiltration, और force-push to main default द्वारा blocked हैं। Limitations: Prompts को reduce करता है लेकिन safety guarantee नहीं देता; यह एक research preview है, sensitive operations को review करने के लिए एक substitute नहीं है। Availability plan, model version, और admin settings पर निर्भर करता है। Build से पहले हमेशा current requirements को verify करें।

क्या auto-approve करता है: केवल tools जो आपने एक allow rule में pre-approved किए हैं, plus read-only commands। Auto-DENIES सब कुछ और। क्या अभी भी gate करता है: Allow list पर नहीं हर tool call को deny किया जाता है। Confirmation के लिए कोई queue नहीं है। Limitations: Locked-down CI और scripts के लिए built। यह अच्छी तरह restrict करता है, लेकिन यह local interactive work पर friction को reduce करने का एक तरीका नहीं है।

क्या auto-approve करता है: सभी tool calls। कोई confirmation prompts नहीं और कोई safety checks नहीं। क्या अभी भी gate करता है: Normal operation में कुछ नहीं। Standard permission checks को bypass किया जाता है; केवल catastrophic delete commands जैसे rm -rf / और rm -rf ~ अभी भी एक last-resort prompt trigger करते हैं। Limitations: केवल एक isolated container या VM के अंदर जहां environment disposable है। कभी भी एक developer workstation पर एक live codebase के विरुद्ध नहीं।

जहां configuration रहता है और यह किसे apply करता है Settings को कई levels पर रखा जा सकता है, और प्रत्येक level उन rules के scope को determine करता है जो यह contains करता है।

User level (~/. claude/settings. json): Machine पर हर project को apply करता है। यह preferences के लिए सही जगह है जो हर जगह आपके साथ follow करने चाहिए, जैसे exploration work के लिए एक preferred default mode। Project level (. claude/settings. json, repo को committed): हर किसी को apply करता है जो repository को clone करता है। यह team-wide conventions, allow rules के लिए सही जगह है जो आपकी project use करती है, और deny rules उन paths के लिए जो touch नहीं किए जाने चाहिए। Local project level (. claude/settings. local. json): एक project के लिए personal overrides, automatically git-ignored। यह आपकी अपनी preferences के लिए सही जगह है जो पूरी team को commit नहीं किए जाने चाहिए। Enterprise level (managed-settings. json, administrators द्वारा set): Users या project files द्वारा override नहीं किया जा सकता। Organization-wide security controls के लिए सही जगह जैसे environment files को edits को deny करना या सभी projects में specific shell commands को block करना।

Allow और deny rules selected mode के top पर layer करते हैं। एक deny rule हमेशा एक allow rule को win करता है, mode के बावजूद जो effect में है। सबसे durable governance control एक enterprise-level deny rule है: इसे किसी भी individual developer द्वारा remove नहीं किया जा सकता और यह तब भी apply होता है जब एक bypass mode set हो।

जहां एक human को अभी भी देखना है: worst-case cost द्वारा review gate को place करना Permission modes और deny rules decide करते हैं कि agent क्या बिना पूछे कर सकता है। वे decide नहीं करते कि आप, human, को अभी भी कहां देखना है इससे पहले कि एक action land करे। वह decision एक question पर rest करता है, वही जो एक safe mode को एक risky से अलग करता है: अगर यह action बिना एक person checking किए चले तो worst outcome क्या है? Cost जितना कम है, आप उतना अधिक let through कर सकते हैं। Cost जितना अधिक है, और undo करना जितना कठिन है, उतना अधिक एक step को एक human gate की आवश्यकता है इससे पहले कि यह execute हो।

वही worst-case question gate को place करता है चाहे agent code write कर रहा हो या एक automated step जैसे एक bot जो एक pull request पर comment करता है या block करता है में unattended चल रहा हो। तीन placements इससे follow करते हैं:

Low-stakes, reversible actions को बिना एक gate के through let करें। एक formatting fix या एक edit confined to working directory में little cost है अगर यह गलत है, इसलिए एक human को हर एक को approve करने की requirement oversight buy करता है जो आपको need नहीं है और काम को slow करता है। यह वह case है जो acceptEdits के लिए built है। किसी भी action को gate करें जो undo करना कठिन है या एक sensitive path तक पहुंचता है: एक write working directory के बाहर, एक destructive shell command, या एक edit एक security-relevant या protected file को। Cost एक गलत call वहां high है, इसलिए agent को pause करना चाहिए और action को एक person के लिए surface करना चाहिए इससे पहले कि यह चले। एक deny rule इसे deterministically enforce करता है, और default या plan mode prompt को place में रखता है जबकि आप decide करते हैं। कभी भी agent को एक sensitive के रूप में अपनी team द्वारा marked code में एक change पर एकमात्र gate न बनने दें। वहां agent का काम एक human decision के लिए एक input है, एक replacement नहीं, इसलिए एक person को change को review करना चाहिए इससे पहले कि यह merge हो चाहे agent या इसकी अपनी review कितनी confident हो।

Gate का placement और permission mode की choice एक ही decision हैं दो sides से देखे गए। Mode एक पूरे session के लिए default set करता है, और gate वह जगह है जहां आप उस एक action के लिए default को override करते हैं जिसकी cost default को छोड़ने के लिए बहुत अधिक है; दोनों इससे आते हैं कि क्या breaks अगर यह unchecked चले।

Cost · Complexity · Risk Cost: Trusted work पर default mode में चलना हर tool call को prompt latency add करता है, और यह एक long refactor पर accumulate करता है। Complexity: Settings और files के multiple levels एक override hierarchy के साथ consistent care की requirement करते हैं। एक deny rule enterprise level पर जो एक allow rule को project level पर contradict करता है को हर किसी द्वारा समझा जाना चाहिए जो project config को maintain करता है। Risk: Risk गलत mode को context के लिए use करने में है। उदाहरण के लिए, एक bypass mode impatience से set किया गया एक non-isolated machine पर agent और आपकी live files के बीच हर safety prompt को remove करता है, और, अन्य modes के विपरीत, protected-path guard को भी remove करता है।

स्क्रीन 3: Bypass mode जिसने एक prompt को remove किया जो मायने रखता था

Watch OutPermission Modes & Human Gates·3 min Bypass mode जिसने एक prompt को remove किया जो मायने रखता था

Setup आपने bypassPermissions को switch किया constant prompts को stop करने के लिए क्योंकि काम routine लगा। Agent कई दिनों से well-behaved था, cleanup task simple था, और हर tool call से पहले prompt-before-every-tool-call behavior unnecessary friction लगा।

The transcript निम्नलिखित pairing session एक codebase cleanup पर हुआ जो बिना incident के तीन दिन चल रहा था। Dev: "ठीक है, मैं इस एक के लिए bypassPermissions को switch कर रहा हूं। यह सिर्फ पुराने API endpoint references को rename कर रहा है। कुछ भी risky नहीं है।" Claude Code: [Scanning files matching pattern /v1/legacy/ ... 47 files found] Claude Code: [Updating endpoint references ... ] Claude Code: [Running post-rename cleanup. sh script ... ] Claude Code: [Deleted 3 files matching /v1/legacy/ in /deploy/config/prod/ ... ] Dev: "Wait। /deploy/config/prod/ में क्या था? " Claude Code: [Files contained environment-specific endpoint overrides production deployment के लिए। उन्हें remove किया गया है।] Dev: "वह directory scope में नहीं था। मैं /src/ पर काम कर रहा था।" Claude Code: [Pattern /v1/legacy/ दोनों /src/ और /deploy/config/prod/ में files को match किया। BypassPermissions mode में, deletions से पहले कोई confirmation request नहीं किया गया।] Prompt जो इस mistake को catch करता था वह turn off हो गया जब bypassPermissions turn on हुआ। Default या acceptEdits mode में, cleanup script confirmation के बिना नहीं चलता, और user deletion को production configuration files तक पहुंचने से पहले stop कर सकता था। BypassPermissions में, pattern match intended से broader था, और script और files के बीच कोई prompt नहीं था जो यह delete करता था। Note gate का precise location: यह script invocation था जो prompt करता, rm deletion commands नहीं। AcceptEdits auto-approves common filesystem commands, including rm working directory के अंदर paths पर। अगर Claude deletions को directly rm commands के रूप में issue करता, acceptEdits उन्हें silently let through करता; केवल default mode उन के लिए prompt करता है।

What to Watch Out for एक bypass mode सभी confirmation prompts को silence करता है, उन सहित जो आपने anticipate नहीं किया हो सकता। Failure pattern यहां एक agent है जो आपके intended से एक broader set of files को match करता है, एक mode में चल रहा है बिना checkpoints के। BypassPermissions भी protected path guard को skip करता है जो अन्य modes keep करते हैं, इसलिए यहां तक कि repo state और Claude का अपना configuration अपना automatic prompt खो देते हैं। इस gap को cover करने के लिए, आपको sensitive directories पर एक deny rule set करना चाहिए modes को switch करने से पहले। अगर आप fewer prompts चाहते हैं बिना safety net को खोए, एक classifier-gated mode (e. g. , auto) use करें एक full bypass के बजाय।

स्क्रीन 4: Checkpoint 1: settings file को assemble करें और human gate को place करें

CheckpointPermission Modes & Human Gates·4 min Checkpoint 1: settings file को assemble करें और human gate को place करें अभी try करें। आप Claude Code को एक trusted local refactor के लिए payments module के लिए configure कर रहे हैं। Refactor को file edits को auto-approve करना चाहिए लेकिन कभी भी destructive shell commands को नहीं चलाना चाहिए, और file . env. production को कभी भी agent द्वारा readable नहीं होना चाहिए। नीचे settings. json pieces हैं।

Part 1: Setting. json pieces को select करें जो सही configuration को assemble करते हैं दो pieces को select करें। ✓Piece A. { "permissions": { "defaultMode": "default"} }✓Piece B. { "permissions": { "defaultMode": "bypassPermissions" } }✓Piece C. { "permissions": { "allow": ["Bash(npm run:)"], "deny": ["Bash(rm:)", "Bash(git push:*)"] } }✓Piece D. { "permissions": { "deny": ["Read(. env. production)"] } }✓Piece E. { "permissions": { "allow": ["Bash()", "Edit()"] } }

Part 2 आपकी settings agent को automatically files को edit करने देती हैं। Refactor के दौरान agent एक deployment configuration file को एक change propose करता है जो कई production services read करते हैं। उस एक action के लिए एक human gate कहां बैठना चाहिए? एक single best answer को choose करें। aकहीं नहीं: settings पहले से ही edits को auto-approve करती हैं, इसलिए इसे चलने दें।bएक human deployment configuration file को change को review और approve करता है write execute करने से पहले, क्योंकि एक गलत value वहां undo करना कठिन है और file के बाहर systems तक पहुंचता है।cBypassPermissions add करें ताकि agent कभी pause न करे।dChange को केवल बाद में review करें, अगले pull request के दौरान।

Submit Skip for now

स्क्रीन 5: CLAUDE.md, rules files, hooks, और subagents के साथ Durable project context

TeachingDurable Project Context·20 min CLAUDE. md, rules files, hooks, और subagents के साथ Durable project context पहले हमने देखा कि कैसे Claude Code permission modes और settings files के माध्यम से actions को gate करता है। वह configuration layer नियंत्रित करता है कि agent क्या करने की अनुमति है। यह cluster इसके top पर build करता है: अब आप सीखेंगे कि कैसे configure करें कि agent क्या जानता है और कैसे behave करता है, ताकि rules और project context जो आप एक session में define करते हैं अगले session की शुरुआत में अभी भी effect में हों।

CLAUDE. md: project file जो हर session में load होता है हर बार Claude Code एक project directory में start होता है, यह एक file named CLAUDE. md को root पर look करता है और read करता है। Contents आपके prompt से पहले context में prepend किए जाते हैं। इसका मतलब है कि हर convention, constraint, और command जो आप CLAUDE. md में put करते हैं हर session के पहले prompt से present है, बिना आपको इसे re-state किए। /init command आपके codebase को scan करता है और एक starter CLAUDE. md generate करता है। Generated file एक great baseline है लेकिन use करने से पहले validate किया जाना चाहिए। इसे refine करें अपने prompts के outcome को control करने वाले rules को hold करने के लिए: आपकी testing commands, आपकी framework conventions, paths जो agent को नहीं touch करने चाहिए, और style decisions जो defaults से differ करते हैं। Size main failure mode है। एक CLAUDE. md जो हर नई instruction के साथ grow करता है dilute कर सकता है rules जो सबसे अधिक matter करते हैं। एक larger file context window का अधिक consume करता है, जो किसी भी single instruction को एक smaller fraction बनाता है जो load होता है, और यह reduce करता है कि agent एक rule को follow करने की chance जो एक real mistake को catch करता है। CLAUDE. md को constraints तक hold करें जो behavior को change करते हैं और सब कुछ और को Skills में move करें जो on demand load होते हैं।

Rules instruction files: scoping guidance जहां यह apply होता है पिछले section में, हमने establish किया कि CLAUDE. md हर session में load होता है और instructions को hold करना चाहिए जो पूरी project में apply होते हैं। अगला question यह है कि क्या करें guidance के साथ जो केवल codebase के एक part में matter करता है। यह वह जगह है जहां rules instruction files आते हैं: वे आपको instructions को apply करने देते हैं केवल जहां वे relevant हैं, हर session में उन्हें load करने के बजाय। CLAUDE. md हमेशा on है, और rules files एक narrower layer add करते हैं उस baseline के top पर। वे project के . claude/rules/ directory में रहते हैं और एक paths glob का उपयोग करके उनके YAML frontmatter में specific paths को scoped किया जा सकता है। एक rule इस तरीके से scoped होता है केवल तब load होता है जब Claude Code files को match करने वाले pattern के साथ काम करता है, यह एक rule को codebase के एक part को apply करने देता है बिना बाकी context को clutter किए। Note करें कि scoping frontmatter से आता है, file placement से नहीं। Rules files को . claude/rules/ के subdirectories में organize किया जा सकता है (e. g. , . claude/rules/database/), लेकिन वह structure केवल organizational है; एक rules file बिना एक paths field के unconditionally launch पर load होता है, CLAUDE. md के समान priority के साथ, चाहे यह . claude/rules/ के अंदर कहीं भी बैठे। Practice में, broad project memory और universal constraints को CLAUDE. md में put करें, और narrow, path-specific guidance को rules files में put करें जो paths के साथ scoped हों। एक constraint जैसे "कभी भी database schema को modify न करें" CLAUDE. md में रहता है क्योंकि यह हर जगह apply होता है। एक constraint जैसे "database module में सभी SQL को एक explicit transaction boundary include करना चाहिए" . claude/rules/database. md में रहता है frontmatter के साथ जैसे: --- paths:

• "src/db/*/. sql"

--- ताकि यह केवल तब context में enter हो जब Claude उन files के साथ काम कर रहा हो।

Hooks: अपनी scripts को lifecycle में fixed points पर चलाना एक Hook आपको tool calls को execute होने से पहले या बाद में intercept और control करने देता है। जब आप CLAUDE. md में एक specific rule write करते हैं agent को हर file edited के बाद Prettier को run करने के लिए, agent अधिकांश समय इसे follow करेगा। Alternatively, एक hook इसे हर single time happen करता है बिना exceptions के क्योंकि hook independently model के decide करने से fire करता है। Hooks settings files में defined हैं और /hooks command का उपयोग करके configured हैं। प्रत्येक hook एक lifecycle event को bind किया जाता है, एक optional matcher जो इसे specific tool types तक scope करता है, और एक command जो event fire होने पर चलता है। Most guardrail और automation use cases के लिए core events हैं:

PreToolUse: एक tool call execute होने से पहले चलता है। क्योंकि यह पहले चलता है, एक PreToolUse hook tool call को examine कर सकता है और code 2 के साथ exit कर सकता है इसे block करने के लिए, stderr को feedback के रूप में लिखते हुए agent देखता है। यह है कि कैसे आप access controls को configuration layer पर enforce करते हैं बजाय agent को CLAUDE. md instruction को respect करने की hope करने के। PostToolUse: एक tool call complete होने के बाद चलता है। चूंकि call पहले से ही हुआ है, यह event इसे block नहीं कर सकता, जो इसे automated side effects के लिए सही जगह बनाता है: एक edit के बाद एक code formatter को run करना, एक file change के बाद tests को trigger करना, या operation को audit trail के लिए log करना। UserPromptSubmit: जब आप एक prompt submit करते हैं, model इसे process करने से पहले चलता है। इसे use करें जब आपको context को inject करना हो या request को validate करना हो किसी भी काम के शुरू होने से पहले। Stop: जब model responding finish करता है। इसे use करें follow-up actions के लिए जो एक turn के अंत में belong करते हैं, जैसे notifications, cleanup tasks, या audit log को commit करना। Notification: जब Claude Code एक notification send करता है, जो तब होता है जब Claude को एक tool use करने की permission चाहिए या Claude Code 60 seconds के लिए idle रहा हो। इसे use करें उन signals को एक external channel या logging system को route करने के लिए। SessionStart: जब एक session start या resume होता है। इसे use करें state को initialize करने के लिए, environment variables को validate करने के लिए, या confirm करने के लिए कि required services reachable हैं इससे पहले कि agent काम शुरू करे। SessionEnd: जब एक session end होता है। इसे use करें teardown tasks के लिए, final audit writes, या notifications कि session close हो गया है।

एक hook जो एक production configuration path को reads को block करता है एक PreToolUse event का उपयोग करके उस constraint को हर tool call पर enforce करता है हर session के दौरान, permission mode के बावजूद। यह एक guardrail और एक convention के बीच का difference है।

Subagents: एक isolated context को काम को delegate करना एक subagent एक specialized assistant है जो Claude Code को tasks को delegate कर सकता है, और प्रत्येक assistant एक task को अपने अलग context में run करता है और केवल अपना output return करता है। यह आपकी main conversation history को inherit नहीं करता, files जो आपने context में accumulate किए हैं, या आपकी current session state। जब आप एक task को एक subagent को send करते हैं, यह एक clean slate से start करता है, काम करता है, और result को hand back करता है। Built-in subagents differ करते हैं कि वे startup पर क्या load करते हैं; यह difference determine करता है कि आपके project rules कैसे apply होते हैं। हमेशा current list को Claude Code docs में check करें, क्योंकि set समय के साथ grow हुआ है, लेकिन जानें कि specific split जो आपके project rules को affect करता है versions में hold करता है। Explore और Plan built-in subagents CLAUDE. md और git status को skip करते हैं research को fast और cheap रखने के लिए। वे speed के लिए optimized हैं, इसलिए project-level rules और repository state जो CLAUDE. md में defined हैं उनके context में नहीं हैं जब वे चलते हैं। Tasks के लिए जहां आपके project constraints को respect किया जाना चाहिए, general-purpose subagent को use करें या एक custom subagent जो explicitly rules को load करता है जिसे यह need करता है। Custom subagents भी automatically आपके skills को नहीं देखते। अगर आप एक custom subagent को . claude/agents में define करते हैं और इसे एक specific skill की need है, आपको explicitly उस skill को agent के front matter में list करना चाहिए। Built-in agents को preloaded skills नहीं हैं। अगर एक built-in agent को skill-backed behavior की need है, सही path एक custom subagent को create करना है जिसके configuration में वह skills listed हों।

नीचे map प्रत्येक mechanism को name करता है, यह क्या load करता है, कब चलता है, इसकी context cost, और क्या इसमें belong करता है। इसे use करें यह decide करने के लिए कि कौन सा mechanism एक specific piece of project knowledge को carry करता है, चूंकि प्रत्येक एक अलग tradeoff बनाता है कि यह कितना context cost करता है और कितनी reliably यह apply होता है। Full picture के लिए प्रत्येक card को flip करें।

MechanismCLAUDE. mdFlip ↻ क्या load करता है: Full file contents session start पर context को prepend किया जाता है।कब चलता है: हर session, unconditionally।Context cost: Session per persistent। Size के साथ dilutes।Belong करता है: Universal project constraints, commands, और framework decisions।

MechanismRules fileFlip ↻ क्या load करता है: File contents। YAML frontmatter में एक paths glob के माध्यम से scoped; बिना paths के, CLAUDE. md की तरह load होता है।कब चलता है: जब Claude एक file को match करने वाले rule के paths patterns को read करता है। Unscoped rules session start पर load होते हैं।Context cost: Path-scoped: केवल triggered होने पर context को add करता है। Unscoped: CLAUDE. md के समान persistent cost।Belong करता है: Path-specific guidance जो हर जगह noise होगा।

MechanismHookFlip ↻ क्या load करता है: Lifecycle event पर अपनी script को run करता है। Context को कोई content add नहीं।कब चलता है: Configured event पर (PreToolUse, PostToolUse, आदि)।Context cost: Minimal: केवल script output अगर Claude को routed हो।Belong करता है: Enforced guardrails, automated side effects, audit logging।

MechanismSubagentFlip ↻ क्या load करता है: केवल task context। Main session से isolated।कब चलता है: जब main session द्वारा एक delegated task के लिए dispatched किया जाता है।Context cost: एक summary return करता है, पूरा task history नहीं।Belong करता है: Exploration, investigation, और tasks जिनका output अन्यथा main context को bloat करेगा। Parallelized किए जा सकने वाले tasks को break down करने के लिए भी useful।

अच्छी तरह से handles करता हैProjects जो आप कई sessions में return करेंगे, जहां एक stable set of rules, per-directory variation, या unconditional guardrails setup को repay करते हैं। एक अलग approach useएक-बार tasks जो आप revisit नहीं करेंगे। एक unfamiliar codebase के quick exploration के लिए, setup overhead warranted नहीं है।

स्क्रीन 6: CLAUDE.md जो grow करता रहा जब तक rules land करना बंद न हो गए

Watch OutDurable Project Context·4 min CLAUDE. md जो grow करता रहा जब तक rules land करना बंद न हो गए

Setup आपका CLAUDE. md grow करता रहा क्योंकि हर नया rule add करने लायक लगा। प्रत्येक addition individually reasonable था, और file प्रत्येक rule के लिए सही जगह लगी। लेकिन कुछ हफ्तों में, file 800 lines से अधिक grow हो गई।

The trace निम्नलिखित एक session log excerpt है एक project से जिसमें एक CLAUDE. md है जो दो महीने की team additions में accumulate हुआ है। Session context window loaded: CLAUDE. md: 847 lines Contents include: framework preferences (lines 1–40), testing conventions (lines 41–90), style guide (lines 91–210), dependency rules (lines 211–320), path restrictions (lines 321–360), historical decisions log (lines 361–700), archived notes (lines 701–847) User prompt: "Auth module को refactor करें नई token service को use करने के लिए। /legacy/tokens/ directory को modify न करें।" Claude Code action: [Reading auth module ... ] Claude Code action: [Editing auth/service. ts ... ] Claude Code action: [Reading /legacy/tokens/store. ts for reference ... ] Claude Code action: [Editing /legacy/tokens/store. ts to update token interface ... ] Path restriction from CLAUDE. md (line 347): "/legacy/tokens/ में files को modify न करें।" User: "आपने /legacy/tokens/store. ts को edit किया। मैंने कहा उस directory को touch न करें।" Claude Code: "मुझे खेद है। /legacy/tokens/ restriction project instructions में है। Edit token interface को update करने के course में किया गया था। मैंने proceed करने से पहले conflict को flag नहीं किया।" Rule file में था; agent को इसका access था। लेकिन, failure dilution था: 846 अन्य lines ने एक instruction की effective weight को reduce किया जो matter करता था। Historical decisions log और archived notes को कहीं note किया जाना चाहिए था, लेकिन वे CLAUDE. md में belong नहीं करते थे।

What to Watch Out for CLAUDE. md एक working set of rules है जो current session के लिए behavior को change करते हैं, एक growing append log नहीं। हर line जो आप add करते हैं हर अन्य line की weight को reduce करता है। अगर एक rule path-specific है, यह एक rules file में belong करता है। अगर एक rule historical context है, यह एक separate reference document में belong करता है जो agent on demand को read करता है। जब आपका CLAUDE. md कुछ सौ lines से अधिक grow करता है, इसे audit करें: identify करें कि कौन से rules truly session-critical हैं और बाकी को move करें। एक rule जो आप afford नहीं कर सकते dilute करने के लिए एक hook के लिए shortest path है।

स्क्रीन 7: Checkpoint 2: सही value को drag करें

CheckpointDurable Project Context·3 min Checkpoint 2: सही value को drag करें अभी try करें। आप एक hook को setup कर रहे हैं जो एक path restriction को enforce करता है, और नीचे configuration के दो blanks हैं। सही को select करें: lifecycle event जो एक tool call execute होने से पहले चलता है, और command जो hook को . env. production के reads को block करने के लिए चलाता है। { "hooks": { "__": [ { "matcher": "Read", "hooks": [{ "type": "command", "command": "__" }] } ] } }

Blank 1: lifecycle event PreToolUsePostToolUseUserPromptSubmitSessionStart Blank 2: command एक script जो stdin से tool call को read करता है, file path को check करता है, और code 2 के साथ exit करता है जब path . env. production है (reason को stderr को लिखते हुए)।एक script जो tool call को एक audit file को log करता है और 0 के साथ exit करता है।एक script जो एक warning print करता है और unconditionally 0 के साथ exit करता है।

Submit Skip for now

स्क्रीन 8: एक workflow को एक plugin के रूप में package करना: skills, custom commands, और marketplace install

TeachingPackaging Workflows·8 min एक workflow को एक plugin के रूप में package करना: skills, custom commands, और marketplace install पहले, हमने mechanisms को cover किया जो Claude Code को durable context और enforce behavior देते हैं: CLAUDE. md हमेशा-on project memory के लिए, rules files scoped guidance के लिए, hooks deterministic guardrails के लिए, और subagents isolated task delegation के लिए। ये mechanisms आपके . claude directory में रहते हैं और project के साथ version-controlled हैं। अब हम अगले question की ओर turn करते हैं: कैसे आप उस setup को package कर सकते हैं ताकि एक teammate इसे एक step में simply install कर सके बजाय आपकी manual configuration को hand से repeat करने के?

Skills reusable workflows हैं जो agent on demand को load करते हैं एक skill एक portable Markdown file है (SKILL. md file) . claude/skills में placed। Front matter skill को identify करता है और describe करता है कि कब यह apply होता है, और body steps को hold करता है। एक ही skill Claude Code में run कर सकता है, Messages API के माध्यम से invoked हो सकता है, या Agent SDK द्वारा loaded हो सकता है। क्या तीनों में change करता है वह नहीं है file itself; यह है जहां skill चलता है, कैसे यह load होता है, और क्या यह touch करने की अनुमति है। एक developer जिसने केवल Claude Code में skills को देखा है assumptions बना सकता है जो तीनों में true नहीं hold करते हैं, इसलिए यह section outlines करता है differences।

कैसे skill हर एक में load और चलता है प्रत्येक tab के लिए select करें कि कैसे skill load होता है, जहां steps चलते हैं, और क्या आपको जानना चाहिए।

Claude Code Messages API Agent SDK Claude Managed Agents

कैसे skill load होता है: . claude/skills से filesystem पर discovered। Description match पर या जब आप इसे name से invoke करते हैं तब load होता है। जहां steps चलते हैं: आपके terminal session में, आपकी local files के विरुद्ध, active permission mode और deny rules के तहत। क्या आपको जानना चाहिए: यह filesystem-based है और settings layer द्वारा governed है।

कैसे skill load होता है: Request के साथ sent और code execution container के अंदर run किया जाता है, आपके application के environment में नहीं। Code-execution और skills beta headers की requirement करता है। जहां steps चलते हैं: Anthropic के code execution container के अंदर, आपकी machine पर नहीं। Skill का filesystem और tool access जो भी वह container provide करता है। क्या आपको जानना चाहिए: एक skill जो local files या local tools को assume करता है यहां same तरीके से behave नहीं करेगा, क्योंकि यह जहां वह files हैं वहां नहीं चल रहा है।

कैसे skill load होता है: Agent द्वारा loaded जो SDK चलाता है, लेकिन क्या filesystem settings (CLAUDE. md, skills) load होते हैं settingSources configuration द्वारा controlled है। Default पर rely न करें: हमेशा explicitly उन sources को set करें जो आप intend करते हैं, और current default behavior को Agent SDK reference के विरुद्ध confirm करें build time पर। आप इसे "settingSources" (TypeScript) / "setting_sources" (Python) के माध्यम से set करते हैं। जहां steps चलते हैं: Process में जो SDK चलाता है, जो आपका environment है, एक बार जब आपने इसे filesystem sources को load करने के लिए बताया है। क्या आपको जानना चाहिए: Common surprise: एक skill जो Claude Code में काम करता था SDK के तहत कुछ नहीं करता क्योंकि settingSources कभी set नहीं किया गया, इसलिए skill कभी load नहीं हुआ।

कैसे skill load होता है: एक बार एक API resource के रूप में defined जो model, system prompt, tools, MCP servers, और skills को name करता है। Anthropic skill को server-side load करता है जब agent चलता है, इसलिए आपकी ओर से कोई filesystem discovery step नहीं है। जहां steps चलते हैं: एक sandbox में जो Anthropic provisions और चलाता है, आपके environment में नहीं। आपका application user events को send करता है और streamed results को read करता है। Skill को access है जो भी वह managed sandbox provide करता है, आपकी local files नहीं। क्या आपको जानना चाहिए: Currently एक public beta जो managed-agents-2026-04-01 beta header की requirement करता है, और sessions server-side stored हैं, जिसका मतलब है Managed Agents currently Zero Data Retention या HIPAA BAA coverage के लिए eligible नहीं हैं। Skills को attached किया जाता है agent resource को define करते समय, session time पर नहीं। कौन से skills available हैं यह change करने के लिए agent definition को update करें।

तीन portability rules

Description को matching criterion के रूप में write करें। Model एक skill को आपके request को इसके description से compare करके load करता है, इसलिए एक description जो identify करता है कि कब skill apply होता है हर runtime में काम करता है, लेकिन एक vague एक सभी में fail करता है। एक local filesystem या local tools को skill body के अंदर exist करने के लिए assume न करें। एक skill जो एक local command को shell out करता है Claude Code में काम करता है लेकिन Messages API पर break करता है, जहां यह एक container में चलता है जिसमें एक command नहीं है। Skill के steps को जो runtime guarantee provide करता है उस तक confined रखें, या dependency को document करें। याद रखें कि subagents skills को inherit नहीं करते। यह Module 2 में true था, और यहां अभी भी true है: एक subagent clean start करता है, इसलिए एक skill जो parent relied था को explicitly हर runtime में listed होना चाहिए जो subagents को support करता है।

Practical takeaway यह है कि आप एक skill को एक बार author कर सकते हैं और reuse कर सकते हैं, लेकिन आपको specifically design करना चाहिए terminals में इसे use करने की ability के लिए। एक skill जो एक clear description को scoped है और local-environment assumptions से free है cleanly runtimes में port करता है, लेकिन एक जो एक specific local environment को assume करता है नहीं।

अच्छी तरह से handles करता हैAdds complexityएक अलग approach use करें

एक task-specific procedure एक बार authored और interactive terminal, एक API integration, और एक headless SDK job में reused। प्रत्येक runtime skill को अलग तरीके से load और sandbox करता है, इसलिए आपको API पर beta headers और SDK पर settingSources को account करना चाहिए। Instructions के लिए जो हर session में एक project में apply करना चाहिए, CLAUDE. md अभी भी सही tool है। Skills on-demand, portable procedures के लिए हैं।

एक workflow को एक explicit entry point देना एक custom command एक defined procedure के लिए एक shortcut है। Current Claude Code में, skills दोनों explicit और automatic invocation के लिए recommended format हैं: आप एक skill को directly /skill-name के साथ invoke करते हैं, या Claude इसे automatically load करता है जब relevant हो। Older . claude/commands/ directory format अभी भी काम करता है लेकिन एक legacy process है। Skills को disable-model-invocation: true के साथ frontmatter में use करें जब आप एक workflow चाहते हैं जो केवल तब चलता है जब आप explicitly इसे call करते हैं। Plugin commands automatically namespaced हैं: plugin का name prefix बन जाता है, इसलिए एक run-tests command एक plugin में named payments को /payments:run-tests के रूप में invoked किया जाता है। यह है कि कैसे दो plugins दोनों एक run-tests command को ship कर सकते हैं बिना collide किए। Authors को plugin name को interface के part के रूप में treat करना चाहिए, चूंकि यह हर command को prefix करता है जो आप ship करते हैं, और aware होना चाहिए कि plugin को rename करना उन्हें सभी को rename करता है।

Packaging layer जो एक setup को installable बनाता है एक plugin skills, hooks, subagents, और MCP servers को एक single installable unit में bundle करता है। Plugins को एक marketplace के माध्यम से packaged और distributed किया जा सकता है, जो एक catalog है plugins का जो किसी और ने create और share किया है। Official Anthropic marketplace automatically available है जब आप Claude Code को start करते हैं, और आप third-party marketplaces को एक GitHub repository में hosted के साथ add कर सकते हैं एक command जैसे /plugin marketplace add <owner/repo> के साथ। Teammates फिर एक simple install command को run कर सकते हैं एक ही setup को get करने के लिए। Plugin एक page of manual setup steps को एक versioned, auditable install के साथ replace करता है। Plugin components को निम्नलिखित के रूप में place करता है:

Skills एक skills directory में जाते हैं। Hooks, subagents, और settings उनके respective locations में जाते हैं।

Plugin manifest bundle को describe करता है, और install command इसे target installation में wire करता है। Plugins को individuals द्वारा या एक enterprise-wide level पर download किया जा सकता है। Enterprise administrators plugins को organization-wide deploy कर सकते हैं managed settings के माध्यम से। एक managed marketplace allowlist gate करता है कि कौन से marketplace sources users को add करने की permission है, इसलिए organization control करता है कि plugins कहां से आ सकते हैं। Allowlist restrict करता है कि users क्या add कर सकते हैं लेकिन marketplaces को automatically register नहीं करता है। अगर आप एक marketplace को सभी users को push करना चाहते हैं बिना उन्हें add command को run करने की requirement के, allowlist setting को pair करें extraKnownMarketplaces के साथ managed settings में। Precedence deployment scope से आता है: क्योंकि managed settings configuration hierarchy में user और project settings के ऊपर बैठते हैं, एक plugin deployed managed scope पर priority लेता है और users या project files द्वारा override नहीं किया जा सकता है। Reference layer के लिए exact setting names को review करें।

Packaging decision table नीचे table प्रत्येक layer को identify करता है, यह किसके लिए है, और कब इसे reach करें।

Layerक्या हैयह किसके लिए हैकब reach करें

Skillएक Markdown file . claude/skills में जो load होता है जब इसका description task को match करता है या जब आप इसे name से invoke करते हैं।एक individual developer या team जो Claude Code को interactively use करता है।एक skill को reach करें जब एक task-specific procedure context से बाहर रहना चाहिए जब तक यह needed न हो, जैसे एक PR review या एक deployment checklist जो केवल तब load होता है जब काम इसे call करता है। Custom commandएक named shortcut जो एक defined procedure को चलाता है जब आप इसे explicitly invoke करते हैं।Developers जो एक predictable, explicit entry point चाहते हैं high-frequency procedures के लिए।एक custom command को reach करें जब procedure का एक clear name हो और आप इसे directly trigger करना चाहते हैं बजाय description पर rely करने के कि यह task को match करे। Pluginएक versioned bundle of skills, hooks, subagents, और MCP servers एक marketplace के माध्यम से distributed।एक team जो एक shared, versioned setup का one-step installation चाहता है।एक plugin को reach करें जब एक working setup currently एक machine पर रहता है और को share, version, और एक team में consistent रखना चाहिए।

Cost · Complexity · Risk Cost: Skills activation पर context cost add करते हैं, लेकिन एक plugin installation और maintenance overhead add करता है। Question यह है कि क्या आप setup cost को एक बार pay करना चाहते हैं, जैसे आप एक plugin install के साथ करते हैं, या repeatedly, जैसे आप करते हैं जब हर developer एक ही manual steps को hand से चलाता है। Complexity: एक plugin जो absolute paths को author के home directory में hard-code करता है एक machine पर correctly install करेगा और सभी दूसरों पर fail करेगा, क्योंकि कोई भी path या environment assumption जो एक skill या hook command में baked है वह चीज है जो most likely machines में break करने के लिए है। Risk: एक plugin components को carry करता है जो यह bundle करता है हर install में। यह important है याद रखना कि एक deny rule या hook जो author locally relied था included नहीं है जब तक यह explicitly bundle के part के रूप में listed न हो। अगर skills या hooks एक guardrail को tied हैं जो bundle में included नहीं है, तो protection एक teammate के machine को carry over नहीं करता है।

स्क्रीन 9: Checkpoint 3: skill को सही runtime में place करें

CheckpointPackaging Workflows·3 min Checkpoint 3: skill को सही runtime में place करें अभी try करें। तीन teams एक ही review-checklist skill को अलग जगहों में reuse करना चाहते हैं। प्रत्येक के लिए, match करें कि skill को load और run करने के लिए क्या configure किया जाना चाहिए। Note: source चार runtime situations present करता है। सभी चार यहां included हैं ताकि match complete रहे। एक developer चाहता है कि skill Claude Code terminal में load हो जब वे एक review के लिए ask करते हैं।Enable filesystem sources को settingSources को explicitly set करके ताकि agent project से skills को load करे। Default पर rely न करें, और current default behavior को Agent SDK reference के विरुद्ध confirm करें build time पर।SKILL. md को . claude/skills में place करें एक description के साथ जो review requests को match करता है।Agent को एक API resource के रूप में define करें जो skill को list करता है और managed-agents-2026-04-01 beta header को calls पर set करें। Skill को write करें ताकि इसके steps local files पर depend न करें, क्योंकि यह Anthropic के sandbox में चलेगा।Code-execution और skills beta headers को send करें और skill को write करें ताकि इसके steps local files या local tools पर depend न करें।एक service Messages API को call करता है और चाहता है कि skill request के part के रूप में चले।Enable filesystem sources को settingSources को explicitly set करके ताकि agent project से skills को load करे। Default पर rely न करें, और current default behavior को Agent SDK reference के विरुद्ध confirm करें build time पर।SKILL. md को . claude/skills में place करें एक description के साथ जो review requests को match करता है।Agent को एक API resource के रूप में define करें जो skill को list करता है और managed-agents-2026-04-01 beta header को calls पर set करें। Skill को write करें ताकि इसके steps local files पर depend न करें, क्योंकि यह Anthropic के sandbox में चलेगा।Code-execution और skills beta headers को send करें और skill को write करें ताकि इसके steps local files या local tools पर depend न करें।एक scheduled headless job Agent SDK को use करता है और repo से skill को expect करता है load होना।Enable filesystem sources को settingSources को explicitly set करके ताकि agent project से skills को load करे। Default पर rely न करें, और current default behavior को Agent SDK reference के विरुद्ध confirm करें build time पर।SKILL. md को . claude/skills में place करें एक description के साथ जो review requests को match करता है।Agent को एक API resource के रूप में define करें जो skill को list करता है और managed-agents-2026-04-01 beta header को calls पर set करें। Skill को write करें ताकि इसके steps local files पर depend न करें, क्योंकि यह Anthropic के sandbox में चलेगा।Code-execution और skills beta headers को send करें और skill को write करें ताकि इसके steps local files या local tools पर depend न करें।एक product team चाहता है कि एक ही review-checklist skill एक long-running agent के अंदर चले जो Anthropic host करता है, एक agent ID के माध्यम से sessions में reachable।Enable filesystem sources को settingSources को explicitly set करके ताकि agent project से skills को load करे। Default पर rely न करें, और current default behavior को Agent SDK reference के विरुद्ध confirm करें build time पर।SKILL. md को . claude/skills में place करें एक description के साथ जो review requests को match करता है।Agent को एक API resource के रूप में define करें जो skill को list करता है और managed-agents-2026-04-01 beta header को calls पर set करें। Skill को write करें ताकि इसके steps local files पर depend न करें, क्योंकि यह Anthropic के sandbox में चलेगा।Code-execution और skills beta headers को send करें और skill को write करें ताकि इसके steps local files या local tools पर depend न करें।

Submit Skip for now

स्क्रीन 10: Plugin जो आपकी machine पर install हुआ और सभी दूसरों पर fail हुआ

Watch OutPackaging Workflows·3 min Plugin जो आपकी machine पर install हुआ और सभी दूसरों पर fail हुआ

Setup एक plugin जो cleanly install होता है आपको बताता है कि package correctly assembled था; लेकिन, यह आपको नहीं बताता कि plugin effectively चलेगा, क्योंकि installation और execution अलग चीजें हैं। Install files को place में copy करता है। Execution paths को resolve करता है और variables जो वह files point करते हैं, उस machine के विरुद्ध जहां वे चल रहे हैं। जब एक plugin author अपनी machine की layout को एक skill में bake करता है, install अभी भी हर जगह succeed करता है, लेकिन execution हर जगह fail करता है author के अपने setup को छोड़कर। यह gap occur करता है क्योंकि यह कुछ है जो author नहीं देख सकता।

क्या हुआ एक developer एक deployment workflow skill build किया, इसे एक plugin के रूप में package किया, और locally test किया। Local testing pass हुआ, plugin internal marketplace के माध्यम से team को गया, और हर teammate का install succeed हुआ, लेकिन जिस moment कोई भी teammate skill को run किया, यह fail हुआ। Root cause skill के SKILL. md में बैठा, एक command में जो /Users/alexmorgan/projects/deploy-utils/validate. sh को point करता था। वह directory author की machine पर exist करता था और कहीं और नहीं। Skill एक absolute path को author के home directory में carry करता था, इसलिए हर teammate का run एक file को look करता था जो उनके system पर या skill में included था। एक दूसरा skill एक ही plugin में एक environment variable, DEPLOY_TOKEN, पर lean करता था, जो author ने अपने shell profile में set किया था, और plugin का README कभी इसे mention नहीं किया। तीन teammates ने दो घंटे debugging में spend किए इससे पहले कि वे दूसरी failure को missing variable को trace किया। Plugin incorrectly author की machine को team की machine के रूप में treat करता था, जिसने break cause किया। दोनों failures example में एक ही root cause और एक ही absolute path हैं। यह SKILL. md में plain text के रूप में बैठता है, और एक reviewer जो file को read करता है इसे catch कर सकता है। Environment variable dangerous हो सकता है क्योंकि कुछ भी package में associated dependency को announce नहीं करता, जिसका मतलब है कि skill fine चलता है right up जब तक step जो variable को need करता है, और केवल तब यह fail करता है। यह है कि कैसे यह तीन लोगों को दो घंटे fix करने के लिए cost कर सकता है।

What to Watch Out for कोई भी path reference एक skill, hook command, या plugin component में project root के relative होना चाहिए या base path के लिए एक environment variable use करना चाहिए। $CLAUDE_PROJECT_DIR को use करें project में stored scripts को reference करने के लिए, और ${CLAUDE_PLUGIN_ROOT} को scripts के लिए जो plugin के अंदर bundled हैं, ताकि path correctly resolve हो चाहे किसकी machine यह चलाता है या किस directory से session start होता है। सुनिश्चित करें कि कोई भी scripts, config files, या अन्य assets जो plugin को depend करता है या तो plugin के अंदर bundled हैं या एक shared project location में included हैं, ताकि हर teammate install के बाद एक ही files को access कर सके। हर environment variable को document करें जो plugin को require करता है और इसे install time पर validate करें ताकि एक missing एक immediately surface हो बजाय mid-run के। फिर install को एक clean machine पर test करें distribution से पहले; यह कोई भी issues को catch करेगा जो build machine को hide कर सकता है।

स्क्रीन 11: Checkpoint 4: broken plugin definition को fix करें

CheckpointPackaging Workflows·4 min Checkpoint 4: broken plugin definition को fix करें अभी try करें। निम्नलिखित SKILL. md author की machine पर काम करता है लेकिन fail करेगा जब एक teammate project को clone करता है और plugin को install करता है। Single defect को select करें, फिर तीन options से सही fix को select करें। --- name: deploy-validate description: Validates a deployment configuration before release. ---

Steps

• Run the validation script: /Users/alexmorgan/projects/deploy-utils/validate. sh absolute path
• If the script exits with a non-zero code, report the error to the developer.
• If validation passes, confirm the deployment configuration is safe to proceed.

Part 1 · Defect कौन सा है? ASkill name plugin name को match नहीं करता है।BDescription बहुत short है model के लिए match करने के लिए।CAbsolute path /Users/alexmorgan/projects/deploy-utils/validate. sh step 1 में।DStep 2 को developer को report करना चाहिए, user को नहीं। Part 2 · सही fix कौन सा है? AProject root से CLAUDE_PROJECT_DIR का उपयोग करके script को reference करें, ताकि यह resolve हो चाहे project कहां clone हो।BPath को एक अन्य absolute path के साथ replace करें जो एक shared network drive को point करता है।CPath को एक home-directory shortcut के साथ replace करें: ~/projects/deploy-utils/validate. sh।DStep 1 को remove करें ताकि skill अब एक external script को call न करे।

Submit Skip for now

स्क्रीन 12: एक MCP server को building और configuring करना: transport, scope, और GitHub server

TeachingMCP Servers·21 min एक MCP server को building और configuring करना: transport, scope, और GitHub server पहले sections ने plugins को packaging layer के रूप में introduce किया जो skills, hooks, subagents, और MCP servers को एक single installable unit में bundle करता है। यह section further explain करता है कि MCP server bundles क्या हैं और कैसे उन्हें build करें। एक MCP server build करते समय, एक पहले decisions में से एक appropriate transport mechanism को determine करना है और server के scope को define करना है।

एक MCP server क्या है और यह एक tool को directly wire करने से कैसे अलग है? जब एक tool को directly एक application में wire करते हैं, आप tool के schema को define करने के लिए responsible हैं और इसकी functionality। दोनों उस application के code में रहते हैं। अगर तीन अलग applications को एक ही external service को access करने की need है, प्रत्येक एक अपना integration maintain करता है। Model Context Protocol, या MCP, tool definitions को individual applications से separate करता है और उन्हें एक process में turn करता है जिसे server कहा जाता है। एक MCP server एक process है जो tools, resources, और prompts को expose करता है जो MCP clients use कर सकते हैं। Claude Code में एक built-in MCP client है। जब आप एक MCP server को connect करते हैं, Claude Code tools को discover करता है जो यह provide करता है और उन्हें एक session के दौरान invoke कर सकता है। एक MCP server के साथ, आप capability को एक बार build करते हैं, और हर MCP client जो इसे connect करता है integration को re-implement किए बिना access पाता है।

MCP servers भी resources और prompts को expose करते हैं एक MCP server tools, resources, और prompts को expose करता है। हमने पहले से ही tools के बारे में सीखा है: actions जो model call कर सकता है। अन्य दो cases को cover करते हैं जहां एक tool call आपको जो need है नहीं देगा। एक resource read-only data है जो server expose करता है client को fetch करने के लिए और directly context में place करने के लिए, बजाय model को एक tool call करने के लिए इसे get करने के लिए। Client एक resource को इसके address द्वारा request करता है, और server data को return करता है। Resources दो forms में आते हैं: एक direct resource एक fixed address है data के लिए जो कोई parameters नहीं लेता है, जैसे एक available documents की list, और एक templated resource एक parameter को address में put करता है, जैसे एक document address जो एक document identifier लेता है। एक resource को reach करें जब आप known data को turn के start से context में होना चाहते हैं। आप यह चाहते हैं जब एक resource को directly pull करना cheaper और अधिक predictable है एक tool call को use करने से इसे get करने के लिए। Resource support MCP clients में vary करता है; verify करें कि आपके client के पास resources को context में inject करने के लिए एक mechanism है इससे पहले कि आप इस pattern पर rely करें। एक prompt एक pre-written instruction template है जो server expose करता है ताकि एक client एक vetted prompt को name से invoke कर सके बजाय हर user को अपना लिखने के लिए ask करने के। एक user पहले से ही अपने अपने words में अधिकांश tasks को ask कर सकता है, इसलिए एक prompt useful है जब specific wording की need है: एक task जहां एक carefully built instruction materially better results produce करता है जो भी एक user type करेगा, और जहां आप चाहते हैं कि हर client एक ही quality को get करे। Instruction को server पर package करना मतलब है कि prompt एक जगह में maintain किया जाता है और हर जगह reused होता है जहां server connected है।

Transport: कैसे Claude Code server को talk करता है Transport MCP client और MCP server के बीच communication channel है। सही transport depend करता है कि server कहां चलता है। प्रत्येक tab के लिए select करें कि यह क्या है और कब use करें।

stdio HTTP SSE

stdio server को एक local process के रूप में client के समान machine पर चलाता है। Client server को एक subprocess के रूप में launch करता है और standard input और output के माध्यम से communicate करता है। यह एक local tool, एक personal script, या एक development server के लिए सही choice है जो आप अपनी machine पर चलाते हैं। यह एक server के लिए काम नहीं करता जो आप अपनी team में share करना चाहते हैं या remotely host करना चाहते हैं।

HTTP recommended form of transport है किसी भी server के लिए जो locally नहीं चलता है। यह एक standard HTTP connection पर connect करता है और servers को एक अलग machine पर hosted support करता है। जब आप एक HTTP server को register करते हैं, आप URL provide करते हैं और client network पर connect करता है। Shared team servers और hosted integrations HTTP use करते हैं।

SSE (Server-Sent Events) एक older means of transport है जो current HTTP transport से पहले आता है। यह current HTTP transport द्वारा superseded हो गया है और new servers के लिए अब recommended नहीं है। अगर आप SSE को existing configuration या documentation में encounter करते हैं, इसे एक legacy option के रूप में treat करें बजाय एक current recommendation के।

Context cost प्रत्येक connected MCP server tool definitions को contribute करता है जो context window में load होते तो occupy करते। Default द्वारा, Claude Code इन definitions को defer करता है बजाय उन्हें upfront load करने के, और यह एक search step को use करता है relevant tools को discover और load करने के लिए केवल जब एक task उन्हें call करता है। केवल tools जो called होते हैं context में enter करते हैं। एक opt-in mode tool definitions को upfront load करता है जब वे roughly 10 percent of context window के अंदर fit करते हैं, केवल तब defer करते हैं जब वह limit exceed होता है। किसी भी तरीके से, केवल servers को connect करना जो आपको need है हर request को lean रखता है, क्योंकि हर connected server definitions के pool को add करता है जो model को account करना है।

Prompt caching: reusable requests के लिए एक बार pay करना Context-cost problem जो आपने अभी MCP servers के साथ देखा है दोनों एक cost और window dimension है। हर request अपने input को scratch से reprocess करता है, parts सहित जो last request पर identical थे, जिसका मतलब है कि आप हर बार same stable content को reprocess करने के लिए pay करते हैं। Prompt caching आपको एक ही stable content के लिए दो बार pay करने से stop कर सकता है। Caching processing work को store करता है जो एक stable prefix पर किया गया है आपके request का ताकि एक follow-up request इसे reuse कर सके बजाय same tokens को reprocess करने के। पहला request prefix को cache में write करता है, और follow-up requests identical content को send करते हैं cache point तक एक fraction of cost पर। Content exactly match करना चाहिए: एक single changed character cache point से पहले उस cache को invalidate करता है और एक fresh write को force करता है। यह है कि कैसे strongest candidates caches के लिए request के parts हैं जो rarely change करते हैं, जैसे एक long system prompt, एक large set of tool definitions, या एक reference document जो आप कई questions के बारे में ask करते हैं। आप caching को turn on करते हैं एक cache breakpoint को marking करके; कोई global setting नहीं है जो caching को turn on करता है। Messages API में आप एक cache_control field को type ephemeral के साथ add करते हैं last block को जो आप cache करना चाहते हैं; यह सब कुछ को cache करता है up to और including वह block। आप up to चार breakpoints को place कर सकते हैं। Request एक fixed order में process किया जाता है tools, system prompt, और messages का, इसलिए एक breakpoint tools के बाद tool definitions को cache करता है जबकि messages को dynamic रखता है। Cache का एक time limit है। Default cache lifetime पांच minutes है last read से। एक opt-in one-hour lifetime available है एक ttl को 1h पर set करके breakpoint पर। Five-minute default एक back-and-forth model को suit करता है जहां requests हर कुछ minutes आते हैं, चूंकि हर read clock को reset करता है। One-hour option एक workload को suit करता है longer gaps के साथ requests के बीच, जैसे एक agent जो steps के बीच pause करता है, जहां five-minute window expire हो सकता है अगले request से पहले। अगर window अगले request से पहले expire होता है, आप left होते हैं write cost को फिर से pay करने के लिए कोई read benefit के बिना। कृपया note करें कि caching केवल एक minimum token threshold के ऊपर apply होता है (1,024 tokens most current models के लिए) इसलिए short prompts को cache नहीं किया जाएगा यहां तक कि अगर एक breakpoint set हो।

Retrieval-augmented generation: कैसे Claude केवल knowledge को pull करता है जो एक request को need करता है Context-cost problem जो आपने अभी MCP servers के साथ देखा है एक ही है जो एक large body of reference material create करता है। एक model सब कुछ को read करता है अपने context window में हर request के लिए, इसलिए अधिक documents आप upfront load करते हैं, अधिक context use होता है, और कम room बचता है काम के लिए। Retrieval-augmented generation, usually shortened to RAG, pattern है जो यह resolve करता है। हर document को context में load करने के बजाय, system material को context window के बाहर store करता है, parts को find करता है जो current request के लिए most relevant हैं, और केवल वह parts को model को supply करता है request time पर। Model फिर अपना answer generate करता है उस retrieved slice से बजाय पूरी library से। RAG दो forms में आता है: Classical RAG upfront hard work करता है। इससे पहले कि कोई question ask करे, source material को chunks में split किया जाता है, और प्रत्येक chunk को एक set of numbers (called एक embedding) में convert किया जाता है जो इसके meaning को mathematically capture करता है। वह numbers एक database में store किए जाते हैं। जब एक user एक question ask करता है, system question को same type of numbers में convert करता है, फिर find करता है कि कौन से chunks most similar numbers हैं। इसे एक librarian की तरह think करें जो, library open होने से पहले, पहले से ही हर book को read किया है और हर chapter के लिए एक precise summary card लिखा है, इसलिए जब आप एक question के साथ arrive करते हैं, वे right cards को instantly pull कर सकते हैं। Agentic search upfront indexing को completely skip करता है। कोई pre-built database नहीं है। Instead, model figure out करता है कि इसे क्या need है जिस moment आप ask करते हैं, फिर जाता है और fetch करता है: live sources को search करता है, documents को on demand read करता है, results को pull करता है जैसे task unfolds होता है। इसे एक researcher की तरह think करें जो, जब आप एक question ask करते हैं, जाता है और answer को find करता है themselves बजाय pre-prepared cards को consult करने के। आप पहले से ही agentic search को encounter किया हो सकता है बिना इसके name को जाने। Claude Code में, जब आप कई external tools (MCP servers) को connected हैं, Claude हर tool definition को upfront load नहीं करता; यह एक बार में hold करने के लिए बहुत अधिक होगा। Instead, यह केवल tools को discover और load करता है जो current task के लिए need करता है। Claude. ai Projects एक ही तरीके से uploaded documents के लिए काम करता है: जब एक project का knowledge base active window में fit करने के लिए बहुत बड़ा grow करता है, यह केवल document sections को surface करता है जो हर question के लिए most relevant हैं बजाय सब कुछ को load करने के। दोनों approaches एक ही fundamental चीज करते हैं; वे दोनों एक relevant slice of material को find करते हैं और generate करते हैं। Difference timing है: classical RAG slice को find करता है एक advance में built index के विरुद्ध matching करके; agentic search इसे find करता है need के moment पर searching करके। Retrieval के दो properties को समझने लायक हैं इससे पहले कि आप इसे reach करें:

यह scale करता है। जैसे आपका source material grow करता है, हर request की cost flat रहती है, क्योंकि model केवल कभी slice को receive करता है जो उस question के लिए relevant है, पूरी library नहीं। एक knowledge base thousands of documents को grow कर सकता है और एक single question अभी भी roughly same amount of text को pull back करता है। यह है कि कैसे retrieval scale पर काम करता है: source को grow करते रहना चाहिए बिना request को grow करने के। यह केवल जितना अच्छा है जितना यह find करता है। Model slice को reason करता है जो यह receive करता है। अगर retrieval step document को miss करता है जो आपको need था, model कभी इसे नहीं देखता है। यह मतलब है कि कैसे आप अपनी material को organize करते हैं important है: files जिनके vague names हैं ("notes_final_v3. pdf") harder हैं surface करने के लिए जो files descriptive names हैं ("Q3 refund policy, updated August 2024")। Related files को grouping करना भी help करता है। Good retrieval एक well-organized source के साथ start होता है।

Configuration scope: कौन server को load करता है Scope determine करता है कि कौन से users और projects server को load करते हैं। प्रत्येक scope एक अलग configuration location को correspond करता है।

Local scope server configuration को ~/. claude. json में store करता है current project के path के तहत। यह केवल project को apply करता है जो आप currently काम कर रहे हैं और teammates के साथ share नहीं किया जाता है। यह सही scope है एक server के लिए जो एक specific project context को tied है जो आप repository को commit करने के लिए ready नहीं हैं, या tooling के लिए जो केवल एक project में sense बनाता है। User scope server configuration को आपकी personal Claude settings में store करता है और इसे सभी आपकी projects में available बनाता है। यह अभी भी personal है: teammates इसे नहीं देखते, और यह repository में write नहीं किया जाता है। यह सही scope है एक personal utility के लिए जो आप हर project में use करते हैं, जैसे एक local database tool या एक script जो आप depend करते हैं चाहे कौन सा codebase आप काम कर रहे हैं। Project scope server configuration को एक . mcp. json file में write करता है repository के root पर। जब वह file version control को commit किया जाता है, हर किसी को जो repository को clone करता है एक ही server को automatically get करता है। यह सही scope है एक server के लिए जो पूरी team को access कर सकता है, क्योंकि configuration code के साथ travel करता है। एक चीज को keep in mind: एक project-scoped server हर teammate की machine से चलता है। एक stdio server के लिए, committed configuration launch command को store करता है, और हर clone एक अपना local subprocess को spawn करता है, इसलिए हर teammate को runtime को need है (जैसे Node एक npx-launched server के लिए) locally installed। Enterprise scope एक centrally managed configuration के माध्यम से deploy करता है जो एक administrator द्वारा controlled है। Administrators servers को सभी users को organization में push कर सकते हैं बिना individual configuration steps के। यह सही scope है shared internal services, security tooling, या कोई भी server के लिए जो organization में present होना चाहिए और individual developers को configure करने के लिए left नहीं किया जा सकता।

Permission rules जो एक single MCP tool को target करते हैं, पूरे server को नहीं एक server को connect करना इसकी पूरी tool list को expose करता है, लेकिन आप rarely चाहते हैं कि agent हर एक को बिना checking के reach करे। Permission layer से permission-modes section MCP tools को extend करता है, और rules एक individual tool को name कर सकते हैं बजाय पूरे server के। एक MCP tool को identify किया जाता है एक permission rule में इसके server और tool name द्वारा: mcpservertool। एक allow rule mcpgithubcreate_issue पर उस एक tool को run करने देता है बिना एक prompt के जबकि GitHub server पर हर अन्य tool अभी भी prompt करता है। एक deny rule एक write-capable tool पर इसे block करता है जबकि read-only tools एक ही server पर available रहते हैं। यह है कि कैसे आप एक broad server को connect करते हैं लेकिन agent को एक narrow slice के अंदर रखते हैं जो यह कर सकता है। एक deny एक tool पर एक allow को server पर override करता है। API MCP connector एक अन्य useful control है। अगर आप server को API MCP connector के माध्यम से reach कर रहे हैं, एक mcp_toolset object आपको एक enabled flag को per tool set करने देता है। यह enabled flag आपको एक server को register करने देता है लेकिन केवल specific tools को expose करता है जो आप चाहते हैं कि model देखे। एक permission rule decide करता है कि क्या एक exposed tool run कर सकता है; enabled flag decide करता है कि क्या model tool को देखता है। पहला एक governance control है, दूसरा एक context-cost और scope control है। ये controls अक्सर एक साथ use किए जाते हैं। हमेशा exact rule syntax और connector beta header को documentation के विरुद्ध verify करें publishing से पहले।

GitHub MCP server: transport, scope, और authentication एक concrete example में GitHub MCP server एक remote server है जो GitHub द्वारा maintained है जो tools को expose करता है repository management के लिए including reviewing pull requests, opening issues, searching code, और अधिक। Connection process के माध्यम से walking करके, आप देख सकते हैं कि कैसे transport, scope, और authentication एक server में एक साथ काम करते हैं जो किसी और द्वारा maintained है। GitHub server HTTP transport use करता है क्योंकि यह remotely GitHub द्वारा hosted है। आप इसे server URL provide करके register करते हैं, और client network पर connect करता है। Scope के लिए, project scope को choose करें जब आपकी पूरी team को एक ही repository tooling को access करने की need है, और local scope जब केवल आपको server को access करने की need है। GitHub MCP server के लिए authentication एक Personal Access Token use करता है। आप token को GitHub में generate करते हैं, फिर इसे अपने MCP configuration में request header के Bearer token के रूप में pass करते हैं। Token को एक environment variable के माध्यम से supply किया जाना चाहिए और configuration file में referenced होना चाहिए। यह . mcp. json को inline commit नहीं किया जाना चाहिए, क्योंकि एक token जो directly एक committed file में written है repository history में enter करता है और file को एक later commit में overwrite करके remove नहीं किया जा सकता। OAuth एक अलग authentication mechanism है, servers द्वारा use किया जाता है जहां service individual users को एक browser-based sign-in flow के माध्यम से authenticate करता है। Linear एक server का एक example है जो इस pattern को use करता है। जब आप एक Linear MCP server को पहली बार connect करते हैं, client Linear के sign-in page को redirect करता है। आप access को approve करने के बाद, एक token issue किया जाता है और automatically store किया जाता है। कोई credential को copy या hand से manage नहीं किया जाता है। OAuth सही pattern है किसी भी integration के लिए जहां service का authorization model user identity को tied है। GitHub MCP एक service credential use करता है जो आप generate और store करते हैं; Linear MCP एक sign-in flow को initiate करता है जो credential को आपके लिए handle करता है। दोनों remote HTTP servers हैं, और दोनों एक ही transport और scope logic को follow करते हैं। Authentication step वह है जो differ करता है।

MCP setup reference नीचे table प्रत्येक deployment context के लिए transport और scope decisions को capture करता है।

ContextTransportScopeConfig locationSecrets handling

Personal local tool (केवल आपकी machine पर चलता है)stdioLocal~/. claude. json (per-project entry)केवल environment variables। कभी भी config file में नहीं। Shared team server (सभी teammates एक ही service को connect करते हैं)HTTPProject (. mcp. json). mcp. json repo root को committedOAuth या env variables। API keys को कभी भी . mcp. json को commit नहीं किया जाना चाहिए। Personal experiment (share करने के लिए ready नहीं)stdio या HTTPLocalPersonal Claude settingsकेवल environment variables। Organization-wide deployment (admin-managed)HTTPEnterpriseManaged settings (admin-controlled)Secrets को administrator द्वारा manage किया जाता है। Config को override करने के लिए locked।

Cost · Complexity · Risk Cost: प्रत्येक connected MCP server अपने tool definitions को context window में add करता है। अधिक servers connected, अधिक हर request। केवल servers को load करें जो एक given task को need करता है। Complexity: Transport और scope independent decisions हैं, लेकिन वे interact करते हैं: एक stdio server को project-scoped नहीं किया जा सकता sharing के लिए क्योंकि यह केवल एक machine पर चलता है। Transport को match करें जहां server चलता है scope को choose करने से पहले। Risk: एक API key को . mcp. json के अंदर commit करना इस section में most common mistake है। Key repository history में travel करता है जहां later rotate करना exposure को remove करने के लिए sufficient नहीं है। Secrets environment variables में जाते हैं। Configuration file केवल server address को hold करता है।

अच्छी तरह से handles करता हैएक reusable integration जो आप multiple Claude Code sessions में use करना चाहते हैं और team के साथ share करना चाहते हैं, जहां capability stable enough है एक separate process के रूप में maintain करने के लिए। GitHub server एक great example है। Cost या complexity को add करता हैTeams जो environment secrets को carefully manage नहीं कर रहे हैं को closely watched होना चाहिए। MCP servers को add करना secret को mishandle किए जाने के लिए जगहों की संख्या को increase करता है। Risk . mcp. json file पर concentrate करता है, जो repository को commit किया जाता है। एक अलग approach useएक one-off task जहां tool logic directly codebase में रह सकता है और sessions या applications में reused होने की need नहीं है। एक single-project integration के लिए एक person द्वारा use किया जाता है, tool को directly API call में wire करना एक server को maintain करने से simpler हो सकता है।

स्क्रीन 13: API key जो configuration file के साथ repository में travel किया

Watch OutMCP Servers·4 min API key जो configuration file के साथ repository में travel किया

Setup Server काम कर रहा था, team को एक shared setup की need था, और authentication method को clean up करना कुछ ऐसा लगा जो आप handoff के बाद कर सकते हैं। वह shortcut एक temporary hardcoded API key को एक shared credential exposure में turn किया जिस moment configuration file को commit किया गया।

क्या हुआ एक developer एक data warehouse MCP server को एक service account API key का उपयोग करके connect किया। Server को quickly काम करने के लिए setup के दौरान, key को directly . mcp. json configuration file में place किया गया। Plan यह था कि इसे एक environment variable में move करें sharing से पहले setup को team के साथ। Developer . mcp. json को project repository में commit किया ताकि teammates एक ही server को connect कर सकें repository को clone करके, और key committed के साथ। 48 घंटों के अंदर, तीन teammates ने repository को clone किया, और एक CI pipeline ने एक fresh clone को trigger किया। Key अब चार जगहों में था: local machine, repository history, तीन teammate machines, और CI runner की file system। यह realize करने के बाद, developer key को एक environment variable में move किया, . mcp. json को update किया, और corrected file को commit किया। लेकिन, key अभी भी commit history में था, और service account को rotate किया जाना था। Rotation ने दो external services को break किया जो एक ही key के साथ configure किए गए थे, और यह fix करने के लिए तीन घंटे का काम लिया। Corrected . mcp. json एक environment variable reference का उपयोग करता है एक inline value के बजाय: Before (do not use) { "type": "http", "url": "https://warehouse. internal/mcp", "headers": { "Authorization": "Bearer sk-abc123... " ............. inline credential } } After (correct) { "type": "http", "url": "https://warehouse. internal/mcp", "headers": { "Authorization": "Bearer ${WAREHOUSE_MCP_TOKEN}" ............ env variable reference } }

What to Watch Out for API keys जो एक configuration file को commit किए जाते हैं repository history को commit किए जाते हैं। File को एक later commit में overwrite करना key को history से remove नहीं करता; यह केवल इसे current version से remove करता है। कोई भी credential जो एक committed file में inline written है compromised के रूप में treat किया जाना चाहिए और rotate किया जाना चाहिए। सही pattern value को एक environment variable में put करना है और configuration file में variable को reference करना है। Agent को credential values को directly committed files को write करने से prevent करने के लिए, दो layers को use करें। पहला, एक convention instruction को CLAUDE. md में add करें stating कि credential values को कभी भी . mcp. json को inline write नहीं किया जाना चाहिए। यह rule को model को signal करता है हर session के दौरान। दूसरा, उस instruction को एक PreToolUse hook के साथ back करें जो write और edit operations को . mcp. json के विरुद्ध inspect करता है patterns के लिए जो inline credential values की तरह look करते हैं और operation को block करने के लिए code के साथ exit करता है अगर एक detect किया जाता है। CLAUDE. md instruction intent को communicate करता है; hook इसे deterministically enforce करता है चाहे model क्या decide करे। यह एक ही hook-versus-instruction distinction है जो durable project context section में covered है: एक instruction CLAUDE. md में inconsistently follow किया जा सकता है जब file grow करता है या context shift करता है, और एक hook हर relevant tool call पर fire करता है बिना exception के।

स्क्रीन 14: Checkpoint 5: transport और scope को हर deployment scenario में match करें

CheckpointMCP Servers·4 min Checkpoint 5: transport और scope को हर deployment scenario में match करें अभी try करें। नीचे दिए गए हर deployment scenario के लिए, सही transport और scope को select करें। Labelled configuration snippets provide किए गए हैं। एक local SQLite query tool जो आप केवल अपनी development machine पर use करते हैं।HTTP + Project (. mcp. json)HTTP + Enterprise (managed settings)stdio + Localstdio or HTTP + Localएक code search service hosted आपकी company की infrastructure पर जो पूरी engineering team को access करना चाहिए।HTTP + Project (. mcp. json)HTTP + Enterprise (managed settings)stdio + Localstdio or HTTP + Localएक experimental web-scraping server जो आप इस week test कर रहे हैं एक specific repository के विरुद्ध, share करने के लिए ready नहीं।HTTP + Project (. mcp. json)HTTP + Enterprise (managed settings)stdio + Localstdio or HTTP + Localएक security-scanning server जो आपकी organization की IT team को हर developer के Claude Code installation को deploy करने की need है।HTTP + Project (. mcp. json)HTTP + Enterprise (managed settings)stdio + Localstdio or HTTP + Local

Submit Skip for now

स्क्रीन 15: Claude को enterprise systems से जोड़ना और इसे securely authenticate करना

TeachingEnterprise Integration·18 min Claude को enterprise systems से जोड़ना और इसे securely authenticate करना पहले section ने cover किया कि कैसे एक MCP server को build करें और इसके transport और scope को configure करें। एक server के लिए जो केवल आपकी team द्वारा एक internal project पर use किया जाता है, GitHub personal-access-token example authentication pattern को cover करता है। यह section cover करता है कि क्या change करता है जब integration को एक regulated environment में काम करना चाहिए: identity, secret-handling, और data-residency questions जो एक prototype usually ignore करता है production deployment में requirements बन जाते हैं।

क्यों enterprise integration एक working prototype से अलग है एक prototype जो Claude को एक internal service से connect करता है एक question को answer करता है: क्या connection काम करता है? एक production enterprise integration को कई additional questions को answer करना चाहिए: Model किसके रूप में act कर रहा है, और क्या वह identity auditable है? यह कौन सा data access कर सकता है, और जहां वह data organization को leave करता है? क्या एक administrator configuration को lock कर सकता है ताकि कोई भी individual developer authentication setup को change न कर सके? क्या access को एक तरीके से log किया जा सकता है जो एक compliance audit को satisfy करता है? ये questions enterprise software के लिए नए नहीं हैं; उनके पास एक ही identity, access, और compliance requirements हैं जो किसी भी external system को regulated data को touch करने के लिए apply होते हैं। उन्हें integration design के part के रूप में treat करना वह है जो एक demo को कुछ deployment-ready से अलग करता है।

Authentication patterns by service type सही authentication mechanism depend करता है कि service कहां चलता है और कौन सा identity model यह support करता है। प्रत्येक tab के लिए select करें pattern और कब use करें।

Remote services with user identity Remote services with service identity Local services with file-system accesss

OAuth use करें। MCP server एक 401 Unauthorized को return करता है signal करने के लिए कि authentication required है। Client एक browser-based sign-in flow को initiate करता है। User approve access करने के बाद, एक token issue किया जाता है और store किया जाता है। कोई भी एक secret को hand से copy नहीं करता; OAuth flow expected pattern है cloud services, SaaS tools, और किसी भी integration के लिए जहां user की identity authorization model का part है। Linear MCP server पहले से ही इस module में use करता है यह pattern; GitHub server, contrast में, एक personal access token के साथ authenticate करता है एक header के रूप में pass किया जाता है।

एक API key को एक environment variable के माध्यम से pass करें। Key service account को identify करता है। Key को कभी भी एक configuration file को commit नहीं किया जाना चाहिए; यह environment में रहता है execution के point पर। एक CI pipeline के लिए Agent SDK का उपयोग करते हुए, key को एक secret के रूप में inject किया जाता है pipeline runner द्वारा, code में baked नहीं।

stdio transport बिना network authentication के। Security boundary file-system permission model है। एक denying rule settings files में governance layer है।

Managing credential itself authentication का अन्य half है। एक credential कभी भी configuration के साथ travel नहीं करता है जो इसे reference करता है: config file केवल एक variable reference को hold करता है, और value एक environment variable या एक managed secret store में रहता है execution के point पर inject किया जाता है। Service-account keys को एक secret manager में store करें बजाय files में, और उन्हें एक schedule पर rotate करें और immediately किसी भी suspected exposure के बाद। अगर एक key leak होता है, आपको इसे rotate करना चाहिए, लेकिन याद रखें, आप एक value को rotate नहीं कर सकते जो committed code में baked है। प्रत्येक credential को narrowest access को scope करें जो इसके task को need करता है, इसलिए एक compromised key केवल reach करता है जो वह एक integration को require करता था।

Managing credential के बाद authentication: storage, rotation, और separation from config सही authentication pattern को choose करना connection को establish करता है, लेकिन इसे keep करना एक अलग problem है। MCP key leak mentioned पहले एक bad choice of auth method नहीं था, यह एक credential था जो गलत जगह में रहता था और एक बार spread होने के बाद clean up नहीं किया जा सकता था। तीन practices इसे होने से रखते हैं, और प्रत्येक एक specific तरीके को address करता है एक credential expose हो जाता है। पहली practice separation है: एक credential कभी भी configuration के साथ travel नहीं करता है जो इसे reference करता है। Configuration file एक variable reference को hold करता है, और value कहीं रहता है file नहीं करता है। यह rule है जो leaked-key failure को break किया। कारण यह matters mechanical है: configuration files को commit, share, और clone किया जाता है। एक value जो inline written है हर एक के साथ ride करता है उन copies में, और एक committed value repository history में एक तरीके से enter करता है जो overwriting remove नहीं करता है। अगर आप value को file से बाहर रखते हैं, तो file share करने के लिए safe रहता है। दूसरी practice है जहां value एक बार file से बाहर जाता है। एक value के लिए जो केवल एक machine पर या एक pipeline run में रहता है, एक environment variable inject किया जाता है execution के point पर enough है: CI runner इसे एक secret के रूप में set करता है, configuration इसे name से read करता है, और कुछ भी disk को write नहीं किया जाता है। एक value के लिए जो कई services या लोगों को need है, एक secret store better है। एक secret store एक managed service है जो credentials को hold करता है, authorized callers को runtime पर return करता है, और record करता है कि किसने क्या read किया। यह value को centralize करता है इसलिए एक single rotation हर consumer को एक बार update करता है, और यह copies को remove करता है जो accumulate करते हैं जब हर service अपना credential को अपनी file में keep करता है। एक environment variable को reach करें जब secret local और short-lived हो, और एक secret store जब secret shared हो या audit किया जाना चाहिए। तीसरी practice rotation है: एक credential को एक नए के साथ replace करना एक schedule पर और immediately किसी भी suspected exposure के बाद। Rotation एक leaked key के लिए एकमात्र appropriate response है, क्योंकि एक key जो expose हो गया है secret नहीं बनाया जा सकता। आपको एक नया issue करना चाहिए। यह है कि कैसे inline-credential pattern इतना costly है: एक value जो committed code में baked है हर consumer को hardcoded करता है इसे break करता है change पर। एक credential जो एक secret store या एक environment variable से read किया जाता है code को touch किए बिना rotate करता है, क्योंकि code value को name से reference करता है और name नहीं change करता है जब value के पीछे करता है। दो habits rotation को cheaper बना सकते हैं: प्रत्येक credential को narrowest access को scope करें जो इसके task को need करता है, इसलिए एक key जो leak होता है केवल reach करता है जो वह integration को require करता था। हर service को record रखें जो हर credential को use करता है, इसलिए एक rotation इसके consumers को surface नहीं करता है। Leaked-key failure पहले module में एक committed file को एक inline credential को identify किया। इससे prevent करने के लिए, ये तीन practices को apply करें: separation value को file से बाहर रखता है, एक secret store या environment variable value को एक home देता है जो file share नहीं करता है, और rotation recovery में help कर सकता है केवल जब पहले दो को hold किया जाता है।

क्या regulated industries add करते हैं working authentication के top पर एक financial services या healthcare customer "क्या authentication काम करता है? " से अधिक questions ask करता है। वे ask करते हैं कि data कहां process किया जाता है, कैसे access को log किया जाता है, और क्या एक administrator configuration को lock कर सकता है ताकि एक developer authentication setup को change न कर सके एक audit window के दौरान। Enterprise managed configuration पहले sections से अंतिम question को answer करता है: एक administrator-deployed server configuration जो individual users द्वारा override नहीं किया जा सकता मतलब है कि auth setup organization में consistent है और हर developer की settings file को correct होने पर depend नहीं करता है। Audit hooks logging question को answer करते हैं: एक PostToolUse hook जो हर tool call को log करता है और इसके parameters एक audit store को compliance review को need करने वाली record को provide करता है। Hook deterministically हर call के लिए fire करता है, model के बावजूद क्या decide करता है, और log कुछ नहीं है जो model skip कर सकता है। Data residency processing question को answer करता है: एक server configured एक HTTP endpoint के साथ एक specific region में, एक platform deployment के साथ combined जो processing को उस region में pin करता है, एक compliance reviewer को एक checkable answer देता है कि data कहां जाता है। यह है कि कैसे infrastructure requirement और platform choice पहले module से audit time पर matter करते हैं, केवल build time पर नहीं।

Code modernization: पूरे module को legacy change को apply करना Code modernization एक useful test case है सब कुछ के लिए जो यह module cover करता है, क्योंकि यह concentrate करता है risks पर जो हर tool को manage करने के लिए design किया गया था। Large-scale changes एक unfamiliar legacy codebase को high blast radius, unpredictable dependencies, और limited reversibility को carry करते हैं। इस module से tools प्रत्येक उन risks को directly address करते हैं जब आप उन्हें काम से पहले apply करते हैं। Explore, plan, और code loop core workflow है इस type के काम के लिए। Plan mode agent को read-only explore phase में hold करता है जबकि आप इसके changes में confidence build करते हैं। आप proposed edits को review कर सकते हैं, identify कर सकते हैं कि कुछ भी paths को touch करता है जो आप expect नहीं करते, और push back कर सकते हैं एक भी file को modify करने से पहले। Hooks guardrails को enforce करते हैं जो specific paths को edits को prevent करते हैं most sensitive phases के दौरान। CLAUDE. md new target patterns के लिए conventions को carry करता है, इसलिए agent उन्हें consistently apply करता है पूरे scope के changes में बजाय surrounding code में legacy patterns को drift करने के। एक responsible scoping approach high-risk work के लिए session से पहले तीन questions को address करता है।

Blast radius क्या है अगर कुछ गलत जाता है: कौन से systems code को depend करते हैं जो change किया जा रहा है, और क्या downstream break करता है अगर एक edit गलत है? Changes कैसे audit किए जाते हैं: क्या एक PostToolUse hook हर tool call को log करता है, और क्या वह log satisfy करता है जो भी review करने की need है कि agent क्या touch किया? कौन प्रत्येक phase को approve करता है अगले से पहले शुरू होने से पहले? Plan mode exploration और execution के बीच boundary को enforce करता है, लेकिन approval decision itself आपका है define और document करने के लिए काम से पहले।

ये questions modernization work के लिए specific नहीं हैं। वे किसी भी high-risk agentic task को apply करते हैं। Code modernization उन्हें clearly surface करता है क्योंकि scope large है, codebase unfamiliar है, और cost गलत होने की high है।

Authentication और integration checklist नीचे table प्रत्येक service type के लिए key decisions को name करता है।

Service typeAuth methodWhere secrets liveWhat gets loggedWho can lock the config

Remote with user identity (SaaS, cloud)OAuthToken issued by OAuth provider और client द्वारा store किया जाता है।PostToolUse hook to audit log।Administrator via enterprise managed settings। Remote with service identity (internal API)API key in environment variableEnvironment only। Committed config में कभी नहीं।PostToolUse hook to audit log।Administrator via enterprise managed settings। Local (file system, local DB)File-system permissionsकोई credential needed नहीं। Deny rules path access को enforce करते हैं।PostToolUse hook to audit log।Deny rules in enterprise managed settings।

Cost · Complexity · Risk Cost: OAuth flows एक one-time setup step को add करते हैं per user per service। API key management एक secret rotation process को require करता है, और audit logging through PostToolUse hooks हर tool call को एक small overhead add करता है। Complexity: Regulated environments requirements को add करते हैं जो एक prototype में appear नहीं करते। उन्हें identify करना scoping के दौरान discipline है जो integrations को schedule पर रखता है। Risk: Risk concentrate करता है जब एक prototype production की ओर move करता है। एक system जो hardcoded credentials को use करता है, कोई audit log नहीं है, और centrally locked नहीं किया जा सकता एक regulated customer के security review को pass नहीं करेगा। Fixes hard नहीं हैं, लेकिन उन्हें review से पहले attention की need है।

अच्छी तरह से handles करता हैकोई भी integration जो data को touch करता है एक regulated customer care करता है, जहां same tooling पहले से ही enterprise managed settings और audit hooks को support करता है। Scoping security requirements को upfront add करना little overhead करता है और integration को final review पर stall होने से prevent करता है। Cost या complexity को add करता हैTeams जो OAuth flows या enterprise secrets management से familiar नहीं हैं। ये patterns most regulated organizations में security या IT teams के साथ coordination को require करते हैं, और timeline को account करने की need है। एक अलग approach useएक prototype या proof of concept जो कभी production data को नहीं देखेगा। पूरा enterprise integration checklist एक demo-only integration के लिए warranted नहीं है लेकिन environment variable habit को apply करना secrets के लिए कुछ नहीं cost करता है और एक good practice है।

स्क्रीन 16: OAuth connection जो staging में काम किया और production में fail हुआ

Watch OutEnterprise Integration·3 min OAuth connection जो staging में काम किया और production में fail हुआ

Setup OAuth connection end to end staging में काम किया, इसलिए production को move करना एक routine cutover लगा। जो team को miss हुआ वह यह है कि OAuth redirect URIs per host को register किए जाते हैं और अक्सर per environment governed होते हैं, इसलिए staging में success production host को authorize नहीं किया गया था complete करने के लिए sign-in flow को।

The conversation जो missing step को surface किया निम्नलिखित exchange एक post-deployment review में हुआ MCP integration production में fail होने के बाद। Integration सभी staging tests को pass किया था। Security reviewer: "हर production sign-in attempt MCP connection के माध्यम से fail हो रहा है। Error एक redirect URI mismatch है। OAuth app कहां register किया गया था? "

Developer: "मैंने इसे staging. mycompany. com के लिए development के दौरान register किया। हमने last week को production को move किया। Connection सभी staging के माध्यम से काम किया।"

Security reviewer: "यह issue है। OAuth provider केवल redirect URIs को accept करता है जो आपने explicitly register किए हैं, और production. mycompany. com allowed list पर नहीं है। हर sign-in attempt check को hit करता है, URI match को fail करता है, और sign-in screen को loop back करता है।"

Developer: "तो मुझे केवल production URI को app registration में add करने की need है? "

Security reviewer: "हां, और इससे पहले कि आप करें, check करें कि क्या आपकी staging app registration production से एक अलग app होना चाहिए। अधिकांश enterprise customers अपने security policy के part के रूप में हर environment के लिए अलग OAuth app registrations को require करते हैं, इसलिए environments में एक ही app registration को use करना दूसरा issue है जो मैं flag करूंगा।" Developer को OAuth flow को end to end staging में test किया था और confirm किया था कि यह काम करता है, जिसका मतलब है कि production failure एक code defect नहीं था। Instead, यह एक configuration step था जो per host और per environment को apply करता है, और developer को production के लिए यह करने की need को know नहीं था।

What to Watch Out for OAuth redirect URIs per host को register किए जाते हैं, इसलिए एक working staging OAuth connection production connection को configured नहीं किया गया है। किसी भी OAuth-authenticated MCP integration को एक नए environment में move करने से पहले, नए host के redirect URI को OAuth app registration में add करें। Regulated enterprise customers के लिए, verify करें कि क्या separate OAuth app registrations staging और production के लिए required हैं। Deployment checklist में registration step को include करें ताकि यह first production sign-in attempt पर discovered न हो।

स्क्रीन 17: Checkpoint 6: एक trace से authentication failure को diagnose करें

CheckpointEnterprise Integration·3 min Checkpoint 6: एक trace से authentication failure को diagnose करें अभी try करें: नीचे connection trace को read करें। Authentication failure mechanism को name करें, फिर तीन options से सही targeted fix को select करें। Connection trace [MCP Client] Connecting to https://data-api. internal/mcp ... [MCP Client] GET /auth/token, 401 Unauthorized [MCP Client] Reading credential from: /home/jenkins/. config/mcp-credentials. json [MCP Client] Credential value: WAREHOUSE_TOKEN= sk-**[redacted] [MCP Client] Retrying with credential, 401 Unauthorized [MCP Client] Connection failed after 3 attempts AFix A: API key को rotate करें और /home/jenkins/. config/mcp-credentials. json को नई value के साथ update करें।BFix B: Rejected key को rotate करें, फिर credential को file से बाहर move करें और CI pipeline runner configuration में एक environment variable के रूप में inject करें। MCP configuration को variable को reference करने के लिए update करें।CFix C: इस service के लिए API key authentication से OAuth को switch करें।

Submit Skip for now

स्क्रीन 18: Cumulative integration task: checkpoint

CumulativeCumulative Integration Task·6 min Cumulative integration task: checkpoint नीचे integration के तीन bugs planted हैं इस module में layers में: एक Claude Code configuration layer में, एक plugin या packaging layer में, और एक MCP या authentication layer में। प्रत्येक file के लिए: bug को identify करें और एक sentence लिखें describing करते हुए कि यह runtime पर क्या करता है या fail करता है।

File 1: . claude/settings. json { "permissions": { "defaultMode": "bypassPermissions", "deny": ["Read(. env. production)"] } }

File 2: . claude/skills/migration-validate/SKILL. md --- name: migration-validate description: Validates migration scripts before they run against production. ---

Steps

• Run: /Users/priya/scripts/validate-migration. sh
• Report validation results.

File 3: . mcp. json { "mcpServers": { "data-warehouse": { "type": "http", "url": "https://warehouse. internal/mcp", "headers": { "Authorization": "Bearer sk-prod-warehouse-abc123" } } } }

Reveal model answer Skip for now

Model answer File 1 (settings. json): defaultMode bypassPermissions है; एक production workstation पर हर confirmation prompt को remove करता है, destructive operations के लिए सहित। Deny rule . env. production के लिए correct है; केवल mode गलत है। File 2 (SKILL. md): Step 1 एक absolute path /Users/priya/scripts/validate-migration. sh use करता है; यह path केवल author की machine पर exist करता है और किसी भी teammate की machine पर resolve नहीं करेगा project को clone करने के बाद। File 3 (. mcp. json): API key sk-prod-warehouse-abc123 Authorization header में inline commit किया गया है; यह repository history में enter करता है जहां file को later commit में overwrite करके remove नहीं किया जा सकता, और compromised के रूप में treat किया जाना चाहिए।

कितने आपने catch किए?

सभी तीन correct API key को miss किया (Bug 3) दो of three correct एक of three correct

स्क्रीन 19: Cumulative integration task: assembly

CumulativeCumulative Integration Task·6 min Cumulative integration task: assembly अब सभी तीन files के corrected version को write करें। settings. json, SKILL. md, और . mcp. json के लिए complete corrected content को produce करें।

Reveal model answer Skip for now

Model answer File 1: settings. json (corrected) { "permissions": { "defaultMode": "acceptEdits", "deny": ["Read(. env. production)"] } } File 2: SKILL. md (corrected) --- name: migration-validate description: Validates migration scripts before they run against production. ---

Steps

• Run: $CLAUDE_PROJECT_DIR/scripts/validate-migration. sh
• Report validation results.

File 3: . mcp. json (corrected) { "mcpServers": { "data-warehouse": { "type": "http", "url": "https://warehouse. internal/mcp", "headers": { "Authorization": "Bearer ${WAREHOUSE_MCP_TOKEN}" } } } } settings. json defaultMode को acceptEdits में set करता है permissions के अंदर; file edits और common filesystem commands को auto-approve करता है लेकिन destructive shell commands को gate करता है, एक production migration workstation के लिए सही tradeoff। Skill $CLAUDE_PROJECT_DIR को use करता है ताकि path project root से resolve हो किसी भी machine पर clone करने के बाद। MCP configuration credential को एक environment variable के रूप में reference करता है ताकि यह कभी भी repository history को commit न किया जाए।

आपकी assembly कैसे compare करती है?

Correct assembly Missing permission fix Missing path fix Missing secret fix

स्क्रीन 20: सात key takeaways

RecapKey Takeaways·6 min सात key takeaways

एक takeaway per section, module को tie करते हुए।

1 Permission mode एक risk decision है, एक speed decision नहीं। Claude Code आपको modes देता है ranging से prompt-before-everything को prompt-for-nothing तक। Permission mode को work के risk profile और environment को match करना चाहिए, fewer prompts के लिए preference को नहीं। एक bypass mode एक developer workstation पर एक live codebase के विरुद्ध agent और आपकी files के बीच हर checkpoint को remove करता है। एक deny rule path पर जो touch नहीं किया जाना चाहिए, project या enterprise level पर set किया गया, gap को cover करता है जो एक mode अकेले नहीं करता है।

2 एक AI code review आपको findings का एक set देता है triage करने के लिए, एक verdict को apply करने के लिए नहीं। Findings को trust करें जो reviewer अपने सामने diff से prove कर सकता है, जैसे एक missing null check या एक unclosed resource, और उन्हें lines पर confirm करें जो यह cite करता है। किसी भी claim को runtime behavior या अन्य system के बारे में एक hypothesis के रूप में treat करें, क्योंकि reviewer ने वह claim बिना evidence के किया जो इसे prove करेगा। Human gate को उस point पर place करें जहां एक finding एक action में turn करता है जो undo करना कठिन है और reviewer की accuracy को raise करें इसे conventions देकर जो यह अन्यथा guess करना होगा।

3 एक skill portable है, लेकिन "runs everywhere" कुछ है जो आप design करते हैं। एक ही SKILL. md Claude Code में, Messages API पर, और Agent SDK के माध्यम से चल सकता है, लेकिन प्रत्येक एक अलग तरीके से load और sandbox करता है: Claude Code में filesystem discovery, API पर beta headers और एक code execution container, और SDK पर settingSources। एक skill एक clear description को scoped है और local-environment assumptions से free है cleanly port करता है; एक जो terminal को assume करता है जो यह written था में नहीं। हर runtime में, subagents clean start करते हैं: वे automatically skills को preload नहीं करते।

4 Durable context प्रत्येक concern के लिए सही mechanism को require करता है। CLAUDE. md session-persistent project memory है, लेकिन size के साथ dilute करता है। Rules files guidance को scope करते हैं जहां यह apply होता है। Hooks guardrails को deterministically enforce करते हैं, probabilistically नहीं। Subagents exploration work को main context से बाहर रखते हैं। ये चार mechanisms प्रत्येक एक अलग problem को solve करते हैं, इसलिए सभी को CLAUDE. md में force करना एक single file produce करता है जो maintain करना कठिन है और ignore करना आसान है।

5 एक shareable setup portable components को require करता है। एक plugin जो author के home directory को एक absolute path को reference करता है एक machine पर install करेगा और सभी दूसरों पर fail करेगा। Skills, hooks, और plugin components जो share किए जाएंगे project root को relative paths को reference करना चाहिए, और कोई भी environment variable requirement को document या install time पर validate किया जाना चाहिए। Distribution से पहले एक clean machine से install को test करें।

6 Transport और scope independent decisions हैं dependent consequences के साथ। Stdio आपकी machine पर चलने वाले servers के लिए है। HTTP कुछ भी remotely hosted या multiple developers द्वारा accessed के लिए है। Local scope एक server को personal रखता है; project scope इसे repo के साथ . mcp. json के माध्यम से share करता है। Combination deployment intent को match करना चाहिए: एक shared team server HTTP transport और project या enterprise scope को require करता है। एक stdio server . mcp. json में एक configuration है जो shareable लगता है लेकिन नहीं है।

7 Enterprise integration security requirements को deployment से पहले identify करने को require करता है। एक regulated customer identity, data residency, access logging, और configuration control के बारे में ask करता है। Answers OAuth से आते हैं user-identity services के लिए, environment variables service credentials के लिए, PostToolUse hooks audit logging के लिए, और enterprise managed settings configuration lock के लिए। इनमें से कोई भी hard नहीं है implement करने के लिए, लेकिन सभी hard हैं एक production deployment के बाद retrofit करने के लिए एक security review को fail किया है।

क्या आगे आता है Module 4 production engineering, evaluations, और security को cover करता है: कैसे measure करें कि क्या आपके Claude Code integrations scale पर correctly काम करते हैं, कैसे eval harnesses को build करें, और कैसे production-grade safety guardrails को design करें। Permission modes, hooks, और authentication patterns इस module से foundation हैं जो वह evaluations test करते हैं।

Sources

Claude 101 (Skilljar) Claude Code 101 In Action (Skilljar) Building with the Claude API (Skilljar) code. claude. com platform. claude. com docs. claude. com

आप अब Claude Code को safely चला सकते हैं, इसे एक team asset के रूप में share कर सकते हैं, और इसे real systems को connect कर सकते हैं। Permission modes से enterprise authentication तक, आप अब configuration decisions को hold करते हैं जो एक integration को काम करते रहते हैं लंबे समय के बाद यह आपकी machine को छोड़ता है।

स्क्रीन 21: इस module से Key terms

GlossaryKey Terms·3 min इस module से Key terms

Alphabetical। एक term को expand करने के लिए click करें।

Claude Agent SDKA programmable interface जो एक ही agent loop को expose करता है Claude Code terminal में चलाता है। यह developers को loop को code से invoke करने देता है, permission mode और available tools को set करता है, और tasks को एक interactive session के बिना चलाता है। एक ही permission model और deny rules जो terminal में apply होते हैं SDK में apply होते हैं। CLAUDE. mdएक Markdown file जो एक Claude Code project के root पर placed है। इसके contents session के start पर context window को prepend किए जाते हैं। यह universal project constraints, conventions, और commands को hold करता है जो सभी sessions में unconditionally apply करना चाहिए। Files जो roughly 200-300 lines से अधिक grow करते हैं critical rules को dilute करने का risk रखते हैं। HookA command जो एक lifecycle event को Claude Code के execution में bind किया जाता है (PreToolUse, PostToolUse, UserPromptSubmit, Stop)। Instructions के विपरीत CLAUDE. md में, hooks deterministically configured event पर चलते हैं चाहे model क्या decide करे। एक PreToolUse hook code 2 के साथ exit कर सकता है एक tool call को block करने के लिए इससे पहले कि यह चले। MCP (Model Context Protocol)एक open communication layer जो एक MCP client जैसे Claude Code को एक MCP server को connect करने देता है जो tools, resources, और prompts को expose करता है। Protocol define करता है कि कैसे client server के tools को discover और call करता है। MCP का उपयोग करना tool definition और maintenance को individual application code से बाहर move करता है और एक reusable server में जो कोई भी MCP client attach कर सकता है। MCP transportMCP client और MCP server के बीच communication channel। Stdio server को एक local subprocess के रूप में client के समान machine पर चलाता है। HTTP एक remotely hosted server को एक network पर connect करता है। Transport की choice determine करता है कि server कहां चल सकता है और कौन इसे connect कर सकता है। Permission modeएक setting Claude Code में जो नियंत्रित करता है कि कितनी बार agent tool calls को execute करने से पहले confirmation के लिए request करता है। Modes range करते हैं default (लगभग हर action से पहले prompts) को bypass modes (कोई prompts नहीं) तक। Deny rules किसी भी mode को override करते हैं; एक deny rule enterprise settings level पर किसी भी individual configuration द्वारा bypass नहीं किया जा सकता। PluginA versioned bundle of Claude Code components (skills, hooks, subagents, और MCP server configurations) एक marketplace के माध्यम से distributed। एक plugin को install करना recipient को author के समान setup देता है एक single step में। Plugin एक page of manual setup steps को एक versioned, auditable install के साथ replace करता है। Rules instruction fileएक file जो guidance को एक specific path या condition में Claude Code में scope करता है। CLAUDE. md के विपरीत, जो unconditionally हर session के लिए load होता है, एक rules file केवल तब activate होता है जब Claude Code directory में काम कर रहा है जो यह supervise करता है। Path-specific guidance को main project memory file से बाहर रखने के लिए use किया जाता है। SubagentA separate execution context जो Claude Code द्वारा launched किया जाता है एक delegated task को handle करने के लिए। एक subagent main conversation के context को inherit नहीं करता, files जो आपने context में accumulate किए हैं, या आपकी current session state। जब आप एक task को एक subagent को send करते हैं, यह एक clean slate से start करता है, काम करता है, और केवल एक summary को return करता है। Exploratory या investigative work के लिए subagents को use करना main session context को content से भरने से रखता है जो reused नहीं होगा।

स्क्रीन 22: Congrats! आपने successfully इस module को complete किया है।

Module CompleteDeveloper Path·2 min Congrats! आपने successfully इस module को complete किया है। आप अब Claude Code को सही permission mode के तहत चला सकते हैं, इसे durable project context दे सकते हैं, एक workflow को एक shareable plugin के रूप में package कर सकते हैं, और Claude को real systems को MCP के माध्यम से connect कर सकते हैं बिना एक credential को leak किए या एक security review को fail किए। इस module में configuration decisions वह हैं जो एक integration को काम करते रहते हैं इसके बाद यह आपकी machine को छोड़ता है।

4 of 8 checkpoints passed

M1

MSO Foundations Tokens, context windows, sampling, model tiers, prompting modes, और API transport mechanics।

M2

Production-Grade Prompting, Agents & Tool-use Production-ready prompts, tool-use loops, streaming, context और memory management, और checkpointed agent loops।

M3

Claude Code, MCP & Integration Permission modes, durable context, plugin packaging, MCP servers, और enterprise authentication।

You Are Here

M4

Production Engineering, Evals, and Security Evals, tracing, failure handling, cost और orchestration budgets, और security boundaries जो production में hold करते हैं।

Up Next

M5

Accelerators and IP Contribution Package accelerators, prepare verifiable contributions, choose deployment platforms, और mark trust boundaries।

Review module Start over Start Module 4 → Return to course home

Module 3 complete।