निजी AI समाचार सारांश के लिए लिंक का सार लिखने वाले निर्देश से अधिक चाहिए। उसे अनुमति प्राप्त स्रोतों से सामग्री लेनी चाहिए, पहले देखी सामग्री पहचाननी चाहिए, तथ्य-आधारित शर्तों को निर्णय से अलग रखना चाहिए और भेजी सामग्री का स्रोत लिंक सहित रिकॉर्ड सहेजना चाहिए। Cole Medin का build-signal-engine कौशल कोडिंग एजेंट को आपके अपने रिपॉज़िटरी में ऐसा सिस्टम बनाने के निर्देश देता है। यह निर्माण प्रक्रिया है; तैयार कोड और उसका व्यवहार आपके उत्तरों, स्रोतों, सेवाओं और जाँच पर निर्भर हैं।

यह मार्गदर्शिका उन लोगों के लिए है जो पहले से Claude Code इस्तेमाल करते हैं, प्रोजेक्ट फ़ोल्डर नियंत्रित करते हैं और तय कर सकते हैं कि कौन-सी फ़ीड या API इस्तेमाल करने की अनुमति है। स्रोतों तक पहुँच और चुनी गई सशुल्क डेटा या मॉडल सेवा की पहुँच-संबंधी जानकारी चाहिए। कौशल की फ़ाइलें रिपॉज़िटरी के MIT लाइसेंस में उपलब्ध हैं, लेकिन एजेंट का उपयोग, स्रोत प्राप्त करना और मॉडल कॉल फिर भी पैसे ले सकते हैं। BIG CHANGE ने commit 847be0848ae7b997ae4420bc0eac267177a066a2 वाला कौशल और प्रदाता दस्तावेज़ जाँचे। हमने इसे स्थापित नहीं किया, इंजन नहीं बनाया और सारांश नहीं चलाया।

1. कौशल का निश्चित संस्करण प्रोजेक्ट में जोड़ें

अलग कार्य फ़ोल्डर में Cole Medin का कौशल रिपॉज़िटरी क्लोन करें, फिर निश्चित commit चुनें:

Terminal
git clone https://github.com/coleam00/skills.git skills-source
git -C skills-source checkout --detach 847be0848ae7b997ae4420bc0eac267177a066a2

पूरा skills-source/.claude/skills/build-signal-engine/ फ़ोल्डर <your-project>/.claude/skills/build-signal-engine/ में कॉपी करें। references/ और templates/ उपफ़ोल्डर SKILL.md के साथ रखें; निर्देश इन्हें सापेक्ष पथ से पढ़ते हैं। कॉपी के साथ रिपॉज़िटरी का MIT LICENSE और कॉपीराइट सूचना भी रखें। प्रोजेक्ट की यह स्थानीय कॉपी अन्य कौशल नहीं लाती और मार्गदर्शिका को जाँचे जा सकने वाले संस्करण से जोड़ती है।

रिपॉज़िटरी Claude Code में खोलें और नया सत्र शुरू करें ताकि प्रोजेक्ट का कौशल मिले। उपलब्ध कौशल में build-signal-engine देखें, फिर इंजन बनाने वाले रिपॉज़िटरी के पथ के साथ /build-signal-engine चलाएँ। Claude Code कौशल दस्तावेज़ प्रोजेक्ट पथ .claude/skills/<name>/SKILL.md की खोज और /skill-name का उपयोग बताते हैं। कौशल न मिले तो स्रोत या प्रदाता बदलने से पहले फ़ोल्डर की वर्तनी और उसके सीधे भीतर SKILL.md होने की जाँच करें। कोड लिखने या चलाने की अनुमति देने से पहले कौशल और सहायक फ़ाइलें पढ़ें।

2. अपने उदाहरणों से बने प्रोफ़ाइल को स्वीकृत करें

कौशल बातचीत से शुरू होता है। एजेंट को बताएँ कि कौन-सी जानकारी आपका कोई निर्णय बदल सकती है, सचमुच छूटी सामग्री पहले कहाँ आई थी और सारांश कहाँ पढ़ना चाहते हैं। ऐसी वास्तविक सामग्री दें जिसे आप चाहते थे और जिसे छोड़ देते, संभव हो तो लिंक सहित। अनुमत स्रोत, उम्र या प्रतिक्रिया जैसी तथ्यात्मक सीमाएँ, सारांश की लंबाई और भेजने का स्थान चुनें। एजेंट को उत्तरों का PROFILE.md बनाना चाहिए, इसके लिए templates/PROFILE.md का उपयोग करके निर्माण से पहले आपकी स्वीकृति लेनी चाहिए।

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

