Claude Code, Codex या Cursor के साथ एनोटेशन अध्ययन बनाना

potato-skill एनोटेशन अध्ययन के सादे विवरण को एक चलते हुए Potato टास्क में बदल देता है। इसके साथ 28 संदर्भ फ़ाइलें और नौ हेल्पर स्क्रिप्ट आती हैं, जो कॉन्फ़िग से पहले आने वाले डिज़ाइन फ़ैसलों, एनोटेटर को दिखने वाले इंटरफ़ेस, और उन जाँचों को कवर करती हैं जो ऐसे टास्क पकड़ती हैं जो वैलिडेट तो हो जाता है पर काम नहीं करता। यह Claude Code, Codex और Cursor में इंस्टॉल होता है, और GPL-3.0-or-later के तहत जारी किया गया है।

स्किल इंस्टॉल करना

Claude Code इसे एक प्लगिन मार्केटप्लेस से, दो कमांड में इंस्टॉल करता है:

/plugin marketplace add davidjurgens/potato-skill
/plugin install potato-skill@potato

Codex और Cursor इसे skills CLI से इंस्टॉल करते हैं, जो स्किल को उस प्रोजेक्ट में कॉपी कर देता है जिसमें आप काम कर रहे हैं:

npx skills add davidjurgens/potato-skill --agent codex cursor

Potato ख़ुद वहाँ इंस्टॉल होना चाहिए जहाँ एजेंट कमांड चलाता है, क्योंकि नौ हेल्पर उसकी रजिस्ट्री import करते हैं और potato कमांड चलाते हैं:

pip install potato-annotation

Codex या Cursor इंस्टॉल में क्या-क्या आता है

skills CLI .agents/skills/potato-skill/ लिखता है, जिसमें SKILL.md, सारी 28 संदर्भ फ़ाइलें और सभी नौ स्क्रिप्ट होती हैं, इसलिए Codex या Cursor प्रोजेक्ट को वही सामग्री मिलती है जो Claude Code इंस्टॉल को मिलती है। यह AGENTS.md और .cursor/rules को नहीं छेड़ता, और उस डायरेक्टरी में कोई स्किल कैसे खोजी जाए यह हर टूल पर निर्भर है।

रिपॉज़िटरी अपनी जड़ में एक AGENTS.md भी रखती है, जिसे Codex और Cursor बिना किसी इंस्टॉल चरण के फ़ाइलनाम से पढ़ लेते हैं। वह फ़ाइल संदर्भ सामग्री के लगभग 79,000 शब्दों के मुक़ाबले एक छोटा सारांश है, और वह उन संदर्भ फ़ाइलों तथा स्क्रिप्ट की ओर इशारा करती है जिन्हें सिर्फ़ पूरा इंस्टॉल ही डिस्क पर रखता है। इसका इस्तेमाल तब कीजिए जब आप चाहते हों कि एजेंट के पास सौंपने-से-पहले-जाँचने वाला चक्र और वे नियम हों जो असर करते हैं, और skills CLI तब इस्तेमाल कीजिए जब आपको उनके पीछे की संदर्भ सामग्री चाहिए।

वे डिफ़ॉल्ट जो स्किल बिना पूछे तय करती है

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

वे फ़ैसले जो यह आपको वापस सौंपती है

पाँच फ़ैसले एक ही बैच संदेश में शोधकर्ता के पास वापस जाते हैं, हर एक के साथ एक प्रस्तावित उत्तर, ताकि उसे एक शब्द में स्वीकार किया जा सके:

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

इनमें से कुछ भी निर्माण को नहीं रोकता। स्किल अपनी धारणाएँ बताती है, टास्क बनाती है, उसे सत्यापित करती है, और सवाल तब पूछती है जब आपके सामने पहले से कुछ ऐसा होता है जिसे आप क्लिक करके देख सकते हैं।

सौंपने से पहले की जाँचें

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

potato validate config.yaml --strict
potato preview config.yaml --screenshot shot-01.png

