व्यावहारिक अभ्यास: शून्य से एक TODO टूल में फ़ीचर जोड़ना और एक बार कमिट करना

📚 सीरीज़ नेविगेशन: पिछला लेख 33 Windows के महत्वपूर्ण बिंदु Windows पर आने वाली उन सभी मुश्किलों जैसे - पाथ (paths), न्यूलाइन कैरेक्टर (newlines), terminal और सैंडबॉक्स अंतर - को एक-एक करके समझाता है। इस लेख में हम किसी नए फ़ीचर के बारे में बात नहीं करेंगे, बल्कि एक अधिक रोमांचक काम करेंगे: पिछले तीस से अधिक अध्यायों में सीखे गए पुर्जों को अपने हाथों से जोड़कर एक चालू मशीन बनाना। अगला लेख 35 कमांड और कॉन्फ़िगरेशन चीट शीट पूरे लेख में उपयोग किए गए कमांड और कॉन्फ़िगरेशन कुंजियों (keys) को एक ही तालिका में संकलित करेगा, जिसे एक संदर्भ पुस्तक (reference book) की तरह कभी भी देखा जा सकता है।

दोस्तों, आज कोई क्लास नहीं है, चलिए मिलकर शून्य से एक छोटी सी चीज़ बनाते हैं।

मेरे पास एक बहुत ही सरल कमांड-लाइन टूल है - Python में लिखा गया todo.py। यह TODO जोड़ सकता है और उन्हें सूचीबद्ध (list) कर सकता है, बस यही दो फ़ीचर हैं। इसमें एक साफ़ कमी है: जो काम जोड़ा गया है, उसे पूरा होने के बाद हटाया नहीं जा सकता, और आप केवल सूची को लंबा होते हुए देख सकते हैं। इस लेख में, हम 'TODO हटाने' के इस फ़ीचर को पृष्ठभूमि बताने, काम सौंपने (task delegation), अनुमति (permissions) सेट करने से लेकर स्व-सत्यापन (self-validation) और git कमिट तक पूरी तरह से पूरा करेंगे।

सीधे शब्दों में कहें तो, पिछले हर लेख में यह बताया गया है कि "किसी एक पुर्जे का उपयोग कैसे करें" - AGENTS.md कैसे लिखें, प्रॉम्प्ट कैसे दें, अनुमति कैसे सेट करें, git उसे कैसे सौंपें। अलग से देखने पर ये सभी समझ में आते हैं, लेकिन जब वास्तव में किसी काम की बात आती है, तो इन पुर्जों को किस क्रम में और कैसे जोड़ना है, इसमें बहुत से लोग भ्रमित हो जाते हैं। यह लेख वही "असेम्बली ड्राइंग" (assembly drawing) है।

मैं यह मानकर नहीं चलूँगा कि आपके कंप्यूटर पर यह प्रोजेक्ट पहले से है। सेक्शन 01 में मैं आपको दो मिनट में यह todo.py बनाना सिखाऊँगा, जिसके बाद आप मेरे हर कदम का अनुसरण कर सकते हैं और अपनी आँखों से परिणाम देख सकते हैं। यह एक "करके सीखने" (follow-along) वाला लेख है, न कि केवल "पढ़कर समझने" वाला - बिना हाथ आजमाए केवल पढ़ना, न पढ़ने के बराबर है।

इस लेख को पूरा पढ़ने के बाद, आपको मिलेगा:

शून्य से कमिट तक का एक संपूर्ण विकास पथ (development workflow), जहां हर कदम पिछले किसी लेख से मेल खाता है, जो आपकी आदत बन जाएगा
एक AGENTS.md जिसे आप कॉपी कर सकते हैं, एक पूर्ण प्रॉम्प्ट संदेश, और वास्तविक कमांड व अपेक्षित आउटपुट
"Codex को स्वयं टेस्ट चलाने देना और लक्ष्य पूरा होने तक काम बंद न करना" का व्यावहारिक तरीका
Codex को एक साफ़ git कमिट सौंपने और आपके द्वारा अंतिम समीक्षा करने की प्रक्रिया
एक संपूर्ण मिलान तालिका कि "यह कदम किस लेख के ज्ञान का उपयोग कर रहा है", जिसे आप भविष्य में किसी भी प्रोजेक्ट में लागू कर सकते हैं

⚠️ नीचे दिए गए सभी विशिष्ट कमांड, पैरामीटर और डिफ़ॉल्ट व्यवहार Codex के आधिकारिक दस्तावेज़ पर आधारित हैं; मॉडल के नाम और इंटरफ़ेस टेक्स्ट जैसे बदलते रहने वाले विवरणों के लिए अपने स्थानीय codex --help और वास्तविक प्रदर्शन को देखें, इस लेख में उन्हें हार्डकोड नहीं किया गया है।

01 पहले "निशाना" तय करें: दो मिनट में एक TODO टूल बनाएं

