നിങ്ങളുടെ 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/-ലെ സ്വതന്ത്ര മാർക്ക്ഡൗൺ ഫയലുകളാണ്; അവ സമാന്തരമായി ജോലി ചെയ്യുന്നു. അവയ്ക്ക് സ്വന്തം കോൺടെക്സ്റ്റ് വിൻഡോകളുണ്ട്, സ്കില്ലുകളെ വിളിക്കാനും കഴിയും.

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

ഓരോ സബ്ഏജന്റ് ഫയലിനും YAML ഫ്രണ്ട്മാറ്റർ ഉണ്ട്:

• 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

ഇത് ആറ്റോമിക് ഡിസൈൻ രീതിശാസ്ത്രം പിന്തുടരുന്നു: ആറ്റങ്ങൾ, തന്മാത്രകൾ, ജീവികൾ (atoms, molecules, organisms). ഓരോ സ്കില്ലും ഒരേയൊരു കാര്യത്തിലെ വിദഗ്ധനാണ്. കാർഡ് വേണ്ടിവരുമ്പോൾ കാർഡ് സ്കിൽ സ്വയം പ്രവർത്തിക്കും.

ഓരോ സ്കില്ലിനും അറിയാവുന്നത്:

• കമ്പോണന്റിന്റെ സ്കീമ (പ്രോപ്പുകൾ, സ്ലോട്ടുകൾ, വേരിയന്റുകൾ)
• നിങ്ങളുടെ ഡിസൈൻ സിസ്റ്റം കീഴ്വഴക്കങ്ങൾ
• ഫ്രെയിംവർക്ക്-നിർദ്ദിഷ്ട പാറ്റേണുകൾ
• 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. സ്കീമ വായിക്കുന്നു:  അനുവദനീയമായ പ്രോപ്പുകൾക്കെതിരെ നിങ്ങളുടെ പാരാമീറ്ററുകൾ പരിശോധിക്കുന്നു
3. മറ്റ് സ്കില്ലുകളെ പരാമർശിക്കുന്നു:  image, heading, button സ്കില്ലുകൾ അവരുടെ വൈദഗ്ധ്യം നൽകുന്നു
4. വർക്ക്ഫ്ലോ പ്രവർത്തിപ്പിക്കുന്നു: workflows/generate.md പ്രവർത്തിക്കുന്നു
5. സ്വയം പരിശോധിക്കുന്നു: സ്വന്തം ഔട്ട്പുട്ടിൽ validate വർക്ക്ഫ്ലോ പ്രവർത്തിപ്പിക്കുന്നു
6. ഫലം തിരികെ നൽകുന്നു:  കമ്പോണന്റും മുന്നറിയിപ്പുകളും നൽകുന്നു

കാർഡ് സ്കിൽ വെറുതെ മാർക്കപ്പ് ഉണ്ടാക്കുകയല്ല. ഓരോരുത്തരും തങ്ങളുടെ മേഖലയിലെ വൈദഗ്ധ്യം സംഭാവന ചെയ്യുന്ന വിദഗ്ധരുടെ ഒരു സംവിധാനത്തെ അത് ഏകോപിപ്പിക്കുന്നു.

എന്തുകൊണ്ട് ഇത് പ്രധാനം: നിർമ്മാതാവിൽ നിന്ന് സിസ്റ്റം ചിന്തകനിലേക്ക്

ടെലിപ്രോംപ്റ്റർ മാതൃക നിങ്ങളെ ഓപ്പറേറ്ററായി നിലനിർത്തുന്നു. സ്കിൽ മാതൃക നിങ്ങളെ ആർക്കിടെക്റ്റാക്കുന്നു.

പ്രോംപ്റ്റുകൾ എഴുതുന്നതിൽ നിന്ന് സ്കില്ലുകൾ രൂപകൽപ്പന ചെയ്യുന്നതിലേക്ക് ഞാൻ മാറിയപ്പോൾ പല കാര്യങ്ങളും മാറി:

സന്ദർഭം ആവർത്തിക്കുന്നത് ഞാൻ നിർത്തി. ഓരോ സ്കില്ലിനും അതിന്റെ മേഖല ഇതിനകം അറിയാം. ഒരു കാർഡ് വേണ്ടപ്പോഴെല്ലാം കാർഡ് എന്താണെന്ന് ഞാൻ വിശദീകരിക്കാറില്ല.

