Claude Code / Codex
निर्देश प्रॉम्प्ट और टेम्पलेट संग्रह
30 CLAUDE.md / AGENTS.md / Cursor Rules टेम्पलेट। उन्हें जेनरेट करवाने के लिए चैट में एक प्रॉम्प्ट पेस्ट करें, या एक तैयार फ़ाइल सीधे पेस्ट करें। दोनों ही तरीके काम करते हैं।
AI कोडिंग एजेंट (Claude Code, OpenAI Codex, Cursor और अन्य) आपकी रिपॉज़िटरी की रूट में मौजूद निर्देश फ़ाइल (CLAUDE.md / AGENTS.md) को पढ़कर "इस प्रोजेक्ट के नियम" सीखते हैं। लेकिन जब वे निर्देश अस्पष्ट होते हैं, तो AI उन्हें खुशी-खुशी अनदेखा कर देता है। एक प्रभावी निर्देश फ़ाइल ऐसी दिखती है: छोटे आदेशात्मक वाक्य, स्पष्ट निषेध, और सत्यापन चरणों के साथ एक स्पष्ट "पूर्णता की परिभाषा"।
वे क्यों अनदेखा किए जाते हैं और इसे कैसे ठीक करें, इसके लिए देखें "AI आपके .md नियमों को क्यों अनदेखा करता है, और इसे कैसे ठीक करें" ।
बस प्रॉम्प्ट को Claude Code / Codex / Cursor के चैट बॉक्स में सीधे पेस्ट करें। AI आपकी रिपॉज़िटरी की जाँच करता है और उसमें आपके असली कमांड के साथ एक निर्देश फ़ाइल लिखकर देता है।
लगभग कोई मैनुअल एडिटिंग की ज़रूरत नहीं। इसका उपयोग मौजूदा निर्देश फ़ाइलों की जाँच और सुधार के लिए, या उन्हें AGENTS.md / Cursor फ़ॉर्मेट में बदलने के लिए भी करें।
एक तैयार निर्देश फ़ाइल कॉपी करें और इसे अपनी रिपॉज़िटरी की रूट में CLAUDE.md के रूप में सेव करें। <name> जैसे कुछ ही प्लेसहोल्डर को अपने अपने परिवेश के अनुसार बदलें।
उन लोगों के लिए जो सामग्री को खुद समझना और प्रबंधित करना चाहते हैं, या जो किसी विशिष्ट भाषा/फ़्रेमवर्क के लिए शुरुआती टेम्पलेट चाहते हैं।
बस चैट में पेस्ट करें (जेनरेट और सुधार प्रॉम्प्ट)
शून्य से एक निर्देश फ़ाइल जेनरेट करें (CLAUDE.md / AGENTS.md, रिपॉज़िटरी की स्वतः जाँच करता है)★
सबसे आसान विकल्प। इसे चैट में पेस्ट करें और AI आपकी रिपॉज़िटरी की जाँच करके उसमें आपके असली कमांड के साथ एक निर्देश फ़ाइल लिख देता है। लगभग कोई मैनुअल एडिटिंग की ज़रूरत नहीं।
इस पूरी रिपॉज़िटरी की जाँच करें और रूट में वह निर्देश फ़ाइल बनाएँ
जिसे आप (यह एजेंट) स्वतः लोड करते हैं
(Claude Code `CLAUDE.md` का उपयोग करता है, Codex `AGENTS.md` का, Cursor `.cursor/rules/` का)।
इसमें शामिल करें:
- प्रोजेक्ट अवलोकन (ऐप क्या करता है, टेक स्टैक)
- कमांड (dev server / build / test / lint)। असली कमांड को
package.json या Makefile जैसी वास्तविक फ़ाइलों से पहचानें (अनुमान न लगाएँ)
- कोडिंग परंपराएँ (मौजूदा कोड से पढ़ी गई वास्तविक शैली से मेल खाएँ)
- पूर्ण नियम: कभी भी secrets या .env कमिट न करें / असंबंधित लाइनों को कभी re-format न करें /
जब तक कहा न जाए तब तक कभी push न करें
- पूर्णता की परिभाषा: जब तक lint और test पास न हों तब तक "done" की रिपोर्ट न करें
(असली कमांड नाम शामिल करें)
खाली जगहों को अनुमान से न भरें; जब कुछ अस्पष्ट हो तो मुझसे पूछें।
अंत में, इसे ऊपर बताई गई निर्देश फ़ाइल के रूप में पूरी तरह लिखकर दें।यह क्यों काम करता है:AI से आपकी अपनी रिपॉज़िटरी पढ़वाकर लिखवाना सबसे तेज़ रास्ता है। फ़ाइल का नाम टूल पर छोड़ देना (CLAUDE.md / AGENTS.md, आदि) मतलब यह Claude और Codex दोनों में वैसे ही काम करता है। और चूँकि यह कमांड और पाथ को आपकी वास्तविक फ़ाइलों से तय करता है, इसलिए कोई मैनुअल एडिटिंग की ज़रूरत नहीं।
मौजूदा निर्देश फ़ाइल की जाँच करें और उसे "प्रभावी" रूप में फिर से लिखें
उन स्थितियों के लिए जब आपके पास पहले से ही एक निर्देश फ़ाइल (CLAUDE.md / AGENTS.md) है लेकिन AI उसका पालन नहीं करता। उससे कमज़ोर बिंदु बतवाएँ, फिर इसे आदेशात्मक शब्दों और सत्यापन चरणों के साथ फिर से लिखवाएँ।
उस निर्देश फ़ाइल को पढ़ें जिसे आप (यह एजेंट) लोड करते हैं (CLAUDE.md / AGENTS.md, आदि),
उन कमज़ोर बिंदुओं को इंगित करें जिन्हें AI एजेंट अक्सर अनदेखा करते हैं, और फिर इसे
एक प्रभावी रूप में फिर से लिखें।
देखने योग्य बातें:
- अस्पष्ट शब्दों को आदेशों में बदलें (हमेशा X करें / कभी Y न करें)
- एक "पूर्णता की परिभाषा" और सत्यापन चरण जोड़ें (lint / test चलाना)
- निषेधों को लक्ष्य तक ठोस बनाएँ (डायरेक्टरी नाम, कमांड नाम)
- अगर यह बहुत लंबा है, तो इसे केवल उस मूल तक छोटा करें जिसे आप लागू करवाना चाहते हैं
पहले कमज़ोर बिंदुओं को बुलेट पॉइंट के रूप में सूचीबद्ध करें, फिर पूरा फिर से लिखा गया
संस्करण आउटपुट करें और इसे उस निर्देश फ़ाइल पर लागू करें।यह क्यों काम करता है:एक "अप्रभावी निर्देश फ़ाइल" आमतौर पर अस्पष्ट होती है, उसमें कोई सत्यापन चरण नहीं होते, और निषेध केवल अमूर्त रूप में नामित होते हैं। ठीक करने से पहले AI से खुद कमज़ोर बिंदु बतवाने से सुधार ठोस बन जाते हैं।
अपनी वर्तमान रिपॉज़िटरी के अनुरूप एक "पूर्णता की परिभाषा" जोड़ें
अपने असली कमांड के साथ सबसे महत्वपूर्ण एकल ब्लॉक जोड़ें, ताकि AI तब रुकना बंद कर दे जब वह केवल यह सोचता है कि उसने काम पूरा कर लिया है।
इस रिपॉज़िटरी के वास्तविक build / test / lint कमांड पहचानने के बाद,
उस निर्देश फ़ाइल में एक "Definition of Done" सेक्शन जोड़ें जिसे आप लोड करते हैं
(CLAUDE.md / AGENTS.md, आदि)।
आवश्यकताएँ:
- इसे इस रूप में एक चेकलिस्ट बनाएँ "जब तक निम्नलिखित सभी पूरे न हों तब तक done की रिपोर्ट न करें"
- असली lint और test कमांड को स्पष्ट रूप से बताएँ
- शामिल करें: बदली गई फ़ाइलों में कोई TODO या debug log न छोड़ें, और अपने diff को फिर से पढ़ें
मौजूदा सामग्री को न तोड़ें; केवल सेक्शन जोड़ें।यह क्यों काम करता है:जब पूर्णता के मानदंड अस्पष्ट होते हैं, तो AI आत्म-संतुष्टि के कारण रुक जाता है। बस असली कमांड के साथ एक चेकलिस्ट जोड़ने से आत्म-सत्यापन लूप चलने लगता है। "जोड़ें, मौजूदा सामग्री न तोड़ें" बताना सुरक्षित तरीका है।
भाषा/फ़्रेमवर्क की स्वतः पहचान करें और नियम जोड़ें
उससे स्टैक की पहचान करवाएँ और सही नियम जुड़वाएँ, जैसे Next.js के लिए Server/Client सीमाएँ।
इस रिपॉज़िटरी की भाषा और फ़्रेमवर्क की स्वतः पहचान करें, और उससे संबंधित
सर्वोत्तम-अभ्यास नियमों को उस निर्देश फ़ाइल में जोड़ें जिसे आप लोड करते हैं
(CLAUDE.md / AGENTS.md, आदि)।
उदाहरण:
- Next.js: Server/Client सीमा (डिफ़ॉल्ट Server है, use client को न्यूनतम रखें)
- Laravel: Form Requests के माध्यम से validation, migration परंपराएँ
- Python: type annotations, raw data को कभी overwrite या मनगढ़ंत न करें
जोड़ने से पहले अपनी पहचान का आधार एक पंक्ति में बताएँ (आपने किन फ़ाइलों से निर्णय लिया)।
जो पहले से लिखा है उसे डुप्लिकेट न करें।यह क्यों काम करता है:गलती के बिंदु भाषा के अनुसार अलग होते हैं। AI से स्वतः पहचान करवाकर केवल प्रासंगिक नियम जुड़वाना एक सामान्य टेम्पलेट से अधिक सटीक है, और रखरखाव में आसान भी।
security / Git / testing के लिए पूर्ण नियम जोड़ें
"पूर्ण नियमों" का एक सेट जोड़ें जो अपरिवर्तनीय दुर्घटनाओं को रोकते हैं।
उस निर्देश फ़ाइल में निम्नलिखित "पूर्ण नियम" जोड़ें जिसे आप लोड करते हैं
(CLAUDE.md / AGENTS.md, आदि), इस रिपॉज़िटरी की सेटअप के अनुरूप।
- secrets, .env, या credentials कभी कमिट न करें
- जब तक कहा न जाए तब तक कभी push / force-push न करें
- input को boundary पर validate करें / authentication या authorization को खुद कभी ढीला न करें
- production DB पर कभी destructive कमांड (DROP / TRUNCATE / migrate:fresh, आदि) न चलाएँ
- जब भी आप behavior बदलें, हमेशा tests जोड़ें या अपडेट करें
अगर समान नियम पहले से मौजूद हैं, तो उन्हें डुप्लिकेट न करें; केवल जो कमी है उसे भरें।यह क्यों काम करता है:दुर्घटनाएँ "लीक हुए secrets, बिना अनुरोध के push, destructive DB ऑपरेशन" के आसपास केंद्रित होती हैं। इन्हें नामित पूर्ण नियमों के रूप में जोड़ना AI को शुरुआत में ही पटरी से उतरने से रोकता है।
CLAUDE.md को AGENTS.md (Codex) फ़ॉर्मेट में बदलें
वही सामग्री Codex के लिए फिर से बनाएँ। उन लोगों के लिए जो कई AI टूल साथ में उपयोग करते हैं।
इस `CLAUDE.md` की सामग्री को OpenAI Codex के लिए `AGENTS.md` फ़ॉर्मेट में
बदलें और इसे लिखकर दें।
- अर्थ बरकरार रखें, लेकिन इसे ऐसी संरचना में फिर से ढालें जो Codex के लिए
पढ़ने में आसान हो (headings, bullet points)
- कमांड, पूर्ण नियम, और पूर्णता की परिभाषा को वैसे ही रखें
- इसे रूट में `AGENTS.md` के रूप में आउटपुट करेंयह क्यों काम करता है:CLAUDE.md और AGENTS.md अपनी लगभग सारी सामग्री साझा करते हैं। एक को स्रोत-सत्य मानकर उससे बदलना दो फ़ाइलों के रखरखाव की मेहनत को कम करता है।
Cursor Rules (.mdc) फ़ॉर्मेट में बदलें
Cursor के Project Rules फ़ॉर्मेट में। हमेशा-लागू नियम और फ़ाइल-प्रकार-सीमित नियम अलग-अलग आउटपुट करता है।
इस `CLAUDE.md` की सामग्री को Cursor के Project Rules फ़ॉर्मेट में बदलें
(`.cursor/rules/` के अंतर्गत `.mdc` फ़ाइलें)।
- नियमों को सार्थक इकाइयों में विभाजित करें
- उन नियमों को अलग करें जो हमेशा लागू होने चाहिए उन नियमों से जो केवल विशिष्ट
फ़ाइल प्रकारों पर लागू होते हैं
- प्रत्येक फ़ाइल के शीर्ष पर उपयुक्त लागू-शर्तें (globs, आदि) सेट करेंयह क्यों काम करता है:Cursor एक बड़ी नियम शीट की तुलना में उद्देश्य के अनुसार विभाजित .mdc फ़ाइलों के साथ बेहतर काम करता है। विभाजन के निर्णय AI पर छोड़ देना भी तेज़ है।
monorepo के लिए विभाजित निर्देश फ़ाइलें जेनरेट करें
सामान्य नियमों को रूट में और स्टैक-विशिष्ट नियमों को प्रत्येक पैकेज में स्वतः वितरित करता है।
इस monorepo की संरचना की जाँच करें और वे निर्देश फ़ाइलें बनाएँ जिन्हें आप
(यह एजेंट) लोड करते हैं (Claude Code CLAUDE.md का उपयोग करता है, Codex AGENTS.md का, आदि),
इस प्रकार विभाजित करके।
- रूट में: पूरी रिपॉज़िटरी के लिए सामान्य नियम
(commit परंपराएँ, secret सुरक्षा, समग्र पूर्णता की परिभाषा)
- प्रत्येक package/app डायरेक्टरी में: केवल उस स्टैक के विशिष्ट नियम और कमांड
डुप्लिकेशन से बचें, और प्रत्येक पैकेज में एक पंक्ति का नोट जोड़ें जिसमें लिखा हो "रूट के
सामान्य नियमों का पालन करें"। अंत में, यह रिपोर्ट करें कि आपने किस डायरेक्टरी में क्या रखा।यह क्यों काम करता है:एक monorepo एक विशाल निर्देश फ़ाइल के अंतर्गत टूट जाता है। सामान्य नियमों को रूट में और विशिष्ट नियमों को प्रत्येक पैकेज में विभाजित करना AI को उस संदर्भ के लिए सही नियम पढ़ने देता है जिसमें वह है।
तैयार-पेस्ट करने योग्य पूरी फ़ाइलें - मूल बातें और नियम
सार्वभौमिक आधार (किसी भी प्रोजेक्ट के लिए)
आपकी पहली फ़ाइल। प्रोजेक्ट अवलोकन, कमांड, परंपराओं और पूर्ण नियमों के साथ एक न्यूनतम सेटअप। संदेह होने पर, यहाँ से शुरू करें और जोड़ें या हटाएँ।
# Project: <name>
## यह क्या है
ऐप का एक-पैराग्राफ अवलोकन। यह क्या करता है, इसे कौन उपयोग करता है, और टेक
स्टैक (भाषा, फ़्रेमवर्क, DB, runtime)।
## कमांड
- Dev server: `npm run dev`
- Build: `npm run build`
- Test: `npm test`
- Lint: `npm run lint`
## परंपराएँ
- भाषा TypeScript (strict) है। `any` का उपयोग न करें।
- उस फ़ाइल की शैली से मेल खाएँ जिसे आप वर्तमान में एडिट कर रहे हैं। समाप्त करने से पहले हमेशा Lint पास करें।
- बदलाव न्यूनतम रखें; असंबंधित लाइनों को न छुएँ (कोई असंबंधित re-formatting नहीं)।
## पूर्ण नियम (सख्ती से लागू)
- done की रिपोर्ट करने से पहले, हमेशा ऊपर के tests और Lint चलाएँ और उन्हें पास कराएँ।
- secrets, .env, या build artifacts कभी, कतई कमिट न करें।
- नई फ़ाइलें बनाने के बजाय मौजूदा फ़ाइलों को एडिट करना पसंद करें।
- जब आवश्यकताएँ अस्पष्ट हों, तो बड़ा बदलाव करने से पहले ठीक एक स्पष्टीकरण प्रश्न पूछें।
## सीमा से बाहर (जब तक अन्यथा न कहा जाए)
- CI config, dependency versions, infrastructure setup।यह क्यों काम करता है:"कमांड" को पहले रखने से AI को अपने काम को सत्यापित करने का एक तरीका मिलता है। पूर्ण नियमों को छोटे आदेशों के रूप में लिखना (हमेशा / कभी नहीं) उन्हें अनदेखा करना कठिन बना देता है। "सीमा से बाहर" सेक्शन बेकाबू बदलावों को पहले ही रोक देता है।
"पूर्णता की परिभाषा" ब्लॉक जो नियमों का पालन करवाता है★
सबसे महत्वपूर्ण। AI को तब रुकने से रोकता है जब वह केवल यह सोचता है कि उसने काम पूरा कर लिया है। एक सामान्य ब्लॉक जिसे आप किसी भी निर्देश फ़ाइल में पेस्ट कर सकते हैं।
## पूर्णता की परिभाषा (रिपोर्ट करने से पहले हमेशा पढ़ें)
काम को "done" तभी मानें जब निम्नलिखित सभी पूरे हों:
1. `npm run lint` exit code 0 के साथ पास होता है
2. `npm test` exit code 0 के साथ पास होता है
3. बदली गई फ़ाइलों में कोई TODO / FIXME / debug log नहीं बचा है
4. आपने अपने diff को फिर से पढ़ा है और पुष्टि की है कि यह अनुरोध से मेल खाता है
अगर इनमें से एक भी पूरा नहीं होता, तो काम जारी रखें। "done" की रिपोर्ट न करें।
## पूर्ण नियम (सख्ती से लागू)
- `legacy/` या `vendor/` के अंतर्गत फ़ाइलें एडिट न करें।
- dependencies जोड़ें, हटाएँ, या अपडेट न करें।
- उन लाइनों को re-format न करें जिन्हें आपने नहीं बदला।
- सिर्फ़ build पास कराने के लिए tests को delete या disable न करें।
## जब संदेह हो
अनुमान पर आगे न बढ़ें; ठीक एक संक्षिप्त प्रश्न पूछें।
एक गलत, बड़ा बदलाव एक स्पष्टीकरण प्रश्न से कहीं बुरा है।यह क्यों काम करता है:जब "पूर्णता के मानदंड" अस्पष्ट होते हैं, तो AI आत्म-संतुष्टि के कारण रुक जाता है। इसे एक चेकलिस्ट में बदलना और "अगर पूरा न हो, तो जारी रखें; done न कहें" बताना आत्म-सत्यापन लूप को चालू कर देता है। निषेधों को पाथ तक नामित करना काम करता है।
न्यूनतम संस्करण (बस कुछ लाइनें)
उन प्रोजेक्ट के लिए जो लंबी निर्देश फ़ाइलें नापसंद करते हैं। न्यूनतम मूल जो फिर भी दुर्घटना दर को काफ़ी कम कर देता है।
# <name>
- Stack: <उदाहरण: Next.js + TypeScript + PostgreSQL>
- समाप्त करने से पहले हमेशा चलाएँ: `npm run lint` और `npm test` (दोनों पास होने चाहिए)
- मौजूदा शैली से मेल खाएँ। असंबंधित लाइनों को re-format न करें।
- secrets या .env कमिट न करें। जब तक कहा न जाए तब तक push न करें।
- जब अस्पष्ट हो, तो अनुमान न लगाएँ; ठीक एक प्रश्न पूछें।यह क्यों काम करता है:निर्देश फ़ाइलों के लिए लंबा होना बेहतर नहीं है। इसे केवल उस मूल तक सीमित करना जिसे आप लागू करवाना चाहते हैं (सत्यापन, re-formatting पर रोक, secret सुरक्षा, push न करना, प्रश्न पूछना) AI को इसे अंत तक याद रखने देता है।
तैयार-पेस्ट करने योग्य पूरी फ़ाइलें - भाषा और फ़्रेमवर्क के अनुसार
Next.js / TypeScript
App Router मानता है। AI के लिए Server/Client सीमा और data-fetching शैली तय करता है।
# Next.js (App Router) + TypeScript
## Stack
Next.js (App Router), TypeScript strict, Tailwind CSS, <your-ORM>
## कमांड
- Dev: `npm run dev`
- Build: `npm run build` # बिना type errors के पास होना चाहिए
- Lint: `npm run lint`
- Test: `npm test`
## आर्किटेक्चर नियम
- डिफ़ॉल्ट रूप से Server Components का उपयोग करें। "use client" केवल तब जोड़ें जब state, effects,
या browser APIs की ज़रूरत हो। Client Components को छोटा और leaves पर रखें।
- डेटा Server Components या Route Handlers में fetch करें।
शुरुआती डेटा useEffect में fetch न करें।
- components को उनके route segment के साथ co-locate करें। साझा UI `components/` में जाता है।
- बाहरी input को हमेशा boundary पर schema-validate करें (उदाहरण: Zod)।
## परंपराएँ
- कोई `any` नहीं। public functions को स्पष्ट return types दें।
- मौजूदा design tokens / Tailwind classes का उपयोग करें। खुद से रंग न जोड़ें।
- `page.tsx` को पतला रखें; logic को functions और components में डालें।
## पूर्णता की परिभाषा
`npm run build`, `npm run lint`, और `npm test` सभी exit code 0 के साथ पास होते हैं।
कोई `any` नहीं, कोई unused exports नहीं, कोई बचा हुआ console.log नहीं।यह क्यों काम करता है:Next.js AI के "Server बनाम Client निर्णय" को गलत करने का शीर्ष उदाहरण है। "डिफ़ॉल्ट Server, use client को न्यूनतम रखें" स्पष्ट रूप से लिखना दुर्घटनाओं को नाटकीय रूप से कम कर देता है।
React (Vite) SPA
Vite-आधारित SPA के लिए। state management और component design के दृष्टिकोण को तय करता है।
# React (Vite) + TypeScript
## कमांड
- Dev: `npm run dev`
- Build: `npm run build`
- Lint: `npm run lint`
- Test: `npm test` (Vitest + Testing Library)
## नियम
- केवल function components और Hooks। class components का उपयोग न करें।
- state को न्यूनतम रखें, इस क्रम में "local -> Context -> state library"।
state को बिना ज़रूरत global तक न उठाएँ।
- side effects को useEffect में सीमित करें, और dependency array को सही ढंग से लिखें।
- UI को logic से अलग करें। data fetching को समर्पित hooks (useXxx) में समूहित करें।
- Accessibility: interactive elements को उपयुक्त roles और keyboard संचालन दें।
## परंपराएँ
- कोई `any` नहीं। props को types के साथ परिभाषित करें।
- मौजूदा components और styles की शैली से मेल खाएँ।
## पूर्णता की परिभाषा
`npm run build`, `npm run lint`, और `npm test` exit code 0 के साथ पास होते हैं।यह क्यों काम करता है:React में, क्लासिक दुर्घटनाएँ हैं "state को बहुत जल्दी global तक उठाना" और "गलत useEffect dependencies"। promotion क्रम और dependency-array नियम को स्पष्ट लिखना चीज़ों को स्थिर रखता है।
Node.js API (Express / Hono)
backend APIs के लिए। validation, error handling, और secret management के लिए guardrails लगाता है।
# Node.js API (Express / Hono) + TypeScript
## कमांड
- Dev: `npm run dev`
- Build: `npm run build`
- Test: `npm test`
- Lint: `npm run lint`
## नियम
- सभी input (body, query, params, headers) को boundary पर schema-validate करें।
- errors को न दबाएँ। उन्हें एक central error handler के माध्यम से typed लौटाएँ।
- secrets को environment variables से पढ़ें। उन्हें code में hardcode न करें।
- DB access को layer करें (route -> service -> repository)।
- एक सुसंगत JSON shape लौटाएँ (success और failure के shapes को एकीकृत करें)।
## पूर्ण नियम
- authentication / authorization logic को खुद से skip या ढीला न करें।
- सार्वजनिक रूप से उजागर endpoint जोड़ते समय हमेशा authorization सत्यापित करें।
- log में personal information, tokens, या passwords न डालें।
## पूर्णता की परिभाषा
`npm test` (happy path + error cases) और `npm run lint` पास होते हैं।यह क्यों काम करता है:APIs के लिए, तीन बड़े दुर्घटना कारण हैं "बिना validate किया input", "दबा दी गई errors", और "log में secrets"। boundary validation और authorization जाँच को पूर्ण नियम बनाना उनके पालन की संभावना बढ़ाता है।
Laravel / PHP
AI को एक convention-first फ़्रेमवर्क का अभ्यस्त बनाता है: Eloquent, migrations, और परंपराएँ।
# Laravel + PHP
## कमांड
- Serve: `php artisan serve`
- Migrate: `php artisan migrate`
- Test: `php artisan test`
- Format: `./vendor/bin/pint` # समाप्त करने से पहले चलाएँ
## परंपराएँ (Laravel के तरीके का पालन करें)
- Eloquent relations का उपयोग करें। स्पष्ट कारण के बिना raw SQL से बचें।
- input को Form Request classes में validate करें। इसे controllers के अंदर न करें।
- controllers को पतला रखें। business logic को Services / Actions में डालें।
- हर schema बदलाव को एक नया migration मिलता है। पहले से चल चुके migration एडिट न करें।
- named routes और route model binding का उपयोग करें।
## पूर्ण नियम
- `.env` या असली credentials कभी, कतई कमिट न करें।
- production DB के विरुद्ध `migrate:fresh` जैसे destructive कमांड न चलाएँ।
- जब भी आप behavior बदलें, हमेशा tests जोड़ें या अपडेट करें (`php artisan test`)।
## पूर्णता की परिभाषा
`php artisan test` और `./vendor/bin/pint --test` दोनों पास होते हैं।यह क्यों काम करता है:एक "convention-first" फ़्रेमवर्क के लिए, "फ़्रेमवर्क की परंपराओं का पालन करें" स्पष्ट लिखना और destructive कमांड पर रोक लगाना सुरक्षित कदम है। पहले से चल चुके migrations को एडिट करने पर रोक भी मायने रखती है।
Python / data analysis
types, virtual environments, और reproducibility पर ज़ोर देता है। "डेटा न तोड़ें या मनगढ़ंत न करें" नियमों को पहले रखता है।
# Python / data analysis
## परिवेश
- प्रोजेक्ट venv `.venv` का उपयोग करें। globally install न करें।
- Install: `pip install -r requirements.txt`
- Run: `python -m src.main`
- Test: `pytest`
- Format: `ruff check .` और `ruff format .`
## परंपराएँ
- हर function signature में type annotations जोड़ें। अगर configured हो तो `mypy src` चलाएँ।
- notebooks में logic न डालें। पुन: उपयोग योग्य code `src/` में जाता है।
- randomness का उपयोग करने वाली किसी भी चीज़ के लिए seed fix करें, ताकि परिणाम reproducible हों।
## पूर्ण डेटा नियम (सबसे महत्वपूर्ण)
- missing values को चुपचाप न भरें और न मनगढ़ंत करें। अगर missing
values हों, तो उनकी रिपोर्ट करें और पुष्टि करें कि उन्हें कैसे संभालना है।
- raw data फ़ाइलों को overwrite न करें। output को `data/processed/` में लिखें।
- सभी assumptions (filters, excluded rows, units) को code comments में दर्ज करें।
## पूर्णता की परिभाषा
`pytest` पास होता है, `ruff check .` साफ़ है, और परिणाम एक साफ़ स्थिति से reproduce होते हैं।यह क्यों काम करता है:विश्लेषण में, AI की सबसे बड़ी गलतियाँ हैं "missing values को चुपचाप भरना" और "raw data को overwrite करना"। बस इन्हें स्पष्ट रूप से रोकना परिणामों को कहीं अधिक भरोसेमंद बना देता है।
Go
AI को Go के तरीके का पालन करवाता है, जो सरलता और स्पष्ट error handling को महत्व देता है।
# Go
## कमांड
- Build: `go build ./...`
- Test: `go test ./...`
- Format: `gofmt -w .` और `go vet ./...`
## परंपराएँ
- errors को न दबाएँ। हमेशा उन्हें `if err != nil` से संभालें, और
उन्हें context के साथ लौटाएँ (`fmt.Errorf("...: %w", err)`)।
- early returns के साथ nesting को उथला रखें।
- concurrency का उपयोग केवल तब करें जब ज़रूरत हो। goroutine leaks और races के लिए सावधान रहें
(`go test -race` को पास कराएँ)।
- exported symbols पर comment करें। standard library को प्राथमिकता दें।
## पूर्ण नियम
- अनावश्यक abstractions या interfaces न जोड़ें (ज़रूरत पड़ने पर बनाएँ)।
- एक dependency जोड़ने से पहले, पहले जाँचें कि क्या standard library पर्याप्त है।
## पूर्णता की परिभाषा
`go build ./...`, `go vet ./...`, और `go test -race ./...` सभी पास होते हैं।यह क्यों काम करता है:Go में, "अति-abstraction" और "दबा दी गई errors" दुर्घटना के स्रोत हैं। early returns, %w wrapping, और -race को स्पष्ट लिखना सुरक्षित, idiomatic Go code तैयार करता है।
Rust
unwrap और unsafe के अति-उपयोग को रोकता है, और इसे Result/Option को सही ढंग से संभालने पर मजबूर करता है।
# Rust
## कमांड
- Build: `cargo build`
- Test: `cargo test`
- Lint: `cargo clippy -- -D warnings`
- Format: `cargo fmt`
## परंपराएँ
- production code में `unwrap()` / `expect()` का लापरवाही से उपयोग न करें।
`Result` / `Option` को `?` या match के साथ सही ढंग से संभालें।
- `unsafe` सिद्धांत रूप में प्रतिबंधित है। अगर वास्तव में आवश्यक हो, तो कारण को comment में बताएँ।
- borrowing और lifetimes पर compiler का पालन करें। `clone()` के साथ बचने से पहले design पर
फिर से विचार करें।
- error types को `thiserror` / `anyhow`, आदि के साथ सार्थक बनाएँ।
## पूर्णता की परिभाषा
`cargo build` और `cargo test` पास होते हैं, और
`cargo clippy -- -D warnings` शून्य warnings की रिपोर्ट करता है।यह क्यों काम करता है:Rust में, जब AI फँस जाता है तो वह `unwrap()` और `clone()` के साथ बचने की कोशिश करता है। इन्हें हतोत्साहित करना और clippy को -D warnings के साथ पास कराना गुणवत्ता बनाए रखता है।
Ruby on Rails
इसे "पटरी पर" रखें। fat models/controllers से बचें और परंपराओं का पालन करें।
# Ruby on Rails
## कमांड
- Serve: `bin/rails server`
- Migrate: `bin/rails db:migrate`
- Test: `bin/rails test` (या `bundle exec rspec`)
- Format: `bundle exec rubocop -A`
## परंपराएँ (Rails के तरीके का पालन करें)
- "convention over configuration" का सम्मान करें; अपनी खुद की संरचना न बनाएँ।
- fat controllers / models से बचें। logic को Services / Concerns में डालें।
- input को strong parameters से सीमित करें।
- N+1 से बचें (`includes` का उपयोग करें)।
- schema बदलावों को एक नया migration मिलता है। पहले से चल चुके migration एडिट न करें।
## पूर्ण नियम
- `.env` या credentials कभी, कतई कमिट न करें।
- production DB के विरुद्ध destructive कमांड न चलाएँ।
- जब आप behavior बदलें, tests जोड़ें या अपडेट करें।
## पूर्णता की परिभाषा
Tests और `bundle exec rubocop` पास होते हैं।यह क्यों काम करता है:Rails परंपरा से भटकने पर तेज़ी से अनुरक्षणीय नहीं रह जाता। "पटरी पर रहें", "fat से बचें", और "N+1 से बचें" स्पष्ट लिखना Rails के idioms बनाए रखता है।
SQL / DB migrations
डेटा न तोड़ें; केवल reversible बदलाव। migrations के लिए सुरक्षा guardrails।
# SQL / database migrations
## पूर्ण नियम (डेटा सुरक्षा सबसे पहले आती है)
- production data के विरुद्ध destructive ऑपरेशन खुद से न चलाएँ
(DROP / TRUNCATE / बिना शर्त DELETE या UPDATE)।
- migrations को केवल forward दिशा ही नहीं, बल्कि एक rollback प्रक्रिया भी देनी चाहिए।
- पहले से चल चुके migrations को एडिट न करें। हमेशा नए जोड़ें।
- columns को चरणों में drop या rename करें ("add -> migrate -> retire"); इसे एक झटके में न करें।
## query परंपराएँ
- `SELECT *` से बचें; उन columns को निर्दिष्ट करें जिनकी आपको ज़रूरत है।
- पुष्टि करें कि WHERE / JOIN conditions एक index का उपयोग कर सकती हैं।
- बड़े updates को batches में बाँटें ताकि lock time कम रहे।
- destructive सत्यापन queries के लिए, चलाने से पहले पहले एक `SELECT` से प्रभावित count की पुष्टि करें।
## पूर्णता की परिभाषा
एक staging-समकक्ष परिवेश में apply और rollback दोनों सफल होते हैं, और आपने
मौजूदा डेटा में कोई अनपेक्षित बदलाव न होने की पुष्टि कर ली है।यह क्यों काम करता है:DB सभी में सबसे "अपरिवर्तनीय" क्षेत्र है। destructive ऑपरेशन पर रोक, चरणबद्ध schema बदलाव, और आवश्यक rollback को स्पष्ट लिखना जीवनरेखा है।
तैयार-पेस्ट करने योग्य पूरी फ़ाइलें - workflow के अनुसार
Test-driven (TDD)
"tests को टालें नहीं" और "tests delete करके पास न कराएँ" को लागू करता है।
# Test-driven तरीका
जब behavior बदलें, तो हर बार इस लूप का पालन करें:
1. पहले एक "failing test" लिखें जो वांछित behavior को व्यक्त करता है।
2. test चलाएँ और पुष्टि करें कि यह सही कारण से fail होता है।
3. test को पास कराने के लिए न्यूनतम code लिखें।
4. पूरा test suite चलाएँ और पुष्टि करें कि सब कुछ हरा है।
5. हरा बनाए रखते हुए refactor करें।
## पूर्ण नियम
- suite पास कराने के लिए tests को delete या skip न करें।
- चीज़ों को हरा बनाने के लिए assertions को कमज़ोर न करें।
- अगर कोई test वास्तव में गलत है, तो इसे बदलने से पहले कारण समझाएँ।
- tests के बिना नया code "done" नहीं है।
## पूर्णता की परिभाषा
पूरा suite पास होता है, coverage गिरा नहीं है, और implementation को revert करने पर
नया test fail होता है (यानी यह एक सार्थक test है)।यह क्यों काम करता है:जब फँस जाता है, तो AI कभी-कभी tests को delete कर देता है और कहता है "यह पास हो गया"। "delete न करें, कमज़ोर न करें, revert पर fail होने की पुष्टि करें" लिखना छिद्रों को बंद कर देता है।
Debugging-केंद्रित
अनुमान-आधारित fixes को रोकता है। मूल-कारण पहचान फिर न्यूनतम fix के अनुशासन को लागू करता है।
# Debugging तरीका
इस क्रम में आगे बढ़ें। अनुमान लगाकर fix न करें:
1. reproduction steps स्थापित करें (bug को कैसे trigger करें)।
2. expected behavior और actual behavior को, एक-एक वाक्य में लिखें।
3. एक hypothesis बनाएँ। fix करने से पहले इसे logs या एक minimal repro से सत्यापित करें।
4. एक बार जब आप कारण पहचान लें, तो न्यूनतम fix लागू करें।
5. fix करने के बाद, पुष्टि करें कि repro steps के माध्यम से bug चला गया है और मौजूदा tests पास होते हैं।
6. अगर संभव हो, तो एक regression test जोड़ें जो इस bug को पकड़ता है।
## पूर्ण नियम
- कारण अज्ञात रहते हुए एक साथ कई जगहों को न बदलें।
- "अभी के लिए काम कर रहा है" पर न रुकें। समझाएँ कि यह क्यों ठीक हुआ।
- असंबंधित refactoring को debugging में न मिलाएँ।यह क्यों काम करता है:जब किसी bug पर फँस जाता है, तो AI एक साथ कई जगहों को फिर से लिखता है और चीज़ों को बदतर बना देता है। "reproduce -> hypothesize -> verify -> minimal fix -> regression test" क्रम को मजबूर करना इसे विश्वसनीय रूप से ठीक करता है।
Refactoring-केंद्रित
"behavior न बदलें" को पूर्ण शर्त बनाता है। हरे tests द्वारा समर्थित सुरक्षित सुधार।
# Refactoring तरीका
## मूल सिद्धांत
बाहर से दिखने वाले behavior को न बदलें। किसी भी input के लिए outputs या side
effects को बिल्कुल न बदलें।
## चरण
1. पहले पुष्टि करें कि target क्षेत्र के लिए tests मौजूद हैं और हरे हैं।
अगर नहीं, तो पहले characterization tests लिखें जो वर्तमान behavior को तय करते हैं।
2. छोटे, single steps में बदलें, हर step के बाद tests चलाएँ।
3. एक commit = एक प्रकार का सुधार रखें।
## पूर्ण नियम
- feature additions या bug fixes को refactoring में न मिलाएँ (उन्हें अलग काम बनाएँ)।
- अगर कोई test लाल हो जाता है, तो वहीं रुक जाएँ। आगे न बढ़ें।
- public API signatures को खुद से न बदलें (ज़रूरत हो तो पहले पुष्टि करें)।
## पूर्णता की परिभाषा
सभी tests हरे रहते हैं, और code कम duplication के साथ अधिक पठनीय है।यह क्यों काम करता है:refactoring के लिए, "behavior न बदलें" ही सब कुछ है। इसे मूल सिद्धांत बनाए और हरे tests से समर्थित किए बिना, AI खुशी-खुशी features तोड़ देगा। feature additions मिलाने पर रोक भी मायने रखती है।
specs / design documents लिखना
इसे तुरंत implement न करने दें; पहले design को prose में लिखवाएँ। rework को नाटकीय रूप से कम करता है।
# एक design document कैसे लिखें
implement करने से पहले, पहले निम्नलिखित को prose में लिखें (code न लिखें):
## 1. लक्ष्य
हल करने वाली समस्या, और इसे प्राप्त कहलाने की शर्तें (success criteria)।
## 2. वर्तमान स्थिति और बाधाएँ
मौजूदा setup, dependencies, और सम्मान करने योग्य बाधाएँ (performance, compatibility, deadline)।
## 3. design प्रस्ताव
- चुना गया approach, और वे approaches जिन पर आपने विचार किया और अस्वीकार किया (और क्यों)।
- data flow, मुख्य interfaces, और बदलने योग्य फ़ाइलें।
## 4. जोखिम और खुले प्रश्न
क्या टूट सकता है, पुष्टि की ज़रूरत वाली assumptions, और निर्णय की ज़रूरत वाले बिंदु।
## 5. योजना
implementation को छोटे steps में बाँटें, सत्यापन योग्य इकाइयों में क्रमबद्ध करें।
## नियम
- जब तक यह design अनुमोदित न हो जाए तब तक implement करना शुरू न करें।
- अज्ञात को "खुले प्रश्न" के अंतर्गत सूचीबद्ध करें; उन्हें अपनी assumptions से न भरें।यह क्यों काम करता है:AI सीधे implementation पर कूद जाता है और गलत दिशाओं का बड़े पैमाने पर उत्पादन करता है। बस "पहले design लिखें, अनुमोदन तक implement न करें" डालना rework को नाटकीय रूप से कम कर देता है।
बड़े बदलावों को चरणबद्ध करना
एक विशाल एक-साथ बदलाव को रोकता है। इसे छोटी, समीक्षा योग्य इकाइयों में बँटवाता है।
# बड़े बदलाव कैसे करें
## मूल सिद्धांत
एक विशाल बदलाव से बचें। इसे इस तरह बाँटें कि प्रत्येक step स्वतंत्र रूप से
समीक्षा योग्य, परीक्षण योग्य, और (आदर्श रूप से) deploy योग्य हो।
## चरण
1. अंतिम रूप तक ले जाने वाले बदलावों को छोटे, स्वतंत्र steps के अनुक्रम में
विघटित करें, और इसे प्रस्तुत करें।
2. प्रत्येक step के लिए, "क्या / क्यों / प्रभाव का दायरा" 1-2 लाइनों में लिखें।
3. प्रत्येक step के बाद, पूरा test suite चलाएँ और आगे बढ़ने से पहले हरा पुष्टि करें।
4. backward compatibility बनाए रखते हुए आगे बढ़ें (add -> migrate -> पुराने path को retire करें)।
## पूर्ण नियम
- एक साथ एक विस्तृत क्षेत्र को फिर से न लिखें और "बाद में सब एक साथ test करना" न करें।
- अगर कोई step बहुत बड़ा हो जाए, तो इसे और बाँटें।
- प्रत्येक step को ऐसी granularity पर रखें जिसे revert किया जा सके।
## पूर्णता की परिभाषा
सभी steps पूरे होने के बाद tests हरे हैं, और हर intermediate commit भी टूटा हुआ नहीं है।यह क्यों काम करता है:AI बड़े overhauls को "सब कुछ एक साथ फिर से लिखना" के रूप में करता है, और जब यह टूटता है, तो कारण को अलग करना असंभव हो जाता है। चरणों में बाँटना और हर एक पर हरा मजबूर करना आपको बड़े overhauls सुरक्षित रूप से करने देता है।
तैयार-पेस्ट करने योग्य पूरी फ़ाइलें - संचालन और governance
Code-review विशिष्ट
तुच्छ nitpicks की बाढ़ को रोकता है; इसे severity क्रम में रिपोर्ट करवाता है। review मानदंड तय करता है।
# Code review निर्देश
बदलावों की समीक्षा करें, उन्हें severity के अनुसार समूहित करें, और इस क्रम में रिपोर्ट करें:
1. CRITICAL - security holes, data loss, crashes, टूटा हुआ authentication
2. HIGH - logic bugs, race conditions, गायब error handling
3. MEDIUM - performance issues, गायब tests, भ्रमित करने वाले नाम
4. LOW - छोटे style nitpicks (केवल तभी जब कोई उच्च-स्तरीय issue न हो)
## कैसे रिपोर्ट करें
- प्रत्येक finding के लिए: file:line / क्या गलत है / यह क्यों मायने रखता है / एक ठोस fix।
- केवल सबसे छोटा प्रासंगिक snippet quote करें। पूरी फ़ाइल paste न करें।
- अगर कोई बदलाव सही है, तो स्पष्ट रूप से कहें। समस्याओं को मनगढ़ंत न करें।
## न करने योग्य बातें
- असली bugs को LOW nitpicks के ढेर के नीचे न दबाएँ।
- पूरी फ़ाइलें फिर से न लिखें। सबसे छोटा diff प्रस्तावित करें।
- जब तक वास्तविक नुकसान न हो, diff के दायरे से बाहर की लाइनों को flag न करें।
## Output
एक-पंक्ति निर्णय के साथ समाप्त करें: APPROVE / REQUEST CHANGES / BLOCK, कारण सहित।यह क्यों काम करता है:अकेला छोड़ दिया जाए, तो एक review AI तुच्छ nitpicks का बड़े पैमाने पर उत्पादन करता है। severity क्रम के साथ "अगर कोई समस्या न हो तो ऐसा कहें" और "मनगढ़ंत न करें" निर्दिष्ट करना शोर हटाता है और इसे उपयोग योग्य बनाता है।
Commit / PR संचालन नियम
बिना अनुरोध के pushes, विशाल commits, और लीक हुए secrets को रोकता है। Git ऑपरेशन के लिए सुरक्षा guardrails।
# Git / PR नियम
## Commits
- Conventional Commits का उपयोग करें: `type(scope): summary`
type: feat, fix, refactor, test, docs, chore।
- एक commit = एक logical बदलाव। इसे छोटा और समीक्षा योग्य रखें।
- body में, "what" के बजाय "why" लिखें।
## पूर्ण नियम
- जब तक कहा न जाए तब तक `git push` न करें।
- shared branches / main पर force-push, rebase, या amend न करें।
- secrets, .env, credentials, या बड़े binaries कमिट न करें।
- फ़ाइलों को नाम से add करें। `git add -A` से सब कुछ एक साथ न लाएँ।
## Pull requests
- शीर्षक 70 अक्षरों के भीतर। body "Summary" + "Test plan (checklist)" है।
- किसी भी breaking changes को नोट करें।
- merge न करें। PR बनाएँ और URL रिपोर्ट करें।यह क्यों काम करता है:Git ऑपरेशन "अपरिवर्तनीय दुर्घटनाओं" के प्रति प्रवण होते हैं। pushes, force-pushes, और secret leaks को "कभी X न करें" से नामित और प्रतिबंधित करना ही काम करता है।
Security-review विशिष्ट
इसे category के अनुसार vulnerabilities के लिए sweep करवाता है। false positives की तुलना में misses से बचने को प्राथमिकता देता है।
# Security review निर्देश
बदलावों को निम्नलिखित angles के विरुद्ध क्रम में जाँचें, और पाई गई किसी भी
समस्या को एक severity rating के साथ रिपोर्ट करें:
- गायब input validation (injection: SQL / command / XSS / SSRF)
- authentication/authorization में अंतराल (गायब permission checks, privilege escalation)
- secret exposure (hardcoded keys/tokens, logs में output)
- insecure defaults (अत्यधिक exposure, ढीला CORS, बिना validate किए redirects)
- dependencies में ज्ञात vulnerabilities, insecure crypto / RNG उपयोग
## कैसे रिपोर्ट करें
- प्रत्येक finding के लिए: location / attack scenario (इसका कैसे शोषण किया जा सकता है) / एक ठोस fix।
- जिन संदेहों के बारे में आप निश्चित नहीं हैं उन्हें "needs confirmation" के रूप में flag करें (उन्हें चुपचाप skip न करें)।
- अगर कोई समस्या न हो, तो उन angles के साथ "no issues" बताएँ जिन्हें आपने जाँचा।
## न करने योग्य बातें
- असली attack code या exploitation steps generate न करें (केवल fixes दिखाएँ)।यह क्यों काम करता है:security में, एक "miss" सबसे महँगा होता है। angles को सूचीबद्ध करना और "संदेहों को needs-confirmation के रूप में flag करें" कहना false positives के डर से चुप रहने वाले behavior को रोकता है।
Docker / infra सुरक्षा guardrails
container और infrastructure ऑपरेशन में अपरिवर्तनीय दुर्घटनाओं को रोकता है।
# Docker / infrastructure कार्य नियम
## पूर्ण नियम (विनाश रोकना सबसे पहले आता है)
- production या shared परिवेशों के विरुद्ध destructive कमांड खुद से न चलाएँ
(`docker system prune`, volumes हटाना, `down -v`, आदि)।
- images को fixed tags पर pin करें। `latest` पर निर्भर न रहें।
- secrets को environment variables / secret management के माध्यम से पास करें।
उन्हें Dockerfile या image में bake न करें।
- exposed ports और privileges (privileged, आदि) को न्यूनतम आवश्यक तक रखें।
## परंपराएँ
- Dockerfiles को multi-stage builds के साथ छोटा रखें, layer caching के प्रति सचेत रहें।
- एक non-root user के रूप में चलाएँ।
- बदलावों के बाद, रिपोर्ट करने से पहले locally build और start करके सत्यापित करें।
## पूर्णता की परिभाषा
`docker build` पास होता है, container start होता है, और health check / basic
operation की पुष्टि की जा सकती है।यह क्यों काम करता है:Infrastructure एक ऐसा क्षेत्र है जहाँ आप एक झटके में एक परिवेश को नष्ट कर सकते हैं। destructive कमांड पर रोक, latest निर्भरता से बचना, और secrets को bake न करना स्पष्ट लिखना सुरक्षा guardrails बनाता है।
Dependency update नियम
अनधिकृत dependency additions और major updates को रोकता है। supply-chain के प्रवेश बिंदु को कसता है।
# Dependency नियम
## पूर्ण नियम
- एक dependency जोड़ने से पहले, जाँचें कि क्या standard library या एक मौजूदा
dependency पर्याप्त है।
- एक नई dependency जोड़ते समय, इसके उद्देश्य, विकल्पों, और
maintenance status पर एक पंक्ति का नोट जोड़ें।
- major versions को खुद से न बढ़ाएँ (केवल तब जब कहा जाए)।
- lock files (package-lock.json, आदि) को खुद से फिर से generate न करें।
- संदिग्ध मूल वाले या अत्यंत कम stars या खराब maintenance वाले packages से बचें।
## चरण
1. addition या update का कारण बताएँ।
2. इसे जोड़ने के बाद, पुष्टि करें कि build और tests पास होते हैं।
3. पुष्टि करें कि license आपके use case के साथ टकराता नहीं है।
## पूर्णता की परिभाषा
dependency बदलाव के बाद build और tests पास होते हैं, और आप lock file में diff समझा सकते हैं।यह क्यों काम करता है:लापरवाह dependency additions और major updates build breakage और supply-chain दुर्घटनाओं के प्रवेश बिंदु हैं। "पहले जाँचें कि क्या मौजूदा पर्याप्त हैं" और "बिना अनुरोध के major updates न करें" काम करते हैं।
अगर आपकी निर्देश फ़ाइल "काम नहीं कर रही" ऐसा लगे
जब टेम्पलेट जोड़ने के बाद भी AI नियमों का पालन नहीं करता, तो इसका कारण अक्सर फ़ाइल का स्थान, विवरण का स्तर, या प्राथमिकता होती है। हम कारण के अनुसार समाधान समझाते हैं।
पढ़ें: AI आपके .md नियमों को क्यों अनदेखा करता है और इसे कैसे ठीक करें* प्रॉम्प्ट हिंदी में हैं; फ़ाइल टेम्पलेट के अंदर कमांड और पाथ अंग्रेज़ी में रखे गए हैं (वे परिवेश पर निर्भर हैं)। अंतिम बार अपडेट किया गया: 2026-05