--strict किसी अपरिचित कॉन्फ़िग कुंजी को चेतावनी से बदलकर विफलता बना देता है। इसके बिना टाइपो स्वीकार कर लिया जाता है, नज़रअंदाज़ कर दिया जाता है, और जो सुविधा आपने चालू की समझी थी वह बंद ही रहती है। यही उस कॉन्फ़िग का आम कारण है जो पढ़ने में सही लगता है जबकि होता कुछ नहीं।

--screenshot एक असली Potato सर्वर बूट करता है और उसे हेडलेस Playwright में चलाता है, कंसोल एरर, बिना पकड़े गए पेज एक्सेप्शन, और 400 या उससे ऊपर के HTTP रिस्पॉन्स दर्ज करते हुए। यह तभी 0 के साथ बाहर निकलता है जब तीनों सूचियाँ ख़ाली हों। वह चरण वह पकड़ता है जो वैलिडेशन नहीं पकड़ सकता, क्योंकि एनोटेशन इंटरफ़ेस का ज़्यादातर हिस्सा HTML आने के बाद JavaScript बनाता है। अदृश्य रेडियो बटन इसका आम मामला है, क्योंकि लेबल का टेक्स्ट फिर भी रेंडर होता है और सरसरी नज़र में सवाल सही दिखता है।

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

नौ हेल्पर में से तीन उन हिस्सों को स्वचालित करते हैं जिन्हें आँकने के बजाय मापा जा सकता है। check_ui.py लाइव लेआउट को 1280x900 पर मापता है और ऐसी योजनाओं या Next बटन की रिपोर्ट करता है जो फ़ोल्ड के नीचे रह जाएँ, साथ ही ख़ाली मीडिया विजेट और दोहरे शॉर्टकट। boot_and_check.py सर्वर चालू करता है और हर उस सुविधा की रिपोर्ट करता है जो कॉन्फ़िगर तो है पर जिसने कुछ लोड नहीं किया, जैसे कोई प्रशिक्षण दौर जिसने शून्य प्रशिक्षण आइटम लोड किए। walk_task.py चलते हुए टास्क में उसी तरह चलता है जैसे कोई एनोटेटर चलता, और बताता है कि वह कहाँ रुक जाता है।

एनोटेटर के शुरू करने के बाद सुरक्षित और असुरक्षित बदलाव

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

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

प्रमाणीकरण दूसरा मामला है। डिफ़ॉल्ट बैकएंड खाते मेमोरी में रखता है, इसलिए सर्वर बंद करना हर एनोटेटर का लॉगिन अपने साथ ले जाता है, जबकि एनोटेशन डिस्क पर सुरक्षित बने रहते हैं। कोई एनोटेटर लौटता है, उसी उपयोगकर्ता-नाम से दोबारा पंजीकरण करता है, और अपने काम से फिर जुड़ जाता है, जो समस्या को तब तक छिपाए रखता है जब तक कोई अलग उपयोगकर्ता-नाम टाइप करके दूसरे व्यक्ति के रूप में कॉर्पस दोबारा शुरू नहीं कर देता। authentication.user_config_path सेट करने से खाते सॉल्टेड हैश के साथ बाहर लिख दिए जाते हैं। यह वहीं सबसे ज़्यादा मायने रखता है जहाँ इसे भूलना सबसे आसान है, क्योंकि Render और Hugging Face Spaces कंटेनर अपने आप रीस्टार्ट करते हैं।

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

Potato के MCP सर्वर

Potato दो MCP सर्वर के साथ आता है, जो एजेंट को वही जवाब बिना शेल में निकले देते हैं। potato mcp serve --root . 12 ऑथरिंग टूल उजागर करता है जो CLI की तरह वही रजिस्ट्री पढ़ते हैं, जिनमें render_task_screenshot भी है, जो रेंडर किया गया पेज एक इमेज के रूप में लौटाता है। potato mcp connect चलते हुए अध्ययन से पुल बनाता है और 12 लाइव टूल जोड़ता है, जो स्थिति, प्रगति, एनोटेटर, सहमति, असाइनमेंट और निर्यात को कवर करते हैं। इस पुल के लिए कॉन्फ़िग में एक mcp ब्लॉक चाहिए जो उजागर किए जाने वाले टूल सूचीबद्ध करे, और potato mcp issue-token से मिला एक टोकन।

