/goal के लिए संपूर्ण गाइड

/goal कोई फ़ीचर नहीं है। यह एक मूलभूत तत्व (primitive) है।

HTTP एक मूलभूत तत्व है। JSON एक मूलभूत तत्व है। /goal कोडिंग एजेंटों के लिए भी ऐसा ही बनता जा रहा है।

कुछ हफ्ते पहले, OpenAI के Codex CLI ने /goal को कोडिंग वर्कर को एक परिभाषित "काम हो गया" (done) स्थिति के साथ काम देने के तरीके के रूप में जोड़ा। Claude Code ने इसे इस सप्ताह जोड़ा है।

Hermes Agent, ऑर्केस्ट्रेटर जिसे मैं Mac Mini पर चलाता हूँ ताकि कोडिंग वर्कर्स के बीच काम का समन्वय कर सकूँ, में पहले से ही /goal बिल्ट-इन है।

तो अब मेरे पास एक बिल्डर, एक रिव्यूअर और एक ऑर्केस्ट्रेटर है जो सभी एक ही निर्देश प्रारूप को स्वीकार करते हैं, भले ही उनमें और कुछ भी समान न हो।

अगर आपने केवल /goal को एक फैंसी प्रॉम्प्ट के रूप में इस्तेमाल होते देखा है, तो आप इसके वास्तविक बदलाव को समझने से चूक गए हैं।

/goal वास्तव में क्या है

एक सामान्य प्रॉम्प्ट एजेंट से अगला उत्तर मांगता है। आप पढ़ते हैं कि क्या वापस आया है, तय करते हैं कि यह सही है या नहीं, और एजेंट को अगले चरण पर ले जाते हैं। आप हर मोड़ पर नियंत्रण कर रहे हैं।

/goal इसे उलट देता है। आप लिखते हैं कि "काम हो गया" (done) कैसा दिखता है, इसे एक बार सबमिट करते हैं, और एजेंट तब तक उसकी ओर काम करता है जब तक वह वहां नहीं पहुँच जाता। यहाँ एक वास्तविक उदाहरण है:

1/goal Build the app described in SPEC.md. Done means tests pass,
2build passes, README is accurate, and git status only shows
3relevant project files.

यह गोल तब तक सक्रिय रहता है जब तक यह प्राप्त नहीं हो जाता, रोक नहीं दिया जाता, ब्लॉक नहीं हो जाता, साफ़ नहीं हो जाता, या इसका बजट खत्म नहीं हो जाता।

यह एक सामान्य एक-शॉट कमांड के अंदर "goal" शब्द डालने से अलग है। यदि आप codex exec 'goal: build the app' लिखते हैं, तो वह अभी भी एक लेबल वाला प्रॉम्प्ट है। असली मूलभूत तत्व एक इंटरैक्टिव वर्कर सत्र के अंदर रहता है। आप CLI लॉन्च करते हैं, आप /goal सबमिट करते हैं, और आप वहाँ से चले जाते हैं।

बदलाव प्रॉम्प्टिंग (आप ड्राइविंग कर रहे हैं) से असाइन करने (एजेंट आपके द्वारा परिभाषित लक्ष्य की ओर ड्राइव कर रहा है) की ओर है।

GIF

तीन उपकरण जो वर्तमान में /goal बोलते हैं

/goal स्वीकार करने वाले तीन उपकरण सभी एक ही तरह की चीज़ नहीं हैं, इसलिए विशिष्ट होना उचित है।

Codex OpenAI का कोडिंग CLI है। कार्यान्वयन में मजबूत, खासकर जब एक स्पष्ट स्पेक दिया जाता है। /goal वह तरीका है जिससे आप उसे वह स्पेक देते हैं।

Claude Code Anthropic का कोडिंग CLI है। उल्टे में मजबूत: यह पता लगाना कि कोड में क्या गलत है जो सही दिखता है। स्पेक अनुपालन, सुरक्षा मुद्दे, त्रुटि स्थितियाँ, सुरक्षा छेद। /goal वह तरीका है जिससे आप इसे कोड की ओर इशारा करते हैं और समीक्षा के लिए कहते हैं।

