Codex के उपयोग मामलों का संग्रह बड़े पैमाने पर विस्तारित

• OpenAI ने Codex के उपयोग मामलों वाले पेज को बड़े पैमाने पर फिर से व्यवस्थित किया है और इसे पहले के 12 से बढ़ाकर 52 use cases तक विस्तारित किया है
• अब यह सिर्फ़ साधारण coding सहायता से आगे बढ़कर engineering, design, data, finance, operations, QA, sales आदि पूरी कंपनी की टीमों के काम डेलिगेट करने वाले platform के रूप में अपनी पोज़िशनिंग बदल रहा है
• Computer Use (Mac automation), Gmail inbox management, Slack, Zoom, documents, spreadsheets, financial modeling (DCF·cash flow·budget), iOS/macOS native development, sales·marketing workflows, QA, automation, deployment, Evals, और ChatGPT app तक, इसे इस तरह व्यवस्थित किया गया है कि असली कामकाजी workflows Codex को सौंपे जा सकें

1. Codex को कार्यस्थल सहयोगी की तरह सेट करना (Automation / Integrations)

कठिनाई: Easy | समय: Long-running

• यह Slack, Gmail, Calendar, Notion, GitHub, Linear, local notes जैसे उन टूल्स को, जिनमें वास्तव में काम चलता है, एक Codex thread में जोड़कर उसे “मेरे काम का context जानने वाले सहयोगी” की तरह इस्तेमाल करने का तरीका है
• पहली बार चलाने पर Codex से ऐसे महत्वपूर्ण अनुरोध, बदले हुए दस्तावेज़, छूटे हुए निर्णय, और अटके हुए handoff ढूँढने को कहा जाता है जो आसानी से नज़रअंदाज़ हो सकते हैं, और उपयोगकर्ता उसे क्या उपयोगी है और क्या noise है, इस पर feedback देता है
• इसके बाद उसी thread में automation लगाकर उससे नियमित रूप से context जाँचना कराया जा सकता है। जिन फ़ैसलों में मानव निर्णय चाहिए, उन्हें Codex अपने-आप न निपटाए बल्कि उपयोगकर्ता तक पहुँचाए, ऐसा डिज़ाइन किया गया है
• उपयुक्त: वे व्यक्ति, operator, manager, PM, और engineer जिन्हें कई टूल्स में बिखरे कामकाजी context को लगातार ट्रैक करना पड़ता है

2. Feedback को action में बदलना (Data / Integrations)

कठिनाई: Easy | समय: 30m

• Slack channel, GitHub/Linear issues, survey CSV, customer interview notes, Google Drive documents जैसे कई स्रोतों से feedback इकट्ठा करके उसे Google Sheet या Doc के रूप में review किए जा सकने वाले output में व्यवस्थित किया जाता है
• Codex feedback को themes, evidence links, follow-up questions, और assigned actions में समूहित करता है, और review की गई सामग्री को Slack updates या issue drafts से आगे जोड़ा जा सकता है
• अगर feedback sources लगातार बदलते रहते हों, तो उसी thread में automation लगाकर केवल नए themes या मज़बूत हुए evidence वाले items की सूचना दिलाई जा सकती है
• उपयुक्त: वे टीमें जिन्हें beta feedback, customer VOC, issue threads, और research notes को product action में बदलना होता है

3. बिखरे हुए डेटा को साफ़ और तैयार करना (Data / Knowledge Work)

कठिनाई: Easy | समय: 5m

• जब CSV या spreadsheet में मिले-जुले date formats, currency strings, duplicate rows, empty values, summary rows, aliases आदि साथ मिले हों, तो मूल डेटा को सुरक्षित रखते हुए साफ़ की हुई copy बनवाई जाती है
• उपयोगकर्ता पहले से दिख रही समस्याओं और इच्छित output format को स्पष्ट रूप से बताता है, जैसे cleaned CSV, upload के लिए file, या नई sheet tab
• Codex साफ़ की हुई file के साथ data quality notes भी छोड़ता है ताकि आगे analysis या upload से पहले कोई व्यक्ति उसकी review कर सके
• उपयुक्त: वे टीमें जिन्हें अलग-अलग systems से मिली data files को analysis या operational system input के लिए तैयार करना होता है

4. टेबल-फ़ॉर्म डेटा पर query करना (Data / Knowledge Work)

कठिनाई: Easy | समय: 30m

• CSV, spreadsheet, dashboard export, Google Sheet, या local data file पर सवाल पूछने पर Codex columns की जाँच करता है और calculation, aggregation, तथा chart generation करता है
• केवल साधारण जवाब तक सीमित न रहकर, HTML-आधारित browser visualization बनाकर उसे Codex app में सीधे खोलने योग्य बनाने वाला workflow सुझाया जाता है
• पहली analysis के बाद region, cohort, product, week, model version, customer segment आदि के आधार पर उसी thread में आगे comparative analysis कराया जा सकता है
• उपयुक्त: data-driven काम जहाँ तेज़ calculation, सरल charts, और meetings के लिए summary चाहिए

5. GitHub Pull Request की review करना (Integrations / Workflow)

कठिनाई: Easy | समय: 5s