काम शुरू करने से पहले आपके पास कोई चीज़ होनी चाहिए। चलिए पहले इस प्रोजेक्ट को मैन्युअल रूप से बनाते हैं — इसके बाद की सभी गतिविधियाँ इसी के इर्द-गिर्द घूमेंगी।

सादृश्य: यह घर को सजाने से पहले एक खाली ढांचा (rough structure) तैयार करने जैसा है। बिना घर के, बेहतरीन डिज़ाइन भी ज़मीन पर नहीं उतर सकता। यह todo.py हमारा खाली ढांचा है, जो इतना सरल है कि इसे एक नज़र में देखा जा सकता है, लेकिन "सभी महत्वपूर्ण दीवारें मौजूद हैं" — इसमें डेटा है, फ़ंक्शन हैं और एक एंट्री पॉइंट है, जो हमारे लिए एक नई दीवार (हटाने का फ़ीचर) जोड़ने के लिए पर्याप्त है।

एक खाली फ़ोल्डर ढूंढें, उसमें todo.py बनाएं और नीचे दी गई सामग्री लिखें (Mac / Linux / Windows सभी के लिए समान है, बस Python 3 होना चाहिए):

python

# todo.py
import sys

TODOS = []

def add(item):
    TODOS.append(item)
    print(f"已添加：{item}")

def list_todos():
    if not TODOS:
        print("（暂无待办）")
        return
    for i, item in enumerate(TODOS, 1):
        print(f"{i}. {item}")

def main():
    if len(sys.argv) < 2:
        print("用法：python todo.py [add <内容> | list]")
        return
    cmd = sys.argv[1]
    if cmd == "add":
        add(" ".join(sys.argv[2:]))
    elif cmd == "list":
        list_todos()
    else:
        print(f"未知命令：{cmd}")

if __name__ == "__main__":
    main()

इसे बनाने के बाद, यह जांचने के लिए चलाएं कि यह काम कर रहा है या नहीं:

bash

python todo.py add 买咖啡豆
python todo.py list

अपेक्षित आउटपुट:

text

已添加：买咖啡豆
（暂无待办）

ध्यान दें कि यहाँ एक "विशेषता" है — चूंकि हर रन एक नया प्रोसेस होता है, इसलिए TODOS मेमोरी लिस्ट चलने के बाद साफ़ हो जाती है, इसलिए list कमांड चलाने पर वह खाली दिखाई देती है। यह कोई बग नहीं है, यह हमारे इस छोटे से टूल की सेटिंग है, इसे याद रखें, सेक्शन 05 में सत्यापन के दौरान हम इसका उपयोग करेंगे।

अंत में, इसे Git के नियंत्रण में लाएं (बाद में कमिट करने के लिए):

bash

git init
git add todo.py
git commit -m "init: TODO 小工具初版"

आपको Git द्वारा पहली कमिट बनाने की रिपोर्ट दिखाई देनी चाहिए। निशाना तय हो चुका है, अब आधिकारिक तौर पर काम शुरू करते हैं।

💡 संक्षेप में: पहले दो मिनट में मैन्युअल रूप से todo.py का न्यूनतम चलने वाला संस्करण बनाएं और इसे Git में जोड़ें, ताकि बाद के हर कदम का कोई न कोई लक्ष्य हो।

02 पहला कदम: `AGENTS.md` लिखें, प्रोजेक्ट की पृष्ठभूमि एक बार में स्पष्ट करें

Codex जब पहली बार किसी प्रोजेक्ट में आता है, तो वह एक खाली पन्ने की तरह होता है — उसे नहीं पता होता कि यह कौन सा प्रोजेक्ट है, इसे कैसे चलाना है या इसके क्या नियम हैं। काम शुरू करने से पहले सबसे पहला काम उसे एक "हैंडओवर लिस्ट" (handover list) देना है। यह वही चीज़ है जो 11 प्रोजेक्ट निर्देशिका AGENTS.md में बताई गई है।

सादृश्य: यह किसी अस्थायी कर्मचारी के लिए "साइट निर्देश" (site notice) चिपकाने जैसा है। कर्मचारी कितना भी कुशल क्यों न हो, अगर उसे यह नहीं पता कि "मेन स्विच कहाँ है, कौन सी दीवार नहीं तोड़नी है, और कचरा कहाँ फेंकना है," तो वह मदद करने के बजाय काम बिगाड़ सकता है। AGENTS.md दरवाजे पर चिपकाए गए उसी निर्देश की तरह है, जिसे Codex काम शुरू करने से पहले देखता है।

प्रोजेक्ट के रूट फ़ोल्डर में AGENTS.md बनाएं और इसे कॉपी करें (छोटा, सटीक और केवल वही लिखें जो वास्तव में काम का हो):

markdown

# TODO 小工具

一个命令行待办工具，纯 Python 3 标准库，无第三方依赖。

## 运行
- 添加：`python todo.py add <内容>`
- 列出：`python todo.py list`

## 约定
- 只用标准库，不要引入任何第三方包
- 新功能要保持现有命令行风格（`python todo.py <命令> <参数>`）
- 改完必须能用上面的命令跑通