Hermes Agent पूरी तरह से एक अलग तरह का उपकरण है। कोडिंग वर्कर नहीं, बल्कि एक ऑर्केस्ट्रेटर है जो ऊपर के दो कोडिंग वर्कर्स जैसे उपकरणों के बीच काम का समन्वय करता है। /goal वह तरीका है जिससे Hermes उन कार्यों को सौंपता है जो काम के लिए सही उपकरण हैं, और यह भी कि मैं Hermes को पहले स्थान पर बताता हूँ कि मुझे क्या चाहिए।

जो मायने रखता है वह यह नहीं है कि उनमें से किसी एक ने /goal शिप किया। यह है कि तीन अलग-अलग टीमें एक ही मूलभूत तत्व पर एकत्रित हुईं, और यह अभिसरण ही उन्हें रचना (compose) करना संभव बनाता है।

GIF

सेटअप करना

पहली बार जब मुझे Mac Mini पर Codex और Claude Code की आवश्यकता थी जो Hermes चलाता है, तो मैंने उन्हें हाथ से इंस्टॉल नहीं किया। मैंने Hermes को एक संदेश भेजा जिसमें कहा गया कि वह दोनों को इंस्टॉल करे और मुझे लॉग इन करे। उसने बाकी काम संभाल लिया।

अब यही वर्कफ़्लो है। आप इंस्टॉल कमांड टाइप नहीं करते। सेटअप भी सिर्फ एक और गोल है।

अगर आपने अभी तक कोई ऑर्केस्ट्रेटर नहीं चलाया है, तो Codex और Claude Code के लिए इंस्टॉल पेज काफी आसान हैं। लेकिन एक बार जब आप कर लेते हैं, तो आपको किसी और उपकरण को हाथ से सेट नहीं करना चाहिए। ऑर्केस्ट्रेटर रखने का मतलब यह है कि यांत्रिक काम आपका नहीं रह जाता।

/goal के ऊपर Hermes क्या जोड़ता है

एक कच्चा /goal अपने आप में उपयोगी है। लेकिन यह आपको एक समन्वय समस्या में छोड़ देता है।

यदि Codex एक टर्मिनल में चल रहा है और Claude Code दूसरे में चल रहा है, तो आपको याद रखना होगा कि कौन सी प्रक्रिया क्या कर रही है। आपको लॉग चेक करने होंगे। आपको मैन्युअल रूप से एक उपकरण से दूसरे उपकरण में समीक्षा निष्कर्ष पास करने होंगे।

Hermes उन ढीले रन को एक वर्कफ़्लो में बदल देता है:

1. आप Hermes को संदेश भेजते हैं (मेरे मामले में, फ़ोन से Telegram पर)
2. Hermes एक Kanban बोर्ड पर गोल कार्ड बनाता है
3. Hermes प्रत्येक कार्ड के लिए सही वर्कर चुनता है
4. वर्कर बैकग्राउंड में गोल चलाता है
5. कार्ड प्रक्रिया आईडी, PID, रेपो और डन मापदंड संग्रहीत करता है
6. जब बिल्ड तैयार होता है, Hermes रेपो को रिव्यूअर को सौंपता है
7. यदि समीक्षा अवरुद्ध होती है, Hermes निष्कर्षों को एक फिक्स गोल के रूप में वापस भेजता है
8. Hermes फाइलसिस्टम, टेस्ट, बिल्ड और git स्थिति का निरीक्षण करके अंतिम आउटपुट को सत्यापित करता है

बोर्ड वही है जो /goal बन जाता है जब उसके ऊपर कोई ऑर्केस्ट्रेटर होता है। हर गोल का एक कार्ड होता है, हर कार्ड की एक स्थिति होती है, हर हैंडऑफ़ एक निशान छोड़ता है। टर्मिनलों में शिकार करने के बजाय, आप अपने फ़ोन पर काम को कॉलम में घूमते हुए देखते हैं।

तीन भूमिकाएँ

उपकरण बदलते हैं। भूमिकाएँ नहीं बदलतीं।

