Դադարեցրու քո արհեստական բանականության մատակարարին հեռակառավարված հուշարձողով կառավարելը և ստեղծիր ենթաագենտներ, հմտություններ ու հրամաններ

Հրամանահուշումներից կախվածությունից դեպի բանական գործակալական համակարգեր անցում

Մարդկանց մեծ մասը դեռևս օգտագործում է ԱԲ-ը որպես տելեպրոմպտեր։

Նրանք գրում են հրամանահուշում։ Սպասում են։ Մ ստանում են պատասխան։ Պատճենում‑տեղադրում են այն ինչ‑որ տեղ։ Հետո նորից են անում։ Եվ էլի նորից։ Ամեն փոխազդեցություն սկսվում է զրոյից։ Ամեն զրույց մոռանում է, թե ինչ է եղել մինչ այդ։

Սա համագործակցություն չէ։ Սա թելադրություն է՝ ավելորդ քայլերով։

2026‑ին, եթե դեռ ձեր ԱԲ մատակարարին օգտագործում եք որպես տելեպրոմպտեր, ձեր աչքի առաջ տեղի ունեցող ամբողջ փոփոխությունից դուրս եք մնում։

Տելեպրոմպտերի խնդիրը

Երբ ԱԲ‑ին վերաբերվում եք որպես տելեպրոմպտերի, հնարավոր ինքնավար համակարգին վերաբերվում եք որպես մեկանգամյա տեքստ գեներատորի։ Պատկերը մոտավորապես այսպիսին է․

1. Դուք գրում եք մանրամասն հրամանահուշում
2. Սպասում եք պատասխանին
3. Ձեռքով գնահատում եք արդյունքը
4. Խմբագրում և նորից հրամանահուշում եք տալիս
5. Կորցնում եք ողջ համատեքստը, երբ փակում եք չաթը

Այս մոդելը ունի երեք մահացու թերություն․

Չկա մշտական գիտելիք։ Ամեն զրույց դատարկ էջ է։ Միևնույն համատեքստը նորից ու նորից եք բացատրում։ Ձեր ԱԲ‑ը չի ճանաչում ձեր կոդբազան, ձեր նախասիրությունները, ձեր սահմանափակումները կամ ձեր պատմությունը։

Չկա պատվիրակություն։ Խցանմունքը մնում եք դուք։ Ամեն որոշում, ամեն վավերացում, ամեն հաջորդ քայլ պահանջում է ձեր միջամտությունը։ ԱԲ‑ը սպասում է, մինչև դուք ասեք՝ ինչ անել հետո։

Չկա մասնագիտացում։ Ամեն ինչի համար օգտագործում եք մեկ ընդհանուր միջերես՝ կոդ, փաստաթղթավորում, դիզայն, թեստավորում, ներդնում։ Մեկ հրամանահուշման ոճ։ Մեկ համատեքստի պատուհան։ Մեկ զրույց, որը փորձում է անել շատերի գործը։

Տելեպրոմպտերի մոդելը ԱԲ‑ին տեսնում է որպես գործիք։ Բայց գործիքներն ինքնավարություն չեն մասշտաբում։ Դա անում են գործակալները։

Ինչ է փոխվում, երբ մտածում եք գործակալներով

Claude Code‑ում գործակալի ճարտարապետությունը բաղկացած է երեք հիմնական տարրերից․

• Ենթագործակալներ․ մասնագիտացված Claude‑ի օրինակներ՝ մեկուսացված համատեքստային պատուհաններով (~/.claude/agents/)
• Հմտություններ․ ավտոմատ գործարկվող գիտելիքաշարքեր SKILL.md ֆայլերով (~/.claude/skills/)
• Հրամաններ․ օգտատիրոջ կողմից գործարկվող /slash հրամաններ՝ հստակ գործողությունների համար (~/.claude/commands/)

Հիմնական տարբերությունը ավանդական հրամանահուշումից հետևյալն է․

• Հմտությունները Claude‑ը գործարկում է ինքնաբերաբար՝ ըստ համատեքստի
• Հրամանները պահանջում են, որ դուք explícit գրեք /command
• Ենթագործակալները աշխատում են առանձին համատեքստում՝ իրենց սեփական գործիքներով

Պատկերացրեք տարբերությունը․

Տելեպրոմպտերի մոտեցում․