ഘടകങ്ങൾ ചേർത്ത് ചിന്തിക്കാൻ തുടങ്ങി. ഒരു പേജ് ഒരൊറ്റ പ്രോംപ്റ്റല്ല; അത് ഓർഗാനിസങ്ങളുടെ ഏകോപനമാണ്, ഓർഗാനിസങ്ങൾ തന്മാത്രകളുടെ ഏകോപനമാണ്, തന്മാത്രകൾ ആറ്റങ്ങളുടെ ഏകോപനമാണ്. ഓരോ തട്ടിനും സ്വന്തം സ്കിൽ ഉണ്ട്.

പരിശോധന ഞാൻ ഏൽപ്പിച്ചു. ഓരോ ഔട്ട്പുട്ടും കൈകൊണ്ട് പരിശോധിക്കുന്നതിനു പകരം, /validate കമാൻഡ് ഘടന പരിശോധിക്കുന്നു, /a11y കമാൻഡ് WCAG പാലനം പരിശോധിക്കുന്നു, /test കമാൻഡ് ഓട്ടോമേറ്റഡ് പരിശോധനകൾ നടത്തുന്നു. ഓരോ ഫലവുമല്ല, അപവാദങ്ങളാണ് ഞാൻ നോക്കുന്നത്.

സ്ഥാപനപരമായ അറിവ് ഞാൻ കെട്ടിപ്പടുത്തു. ഒരു സ്കില്ലിന്റെ SKILL.md ഞാൻ മെച്ചപ്പെടുത്തുമ്പോൾ ആ മെച്ചപ്പെടുത്തൽ നിലനിൽക്കുന്നു. ഒരൊറ്റ സംഭാഷണത്തിൽ മാത്രമല്ല, കാലക്രമേണ സംവിധാനം കൂടുതൽ മിടുക്കനാകുന്നു.

AI ഉപയോഗിക്കുന്നതും AI കൊണ്ട് നിർമ്മിക്കുന്നതും തമ്മിലുള്ള വ്യത്യാസം ഇതാണ്.

ഡിസൈൻ തന്നെയാണ് കോഡ്

ഡിസൈൻ സിസ്റ്റങ്ങളിലെ എന്റെ പ്രവർത്തനത്തിൽ ഞാൻ ഒരു തത്വത്തിലെത്തി: ഡിസൈൻ തന്നെയാണ് കോഡ് (The Design Is the Code).

ഡിസൈൻ ടോക്കണുകളും കമ്പോണന്റ് സ്കീമകളും ഏജന്റ് കോൺഫിഗറേഷനുകളും ഒത്തുചേരുമ്പോൾ, ഡിസൈനർമാർ നിർദ്ദേശിക്കുന്നതിനും ഡെവലപ്പർമാർ നിർമ്മിക്കുന്നതിനും ഇടയിൽ ഒരു വിവർത്തന പാളിയുമില്ല. സ്പെസിഫിക്കേഷൻ തന്നെയാണ് നടപ്പാക്കൽ.

ഏജന്റുകൾ ഇത് എങ്ങനെ യാഥാർത്ഥ്യമാക്കുന്നുവെന്ന് നോക്കൂ:

# 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/-ൽ ആറ് പ്രധാന കമാൻഡുകൾ ഉണ്ടാക്കുക:

ഓരോ കമാൻഡും നിർദ്ദേശങ്ങളുള്ള ഒരു മാർക്ക്ഡൗൺ ഫയലാണ്.

ഘട്ടം 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

നിങ്ങളുടെ സ്കിൽ ലൈബ്രറി നിർമ്മിക്കുക

ആറ്റോമിക് ഡിസൈൻ പിന്തുടർന്ന് നിങ്ങളുടെ സ്കില്ലുകൾ ക്രമീകരിക്കുക:

ഓരോ സ്കില്ലിനും:

• സ്വന്തം SKILL.md കോൺഫിഗറേഷൻ ഉണ്ട്
• സ്ലാഷ് കമാൻഡുകളുള്ള workflows/ ഉണ്ട്
• ഡോക്യുമെന്റേഷനുള്ള references/ ഉണ്ട്
• ഓട്ടോമേഷനായി scripts/ ഉണ്ട്
• ഏതൊക്കെ സ്കില്ലുകളെ പരാമർശിക്കുന്നുവെന്ന് അറിയാം