ऑर्केस्ट्रेटर. नियंत्रण लूप का मालिक। कार्य अपघटन, वर्कर चयन, Kanban कार्ड, बैकग्राउंड प्रक्रियाएँ, निर्भरताएँ, अंतिम सत्यापन, उपयोगकर्ता-सामना करने वाला सारांश। मेरे सेटअप में, Hermes।

बिल्डर. एक स्पेक लेता है और काम करने वाला कोड तैयार करता है। कार्यान्वयन वह अड़चन है जिसे यह भूमिका हल करती है। Codex यहाँ मजबूत होता है।

रिव्यूअर. बिल्डर द्वारा उत्पादित कोड को पढ़ता है और पता लगाता है कि उसमें क्या गलत है। शुद्धता अड़चन है। Claude Code यहाँ मजबूत होता है।

एक वास्तविक रन, शुरू से अंत तक

मैंने Hermes agent को यह करने का एक गोल दिया:

1/goal Build a CLI tool that finds X mentions of me and pings me when
2something blows up.

Hermes ने अनुरोध को छह कार्डों में तोड़ दिया।

Shubham Saboo

@Saboo_Shubham_

·

May 12

Codex /goal builds it.

Claude Code /goal review and refines it.

Hermes /goal manages the orchestration and handoff.

All tracked on a single Kanban Board and agents keep running in the loop.

58

61

852

88K

कार्ड 1: स्पेक। Hermes ने स्वयं SPEC.md लिखा, जिसमें स्टैक, रेपो पथ, केवल-पढ़ने की बाधाएँ, मॉक मोड आवश्यकताएँ, परीक्षण और सत्यापन कमांड शामिल थे। PM भूमिका के स्वामित्व में।

कार्ड 2: Codex बनाता है। Codex ने SPEC.md के विरुद्ध /goal चलाया। इसने प्रोजेक्ट फ़ाइलें बनाईं, UI और बैकएंड को लागू किया, परीक्षण जोड़े, और ऐप को पासिंग स्थिति में लाया। लगभग 15 मिनट। जब यह समाप्त हुआ, npm test पास हुआ, npm run build पास हुआ, और git status ने केवल प्रासंगिक नई फ़ाइलें दिखाईं।

कार्ड 3: Claude Code समीक्षा करता है। Claude Code ने Codex द्वारा बनाए गए कोड की समीक्षा करने के लिए /goal चलाया। स्पेक अनुपालन, केवल-पढ़ने की सुरक्षा, API कुंजी हैंडलिंग, त्रुटि स्थितियाँ, परीक्षण, UI उपयोगिता, बग और सुरक्षा मुद्दों की जाँच की। परिणाम: PASS, कोई अवरोधक मुद्दे नहीं।

कार्ड 4: Codex फिक्स लूप। छोड़ा गया, क्योंकि समीक्षा पास हो गई थी। छोड़े जाने पर भी कार्ड मायने रखता है। यह दिखाता है कि Hermes सशर्त कार्य का मॉडल बना सकता है। यदि Claude Code ने अवरुद्ध किया होता, तो Hermes निष्कर्षों को एक नए /goal के रूप में Codex को वापस सौंप देता।

कार्ड 5: Claude Code अंतिम सत्यापन। उसी कारण से छोड़ा गया।

कार्ड 6: Hermes अंतिम सारांश। स्थानीय पथ पर काम कर रहा ऐप, UI और API दोनों मॉक मोड में सत्यापित। Codex ने इसे /goal के साथ बनाया। Claude Code ने इसकी समीक्षा /goal के साथ की और PASS लौटाया।

यह सब एक संदेश से आया। तीन अलग-अलग उपकरणों ने वास्तविक काम किया, लेकिन मैंने केवल Hermes से बात की।

सत्यापन नियम

Hermes ने कभी भी Codex की स्व-रिपोर्ट पर भरोसा नहीं किया। Codex द्वारा बिल्ड को चिह्नित करने के बाद, Hermes ने स्वयं कमांड चलाए:

1npm test         # 17 tests passed
2npm run build    # vite build passed

