तुमच्या AI प्रदात्याला टेलीप्रॉम्प्टर बनवणे थांबवा आणि सबएजंट्स, स्किल्स व कमांड्स तयार करा

प्रॉम्प्टवरील अवलंबित्वाकडून बुद्धिमान एजंट प्रणालींकडे

बहुतेक लोक अजूनही AI चा वापर टेलीप्रॉम्प्टरसारखा करतात.

ते प्रॉम्प्ट टाइप करतात. वाट पाहतात. उत्तर मिळते. ते कुठेतरी कॉपी-पेस्ट करतात. मग पुन्हा तेच. आणि पुन्हा. प्रत्येक संवाद शून्यापासून सुरू होतो. प्रत्येक संभाषण आधी काय झाले ते विसरते.

हे सहकार्य नाही. हे फक्त अनावश्यक पायऱ्यांसह सांगून लिहवून घेणे आहे.

2026 मध्ये, जर तुम्ही अजूनही तुमच्या AI प्रदात्याला टेलीप्रॉम्प्टर बनवत असाल, तर तुमच्या पायाखाली घडणारा संपूर्ण बदल तुम्ही गमावत आहात.

टेलीप्रॉम्प्टरची समस्या

AI ला टेलीप्रॉम्प्टरसारखे वापरताना, संभाव्यतः स्वायत्त असलेल्या प्रणालीला तुम्ही फक्त एकदाच मजकूर तयार करणारे यंत्र समजता. याचा नमुना असा दिसतो:

1. तुम्ही सविस्तर प्रॉम्प्ट लिहिता
2. तुम्ही उत्तराची वाट पाहता
3. तुम्ही आउटपुटचे स्वतः मूल्यमापन करता
4. तुम्ही सुधारणा करून पुन्हा प्रॉम्प्ट देता
5. चॅट बंद केल्यावर सर्व संदर्भ गमावता

या पद्धतीत तीन गंभीर त्रुटी आहेत:

टिकणारे ज्ञान नाही. प्रत्येक संभाषण कोरी पाटी असते. तोच संदर्भ तुम्ही वारंवार समजावता. तुमच्या AI ला तुमचा कोडबेस, तुमच्या आवडीनिवडी, तुमच्या मर्यादा किंवा तुमचा इतिहास माहीत नसतो.

जबाबदारी सोपवणे नाही. अडथळा तुम्हीच राहता. प्रत्येक निर्णय, प्रत्येक पडताळणी, प्रत्येक पुढची पायरी तुमच्या सूचनेवर अवलंबून असते. पुढे काय करायचे ते तुम्ही सांगण्याची AI वाट पाहते.

विशेषज्ञता नाही. कोडिंग, दस्तऐवजीकरण, डिझाइन, चाचणी, डिप्लॉयमेंट या सगळ्यासाठी तुम्ही एकच सर्वसाधारण इंटरफेस वापरता. एकच प्रॉम्प्ट शैली. एकच संदर्भ विंडो. अनेकांचे काम करणारे एकच संभाषण.

टेलीप्रॉम्प्टर पद्धत AI ला साधन मानते. पण साधने स्वायत्तता वाढवत नाहीत. एजंट वाढवतात.

एजंट्सच्या दृष्टीने विचार केल्यावर काय बदलते

Claude Code मध्ये एजंट आर्किटेक्चर तीन मूलभूत घटकांनी बनलेले आहे:

• सबएजंट्स: स्वतंत्र संदर्भ विंडो असलेले विशेषज्ञ Claude इन्स्टन्स (~/.claude/agents/)
• स्किल्स: SKILL.md फाइल्ससह आपोआप सक्रिय होणारे ज्ञान मॉड्यूल्स (~/.claude/skills/)
• कमांड्स: स्पष्ट कृतींसाठी वापरकर्ता सुरू करणाऱ्या /slash कमांड्स (~/.claude/commands/)

पारंपरिक प्रॉम्प्टिंगपेक्षा मुख्य फरक:

• स्किल्स संदर्भानुसार Claude आपोआप सक्रिय करतो
• कमांड्स तुम्ही स्वतः /command टाइप करावी लागते
• सबएजंट्स स्वतःच्या साधनांसह वेगळ्या संदर्भात चालतात

फरक पाहा:

टेलीप्रॉम्प्टर पद्धत:

"आमच्या डिझाइन सिस्टमचे पॅटर्न आणि अॅक्सेसिबिलिटी मानके पाळून मला इमेज, शीर्षक, मजकूर आणि प्राथमिक बटन असलेला कार्ड कॉम्पोनंट लिहून दे..."

Claude Code पद्धत:

/generate card --variant=default --with-image=true --with-button=true

पहिली ही विनंती आहे. दुसरी अशा स्किलला बोलावते जिला आधीच माहीत आहे की कार्ड म्हणजे काय, तुमची डिझाइन सिस्टम काय मागते, कोणती अॅक्सेसिबिलिटी मानके लागू होतात आणि स्वतःचे आउटपुट कसे पडताळायचे.

आर्किटेक्चर: सबएजंट्स, स्किल्स & कमांड्स

टेलीप्रॉम्प्टर पद्धतीची जागा घेणारी रचना ही आहे:

स्तर 1: सबएजंट्स

सबएजंट्स या ~/.claude/agents/ मधील स्वतंत्र markdown फाइल्स असतात, ज्या कामे समांतर पार पाडतात. त्यांच्या स्वतःच्या संदर्भ विंडो असतात आणि ते स्किल्स बोलावू शकतात.

~/.claude/agents/
├── header-builder.md
├── footer-builder.md
└── dashboard-builder.md

प्रत्येक सबएजंट फाइलमध्ये YAML frontmatter असते:

• name: स्पष्ट ओळखनाव
• description: तो काय करतो आणि केव्हा बोलवायचा
• tools: परवानगी असलेल्या क्षमता (Read, Write, Bash, Grep, Glob)

उदाहरण सबएजंट (header-builder.md):

---
name: header-builder
description: Build complete header components with navigation
tools: Read, Write, Bash, Glob, Grep
---  You are a header component specialist...

स्तर 2: स्किल्स

स्किल्स म्हणजे आपोआप सक्रिय होणारे ज्ञान मॉड्यूल्स. तुम्ही Claude ला एखादी अशी गोष्ट विचारता जी एखाद्या स्किलच्या उद्देशाशी जुळते, तेव्हा Claude ती आपोआप लागू करतो.

~/.claude/skills/
├── card/
│   ├── SKILL.md
│   ├── workflows/
│   │   ├── generate.md
│   │   ├── validate.md
│   │   └── improve.md
│   ├── references/
│   │   └── schema.yml
│   └── scripts/
│       └── validate.py

हे Atomic Design पद्धतीचे अनुसरण करते: अॅटम्स, मॉलिक्यूल्स, ऑर्गॅनिझम्स. प्रत्येक स्किल नेमक्या एकाच गोष्टीत तज्ज्ञ असते. तुम्हाला कार्ड हवे असेल तेव्हा कार्ड स्किल आपोआप सक्रिय होते.

प्रत्येक स्किलला हे माहीत असते:

• कॉम्पोनंटचा स्कीमा (props, slots, variants)
• तुमच्या डिझाइन सिस्टमचे संकेत
• फ्रेमवर्कनुसार पॅटर्न्स
• WCAG अॅक्सेसिबिलिटी आवश्यकता
• ती संदर्भ म्हणून वापरू शकणारी संबंधित स्किल्स

स्तर 3: कमांड्स

कमांड्स म्हणजे वापरकर्ता सुरू करणारे शॉर्टकट. त्यांना बोलावण्यासाठी तुम्ही /command टाइप करता. त्या स्किल वर्कफ्लोजमध्ये किंवा जागतिक स्तरावर असतात:

~/.claude/skills/card/workflows/
├── generate.md    # /generate card
├── validate.md    # /validate card
├── improve.md     # /improve card
├── document.md    # /document card
├── test.md        # /test card
└── a11y.md        # /a11y card

कमांड्स नियोजनासाठी सबएजंट्सना बोलावू शकतात, आणि मग मुख्य Claude अंमलबजावणी हाताळतो. यामुळे तुम्हाला सर्व साधनांच्या प्रवेशासह संरचित वर्कफ्लोज मिळतात.

संपूर्ण उदाहरण: कार्ड स्किल

एका खऱ्या स्किलसह हे नेमके कसे चालते ते दाखवतो:

स्किलची रचना

~/.claude/skills/card/
├── SKILL.md           # Core prompt and instructions
├── workflows/         # Slash commands
│   ├── generate.md
│   ├── validate.md
│   ├── improve.md
│   ├── document.md
│   ├── test.md
│   └── a11y.md
├── references/        # Documentation loaded into context
│   └── schema.yml
└── scripts/           # Executable Python/Bash scripts
    └── validate.py

SKILL.md फाइल

---
name: card
description: Generate and validate card components 
  for any design system with accessibility checks
---  # Card Skill  When user requests card components, this skill 
auto-triggers based on context.
 ## Schema  props:
  title: string
  body: string
  image: { src, alt, width }
  variant: default | horizontal | overlay
 slots:
  header: Custom header content
  footer: Buttons, links
 ## Related Skills  This skill can reference:
- image
- heading
- button
- link
- text

स्लॅश कमांड्स वापरणे

नवीन कार्ड तयार करा:

/generate card \   --variant="default" \   --title="Welcome" \   --with-image=true \   --with-button=true

अस्तित्वातील कार्डची पडताळणी करा:

/validate card \   --file="components/card.jsx"

अॅक्सेसिबिलिटी अनुपालन तपासा:

/a11y card --level="AA"

विशिष्ट संदर्भासाठी UX सुधारा:

/improve card \   --context="e-commerce product listing" \   --focus="conversion"

पडद्यामागे काय घडते

तुम्ही /generate card बोलावता तेव्हा Claude:

1. कार्ड स्किल सक्रिय करतो: SKILL.md संदर्भात लोड होते
2. स्कीमा वाचतो:  तुमचे पॅरामीटर्स परवानगी असलेल्या props शी पडताळतो
3. इतर स्किल्सचा संदर्भ घेतो:  image, heading, button स्किल्स त्यांचे कौशल्य पुरवतात
4. वर्कफ्लो चालवतो: workflows/generate.md कार्यान्वित होते
5. स्वतः पडताळणी करतो: स्वतःच्या आउटपुटवर validate वर्कफ्लो चालवतो
6. निकाल परत देतो:  कॉम्पोनंट आणि सोबत काही इशारे असल्यास ते देतो

कार्ड स्किल फक्त मार्कअप तयार करत नाही. ती विशेषज्ञांची एक प्रणाली चालवते, ज्यात प्रत्येकजण आपले क्षेत्रीय कौशल्य देतो.

हे का महत्त्वाचे: निर्मात्याकडून प्रणालीविचारकाकडे

टेलीप्रॉम्प्टर पद्धत तुम्हाला चालक बनवून ठेवते. स्किल पद्धत तुम्हाला शिल्पकार (आर्किटेक्ट) बनवते.

प्रॉम्प्ट लिहिण्याकडून स्किल्स डिझाइन करण्याकडे वळलो, तेव्हा अनेक गोष्टी बदलल्या:

मी संदर्भ पुन्हा सांगणे थांबवले. प्रत्येक स्किलला तिचे क्षेत्र आधीच माहीत असते. कार्ड हवे असेल तेव्हा कार्ड म्हणजे काय हे मी दरवेळी समजावत नाही.