«Գրիր card կոմպոնենտ պատկերով, վերնագրով, հիմնական տեքստով և հիմնական կոճակով՝ հետևելով մեր դիզայն համակարգի օրինակներին և հասանելիության ստանդարտներին...»

Claude Code‑ի մոտեցում․

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

Առաջինը խնդրանք է։ Երկրորդը կանչում է մի հմտություն, որը արդեն գիտի՝ ինչ է card‑ը, ինչ է պահանջում ձեր դիզայն համակարգը, ինչ հասանելիության ստանդարտներ են կիրառվում և ինչպես ինքն իրեն վավերացնի։

Ճարտարապետությունը․ ենթագործակալներ, հմտություններ և հրամաններ

Ահա այն կառուցվածքը, որը փոխարինում է տելեպրոմպտերի մոդելին․

1‑րդ մակարդակ․ ենթագործակալներ

Ենթագործակալները առանձին markdown ֆայլեր են ~/.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

Սա հետևում է Atomic Design մեթոդաբանությանը․ ատոմներ, մոլեկուլներ, օրգանիզմներ։ Յուրաքանչյուր հմտություն վարպետ է մեկ կոնկրետ բանի մեջ։ Երբ ձեզ պետք է card, card հմտությունն ավտոմատ գործարկվում է։

Յուրաքանչյուր հմտություն գիտի․

• Կոմպոնենտի սխեման (props, slots, տարբերակներ)
• Ձեր դիզայն համակարգի կոնվենցիաները
• Ֆրեյմվորկին հատուկ pattern‑ները
• WCAG հասանելիության պահանջները
• Կապված հմտությունները, որոնց կարող է դիմել

3‑րդ մակարդակ․ հրամաններ

Հրամանները օգտատիրոջ կողմից գործարկվող շորթքաթեր են։ Դրանց կանչում եք գրելով /command։ Դրանք ապրում են հմտության workflows‑ում կամ գլոբալ․

~/.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‑ը զբաղվում է գործարկմամբ։ Սա ձեզ տալիս է կառուցված workflows՝ լիարժեք գործիքային հասանելիությամբ։

Ամբողջական օրինակ․ Card հմտություն

Արի՛ ցույց տամ, թե ինչպես է սա աշխատում իրական հմտության օրինակով․

Հմտության կառուցվածքը

~/.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

Slash հրամանների օգտագործումը

Նոր card գեներացնել․

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

Գոյություն ունեցող card‑ը վավերացնել․

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

Ստուգել հասանելիության համապատասխանությունը․

/a11y card --level="AA"

Բարելավել UX‑ը հատուկ համատեքստի համար․

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

Ինչ է կատարվում կուլիսների հետևում

Երբ կանչում եք /generate card, Claude‑ը․

1. Գործարկում է card հմտությունը․ SKILL.md‑ն բեռնվում է համատեքստում
2. Կարդում է սխեման․ ստուգում է ձեր պարամետրերը թույլատրելի props‑ների նկատմամբ
3. Դիմում է այլ հմտությունների․ image, heading, button հմտությունները տրամադրում են իրենց փորձառությունը
4. Գործարկում է workflow‑ը․ workflows/generate.md‑ն կատարվում է
5. Ինքնավավերացվում է․ իր իսկ արդյունքի վրա চালում է validate workflow‑ը
6. Վերադարձնում է արդյունքը․ տալիս է կոմպոնենտը՝ հավելյալ նախազգուշացումների հետ միասին

Card հմտությունը պարզապես markup չի գեներացնում։ Այն համակարգ է համակարգում մասնագետների, որոնցից յուրաքանչյուրը բերում է իր դաշտի փորձառությունը։

Ինչու է սա կարևոր․ ստեղծողից՝ համակարգային մտածողի

Տելեպրոմպտերի մոդելը ձեզ պահում է որպես օպերատոր։ Հմտությունների մոդելը ձեզ դարձնում է ճարտարապետ։

Երբ ես անցա հրամանահուշումներ գրելուց հմտություններ նախագծելու, մի քանի բան փոխվեց․

Դադարեցի կրկնել համատեքստը։ Յուրաքանչյուր հմտություն արդեն գիտի իր դոմենը։ Ամեն անգամ, երբ ինձ պետք է card, այլևս չեմ բացատրում՝ ինչ է card‑ը։