• GitHub organization या repository में Codex code review जोड़कर हर PR पर automatic review लिया जा सकता है, या PR comments में मैन्युअली review माँगा जा सकता है
• मुख्य फ़ोकस security regression, छूटे हुए tests, जोखिमपूर्ण behavior changes, documentation की कमी जैसी उन review signals को अतिरिक्त रूप से पकड़ना है जिन्हें इंसान आसानी से मिस कर सकता है
• अगर AGENTS.md में review priorities और file-specific rules लिखे जाएँ, तो Codex review मानदंडों को repository के अनुसार customize किया जा सकता है
• उपयुक्त: वे टीमें जिन्हें merge से पहले अतिरिक्त review signals चाहिए, और बड़े production codebase पर काम करने वाली टीमें

6. Inbox मैनेज करना (Automation / Integrations)

कठिनाई: Easy | समय: 5m

• Gmail जोड़कर ऐसे emails ढूँढे जाते हैं जिनका reply ज़रूरी है, और हाल में भेजे गए emails या approved writing examples के आधार पर उपयोगकर्ता के tone में reply drafts तैयार किए जाते हैं
• अगर केवल email से context पर्याप्त न हो, तो Slack, Google Drive, project notes जैसे कामकाजी टूल्स से ताज़ा decisions, owners, files, और blockers भी लाए जा सकते हैं
• पहली run को calibration की तरह लेकर, किन emails को नज़रअंदाज़ करना है और कौन-सा tone सही है इस पर feedback देने के बाद इसे नियमित automation में बदला जा सकता है
• उपयुक्त: वे लोग जो inbox sorting और reply draft लिखने का काम बार-बार संभालना चाहते हैं

7. Responsive front-end design लागू करना (Front-end / Design)

कठिनाई: Intermediate | समय: 1h

• Screenshot, design brief, और reference images देकर उन्हें मौजूदा repository के design system, tokens, और components को पुन: उपयोग करने वाले responsive UI में बदला जाता है
• Codex Playwright के साथ वास्तविक browser खोलता है और desktop/mobile breakpoints पर implementation की तुलना references से करते हुए बार-बार सुधार करता है
• जहाँ चीज़ें अस्पष्ट हों, वहाँ नया design system बनाने के बजाय मौजूदा patterns के अनुरूप सबसे सरल implementation चुनने और assumptions को स्पष्ट रूप से लिखने का निर्देश देना बेहतर है
• उपयुक्त: नए front-end screens बनाना, या मौजूदा app में designed screens जोड़ना

8. बड़े codebase को समझना (Engineering / Analysis)

कठिनाई: Easy | समय: 5m

• किसी अपरिचित repository या feature area में प्रवेश करते समय Codex से request flow, module responsibilities, data validation locations, side effects, और आगे पढ़ी जाने वाली files समझाने को कहा जाता है
• केवल सामान्य summary की तुलना में, अगर किसी विशेष system area को निर्दिष्ट किया जाए तो कहीं अधिक व्यावहारिक व्याख्या मिलती है
• follow-up questions के रूप में business logic कहाँ है, validation points कौन-से हैं, कौन-से background jobs आसानी से छूट सकते हैं, और बदलाव के बाद कौन-से tests चलाने चाहिए—ऐसा workflow सुझाया जाता है
• उपयुक्त: नए engineer onboarding, और feature changes से पहले code flow को जल्दी समझने वाले developer

9. Mac app shell बनाना (macOS / Code)

कठिनाई: Advanced | समय: 1h

• Build macOS Apps plugin का उपयोग करके Mac-native SwiftUI app shell बनाया जाता है, और NavigationSplitView आधारित sidebar, detail panel, तथा inspector संरचना स्थापित की जाती है
• menu, toolbar, keyboard shortcuts, और Settings scene जैसे desktop app के स्वाभाविक ढाँचे को शुरुआत में ही डिज़ाइन करने का निर्देश दिया जाता है
• लक्ष्य यह है कि केवल iPad या web app को फैलाकर बनाया गया रूप न हो, बल्कि ऐसा Mac app structure हो जिसमें windows, selection state, commands, और settings स्थिर रूप से काम करें
• उपयुक्त: editor, library, admin tools, और review tools जैसे वे Mac apps जिन्हें sidebar और inspector की ज़रूरत होती है

10. Codex से अपने कंप्यूटर को चलाना (Knowledge Work / Workflow)

कठिनाई: Easy | समय: 5m

• Computer Use के ज़रिए Codex को Mac apps को सीधे देखने, क्लिक करने और टाइप करने देते हुए कई apps और windows के बीच जाकर काम करने दिया जाता है
• यह उन tasks के लिए उपयुक्त है जो किसी सामान्य app UI के अंदर होते हैं जहाँ कोई dedicated plugin नहीं है, जैसे Notes से जानकारी लेकर किसी दूसरे सिस्टम में भरना या Messages की सामग्री देखकर जवाब का draft तैयार करना
• अनुरोध @Computer से शुरू करना अच्छा है, और साथ में वांछित परिणाम तथा वे जोखिमभरे काम भी लिखने चाहिए जिन्हें रोक देना चाहिए
• उपयुक्त उपयोगकर्ता: app UI के अंदर ही संभव दोहराए जाने वाले काम, कई windows और files के बीच जाने वाला knowledge work

11. बग triage को automate करना (Automation / Quality)

कठिनाई: Intermediate | समय: 1h