स्रोत की पहुँच-संबंधी जानकारी प्रोफ़ाइल, निर्देशों, रिपॉज़िटरी में जमा फ़ाइलों और लॉग से बाहर रखें। कौशल ऐसे पर्यावरण फ़ाइल की माँग करता है जिसे Git अनदेखा करे और बना हुआ प्रोग्राम पढ़े। फिर भी हर प्रदाता को भेजे जाने वाले फ़ील्ड देखें, खासकर रुचियों या स्रोत के पाठ में संवेदनशील जानकारी हो तो।

3. पहले एक अनुमत स्रोत बनाएँ, फिर भंडारण जाँचें

अन्य स्रोत जोड़ने से पहले एजेंट से एक स्रोत शुरू से अंत तक लागू करवाएँ। हर स्रोत के लिए अनुमत तरीका तय करें: आधिकारिक फ़ीड या API, आपका चुना प्रदाता या उसकी शर्तों में स्वीकार्य अन्य तरीका। स्वचालित पहुँच की अनुमति न हो तो स्रोत बाहर रखें। references/sources.md स्रोत के प्रकार और विफलताएँ बताता है; पहुँच का अधिकार नहीं देता।

हर प्राप्त सामग्री templates/item_schema.md के फ़ील्ड से मेल खानी चाहिए: स्थिर id, स्रोत, शीर्षक, URL, मुख्य पाठ, प्रकाशन समय, उपलब्ध प्रतिक्रिया और मेटाडेटा। भंडारण में लागू फ़िल्टर, निर्णय और सारांश में शामिल होने का रिकॉर्ड भी रहता है। बदलाव सूची को अलग-अलग तारीख वाले स्थिर पहचान के अंश बनाएँ, बदलते पूरे पृष्ठ को एक सामग्री न मानें। दूसरा भंडारण पहले से न हो तो कौशल SQLite सुझाता है।

वास्तविक स्रोत उत्तर और सहेजी पंक्तियाँ देखें। दूसरी बार संग्रह में पुष्टि करें कि पहचान और URL उन्हीं अंशों को दिखाते हैं; प्रति स्रोत लौटे, नए सहेजे और दोहराए अंश गिनें। अनपेक्षित खाली उत्तर, गायब तारीख, पाठ समझने की त्रुटि या दोबारा समान रिकॉर्ड बनने की जाँच करें। दोहराव हटाना समान पहचान पर फिर भंडारण या आगे निर्णय रोकता है; सशुल्क स्रोत दोबारा लेने की कीमत नहीं मिटाता।

4. तथ्यात्मक फ़िल्टर और निर्णय अलग रखें

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

बाकी अंशों के लिए कौशल प्रति अंश एक प्रकार-निर्धारित निर्णय अनुरोध सुझाता है, जिसमें प्रोफ़ाइल के प्रासंगिकता और ठोस नई बात वाले प्रश्न साथ हों। संदर्भ में OpenRouter के माध्यम से TypeSafe का Jev एक विकल्प है; संरचित परिणाम वाला मॉडल दूसरा विकल्प है। निश्चित संदर्भ typesafe/jev-1.13 बताता है। OpenRouter की अक्टूबर 2026 की Jev मार्गदर्शिका 1.14 बताती है और कहती है कि 1.13 उपलब्ध है। जानबूझकर बदलाव की समीक्षा और जाँच किए बिना निश्चित संस्करण रखें। Jev का निर्णय एंडपॉइंट चैट पूर्ति कॉल से अलग है। BIG CHANGE की पिछली Jev रिपोर्ट सॉफ़्टवेयर निर्णयों में उसकी व्यापक भूमिका समझाती है।

तथ्य या कम प्रासंगिकता के कारण स्पष्ट निष्कासन का कारण सहेजें। स्पष्ट रूप से रखे और अनिश्चित अंश पढ़ने के चरण में भेजें। विफल या गलत स्वरूप वाला निर्णय निष्कर्ष नहीं है: जाँच या नियंत्रित सुधार के लिए चिह्नित करें, चुपचाप न हटाएँ। समस्या पर पढ़ने के चरण में जाने की भी लागत सीमा होनी चाहिए। विफल कॉल या बड़ा समूह स्वीकृत पढ़ने का बजट पार करे तो अंशों को पाठक के लिए साफ़ तौर पर लंबित रखें, असीम खर्च न करें। ये बनाए इंजन से माँगी जाने वाली जाँच हैं, BIG CHANGE द्वारा सत्यापित व्यवहार नहीं।

अपने रखने-हटाने वाले उदाहरण और चिह्नित संग्रह नमूने का मूल्यांकन करें। हर वांछित लेकिन हटाए अंश की समीक्षा करें; सीमा बदलने से पहले अस्पष्ट प्रश्न या स्रोत चयन सुधारें। प्रकार-निर्धारित प्रायिकता आपके पाठ के लिए गलत हो सकती है। पसंद या प्रतिक्रिया क्रम तय करने में मदद कर सकती है; तथ्यात्मक महत्त्व साबित नहीं करती।