ഇത് സ്ഥിരതയുള്ളതും വികസിപ്പിക്കാവുന്നതുമായ ഒരു സംവിധാനം ഉണ്ടാക്കുന്നു; സന്ദർഭം നോക്കി ശരിയായ സ്കിൽ Claude സ്വയം പ്രവർത്തിപ്പിക്കുന്നു.

ഭാവി ഏജന്റിക് ആണ്

ആറ്റോമിക് ഡിസൈനിന്റെ സ്രഷ്ടാവായ Brad Frost ഈ മാറ്റത്തെക്കുറിച്ച് സംസാരിക്കുന്നുണ്ട്: ഡിസൈൻ സിസ്റ്റങ്ങൾ മെഷീൻ-വായനായോഗ്യമായ അടിസ്ഥാനസൗകര്യമാകണം, കാരണം മനുഷ്യ ടീമുകൾ ഉപയോഗിക്കുന്ന അതേ കമ്പോണന്റുകൾ കൊണ്ട് ഇപ്പോൾ AI ഏജന്റുകളും UI-കൾ കൂട്ടിച്ചേർക്കുന്നു.

ഇത് 2030-നെക്കുറിച്ചുള്ള പ്രവചനമല്ല. ഇത് ഇപ്പോൾ നടക്കുന്നു.

നിങ്ങളുടെ ഡിസൈൻ സിസ്റ്റം ഒരു ഏജന്റിന് വായിച്ചെടുക്കാനാവില്ലെങ്കിൽ, അത് പഴഞ്ചനാകുകയാണ്. ഓരോ ചുവടിലും മനുഷ്യൻ പ്രോംപ്റ്റ് ചെയ്യണമെന്ന് നിങ്ങളുടെ ഡെവലപ്മെന്റ് വർക്ക്ഫ്ലോ ആവശ്യപ്പെടുന്നെങ്കിൽ, അത് വളരില്ല. നിങ്ങളുടെ AI ഇടപെടലുകൾ ഓരോ തവണയും പൂജ്യത്തിൽ നിന്ന് തുടങ്ങുന്നെങ്കിൽ, സമാഹരിച്ച അറിവ് നിങ്ങൾ പാഴാക്കുകയാണ്.

AI ഒരു കൗതുകം മാത്രമായിരുന്ന കാലത്ത് ടെലിപ്രോംപ്റ്റർ മാതൃക മതിയായിരുന്നു. AI അടിസ്ഥാനസൗകര്യമാകുമ്പോൾ അത് മതിയാകില്ല.

പ്രോംപ്റ്റ് ചെയ്യുന്നത് നിർത്തൂ. രൂപകൽപ്പന തുടങ്ങൂ.

ഏജന്റുകളെ നിർമ്മിക്കൂ. അവയ്ക്ക് സ്കില്ലുകൾ നൽകൂ. അവ ഏകോപിപ്പിക്കട്ടെ.

ഭാവി സ്ക്രിപ്റ്റുകൾ എഴുതുന്നവരുടേതല്ല, സംവിധാനങ്ങൾക്ക് രൂപം നൽകുന്നവരുടേതാണ്.

വെബ് ഡെവലപ്മെന്റിന്റെ ഭാവിക്കായി ഏജന്റിക് ഡിസൈൻ സിസ്റ്റങ്ങൾ നിർമ്മിക്കുന്നു.

കൂടുതൽ വായനയ്ക്ക്

• The Design Is the Code  ഡിസൈൻ സിസ്റ്റങ്ങളിലെ സെല്ലുലാർ ഓട്ടോമാറ്റ ചിന്തയെക്കുറിച്ചുള്ള എന്റെ അന്വേഷണം
• Atomic Design by Brad Frost  കമ്പോണന്റ് ശ്രേണികൾക്ക് പിന്നിലെ രീതിശാസ്ത്രം
• Designing Systems That Build Themselves  നിർമ്മാതാവിൽ നിന്ന് സിസ്റ്റം ചിന്തകനിലേക്ക്