• Codex को उन जगहों का चक्कर लगाने दिया जाता है जहाँ bug signals इकट्ठे होते हैं, जैसे Sentry alerts, Slack threads, Linear/GitHub issues, PR failure checks, logs और support tickets
• पहले manual sweep से candidate list बनाई जाती है, फिर उसी thread में यह समायोजित किया जाता है कि कौन-सी items उपयोगी हैं, और उसके बाद इसे नियमित automation में बदला जाता है
• पर्याप्त भरोसा बनने पर Codex से Linear issues, Slack updates, GitHub comments और handoff notes के drafts भी लिखवाए जा सकते हैं
• उपयुक्त उपयोगकर्ता: product/engineering teams जिन्हें कई tools में बिखरी bug reports को हर दिन प्राथमिकता देनी होती है

12. slide deck बनाना (Data / Integrations)

कठिनाई: Easy | समय: 30m

• Codex PowerPoint files को सीधे code से edit कर सकता है, और image generation को मिलाकर मौजूदा deck को update या नया deck बना सकता है
• logo placement, खास slides पर text/image layout, मौजूदा branding बनाए रखना, overflow और font replacement checks जैसे delivery से पहले के नियम स्पष्ट रूप से बताए जाते हैं
• यह सलाह दी जाती है कि slides editable .pptx के रूप में रहें, और दोहराए जा सकने वाले layout rules को Codex हर slide पर लागू करे
• उपयुक्त उपयोगकर्ता: वे teams जो structured input या notes को presentation material में बदलती हैं, या जिन्हें बड़ी मात्रा में मौजूदा decks में बदलाव करना होता है

13. Slack में coding task शुरू करना (Integrations / Workflow)

कठिनाई: Easy | समय: 5m

• Slack app install करने और repository व environment को जोड़ने के बाद, thread में @Codex mention करके code task शुरू किया जाता है
• अगर thread में request, constraints और desired outcome पर्याप्त रूप से मौजूद हों, तो Codex उसी context के आधार पर cloud task चलाता है
• result link खोलकर review किया जा सकता है, और ज़रूरत पड़ने पर आगे के edits उसी Slack thread में जारी रखे जा सकते हैं
• उपयुक्त उपयोगकर्ता: वे teams जो Slack discussion से सीधे issue triage, bug fixes या छोटे implementation tasks सौंपना चाहती हैं

14. छोटे UI बदलावों को तेज़ी से दोहराना (Front-end / Design)

कठिनाई: Easy | समय: 5m

• जब मौजूदा app की संरचना पहले से तय हो, तब spacing, alignment, color, copy, responsive behavior और state जैसे छोटे UI बदलाव एक-एक करके तेज़ी से किए जाते हैं
• Codex-Spark जैसे तेज़ model के साथ “एक बार में एक visual note, एक छोटा edit, एक browser check” वाला loop सुझाया जाता है
• change का दायरा सटीक रूप से तय किया जाता है और मौजूदा components, tokens, layout primitives तथा data flow को सुरक्षित रखने की मांग की जाती है
• उपयुक्त उपयोगकर्ता: design review में निकले बारीक UI fixes, या product review के दौरान तुरंत लागू किए जाने वाले बदलाव

15. नए कर्मचारियों की onboarding को coordinate करना (Integrations / Data)

कठिनाई: Intermediate | समय: 30m

• approved new hires की सूची, onboarding tracker, manager/team mapping, equipment और account readiness, तथा calendar milestones को इकट्ठा करके review योग्य onboarding packet बनाया जाता है
• पहले pass को read-only रखना और वास्तविक invites, DMs, emails, channel creation तथा system updates को review के बाद स्पष्ट approval के साथ चलाना सुझाया जाता है
• team-wise summaries, readiness gaps, welcome space names, invite lists, first-week checklist और announcement drafts भी साथ में तैयार किए जा सकते हैं
• उपयुक्त उपयोगकर्ता: People, Recruiting, IT, Workplace Operations, और नए hires का स्वागत करने वाले managers

16. नई अवधारणा सीखना (Knowledge Work / Data)

कठिनाई: Intermediate | समय: 30m

• papers, lecture materials और लंबे documents जैसी high-density सामग्री को Codex पढ़कर problem framing, contribution, method, experiments, limitations और prerequisite concepts को व्यवस्थित कर सकता है
• Subagents का उपयोग करके main text structure समझना, prerequisite knowledge खोजना, figures/formulas का analysis करना, और final report लिखना जैसे roles बाँटे जा सकते हैं
• output को Markdown report, Mermaid diagram, concept map, या claim-to-evidence table जैसे ऐसे रूप में रखना बेहतर है जिन्हें बाद में फिर से review किया जा सके
• उपयुक्त उपयोगकर्ता: वे लोग जिन्हें किसी अनजान research area, जटिल technical concept या लंबे course material को जल्दी सीखना है

17. API integration upgrade करना (Evaluation / Engineering)

कठिनाई: Intermediate | समय: 1h

• मौजूदा OpenAI API integration को नवीनतम recommended models और API features पर ले जाते हुए behavior preservation और regression validation साथ में किया जाता है
• केवल model name बदलना पर्याप्त नहीं है; पहले current endpoints, tool assumptions, response formats, prompts और evaluation paths की inventory बनाई जाती है
• openai-docs का उपयोग करके latest model/prompt guides की जाँच करना, और Promptfoo जैसे eval pipeline से बदलाव से पहले और बाद के behavior को validate करना सुझाया जाता है
• उपयुक्त उपयोगकर्ता: पुराने models/endpoints का उपयोग करने वाले products, और model upgrade पर regression testing चाहने वाली teams

18. app या website deploy करना (Front-end / Integrations)

कठिनाई: Intermediate | समय: 30m