मी रचनेच्या (composition) दृष्टीने विचार करू लागलो. पेज म्हणजे एक प्रॉम्प्ट नाही, ती ऑर्गॅनिझम्सची सांगड आहे; ऑर्गॅनिझम्स मॉलिक्यूल्सची, आणि मॉलिक्यूल्स अॅटम्सची. प्रत्येक स्तराची स्वतःची स्किल आहे.

मी पडताळणी सोपवली. प्रत्येक आउटपुट हाताने तपासण्याऐवजी, /validate कमांड रचना तपासते, /a11y कमांड WCAG अनुपालन तपासते आणि /test कमांड स्वयंचलित तपासण्या चालवते. मी प्रत्येक निकाल नव्हे, तर अपवाद तपासतो.

मी संस्थात्मक ज्ञान उभारले. मी स्किलची SKILL.md सुधारतो तेव्हा ती सुधारणा टिकते. प्रणाली केवळ एका संभाषणापुरती नव्हे, तर कालांतराने अधिक हुशार होत जाते.

AI वापरणे आणि AI सोबत निर्मिती करणे यातला हाच फरक आहे.

डिझाइन म्हणजेच कोड

डिझाइन सिस्टम्सवरील माझ्या कामात मी एका तत्त्वापर्यंत पोहोचलो आहे: डिझाइन म्हणजेच कोड.

डिझाइन टोकन्स, कॉम्पोनंट स्कीमा आणि एजंट कॉन्फिगरेशन्स एकमेकांशी जुळतात, तेव्हा डिझाइनर्स जे ठरवतात आणि डेव्हलपर्स जे बनवतात यांच्यात कोणताही अनुवादाचा स्तर उरत नाही. विनिर्देशच अंमलबजावणी असतो.

एजंट्स हे प्रत्यक्षात कसे आणतात ते पाहा:

# The schema IS the source of truth schema:   props:     variant:       type: string
      enum: [primary, secondary, success, danger, warning, info]       default: primary
    size:       type: string
      enum: [sm, md, lg]       default: md
 tokens:   colors:     - --btn-bg
    - --btn-color
    - --btn-border-color

हा स्कीमा फक्त दस्तऐवजीकरण नाही. तो सत्याचा स्रोत आहे. एजंट त्यातून कॉम्पोनंट्स तयार करतो. व्हॅलिडेटर त्याच्याशी तपासणी करतो. डिझाइन टोकन्स त्याचा संदर्भ घेतात. एक फाइल, अनेक उपयोग.

डिझायनरने Figma मध्ये टोकनची मूल्ये अद्ययावत केली की एजंट कॉन्फिगरेशन अद्ययावत होते. एजंट कॉन्फिगरेशन अद्ययावत झाले की तयार होणारे कॉम्पोनंट्स अद्ययावत होतात. डिझाइन म्हणजेच कोड आहे, कारण दोन्ही एकाच स्कीमातून उगम पावतात.

Claude Code सोबत निर्मिती कशी सुरू करावी

टेलीप्रॉम्प्टर पद्धतीच्या पलीकडे जायला तुम्ही तयार असाल, तर हा एक व्यावहारिक मार्ग आहे:

पायरी 1: तुमची क्षेत्रे ओळखा

तुमच्या कामातील कोणती क्षेत्रे पुनरावृत्तीची, नियमबद्ध आणि संदर्भावर अवलंबून आहेत? तीच स्किलसाठी योग्य उमेदवार आहेत:

• कोड निर्मिती
• दस्तऐवजीकरण
• चाचणी
• पुनरावलोकन आणि पडताळणी
• डिझाइन सिस्टम व्यवस्थापन
• डिप्लॉयमेंट आणि DevOps

पायरी 2: तुमची पहिली स्किल तयार करा

साध्या SKILL.md ने सुरुवात करा:

---
name: my-component
description: Generate and validate my-component
---  # My Component Skill  When user asks about my-component, apply these rules...

पायरी 3: वर्कफ्लोज (कमांड्स) जोडा

workflows/ मध्ये सहा मूलभूत कमांड्स तयार करा:

प्रत्येक कमांड म्हणजे सूचना असलेली एक markdown फाइल आहे.

पायरी 4: स्किल संदर्भ प्रस्थापित करा

स्किल्स इतर स्किल्सचा संदर्भ घेऊ शकतात:

## Related Skills  This skill uses:
- image (for card images)
- button (for CTAs)
- heading (for titles)

ही अवलंबित्वे नकाशावर मांडा. उतरंड तुमच्या क्षेत्राच्या नैसर्गिक रचनेशी जुळली पाहिजे.

पायरी 5: गुंतागुंतीच्या कामांसाठी सबएजंट्स तयार करा

तुम्हाला स्वतंत्र संदर्भ किंवा समांतर अंमलबजावणी हवी असेल, तेव्हा ~/.claude/agents/ मध्ये सबएजंट फाइल तयार करा:

---
name: header-builder
description: Build complete header components with navigation, logo, and search
tools: Read, Write, Bash, Glob, Grep
---  You are a header component specialist. When building headers:
1. Check existing header patterns in the codebase
2. Use the nav, button, logo skills for sub-components
3. Ensure responsive design and accessibility

तुमची स्किल लायब्ररी उभारणे

तुमची स्किल्स Atomic Design नुसार रचा:

प्रत्येक स्किल:

• स्वतःचे SKILL.md कॉन्फिगरेशन असते
• स्लॅश कमांड्ससह workflows/ असते
• दस्तऐवजीकरणासह references/ असते
• स्वयंचलनासाठी scripts/ असते
• ती कोणत्या इतर स्किल्सचा संदर्भ घेते हे जाणते

यामुळे एक सुसंगत, वाढीव प्रणाली तयार होते, जिथे Claude संदर्भानुसार योग्य स्किल आपोआप सक्रिय करतो.

भविष्य एजंटिक आहे

Atomic Design चे निर्माते Brad Frost या बदलाबद्दल बोलत आहेत: डिझाइन सिस्टम्स यंत्रवाचनीय पायाभूत सुविधा बनल्या पाहिजेत, कारण AI एजंट्स आता मानवी टीम्स वापरतात त्याच कॉम्पोनंट्सनी UI जुळवत आहेत.

ही 2030 बद्दलची भविष्यवाणी नाही. हे आत्ता घडत आहे.

तुमची डिझाइन सिस्टम एजंटला वाचता येत नसेल, तर ती कालबाह्य होत आहे. तुमच्या डेव्हलपमेंट वर्कफ्लोमध्ये प्रत्येक पायरीसाठी माणसाला प्रॉम्प्ट द्यावा लागत असेल, तर तो वाढत नाही. तुमचे AI संवाद दरवेळी शून्यापासून सुरू होत असतील, तर तुम्ही साठलेले ज्ञान वाया घालवत आहात.

AI नवलाईची गोष्ट होती तेव्हा टेलीप्रॉम्प्टर पद्धत चालून गेली. AI पायाभूत सुविधा झाल्यावर ती चालणार नाही.

प्रॉम्प्ट देणे थांबवा. डिझाइन करायला सुरू करा.

एजंट्स तयार करा. त्यांना स्किल्स द्या. त्यांना समन्वय साधू द्या.

भविष्य त्यांचे आहे जे प्रणाली उभारतात, त्यांचे नाही जे स्क्रिप्ट्स लिहितात.

वेब डेव्हलपमेंटच्या भविष्यासाठी एजंटिक डिझाइन सिस्टम्स उभारत आहे.

पुढील वाचन

• डिझाइन म्हणजेच कोड  डिझाइन सिस्टम्समधील सेल्युलर ऑटोमेटा विचारसरणीचा माझा शोध
• Brad Frost यांचे Atomic Design  कॉम्पोनंट उतरंडीमागील पद्धत
• स्वतःला उभारणाऱ्या प्रणालींची रचना  निर्मात्याकडून प्रणालीविचारकाकडे