हाथ से लिखे लेबलिंग टूल और उनकी क़ीमत

कुछ सौ आइटम लेबल करवाने का एक आम तरीक़ा यह है कि किसी कोडिंग एजेंट से एक झटपट लेबलिंग टूल माँग लिया जाए, जैसे कोई Streamlit या Flask पेज जो एक बार में एक आइटम दिखाए और हर जवाब को CSV में जोड़ता जाए। जब एक व्यक्ति एक दोपहर भर का डेटा एक बार लेबल करे, तो यह बनाना ठीक ही रहता है। क़ीमत तब आती है जब अध्ययन को हर एनोटेटर के लिए एक लॉगिन चाहिए, प्रति आइटम तीन एनोटेटर जिनमें हर आइटम सही लोगों तक पहुँचे, एक प्रशिक्षण दौर और ध्यान-जाँच, सहमति के आँकड़े, Prolific के लिए एक कंप्लीशन कोड, अगली स्क्रिप्ट जिस फ़ॉर्मैट की उम्मीद करती है उसमें निर्यात, या अगले महीने एक दूसरा अध्ययन जो इसी तरह काम करे। इनमें से हर एक ऐसी सुविधा है जिसे कोई एक ही अध्ययन के लिए बने टूल के भीतर लिखता, परखता और डीबग करता है, और Potato में ये सब पहले से हैं।

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

वे अध्ययन जो स्किल खड़े करती है

पाँच मामले इसका दायरा दिखाते हैं, हर एक एक छोटे विवरण से शुरू होकर एक चलाने लायक टास्क पर ख़त्म होता है:

• क्राउडवर्कर से स्टांस लेबल। प्रति पोस्ट तीन एनोटेटर, एक प्रशिक्षण दौर, ध्यान-जाँच, एक Prolific कंप्लीशन कोड, और लेबल आ जाने पर सहमति। देखें क्राउडसोर्स्ड स्टडी चलाना और अंतर-एनोटेटर सहमति मापना।
• दो चैटबॉट जवाबों की तुलना। एक अगल-बगल लेआउट, जिसमें एक वरीयता स्केल और एक मुक्त-पाठ कारण हो। देखें जोड़ीदार मॉडल तुलना और RLHF वरीयता डेटा।
• एजेंट ट्रेस में विफल होने वाला चरण चिह्नित करना। ट्रेस एक बार में एक चरण करके बिछाया जाता है, और टास्क वह चरण दर्ज करता है जिसे एनोटेटर ने चिह्नित किया, साथ में उसकी व्याख्या। देखें एजेंट ट्रैजेक्टरी एनोटेशन।
• किसी CVAT प्रोजेक्ट को आगे बढ़ाना। potato import 20 फ़ॉर्मैट पढ़ता है, इसलिए मौजूदा बॉक्स अपने लेबल के साथ अंदर आ जाते हैं, और अध्ययन वापस COCO के रूप में निर्यात होता है। देखें बाउंडिंग बॉक्स पर सहमति मापना।
• दो कोडर और एक कोडबुक। कोडबुक ही कोडिंग इंटरफ़ेस बन जाती है, दोनों कोडर को हर जवाब सौंपा जाता है, और एक अधिनिर्णय चरण असहमतियाँ सँभालता है। देखें अधिनिर्णय और असहमति।

Potato की रजिस्ट्री के ख़िलाफ़ परीक्षण

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

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

संदर्भ सामग्री davidjurgens.github.io/potato-skill पर प्रकाशित है, इसलिए आप इंस्टॉल करने से पहले पढ़ सकते हैं कि स्किल एजेंट से क्या कहती है। Anthropic किसी भी स्किल की पहले समीक्षा करने की सलाह देता है।

सवाल

नीचे के सवाल potato-skill और हाथ से बने लेबलिंग टूल के बीच चुनाव, सौंपने से पहले स्किल क्या जाँचती है, और उसके बनाए इंटरफ़ेस को कैसे बदलें, इन विषयों को कवर करते हैं।