• repository, screenshots, design brief, product idea, API docs और data sources के आधार पर Codex web app बना या modify कर सकता है और Vercel preview URL तक deploy कर सकता है
• deployment से पहले project check, build/test, failure log analysis और preview validation करवाना मुख्य बिंदु है
• deployment के बाद भी उसी thread में mobile layout fixes, latest data reflection, और failed build log fixes जैसे काम जारी रखे जा सकते हैं
• उपयुक्त उपयोगकर्ता: वे teams जो ideas या designs को जल्दी से shareable web preview में बदलना चाहती हैं

19. Figma design को code में बदलना (Front-end / Design)

कठिनाई: Intermediate | समय: 1h

• Figma MCP server के ज़रिए सटीक nodes का design context, variables, assets और variants लेकर उन्हें मौजूदा repository के design system के अनुरूप code में बदला जाता है
• get_design_context, और ज़रूरत पड़ने पर get_metadata, get_screenshot के क्रम से structure और references सुरक्षित करने के बाद implementation शुरू करना सुझाया जाता है
• Playwright के साथ browser में implementation result को Figma reference से तुलना करते हुए responsive behavior और interaction differences को बार-बार सुधारा जाता है
• उपयुक्त उपयोगकर्ता: design/frontend teams जिन्हें Figma में तैयार screens या flows को मौजूदा codebase में लागू करना है

20. Computer Use से app QA करना (Automation / Quality)

कठिनाई: Intermediate | समय: 30m

• Computer Use वास्तविक इंटरफ़ेस को देखकर क्लिक, टाइप और स्क्रोल करते हुए मुख्य user flows चलाता है और विफलता बिंदुओं को रिकॉर्ड करता है
• environment, टेस्ट किए जाने वाले मुख्य flows, bug report format, severity criteria, reproduction steps और expected/actual results के बारे में स्पष्ट निर्देश देना चाहिए
• यह feature bugs और UI issues दोनों को पकड़ सकता है, और नतीजों को QA report या engineers को सौंपने लायक triage summary के रूप में व्यवस्थित करता है
• उपयुक्त: release से पहले मुख्य flows का verification, और manual QA को structured बनाना चाहने वाली टीमें

21. डेटासेट विश्लेषण और रिपोर्ट तैयार करना (Data / Analysis)

कठिनाई: Intermediate | समय: 1h

• बिखरी हुई data files को लोड करके cleaning, join, exploratory analysis, visualization और modeling के जरिए decision-making में इस्तेमाल होने वाली report या dashboard के रूप में पैकेज किया जाता है
• यह महत्वपूर्ण है कि Codex पहले प्रोजेक्ट के Python environment, package manager, output folder और script conventions को समझे
• बार-बार होने वाली notebook cleanup, spreadsheet export और final report packaging को reusable skill में बदल देने से वही analysis flow दोबारा इस्तेमाल करना आसान हो जाता है
• उपयुक्त: data cleanup से लेकर charts, notes और reports तक reproducible analysis outputs चाहने वाले analysts/product teams

22. मैसेज से निकले काम पूरे करना (Knowledge Work / Integrations)

कठिनाई: Easy | समय: 5m

• Messages thread में मौजूद booking, research, schedule coordination, receipt submission और information gathering जैसे छिपे हुए कामों को Computer Use पहचानकर पूरा करता है
• किसी खास sender या thread को निर्दिष्ट किया जा सकता है, और काम पूरा होने के बाद उसी मूल message thread में भेजे जाने वाले reply draft को भी तैयार कराया जा सकता है
• payment, order, booking confirmation जैसे मुश्किल से पलटे जा सकने वाले actions के लिए यह ज़रूर निर्देश देना चाहिए कि पहले रुके और approval ले
• उपयुक्त: निजी messages से बने छोटे execution tasks को बिना छूटे पूरा करना चाहने वाले लोग

23. आइडिया से PoC बनाना (Front-end / Engineering)

कठिनाई: Intermediate | समय: 1h

• GPT Image/ImageGen से पहले high-quality UI mockup बनाकर visual direction तय की जाती है, और फिर उसी mock के आधार पर Build Web Apps या Game Studio plugin से काम करने वाला prototype बनाया जाता है
• यह शुरुआती product ideas के लिए उपयुक्त है जहाँ साधारण document planning की तुलना में वास्तविक clickable PoC ज़्यादा जवाब देता है
• अंत में जिस image को implement करना है, उसे नए turn में attach करना बेहतर है ताकि Codex उसे सीधे reference के रूप में देख सके
• उपयुक्त: dashboards, tools, web apps और game ideas को तेज़ी से visualize और validate करना चाहने वाली टीमें

24. ब्राउज़र-आधारित गेम बनाना (Engineering / Code)

कठिनाई: Intermediate | समय: Long-running

• game brief से सीधे coding शुरू नहीं की जाती, बल्कि पहले player goals, main loop, controls, win/loss conditions, rendering और asset plan वाला PLAN.md लिखवाया जाता है
• ImageGen से concept art, sprites, background और UI assets बनाए जाते हैं, और Playwright से वास्तविक browser में controls और screen state को test करते हुए iteration की जाती है
• क्योंकि game में code, UI, assets, balancing और deployment तक लगातार जाँच करनी होती है, यह Codex के long-running iterative work के लिए अच्छा उदाहरण है
• उपयुक्त: शुरू से browser game बनाना, या prototype के controls और visuals को बार-बार validate करने वाले काम

25. कठिन समस्याओं पर बार-बार सुधार करना (Engineering / Analysis)