## 测试
- 如果还没有测试文件，用标准库 `unittest` 新建 `test_todo.py`
- 改完跑：`python -m unittest`

अध्याय 11 के उस कड़वे सबक को याद रखें — कभी भी काम के नियमों को सौ लाइनों की बकवास के बीच न छुपाएं। मैंने पिछले साल यह गलती की थी, AGENTS.md में 140 लाइनें लिख दी थीं, और सबसे महत्वपूर्ण नियम "npm का उपयोग न करें" 140वीं लाइन में छुपा दिया था। Codex का ध्यान पहले ही भटक गया था, और उसने तुरंत npm install चला दिया। इसलिए मैंने इस निर्देश को 20 लाइनों से कम रखा है: इसका हर एक नियम इस काम के लिए ज़रूरी है, इसमें कंपनी का परिचय या विज़न जैसी कोई फ़ालतू बात नहीं है।

💡 संक्षेप में: काम शुरू करने से पहले एक संक्षिप्त और सटीक AGENTS.md लिखें, जिसमें स्पष्ट करें कि "कैसे चलाएं, क्या नियम हैं, कैसे टेस्ट करें", और केवल वही लिखें जो काम का हो।

03 दूसरा कदम: काम सौंपना — लक्ष्य + दायरा + बाधाएं + स्वीकृति, सब कुछ एक बार में स्पष्ट करें

निर्देश तैयार हैं, अब काम सौंपने का समय है। काम सौंपने की गुणवत्ता सीधे तय करती है कि किया गया काम कितना सटीक होगा। यह 13 प्रॉम्प्ट लिखने की कला का मूल सिद्धांत है: यदि आप केवल "हटाने का फ़ीचर जोड़ें" जैसी अधूरी जानकारी देंगे, तो उसे खुद ही अंदाज़ा लगाना पड़ेगा; लेकिन जब आप "चार चीज़ें" स्पष्ट कर देंगे, तो वह भटकेगा नहीं।

सादृश्य: काम सौंपना किसी कारीगर को वर्क ऑर्डर देने जैसा है। आप केवल यह नहीं कह सकते कि "इस कमरे को बदल दो," बल्कि आपको स्पष्ट लिखना होगा: इसे कैसा बनाना है (लक्ष्य), किस दीवार को छूना है और किसे नहीं (दायरा), किस सामग्री का उपयोग करना है (बाधाएं), और काम पूरा कैसे माना जाएगा (स्वीकृति)। इनमें से कोई भी चीज़ छूट गई, तो कारीगर को खुद अंदाज़ा लगाना पड़ेगा, और गलती होने पर आपको दोबारा काम कराना होगा।

प्रोजेक्ट में जाएं और एक Codex सत्र (session) शुरू करें:

bash

codex

फिर इस पूर्ण संरचना वाले प्रॉम्प्ट को उसे दें (आप इसे सीधे कॉपी कर सकते हैं):

text

todo.py में एक "TODO हटाने" का फ़ीचर जोड़ें।

लक्ष्य: `python todo.py done <序号>` का समर्थन करें, जो list द्वारा दिखाए गए नंबर के अनुसार संबंधित TODO को हटाए।
दायरा: केवल todo.py को बदलें, परीक्षण फ़ाइल जोड़ें/संशोधित करें; कमांड-लाइन की समग्र शैली को न बदलें, कोई भी थर्ड-पार्टी पैकेज न जोड़ें।
बाधाएं: नंबर 1 से शुरू होने चाहिए; यदि नंबर सीमा से बाहर हो या संख्या न हो, तो क्रैश होने के बजाय एक अनुकूल संदेश प्रदर्शित करें।
स्वीकृति: unittest के माध्यम से "सामान्य निष्कासन, सीमा से बाहर, और संख्या न होना" इन तीनों स्थितियों को कवर करें, और `python -m unittest` पूरी तरह सफल (all green) होना चाहिए।

नीचे दिए गए दोनों तरीकों की तुलना करें, अंतर स्पष्ट है:

❌ अधूरा काम सौंपना	✅ पूर्ण चार-सूत्रीय काम सौंपना
"हटाने का फ़ीचर जोड़ें"	स्पष्ट कमांड प्रारूप `done <序号>`
यह नहीं बताया कि कहाँ बदलाव करना है और कितना	दायरा सीमित किया: केवल `todo.py` + टेस्ट
यह नहीं बताया कि त्रुटियों को कैसे संभालना है	बाधाएं: सीमा से बाहर / संख्या न होने पर अनुकूल संदेश
यह नहीं बताया कि काम पूरा कब माना जाएगा	स्वीकृति: तीन प्रकार के टेस्ट केस + `unittest` पूरी तरह सफल