क्या कोडिंग एजेंट को कस्टम एनोटेशन टूल बनाना चाहिए या कोई मौजूदा टूल इस्तेमाल करना चाहिए?

कस्टम टूल तभी बनाइए जब एक व्यक्ति कुछ सौ आइटम एक बार लेबल करे। एक Streamlit या Flask पेज जो एक बार में एक आइटम दिखाए और हर जवाब को CSV में जोड़ता जाए, उस स्थिति के लिए काफ़ी है। जैसे ही अध्ययन को प्रति आइटम कई एनोटेटर, एक प्रशिक्षण दौर, ध्यान-जाँच, सहमति के आँकड़े, या Prolific कंप्लीशन कोड चाहिए, इनमें से हर एक को एक ही अध्ययन के लिए बने टूल के भीतर लिखना और परखना पड़ता है, और Potato में ये सब पहले से हैं। इसी वजह से potato-skill Potato पर बनता है, और जो टास्क यह तैयार करता है वह एक फ़ोल्डर है जिसे Potato रखने वाला कोई भी दोबारा चला सकता है।

टास्क सौंपने से पहले potato-skill क्या जाँचता है?

potato-skill टास्क वापस सौंपने से पहले एजेंट से Potato की दो कमांड चलवाता है, और उसकी तीन हेल्पर स्क्रिप्ट वह जाँचती हैं जो ये कमांड नहीं पकड़ सकतीं। potato validate config.yaml --strict किसी भी अपरिचित कॉन्फ़िग कुंजी पर विफल हो जाता है। potato preview config.yaml --screenshot हेडलेस Playwright में एक असली सर्वर बूट करता है और तभी 0 के साथ बाहर निकलता है जब पेज ने कोई कंसोल एरर, कोई बिना पकड़ा गया एक्सेप्शन, और 400 या उससे ऊपर का कोई HTTP रिस्पॉन्स न दिया हो। check_ui.py उन एनोटेशन सवालों या Next बटन की रिपोर्ट करता है जो फ़ोल्ड के नीचे रह जाएँ, boot_and_check.py उन सुविधाओं की रिपोर्ट करता है जो कॉन्फ़िगर तो हैं पर जिन्होंने कुछ लोड नहीं किया, और walk_task.py टास्क में उसी तरह चलता है जैसे कोई एनोटेटर चलता, और बताता है कि वह कहाँ रुक जाता है।

क्या मैं potato-skill के बनाए इंटरफ़ेस को कस्टमाइज़ कर सकता हूँ?

हाँ। टास्क एक सामान्य Potato कॉन्फ़िग है, इसलिए आप लेआउट को हाथ से संपादित कर सकते हैं या एजेंट से उसे बदलने को कह सकते हैं। कस्टम लेआउट के लिए potato-skill एजेंट से कहता है कि हर दौर में एक ही बदलाव करे, हर रेंडर को एक नई स्क्रीनशॉट फ़ाइल में लिखे ताकि लगातार रेंडर से पता चले कि बदलाव ने क्या किया, और तीन या चार दौर की उम्मीद रखे। display_logic के पीछे की कोई भी चीज़ पहले रेंडर में मौजूद नहीं होती, इसलिए एजेंट शर्त को कमेंट कर देता है, रेंडर करता है, और उसे वापस लगा देता है।

आगे पढ़ें

• कोडिंग एजेंट के साथ क्विक स्टार्ट, जो सेटअप को और विस्तार से बताता है
• GitHub पर potato-skill, फ़िलहाल v1.0.1 पर
• स्किल की संदर्भ सामग्री
• शोकेस, आपके अध्ययन से मिलते-जुलते डिज़ाइन के लिए

संदर्भ

David Jurgens, Michael Chen, and Lina Iyer (2026). Potato 2.0: A Comprehensive Annotation Platform with AI-in-the-Loop Support. Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 3: System Demonstrations). https://aclanthology.org/2026.acl-demo.37/