कठिनाई: Advanced | समय: Long-running

• स्पष्ट evaluation system, scoring script और reviewable artifacts देकर Codex को score-based improvement loop चलाने दिया जाता है
• deterministic check और LLM-as-a-judge score को साथ में इस्तेमाल किया जाता है, और overall score तथा judge average के लिए stopping rule रखा जाता है
• संरचना ऐसी होती है कि Codex हर iteration में current output check करे, score मापे, एक improvement लागू करे, दोबारा evaluate करे और logs दर्ज करे
• उपयुक्त: optimization problems जो एक बार में खत्म नहीं होते, या visual/subjective quality को कई बार सुधारने वाले काम

26. वर्कफ़्लो को Skill के रूप में सहेजना (Engineering / Workflow)

कठिनाई: Easy | समय: 5m

• अच्छी तरह काम कर चुके Codex threads, review rules, test commands, release checklists, design rules, writing examples और repo-specific scripts को reusable skill के रूप में सहेजा जाता है
• $skill-creator का उपयोग करके यह structure किया जाता है कि वह कब trigger हो, कौन-सी सामग्री और commands इस्तेमाल हों, और किस तरह का output चाहिए
• home directory के skills सभी repos में इस्तेमाल किए जा सकते हैं, और project के अंदर के skills को टीम के साथ commit करके साझा किया जा सकता है
• उपयुक्त: हर बार लंबा prompt paste करने के बजाय Codex को दोहराए जाने वाले काम याद दिलाना चाहने वाली टीमें

27. डॉक्यूमेंटेशन को अपडेट करना (Engineering / Code)

कठिनाई: Easy | समय: 30m

• code changes, tests, release notes और PR/issue context को साथ पढ़कर README, developer docs, migration note और runbook अपडेट किए जाते हैं
• बेहतर है कि Codex पहले मौजूदा docs में संबंधित feature name, config key, command और example ढूँढे, और फिर केवल न्यूनतम documentation surface को बदले
• अगर यह public documentation है, तो स्पष्ट रूप से सीमित करना चाहिए ताकि internal roadmap, customer information या private context उसमें न मिल जाए
• उपयुक्त: product behavior में बदलाव के साथ documentation को भी साथ-साथ संभालने वाली technical writing/engineering teams

28. iOS ऐप बनाना (iOS / Code)

कठिनाई: Advanced | समय: 1h

• Codex SwiftUI iOS app को scaffold करता है, और xcodebuild या Tuist-आधारित CLI-first build/run loop सेट करता है
• यदि यह मौजूदा project है, तो scheme, simulator, screenshot और UI automation जानकारी को XcodeBuildMCP से जाँचते हुए काम कराया जा सकता है
• SwiftUI expert, Liquid Glass और SwiftUI performance जैसे iOS-related skills जोड़ने पर UI implementation, latest API adoption और performance checks ज़्यादा स्थिर ढंग से किए जा सकते हैं
• उपयुक्त: greenfield SwiftUI apps, और simulator-based verification की ज़रूरत वाले मौजूदा iPhone/iPad projects

29. कोडबेस का रिफैक्टर करना (Engineering / Code)

कठिनाई: Advanced | समय: 1h

• dead code, duplicate logic, बहुत बड़े modules, पुराने abstractions और legacy patterns को खोजकर छोटे, reviewable units में व्यवस्थित किया जाता है
• क्योंकि refactoring stack migration नहीं बल्कि behavior बनाए रखते हुए system का रूप सुधारने का काम है, इसलिए public behavior बनाए रखने की बात स्पष्ट रूप से कहनी चाहिए
• बड़े cleanup work को checkpoints में बाँटने और test व verification दोहराने के flow के लिए ExecPlan या reusable skill का उपयोग सुझाया जाता है
• उपयुक्त: ऐसे पुराने codebases जहाँ features जोड़ना लगातार महँगा होता जा रहा हो, और behavior-preserving cleanup की ज़रूरत हो

30. iOS App Intents जोड़ना (iOS / Code)

कठिनाई: Advanced | समय: 1h

• ऐप के भीतर के मुख्य action और entities की पहचान कर उन्हें Shortcuts, Siri, Spotlight, widgets, controls जैसे system surfaces में इस्तेमाल करने योग्य बनाता है
• पूरी स्क्रीन के बजाय पहले कुछ ऐसे actions और objects डिज़ाइन किए जाते हैं जिन्हें system को समझना चाहिए और जिन्हें यूज़र ऐप खोले बिना चलाना चाहें
• यह ऐसा flow है जिसमें Codex मौजूदा ऐप के model, navigation और data access paths का विश्लेषण करता है और पहला intent surface छोटे स्तर पर लागू करवाता है
• उपयुक्त: ऐसे ऐप जिनमें पहले से उपयोगी फीचर्स हैं, लेकिन वे iOS system automation और search में अच्छी तरह दिखाई नहीं देते

31. macOS ऐप बनाना (macOS / Code)

कठिनाई: Advanced | समय: 1h

• SwiftUI-आधारित macOS ऐप बनाते समय पहले WindowGroup, Window, Settings, MenuBarExtra, DocumentGroup जैसे scene model चुनने के लिए कहता है
• xcodebuild या swift build और प्रोजेक्ट के लोकल script/build_and_run.sh के ज़रिए shell-first build/run loop तैयार करता है
• ऐप के बड़ा होने पर windows, menu, sidebar, Settings, AppKit interop और signing समस्याओं को desktop app के नज़रिए से संभालता है
• उपयुक्त: नए Mac ऐप जिन्हें desktop native structure चाहिए, या मौजूदा Mac ऐप जिनके UI/build/deployment में सुधार करना है