मेरा अपना अनुभव है: स्वीकृति मानदंडों को प्रॉम्प्ट में लिखना सबसे प्रभावी होता है। पिछले महीने मैंने Codex से एक पार्सिंग स्क्रिप्ट में त्रुटि सहनशीलता (fault tolerance) जोड़ने को कहा था। पहली बार मैंने आलस्य में स्वीकृति मानदंड नहीं लिखे, उसने "काम पूरा कर दिया" लेकिन खाली फ़ाइलों पर स्क्रिप्ट क्रैश हो गई; जब मैंने "खाली फ़ाइल, बहुत बड़ी फ़ाइल और विकृत कोड तीनों में क्रैश न होना" जोड़कर दोबारा काम सौंपा, तो यह एक बार में ही सही हो गया। Codex की क्षमता अक्सर इस बात से सीमित होती है कि आप उससे कैसे पूछते हैं।

💡 संक्षेप में: काम सौंपते समय "लक्ष्य + दायरा + बाधाएं + स्वीकृति" इन चारों चीज़ों को स्पष्ट रूप से बताएं; जहाँ भी कमी होगी, उसे खुद ही अंदाज़ा लगाना पड़ेगा। विशेष रूप से स्वीकृति मानदंडों को तय करना उसे यह बताने जैसा है कि "काम पूरा होने तक रुकना नहीं है"।

04 तीसरा कदम: अनुमतियां सेट करें — उसे फाइलें बदलने और टेस्ट चलाने दें, लेकिन नियंत्रण में रखें

काम सौंपने से पहले (या सत्र शुरू करते समय), यह सोचना ज़रूरी है: हम Codex को कितनी छूट देना चाहते हैं? यह 15 अनुमतियां, सैंडबॉक्स और स्वीकृति का विषय है — सैंडबॉक्स तय करता है कि "वह कहाँ तक जा सकता है" और स्वीकृति तय करती है कि "काम करने से पहले वह आपसे पूछता है या नहीं"।

सादृश्य: यह घर में आने वाले कर्मचारी को एक्सेस कार्ड देने जैसा है। यदि कार्ड की अनुमति बहुत कम है, तो उसे हर छोटे काम के लिए आपको बुलाना पड़ेगा, जो परेशान करने वाला है; यदि अनुमति बहुत अधिक है, तो वह आपके बेडरूम में जाकर दराजें टटोल सकता है, जो जोखिम भरा है। इस काम के लिए, हमें चाहिए कि "वह इस प्रोजेक्ट फ़ोल्डर के अंदर फ़ाइलें बदल सके और टेस्ट चला सके, लेकिन इस सीमा से बाहर न जा सके"।

इस काम के लिए, "वर्कस्पेस लिखने योग्य + आवश्यकतानुसार स्वीकृति" (workspace-write + on-request) का स्तर सुझाया जाता है — वह प्रोजेक्ट फ़ोल्डर में स्वतंत्र रूप से फ़ाइलें बदल सकता है (बनाने और हटाने सहित) और python -m unittest चला सकता है, लेकिन यदि वह वर्कस्पेस से बाहर की फ़ाइलों को बदलने या इंटरनेट से कनेक्ट करने का प्रयास करेगा, तो वह रुककर आपसे पूछेगा। कमांड-लाइन पर इसे ऐसे निर्दिष्ट करें:

bash

codex --sandbox workspace-write --ask-for-approval on-request

या इसे डिफ़ॉल्ट बनाने के लिए ~/.codex/config.toml (TOML प्रारूप में कॉन्फ़िगरेशन फ़ाइल) में लिखें:

toml

# ~/.codex/config.toml
sandbox_mode = "workspace-write"
approval_policy = "on-request"

अध्याय 15 के अनुसार इन तीन डिफ़ॉल्ट मानों को याद रखें, ताकि आप किसी समस्या में न फंसें:

आपकी सोच	वास्तविक डिफ़ॉल्ट (workspace-write के तहत)
वह स्वतंत्र रूप से इंटरनेट से पैकेज डाउनलोड कर सकता है	नेटवर्क डिफ़ॉल्ट रूप से बंद होता है
वह `.git` फ़ोल्डर को बदल सकता है	`.git` डिफ़ॉल्ट रूप से केवल-पठन (read-only) सुरक्षित होता है
वह कहीं भी बदलाव कर सकता है	केवल वर्कस्पेस फ़ोल्डर के भीतर लिखने की अनुमति होती है

कभी भी काम आसान बनाने के चक्कर में sandbox_mode को danger-full-access के रूप में सेट न करें। पिछले साल मैंने एक बिना Git इनिशियलाइज़ किए गए अस्थायी फ़ोल्डर में उससे "बेकार फ़ाइलें साफ़ करने" को कहा था। बिना वर्कस्पेस की सीमा के, वह मेरे होम फ़ोल्डर में खोजने लगा — जब मैंने उसे रोकने के लिए Esc दबाया, तब मेरी सांसें थम सी गई थीं। इस TODO प्रोजेक्ट के लिए workspace-write काफी है, नियंत्रण ढीला न करें।

💡 संक्षेप में: काम शुरू करने से पहले सैंडबॉक्स और स्वीकृति से सीमाएं तय करें — workspace-write + on-request उसे प्रोजेक्ट में काम करने और टेस्ट करने की अनुमति देता है लेकिन सीमा से बाहर नहीं जाने देता; danger-full-access को डिफ़ॉल्ट बनाना जोखिम भरा है।