Սկսեցի մտածել կոմպոզիցիայով։ Էջը մեկ հրամանահուշում չէ․ դա օրգանիզմների համակարգում է, որոնք համակարգում են մոլեկուլները, որոնք համակարգում են ատոմները։ Յուրաքանչյուր շերտ ունի իր հմտությունը։

Պատվիրակեցի վավերացումը։ Փոխարենը, որ ինքնուրույն վերանայեմ ամեն արդյունք, /validate հրամանը ստուգում է կառուցվածքը, /a11y հրամանը՝ WCAG համապատասխանությունը, իսկ /test հրամանը՝ ավտոմատ թեստերը։ Ես ստուգում եմ բացառությունները, ոչ թե ամեն արդյունք։

Կառուցեցի ինստիտուցիոնալ գիտելիք։ Երբ բարելավում եմ հմտության SKILL.md‑ն, այդ բարելավումը մնում է։ Համակարգն ավելի խելացի է դառնում ժամանակի ընթացքում, ոչ թե միայն մեկ զրույցի ընթացքում։

Սա տարբերությունն է ԱԲ օգտագործելու և ԱԲ‑ով կառուցելու միջև։

Դիզայնը հենց կոդն է

Իմ աշխատանքում՝ դիզայն համակարգերի հետ, ձևակերպել եմ մի սկզբունք․ Դիզայնը հենց կոդն է։

Երբ դիզայն թոքենները, կոմպոնենտների սխեմաները և գործակալների կոնֆիգուրացիաները համահունչ են, այլևս թարգմանության շերտ չկա այն բանի միջև, ինչ դիզայներներն են նշում, և ինչ զարգացուցիչներն են կառուցում։ Սպեցիֆիկացիան հենց ինքն է իրագործումը։

Ահա թե ինչպես են գործակալները դարձնում սա իրականություն․

# 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 (հրամաններ)

Ստեղծիր վեց հիմնական հրամանները 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/՝ slash հրամաններով
• Ունի references/՝ փաստաթղթավորմամբ
• Ունի scripts/՝ ավտոմատացման համար
• Գիտի, թե որ հմտություններին է հղում անում

Սա ստեղծում է հետևողական, մասշտաբելի համակարգ, որտեղ Claude‑ը ինքն է ըստ համատեքստի գործարկում ճիշտ հմտությունը։

Ապագան գործակալական է

Atomic Design‑ի ստեղծող Բրեդ Ֆրոստը վաղուց է խոսում այս շրջադարձի մասին․ դիզայն համակարգերը պետք է դառնան մեքենայի համար ընթեռնելի ենթակառուցվածք, որովհետև ԱԲ գործակալներն արդեն հավաքում են UI‑ներ նույն կոմպոնենտներից, որոնցով աշխատում են մարդկային թիմերը։

Սա 2030‑ի կանխատեսում չէ։ Սա տեղի է ունենում հենց հիմա։

Եթե ձեր դիզայն համակարգը գործակալի կողմից չի կարող վերլուծվել, այն դառնում է ժառանգական համակարգ։ Եթե ձեր զարգացման workflow‑ը պահանջում է, որ մարդը յուրաքանչյուր քայլին հրամանահուշում գրի, այն չի մասշտաբվում։ Եթե ձեր ԱԲ‑ի փոխազդեցությունները ամեն անգամ սկսվում են զրոյից, դուք վատնում եք կուտակված գիտելիքը։

Տելեպրոմպտերի մոդելը նորմալ էր, երբ ԱԲ‑ը նորություն էր։ Դա նորմալ չէ, երբ ԱԲ‑ը ենթակառուցվածք է։

Դադարե՛ք հրամանահուշում տալ։ Սկսե՛ք նախագծել։

Կառուցե՛ք գործակալներ։ Տվե՛ք նրանց հմտություններ։ Թող նրանք համակարգեն միմյանց։

Ապագան պատկանում է նրանց, ովքեր նախագծում են համակարգեր, ոչ թե նրանց, ովքեր գրում են սցենարներ։

Գործակալական դիզայն համակարգերի կառուցում վեբ զարգացման ապագայի համար։

Լրացուցիչ ընթերցանություն

• The Design Is the Code  Իմ ուսումնասիրությունը բջջային ավտոմատների մտածողության մասին դիզայն համակարգերում
• Atomic Design by Brad Frost  Կոմպոնենտների հիերարխիաների հիմքում ընկած մեթոդաբանությունը
• Designing Systems That Build Themselves  Ստեղծողից՝ համակարգային մտածողի