32. Liquid Glass लागू करना (iOS / Code)

कठिनाई: Advanced | समय: 1h

• iOS 26 और Xcode 26 के आधार पर मौजूदा SwiftUI ऐप को build करता है, और standard controls से अपने-आप मिलने वाले system glass तथा सीधे बदलने वाले custom UI में अंतर करता है
• custom blur/material stack को native glassEffect, GlassEffectContainer, glass button style, glassEffectID transition में ले जाने के लिए कहता है
• अगर पुराने iOS versions का support ज़रूरी हो, तो #available(iOS 26, *) और fallback path को स्पष्ट रूप से बनाए रखना चाहिए
• उपयुक्त: वे टीमें जो iOS 26 Liquid Glass के लिए मौजूदा ऐप के high-traffic flow को सुरक्षित रूप से migrate करना चाहती हैं

33. Mac telemetry जोड़ना (macOS / Code)

कठिनाई: Advanced | समय: 30m

• Mac ऐप के window open, sidebar selection, menu command, sync milestone जैसे flows में Apple Logger-आधारित high-signal logs जोड़ता है
• Codex ऐप को build/run करके Console या log stream में यह प्रमाणित करवाता है कि वास्तविक events अपेक्षित क्रम में हुए या नहीं
• संवेदनशील payload से बचते हुए subsystem/category को स्पष्ट रखता है, ताकि agentic debugging loop में अगला patch ठोस आधार पर तय किया जा सके
• उपयुक्त: Mac ऐप फीचर्स जहाँ केवल code review से flow ट्रैक करना मुश्किल हो, या log-आधारित debugging loop

34. iOS simulator में debugging करना (iOS / Code)

कठिनाई: Advanced | समय: 1h

• Codex और XcodeBuildMCP scheme/simulator ढूँढते हैं, ऐप को build/run करते हैं, फिर UI hierarchy पढ़कर tap, type, swipe, screenshot और log capture करते हैं
• ज़रूरत पड़ने पर LLDB जोड़कर stack frame, local variables और breakpoint की जाँच करता है, और अस्पष्ट bug report को दोहराए जा सकने वाले छोटे बदलाव में बदलता है
• बदलाव के बाद उसी simulator path को फिर चलाकर यह सबूत छोड़ना मुख्य है कि bug गायब हो गया है
• उपयुक्त: iOS UI bugs जो केवल किसी खास tab/scroll/input flow में होते हैं, या crash/hang/navigation समस्याएँ

35. dependency incidents का audit करना (Engineering / Quality)

कठिनाई: Advanced | समय: 1h

• जब public package advisory या supply chain incident होता है, तो तुरंत patch करने के बजाय पहले एक सतर्क read-only audit plan बनवाता है
• Codex authoritative sources और सामान्य टिप्पणियों में अंतर करता है, exposure को साबित या खारिज करने वाले evidence को परिभाषित करता है, फिर manifest, lock file, CI workflow और scripts की जाँच करता है
• untrusted code का execution, install, build और test स्पष्ट मंज़ूरी मिलने तक टालना इसका मूल सिद्धांत है
• उपयुक्त: security/engineering टीमें, और dependency incidents पर तेज़ी से प्रतिक्रिया देने वाले maintainers

36. मीटिंग brief तैयार करना (Integrations / Knowledge Work)

कठिनाई: Easy | समय: 30m

• केवल Calendar invite से पूरी न होने वाली meeting context को Drive documents, Slack threads, Gmail और पुराने notes से इकट्ठा कर objective, agenda, open questions और notes template में व्यवस्थित करता है
• Codex पहले sources inventory बनाता है, फिर verified context, source gap और open questions को अलग-अलग करता है
• मीटिंग तैयारी सामग्री छोटी और स्कैन करने योग्य होनी चाहिए, और यह ट्रैक किया जा सके कि कौन-सी बात किस source से आई है
• उपयुक्त: managers, PMs, operators, interviewers और वे लोग जिन्हें meeting से पहले context जल्दी व्यवस्थित करना है

37. event playbook चलाना (Integrations / Knowledge Work)

कठिनाई: Intermediate | समय: 1h

• event planning channel, approved documents/decks/sheets/templates और calendar deadlines को इकट्ठा कर source-backed playbook बनाता है
• public event page copy और internal operations checklist, owners, approval और open questions को अलग-अलग मैनेज करना इसका मुख्य बिंदु है
• अगर event बार-बार होने वाला हो, तो उसी thread में automation लगाकर deadline, approvals, missing materials और launch checklist status ट्रैक कराया जा सकता है
• उपयुक्त: community, DevRel, marketing और operations teams का event program management

38. code migration चलाना (Engineering / Code)

कठिनाई: Advanced | समय: 1h

• legacy stack से target stack में जाते समय routing, data model, auth, config, background job, build, deploy, test और external contracts की पहले inventory बनाता है
• compatibility layer, module-by-module port, branch-by-abstraction, strangler-style replacement जैसी incremental strategy चुनता है
• हर checkpoint पर parity validation करता है, और migration के कारण ज़रूरी visible changes को स्पष्ट अपवाद के रूप में संभालता है
• उपयुक्त: वे टीमें जिन्हें framework/runtime/language/build system transition को नियंत्रित इकाइयों में आगे बढ़ाना है