05 चौथा कदम: उसे स्वयं सत्यापित करने दें — टेस्ट चलाएं, और सफल होने तक काम बंद न करें

Codex का यह कहना कि "काम पूरा हो गया" इसका मतलब यह नहीं है कि उसने सब कुछ सही किया है। सबसे आसान तरीका यह है कि उसे खुद ही टेस्ट चलाने दें और यह पुष्टि करने दें कि सब कुछ सफल है, जिसके बाद ही वह आपको काम सौंपे — आप केवल अंतिम स्वीकृति देने वाले अधिकारी होंगे। यह कदम अध्याय 13 के "स्वीकृति मानदंडों" को वास्तविक रूप देता है।

सादृश्य: यह शेफ द्वारा परोसने से पहले खुद डिश चखने जैसा है। काम सौंपते समय (सेक्शन 03) आपने पहले ही लिख दिया था कि "python -m unittest का सफल होना" स्वीकृति मानदंड है, जो उसे पहले ही एक पैमाना देने जैसा है। अब Codex बदलाव करने के बाद इस पैमाने से जांच करेगा: टेस्ट चलाएगा → देखेगा कि क्या सब सफल है → यदि नहीं, तो सुधार जारी रखेगा। आपको उसके हर कदम पर नज़र रखने की ज़रूरत नहीं है, वह आपके पास तभी आएगा जब वह स्वयं जांच कर सुनिश्चित कर लेगा कि सब ठीक है।