सत्यापक (verifier) वह है जो /goal को एक वादे के बजाय एक अनुबंध बनाता है। अंतिम के रूप में कार्यकर्ता की स्व-रिपोर्ट पर भरोसा न करें। सत्यापक पर भरोसा करें।

कोडिंग एजेंट आश्वस्त होते हैं। वे आपको बताएंगे कि बिल्ड पास हो गया है जब बिल्ड कभी चलाया ही नहीं गया था। वे आपको बताएंगे कि परीक्षण पास हो गए हैं जब उन्होंने ऐसे परीक्षण लिखे जो कभी निष्पादित नहीं हुए। सत्यापक उस अंतर को बंद कर देता है।

सत्यापन के बिना, /goal सिर्फ एक फैंसी प्रॉम्प्ट है। सत्यापन के साथ, यह एक अनुबंध बन जाता है।

GIF

एक साथ कई गोल चलाना

आप एक साथ कई /goal चला सकते हैं, लेकिन आप पहले इसके बारे में सोचे बिना कई कोडिंग वर्कर्स को एक ही फ़ाइलों पर इंगित नहीं कर सकते।

मेरा डिफ़ॉल्ट प्रति रेपो एक मुख्य बिल्डर है। यदि मुझे समानता (parallelism) चाहिए, तो मैं इसे स्पष्ट सीमाओं पर जोड़ता हूँ। अलग-अलग रेपो, अलग-अलग ब्रांच, git worktrees, अलग-अलग पैकेज, दस्तावेज़ बनाम कोड, परीक्षण बनाम कार्यान्वयन। कोई भी जगह जहाँ दो वर्कर एक-दूसरे के रास्ते में नहीं आ सकते।

खराब पैटर्न एक ही रेपो में एक ही फ़ाइल को संपादित करने वाले तीन वर्कर हैं। आपको विरोध मिलते हैं, आंशिक ओवरराइट होते हैं, और एक वर्कर चुपचाप दूसरे के काम को पूर्ववत कर देता है।

बेहतर पैटर्न किसी भी फ़ाइल पर एक समय में एक लेखक है। बिल्डर लिखता है, रिव्यूअर केवल पढ़ता है, फिक्स गोल फिक्स तक ही सीमित रहते हैं। या तीन प्रतिस्पर्धी दृष्टिकोणों पर तीन वर्कट्री में तीन बिल्डर चलाएँ और ऑर्केस्ट्रेटर को सबसे अच्छा चुनने दें।

बोर्ड ही इसे व्यावहारिक बनाता है। इसके बिना, समानांतर पृष्ठभूमि वर्कर टर्मिनल अराजकता बन जाते हैं।

मेरे लिए क्या बदलता है

यहाँ उपयोगी ढाँचा "मैं पृष्ठभूमि में एजेंट चला सकता हूँ" नहीं है।

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

आप एक एजेंट के खत्म होने की प्रतीक्षा में एक टर्मिनल में बैठना बंद कर देते हैं, और दृश्य स्थिति वाले कार्यों की कतार का प्रबंधन करना शुरू कर देते हैं।

यदि Codex और Claude Code ने प्रत्येक ने अपना स्वयं का नौकरी-हैंडऑफ़ प्रारूप का आविष्कार किया होता, तो कोई भी ऑर्केस्ट्रेटर उनके बीच रूट नहीं कर सकता था। बोर्ड प्रभावशाली है, लेकिन मूलभूत तत्व बोर्ड को और भी उपयोगी बनाता है।

वर्कर बदल सकते हैं, लेकिन मूलभूत तत्व वही रहता है। अगला कोडिंग उपकरण जो /goal अपनाता है, बिना मेरे कुछ भी बदले इस पाइपलाइन में शामिल हो जाएगा। मैं बस इसे काम रूट कर दूंगा।

अच्छे मूलभूत तत्व यही करते हैं।

Hermes, OpenClaw, Claude Code, Codex और अन्य 24/7 एजेंट टीमों के आसपास ऐसी और अच्छी टिप्स और दिलचस्प विचारों के लिए।

फ़ॉलो करें → @Saboo_Shubham_