39. SwiftUI स्क्रीन का refactor करना (iOS / Code)

कठिनाई: Advanced | समय: 1h

• विशाल SwiftUI screen फ़ाइल को behavior और layout बनाए रखते हुए छोटे section view और explicit data flow में विभाजित करें
• Build iOS Apps plugin की SwiftUI view refactor skill MV-first approach की सिफारिश करती है, अनावश्यक view model जोड़ने से बचती है, और side effect को body के बाहर ले जाती है
• एक छोटा validation loop जोड़कर यह सुनिश्चित करना महत्वपूर्ण है कि UI नहीं बदला है और functionality भी बरकरार है
• उपयुक्त: ऐसे SwiftUI screen जिनके body में layout, branching, async काम, और inline action मिले-जुले हों

40. आंतरिक context से PRD draft बनाना (Integrations / Knowledge Work)

कठिनाई: Easy | समय: 30m

• Linear project, Slack planning channel, Notion/Google Drive दस्तावेज़, meeting notes, और research सामग्री को इकट्ठा करके reviewable PRD तैयार करें
• problem, user, requirements, UX, technical considerations, launch plan, timeline, decisions, और open questions जैसे section contract को स्पष्ट रूप से देना बेहतर है
• पहले source appendix की समीक्षा करके देखें कि Codex ने कौन-सा context इस्तेमाल किया, फिर requirements और open questions को refine करें
• उपयुक्त: PM/product team जो टीम की आंतरिक चर्चा से निकली जानकारी को PRD, proposal, launch brief, या decision memo में बदलती है

41. cash flow का पूर्वानुमान लगाना (Data / Knowledge Work)

कठिनाई: Intermediate | समय: 30m

• beginning cash, expected receipts, payroll, vendor payments, debt, tax, capex, working capital, और timing assumptions डालकर editable cash-flow forecast workbook बनाएं
• मूल cadence को बनाए रखें, और ऐसा summary tab बनवाएं जो safety balance breach और cash pressure पैदा करने वाले assumptions दिखाए
• जनरेट की गई .xlsx को Codex में खोलकर formula, scenario, और timing assumptions की समीक्षा करें और उसी thread में संशोधित करें
• उपयुक्त: finance/operations team जो 13-week या monthly cash forecast बनाती है

42. DCF valuation model बनाना (Data / Knowledge Work)

कठिनाई: Intermediate | समय: 30m

• historical financials, valuation assumptions, और modeling notes डालकर revenue growth, margin, capex, working capital, WACC, और terminal value वाला DCF workbook बनाएं
• Codex model tab, formula, assumption, और valuation summary के साथ editable .xlsx बनाता है, और उपयोगकर्ता उसे सीधे Codex में review/modify करता है
• उसी thread में formula link verify करना, assumptions बदलना, scenario जोड़ना, और model tightening जारी रखा जा सकता है
• उपयुक्त: analyst/finance team जिन्हें valuation workbook जल्दी बनाकर review करना होता है

43. budget बनाम actuals की समीक्षा करना (Data / Knowledge Work)

कठिनाई: Easy | समय: 30m

• budget plan, actuals export, और close notes डालकर actuals को plan category से map करें और variance calculate करने वाला review workbook बनाएं
• मूल input, mapping, variance formula, और summary tab को बनाए रखें, और reconciliation issue तथा open finance question को अलग करें
• category mapping ठीक करना, department cut जोड़ना, और finance summary draft लिखना उसी thread में जारी रखा जा सकता है
• उपयुक्त: finance team जिन्हें monthly close review और budget बनाम खर्च के अंतर को leadership को समझाना होता है

44. लक्ष्य का अनुसरण करना (Engineering / Automation)

कठिनाई: Advanced | समय: Long-running

• /goal का उपयोग करके Codex को एक turn पर रुके बिना verify किए जा सकने वाले end condition तक long-running काम जारी रखने दें
• objective, stopping condition, पहले पढ़ी जाने वाली file/document/log/plan, और progress साबित करने वाले command या artifact को स्पष्ट रूप से निर्दिष्ट करें
• migration, large refactor, deployment retry loop, experiment, game, या prototype जैसे वे काम उपयुक्त हैं जिनमें Codex checkpoint के आधार पर स्वतंत्र रूप से आगे बढ़ सकता है
• उपयुक्त: coding काम जो कई घंटों तक चलते हैं, लेकिन जिनका goal और validation loop स्पष्ट होता है

45. AI application में Evals जोड़ना (Evaluation / Quality)

कठिनाई: Intermediate | समय: 1h

• मौजूदा AI app के prompt, model call, tool, retrieval, agent, और product requirement का विश्लेषण करके Promptfoo eval suite जोड़ें
• पूरे system को एक साथ evaluate करने की बजाय classification, extraction, summarization, routing, grounding, tool use, या format rule जैसे किसी एक user-visible behavior से शुरुआत करें
• Codex config और test data बनाता है, eval को local में चलाता है, और बाद में दोबारा उपयोग किए जा सकने वाले commands छोड़ता है
• उपयुक्त: AI app team जो model/prompt/retrieval/agent बदलाव से पहले regression test बनाना चाहती है

46. user story को UI mock में बदलना (Integrations / Knowledge Work)

कठिनाई: Easy | समय: 30m