चूंकि हमने काम सौंपते समय ही टेस्ट की आवश्यकताओं को AGENTS.md (सेक्शन 02 में ## 测试) और प्रॉम्प्ट में लिख दिया था, Codex आमतौर पर स्वयं एक test_todo.py बनाएगा और बदलावों के बाद उसे चलाएगा। जब वह टेस्ट चलाएगा, तो आपको टर्मिनल पर कुछ ऐसा दिखाई दे सकता है:

text

...
----------------------------------------------------------------------
Ran 3 tests in 0.003s

OK

OK और Ran 3 tests देखना यह दर्शाता है कि उसने तीनों प्रकार के टेस्ट केस (सामान्य निष्कासन, सीमा से बाहर, संख्या न होना) पास कर लिए हैं। यदि वह इसे खुद न चलाए, तो आप उसे याद दिला सकते हैं:

text

python -m unittest चलाएं और परिणाम दिखाएं; यदि कोई टेस्ट फेल होता है, तो उसे सफल होने तक सुधारें।

यहाँ [सेक्शन 01] में बताई गई बात पर ध्यान दें: चूंकि TODOS एक मेमोरी लिस्ट है जो प्रोसेस खत्म होने पर साफ़ हो जाती है, आप कमांड-लाइन पर मैन्युअल रूप से "add, done, list" चलाकर इसे सत्यापित नहीं कर सकते — list हमेशा खाली रहेगा। इसलिए इसे सत्यापित करने का सही तरीका केवल यूनिट टेस्ट है, जहाँ एक ही प्रोसेस में add करने के बाद done किया जाता है और फिर जांच की जाती है। यह दिखाता है कि: जिस काम के लिए टेस्ट चलाने की आवश्यकता है, उसे केवल आँखों से देखकर पास न करें।

मेरा अपना नियम है: जब भी Codex कोड बदलता है, मैं हमेशा अंत में कहता हूँ "टेस्ट चलाएं और परिणाम दिखाएं"। एक बार मैंने बिना टेस्ट चलाए ही उसके बदलावों को स्वीकार कर लिया क्योंकि देखने में कोड ठीक लग रहा था, लेकिन बाद में प्रोडक्शन में एक समस्या आ गई — तब से मैं इस कदम को कभी नहीं छोड़ता।

💡 संक्षेप में: काम सौंपते समय स्वीकृति में टेस्ट कमांड शामिल करें, और Codex को काम सौंपने से पहले स्वयं unittest चलाने दें; मेमोरी-आधारित लॉजिक के लिए टेस्ट आवश्यक हैं, केवल देखने से काम नहीं चलेगा।

06 पांचवां कदम (वैकल्पिक): उप-एजेंट (sub-agents) या MCP को काम पर कब लगाना है

इस छोटे से TODO काम के लिए एक मुख्य एजेंट ही काफी है, हमें उप-एजेंट या MCP की आवश्यकता नहीं है। लेकिन इस व्यावहारिक अभ्यास (capstone) का उद्देश्य आपको यह समझाना है कि "हथियार कब अपग्रेड करने हैं," इसलिए इस सेक्शन में सीमाओं को स्पष्ट किया गया है — यह जानना कि कब उपयोग नहीं करना है, उतना ही महत्वपूर्ण है जितना यह जानना कि कब करना है।

सादृश्य: यह काम के दौरान बाहरी मदद लेने जैसा है। यदि केवल एक दीवार पर पेंट करना है, तो आप खुद कर सकते हैं; लेकिन अगर दस कमरों में पेंट करना हो और बाहरी मानकों की जांच करनी हो, तो आपको मदद और संदर्भ की आवश्यकता होगी। उप-एजेंट आपके मददगार हैं, और MCP बाहरी जानकारी का माध्यम है।

बस इन दो नियमों को याद रखें:

काम "बहुत अधिक हो और एक साथ किया जा सकता हो" → उप-एजेंट को बुलाएं। उदाहरण के लिए, केवल एक फ़ीचर हटाने के बजाय, यदि आपको 20 फ़ाइलों में पुराने कोड को बदलना है, तो मुख्य एजेंट को काम बांटने दें और कई उप-एजेंटों को एक साथ काम करने दें। यह एक अकेले एजेंट के काम करने से बहुत तेज़ होगा। इसे कैसे बांटना और सौंपना है, इसके लिए 21 उप-एजेंट देखें — याद रखें कि वे केवल आपके कहने पर ही काम बांटेंगे, खुद से नहीं।
काम में "बाहरी दुनिया तक पहुँच" चाहिए हो → MCP जोड़ें。 उदाहरण के लिए, हटाने से पहले यह जांचना हो कि क्या यह आइटम कंपनी के किसी बाहरी सिस्टम में आर्काइव है, तो यह Codex की अपनी क्षमता से बाहर है। ऐसी स्थिति में MCP एक इंटरफ़ेस के रूप में काम करता है, जैसा कि 20 बाहरी टूल के लिए MCP में बताया गया है।

कार्य	अपग्रेड की आवश्यकता	कारण
`todo.py` में हटाने का फ़ीचर जोड़ना	❌ नहीं	एकल फ़ाइल में छोटा बदलाव, मुख्य एजेंट पर्याप्त है
20 फ़ाइलों से पुराना कोड हटाना	✅ उप-एजेंट	काम बड़ा है और एक साथ हो सकता है, बांटना बेहतर है
हटाने से पहले बाहरी सिस्टम में स्थिति जांचना	✅ MCP	Codex बाहरी दुनिया तक नहीं पहुँच सकता, इंटरफ़ेस चाहिए

सच कहें तो, नए लोग अक्सर यह गलती करते हैं कि वे "जहाँ ज़रूरत न हो वहाँ भी बड़े उपकरणों का उपयोग करते हैं" — तीन लाइनों के बदलाव के लिए भी पांच उप-एजेंट बना देते हैं, जो केवल काम को जटिल बनाता है। पहले सबसे सरल तरीके से काम पूरा करें, और यदि काम बहुत बड़ा हो या बाहरी दुनिया से जुड़ना हो, तभी अपग्रेड करें।

💡 संक्षेप में: छोटे कामों के लिए एक मुख्य एजेंट पर्याप्त है, बड़े उपकरणों का उपयोग न करें; काम बड़ा होने पर उप-एजेंट (अध्याय 21) और बाहरी संपर्क के लिए MCP (अध्याय 20) का उपयोग करें।

07 अंतिम कदम: `git` कमिट — वह ड्राफ्ट तैयार करेगा, आप पुष्टि करेंगे

जब फ़ंक्शन सही काम कर रहा हो और टेस्ट पास हो जाएं, तो अंतिम काम इस बदलाव को साफ़-सुथरे तरीके से कमिट करना है। यह 26 Git और GitHub एकीकरण का हिस्सा है और पूरी प्रक्रिया का समापन है: समीक्षा और कमिट संदेश वह लिखेगा, लेकिन कमिट करने का निर्णय आपका होगा।

सादृश्य: यह अनुबंध पर हस्ताक्षर करने जैसा है। एक पक्ष नियम तैयार करता है (Codex बदलाव देखता है और कमिट संदेश लिखता है), और दूसरा पक्ष उनकी जांच करके हस्ताक्षर करता है (आप समीक्षा करते हैं और कमिट करते हैं)। कमिट इतिहास में दर्ज होता है, इसलिए इसकी पुष्टि आपको करनी होगी。

सत्र में सीधे कहें:

text

इस बदलाव को कमिट करें: पहले git status और git diff देखें, फिर हिंदी में एक कमिट संदेश लिखें जिसमें feat: प्रीफ़िक्स हो। कमिट करने से पहले मुझे बदलाव और संदेश दिखाएं।

Codex आमतौर पर कमिट करने के लिए इस प्रक्रिया का पालन करता है:

text

1. git status   —— देखें कि क्या बदलाव हुए हैं
2. git diff      —— बदलावों की विस्तार से समीक्षा करें
3. git add       —— जिन बदलावों को कमिट करना है उन्हें स्टेज करें
4. git commit    —— संदेश लिखें और कमिट बनाएं

⚠️ प्रायोगिक फ़ीचर, बदल सकता है: Codex को स्वयं git commit चलाने की अनुमति देना codex_git_commit नाम के एक प्रायोगिक स्विच पर निर्भर करता है, जो डिफ़ॉल्ट रूप से बंद होता है। इसलिए अधिक सुरक्षित तरीका यह है: Codex से कहें कि वह बदलावों की समीक्षा करे और कमिट संदेश लिखे, लेकिन git commit कमांड आप स्वयं चलाएं — इससे आपको उसका ड्राफ्ट भी मिल जाएगा और नियंत्रण भी आपके हाथ में रहेगा।

git commit पर सुरक्षा क्यों होती है? क्योंकि workspace-write सैंडबॉक्स के तहत, .git फ़ोल्डर केवल-पठन के लिए सुरक्षित होता है (जैसा कि अध्याय 15 में बताया गया है), इसलिए कमिट जैसे महत्वपूर्ण कार्यों के लिए आपकी अनुमति आवश्यक होती है। यह आपको समीक्षा करने का मौका देता है: क्या सही फ़ाइलें चुनी गई हैं, क्या संदेश सही है, और क्या कोई अनचाही फ़ाइल (जैसे अस्थायी फ़ाइलें) कमिट में तो नहीं जा रही है। पुष्टि के बाद ही आगे बढ़ें। आप इस तरह के कमिट संदेश की अपेक्षा कर सकते हैं:

text

feat: 新增按序号删除待办功能并补充 unittest 用例

कमिट करने के बाद, स्वयं इसकी जांच करें:

bash

git log --oneline -1

अपेक्षित आउटपुट (हैश मान आपके पास अलग हो सकता है):

text

a1b2c3d feat: 新增按序号删除待办功能并补充 unittest 用例

मेरी आदत है कि मैं कभी भी git commit को पूरी तरह से ऑटोपायलट पर नहीं छोड़ता। अध्याय 15 का नियम — "समीक्षा वह करे, अनुमति आप दें" — यहाँ सबसे महत्वपूर्ण है। यह सिर्फ गलत संदेश से बचने के लिए नहीं है, बल्कि यह सुनिश्चित करने के लिए है कि कोई अधूरा काम कमिट न हो जाए, क्योंकि बाद में इतिहास को साफ़ करना अधिक कठिन होता है।

💡 संक्षेप में: कमिट का ड्राफ्ट Codex को तैयार करने दें (बदलाव देखना, संदेश लिखना), लेकिन git commit आप स्वयं करें — यह "समीक्षा वह करे, अनुमति आप दें" के नियम का पालन करता है।

08 पूरी प्रक्रिया पर एक नज़र: प्रत्येक कदम किस अध्याय से संबंधित है

पूरी प्रक्रिया को देखने पर आपको समझ आएगा कि ये अध्याय अलग-अलग नहीं हैं, बल्कि एक ही असेंबली लाइन के हिस्से हैं। आप इस तालिका को भविष्य में किसी भी प्रोजेक्ट के लिए उपयोग कर सकते हैं:

कदम	विवरण	संबंधित अध्याय
① प्रोजेक्ट शुरू करना	न्यूनतम `todo.py` बनाना और Git में जोड़ना	यह अध्याय
② निर्देश लिखना	`AGENTS.md` में पृष्ठभूमि, नियम और टेस्ट बताना	11
③ काम सौंपना	लक्ष्य + दायरा + बाधाएं + स्वीकृति को स्पष्ट करना	13
④ अनुमतियां	`workspace-write` + `on-request` सेट करना	15
⑤ अपग्रेड (वैकल्पिक)	उप-एजेंट या MCP का उपयोग करना	21, 20
⑥ सत्यापन	`unittest` चलाकर सभी टेस्ट पास करना	13
⑦ कमिट	Codex द्वारा ड्राफ्ट तैयार करना और आपके द्वारा कमिट करना	26

यह क्रम यादृच्छिक नहीं है, बल्कि वास्तविक विकास का प्राकृतिक प्रवाह है: पहले उसे प्रोजेक्ट समझाएं (निर्देश), फिर बताएं कि क्या चाहिए (काम सौंपना), फिर उसकी सीमाएं तय करें (अनुमतियां), काम के बाद जांचें (परीक्षण), और अंत में सहेजें (कमिट)।

मॉडल और उसकी क्षमता के लिए मैंने डिफ़ॉल्ट सेटिंग्स का उपयोग किया है — फ़्लैगशिप gpt-5.5 + डिफ़ॉल्ट क्षमता (आमतौर पर medium)। इस छोटे काम के लिए यह काफी है, इसे high पर सेट करने की आवश्यकता नहीं है। यदि आप किसी बहुत बड़े बदलाव पर काम कर रहे हैं, तो 30 मॉडल चयन के अनुसार सेटिंग बदलें। मैंने इस लेख में जानबूझकर डिफ़ॉल्ट सेटिंग्स का उपयोग किया है ताकि आप देख सकें कि प्रक्रिया ही मुख्य है, सेटिंग्स को बदलना केवल एक अतिरिक्त सहायता है।

💡 संक्षेप में: निर्देश → काम सौंपना → अनुमतियां → (आवश्यकतानुसार अपग्रेड) → सत्यापन → कमिट; यह वास्तविक विकास का प्राकृतिक क्रम है। हर अध्याय इस असेंबली लाइन का एक हिस्सा है, और इन्हें एक साथ जोड़ना ही "Codex का सही उपयोग" है।

निष्कर्ष

इस लेख में हमने कोई नया फ़ीचर नहीं सीखा, बल्कि सभी टुकड़ों को एक साथ जोड़ना सीखा:

प्रोजेक्ट शुरू करना: एक न्यूनतम todo.py बनाएं और इसे Git में जोड़ें ताकि हर कदम का एक उद्देश्य हो।
निर्देश: एक छोटा और सटीक AGENTS.md लिखें, केवल वही जानकारी दें जो आवश्यक हो।
काम सौंपना: "लक्ष्य + दायरा + बाधाएं + स्वीकृति" को स्पष्ट करें। स्वीकृति मानदंडों को शामिल करना काम पूरा होने की गारंटी है।
अनुमतियां: workspace-write + on-request सेट करें, कभी भी danger-full-access को डिफ़ॉल्ट न बनाएं।
सत्यापन: उसे स्वयं unittest चलाने दें। कोड को केवल देखने के बजाय हमेशा टेस्ट से जांचें।
कमिट: Codex कमिट का ड्राफ्ट बनाएगा और आप उसकी पुष्टि करेंगे — "समीक्षा वह करे, अनुमति आप दें" का पालन करें।

अब आप सक्षम हैं: किसी भी आवश्यकता को व्यवस्थित तरीके से पूरा करने में। अब आप सीधे काम शुरू करने के बजाय "निर्देश → काम सौंपना → अनुमतियां → सत्यापन → कमिट" के क्रम का पालन कर सकते हैं। यही "Codex के बारे में जानने" और "उसका सही उपयोग करने" के बीच का अंतर है।

अगले लेख 35 कमांड और कॉन्फ़िगरेशन चीट शीट में, हम Codex से संबंधित सभी कमांड, कॉन्फ़िगरेशन और स्लैश कमांड को एक त्वरित संदर्भ तालिका में शामिल करेंगे। इस अभ्यास को करने के बाद, सोचें: इस प्रक्रिया में से कौन से कमांड आपको याद हैं और किन्हें आपको दोबारा देखने की आवश्यकता होगी? वह तालिका उन्हीं कमांड के लिए है जिन्हें आपको देखने की आवश्यकता हो सकती है।

व्यावहारिक अभ्यास: शून्य से एक TODO टूल में फ़ीचर जोड़ना और एक बार कमिट करना ​

01 पहले "निशाना" तय करें: दो मिनट में एक TODO टूल बनाएं ​

02 पहला कदम: AGENTS.md लिखें, प्रोजेक्ट की पृष्ठभूमि एक बार में स्पष्ट करें ​

03 दूसरा कदम: काम सौंपना — लक्ष्य + दायरा + बाधाएं + स्वीकृति, सब कुछ एक बार में स्पष्ट करें ​

04 तीसरा कदम: अनुमतियां सेट करें — उसे फाइलें बदलने और टेस्ट चलाने दें, लेकिन नियंत्रण में रखें ​

05 चौथा कदम: उसे स्वयं सत्यापित करने दें — टेस्ट चलाएं, और सफल होने तक काम बंद न करें ​

06 पांचवां कदम (वैकल्पिक): उप-एजेंट (sub-agents) या MCP को काम पर कब लगाना है ​

07 अंतिम कदम: git कमिट — वह ड्राफ्ट तैयार करेगा, आप पुष्टि करेंगे ​

08 पूरी प्रक्रिया पर एक नज़र: प्रत्येक कदम किस अध्याय से संबंधित है ​

निष्कर्ष ​

अनुशंसित पठन ​

व्यावहारिक अभ्यास: शून्य से एक TODO टूल में फ़ीचर जोड़ना और एक बार कमिट करना

01 पहले "निशाना" तय करें: दो मिनट में एक TODO टूल बनाएं

02 पहला कदम: `AGENTS.md` लिखें, प्रोजेक्ट की पृष्ठभूमि एक बार में स्पष्ट करें

03 दूसरा कदम: काम सौंपना — लक्ष्य + दायरा + बाधाएं + स्वीकृति, सब कुछ एक बार में स्पष्ट करें

04 तीसरा कदम: अनुमतियां सेट करें — उसे फाइलें बदलने और टेस्ट चलाने दें, लेकिन नियंत्रण में रखें

05 चौथा कदम: उसे स्वयं सत्यापित करने दें — टेस्ट चलाएं, और सफल होने तक काम बंद न करें

06 पांचवां कदम (वैकल्पिक): उप-एजेंट (sub-agents) या MCP को काम पर कब लगाना है

07 अंतिम कदम: `git` कमिट — वह ड्राफ्ट तैयार करेगा, आप पुष्टि करेंगे

08 पूरी प्रक्रिया पर एक नज़र: प्रत्येक कदम किस अध्याय से संबंधित है

निष्कर्ष

अनुशंसित पठन