5. भेजने से पहले स्रोत लिंक वाला सारांश सहेजें

पढ़ने वाले मॉडल को बचे अंश स्रोत लिंक सहित मिलने चाहिए। उसे संबंधित रिपोर्ट जोड़कर स्वीकृत प्रोफ़ाइल के रूप में सार लिखना चाहिए। हर प्रविष्टि का स्रोत URL खुलता हो और छोटी बदलाव सूचना, रिलीज़ तथा अपुष्ट दावे में सही अंतर हो। स्रोत से मिलाकर पढ़ें; सुगठित वाक्य किसी बदलाव के होने का प्रमाण नहीं है।

कौशल ईमेल, चैट या नोट्स में भेजने से पहले तारीख वाली digests/YYYY-MM-DD.md सहेजने को कहता है। सुनिश्चित करें कि फ़ाइल मौजूद हो और भेजना विफल होने पर भी खुले। फ़ाइल और रिकॉर्ड बताते हैं कि कोई खबर क्यों जुड़ी। जाँचें कि बनाया भेजने का चरण उसी फ़ाइल से पुनः प्रयास कर सकता है, बिना स्रोत दोबारा लेने या पूरे संचालन का भुगतान फिर करने के।

6. नियमित संचालन की अनुमति दें और उसे देखें

स्वचालन दर्ज करने से पहले एजेंट से वास्तव में बने इंजन की चलाने की कमांड और रोकने की विधि, होस्ट के लिए समय-निर्धारक, स्थानीय समय क्षेत्र, गंतव्य, इस्तेमाल होने वाले पहुँच विवरण, शुल्क वाली पंक्तियों की सीमा, लॉग और दोहरे संचालन से बचाव दिखाने को कहें। चलने वाली सही कमांड जाँचें। कौशल cron, launchd और Windows Task Scheduler के विकल्प बताता है, कोई एक सार्वभौमिक इंजन कमांड नहीं देता। इस खास दैनिक समय-सारणी की अनुमति तभी दें जब मैनुअल संचालन से स्वीकार्य स्रोत लिंक वाली फ़ाइल बन जाए।

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

एक सप्ताह परिणाम को महत्वपूर्ण स्रोतों के साथ पढ़ें। छूटी और अनावश्यक सामग्री चिह्नित करें। छूटने पर पता लगाएँ कि अंश जुटा नहीं, तथ्य नियम से हटा, निर्णय ने हटाया या पढ़ने में छूटा। उस चरण को बदलकर फिर जाँचें। यह समानांतर निरीक्षण सप्ताह आपके स्रोतों और प्रश्नों का प्रमाण देता है; बिना निगरानी सटीकता प्रमाणित नहीं करता।

बड़ा बदलाव

कौशल का पुनः उपयोग योग्य हिस्सा संग्रह, स्थिर भंडारण, तथ्यात्मक फ़िल्टर, प्रकार-निर्धारित निर्णय और स्रोत-संबद्ध पढ़ाई को अलग करना है। कोडिंग एजेंट पाठक द्वारा स्वीकृत प्रोफ़ाइल के आधार पर इन्हें जोड़ सकता है। पहुँच की अनुमति, उदाहरण, खर्च सीमा तथा रोज़ भेजना शुरू या बंद करना पाठक के नियंत्रण में रहते हैं। आपके वातावरण में स्रोत, दोहराव, छूटी सामग्री और निर्धारित संचालन की जाँच पास होने तक सिस्टम का निर्माण अधूरा है।

स्रोत और आगे पढ़ें

  • Cole Medin का निश्चित build-signal-engine कौशल बातचीत और निर्माण चरण बताता है। references/ और templates/ स्रोत मिलान, निर्णय मार्ग और सारांश आउटपुट बताते हैं; ये निर्देश हैं, स्वतंत्र रूप से जाँचा इंजन नहीं।
  • Claude Code कौशल दस्तावेज़ प्रोजेक्ट में खोज और सीधे उपयोग को बताते हैं, इस इंजन की पुष्टि नहीं करते।
  • OpenRouter की Jev मार्गदर्शिका वर्तमान निर्णय API और मॉडल संस्करण बताती है। कीमत और उदाहरण पाठक की प्रक्रिया की लागत या सटीकता का माप नहीं हैं।
  • रिपॉज़िटरी का MIT लाइसेंस वह सूचना बताता है जो कौशल फ़ाइलों की प्रतियों या महत्वपूर्ण हिस्सों के साथ चाहिए।