• Slack, Linear, Google Drive, customer-call notes आदि में बिखरे feedback को इकट्ठा करके user story और constraint में व्यवस्थित करें, फिर ImageGen से UI mock direction तैयार करें
• अगर स्पष्ट user story है तो तुरंत शुरू करें; नहीं है तो Codex पहले context इकट्ठा करके problem और requirement को normalize करे
• चुने गए mock को नए turn में फिर से attach करके मौजूदा codebase के design system और components को reuse करने वाला working prototype implement करें
• उपयुक्त: product/design/engineering team जिन्हें बिखरे product feedback को visual direction में बदलना है और team review के लिए mock चाहिए

47. app को ChatGPT में लाना (Integrations / Code)

कठिनाई: Advanced | समय: 1h

• एक संकीर्ण user outcome को केंद्र में रखकर ChatGPT app डिज़ाइन करें, और MCP server, optional web component, tool metadata को end-to-end बनाएं
• Codex, tool surface और metadata डिज़ाइन, MCP server scaffold, widget implementation, ChatGPT connection, और golden prompt testing संभालने के लिए उपयुक्त है
• v1 में पहले यह तय करें कि widget सच में ज़रूरी है या नहीं, authentication और deployment की ज़रूरत है या नहीं, और local HTTPS testing तथा developer mode verification संभव है या नहीं
• उपयुक्त इनके लिए: वे टीमें जो अपना पहला ChatGPT app बना रही हैं या MCP server/tool metadata को ज़रूरत से ज़्यादा बड़ा किए बिना शुरुआत करना चाहती हैं

48. Expo से React Native app बनाना (Mobile / Engineering)

कठिनाई: Intermediate | समय: 1h

• Expo plugin का उपयोग करके React Native app scaffold करें, और Expo Router, Expo-native package convention, तथा Expo Go आधारित तेज़ testing loop का पालन करें
• केवल तब dev client या EAS build पर जाएँ जब custom native code, store distribution, या Expo Go द्वारा सपोर्ट न की जाने वाली capability की ज़रूरत हो
• Codex native-feeling navigation, loading/empty/error states सहित एक पूरा workflow बनाकर उसे सबसे तेज़ रास्ते से validate करने में मदद करता है
• उपयुक्त इनके लिए: वे developers जो native IDE पर काम शुरू करने से पहले Expo से mobile app को तेज़ी से prototype करना या release के लिए तैयार करना चाहते हैं

49. ऐसा CLI बनाना जिसे Codex इस्तेमाल कर सके (Engineering / Code)

कठिनाई: Intermediate | समय: 1h

• जिन API, log source, export inbox, local DB, और team script तक Codex को बार-बार पहुँचना होता है, उन्हें composable CLI में wrap करें ताकि वे किसी भी repo में चल सकें
• एक अच्छा CLI paged search, exact read by ID, predictable JSON, download, local index, और draft-before-write जैसे agent-friendly behavior देता है
• $cli-creator से CLI बनाएं और $skill-creator से एक companion skill भी तैयार करें, जिसमें लिखा हो कि यह CLI कब इस्तेमाल किया जाना चाहिए
• उपयुक्त इनके लिए: वे टीमें जिन्हें Codex से एक ही service या data source को अक्सर पढ़वाना, खोजवाना, और सुरक्षित तरीके से संचालित करवाना होता है

50. Slack action items को प्राथमिकता देना (Automation / Integrations)

कठिनाई: Easy | समय: 30m

• Slack DM, group DM, channel mention, और thread reply पढ़कर सीधे अनुरोध, implicit follow-up, पहले से सुलझे items, और अब भी live actions में अंतर करें
• Codex नवीनतम thread tail तक पढ़कर unresolved स्थिति तय करता है, फिर urgency और impact के आधार पर ranked action queue बनाता है
• draft reply या handoff बनाया जा सकता है, लेकिन वास्तविक post/send को review के बाद ही होने देने के लिए सीमित रखना बेहतर है
• उपयुक्त इनके लिए: launch, support, product, operations, और community workstream जहाँ काम Slack के ज़रिए आता है

51. सत्यापनीय operations workflows चलाना (Automation / Integrations)

कठिनाई: Intermediate | समय: 30m

• access update, invite batch, quota change, customer setup, routing check, migration follow-up जैसे दोहराए जाने वाले operations tasks Codex से चलवाएँ
• input table, approval source, policy, चलाने वाले script/API/CLI/skill, dry run करना है या नहीं, और retry boundary को स्पष्ट दें ताकि वह missing fields का अनुमान न लगाए
• result CSV, log file, dashboard link, screenshot, PR check जैसे verification artifacts माँगें जिन्हें इंसान सत्यापित कर सके
• उपयुक्त इनके लिए: वे operations कार्य जिनमें structured input और स्पष्ट approval/audit trail की ज़रूरत होती है

52. मीटिंग को follow-up काम में बदलना (Automation / Integrations)

कठिनाई: Intermediate | समय: 5m

• Zoom transcript और AI Companion summary का उपयोग करके customer meeting से निकले key takeaway, risk, opportunity, decision, और action item को structured करें
• Codex follow-up email, account plan, CRM update, और Slack notification का draft बनाता है, लेकिन भेजना या रिकॉर्ड करना user की review के बाद ही होना चाहिए
• Zoom cloud recording, transcript, AI Companion summary के साथ Gmail, Slack, Google Docs, और CRM जैसे destination tools को जोड़ने पर प्रभाव बढ़ता है
• उपयुक्त इनके लिए: वे customer-facing टीमें जिन्हें discovery, renewal, implementation, या executive sponsor call के बाद बार-बार follow-up tasks संभालने होते हैं