Ĉesu Uzi Vian Liveranton de AI kiel Telepromptron kaj Kreu Subagentojn, Kapablojn kaj Komandojn

Transiri de dependececo je instigoj al sistemoj de inteligentaj agentoj

Plej multaj homoj ankoraŭ uzas AI-on kiel telepromptilon.

Ili tajpas instigon. Ili atendas. Ili ricevas respondon. Ili kopi-gluas ĝin ien. Poste ili faras tion denove. Kaj denove. Ĉiu interago komenciĝas je nulo. Ĉiu konversacio forgesas tion, kio venis antaŭe.

Tio ne estas kunlaboro. Tio estas diktado kun kromaĵoj.

En 2026, se vi ankoraŭ telepromptas vian AI-provizon, vi maltrafas la tutan ŝanĝon okazantan rekte sub vi.

La teleprompter-problemo

Kiam vi uzas AI-on kiel telepromptilon, vi traktas potenciale aŭtonoman sistemon kiel unufojan teksto-generilon. La ŝablono aspektas tiel:

1. Vi verkas detalan instigon
2. Vi atendas la respondon
3. Vi permane pritaksas la eligon
4. Vi plirafinas kaj re-instigas
5. Vi perdas la tutan kuntekston kiam vi fermas la babilejon

Tiu modelo havas tri fatalajn mankojn:

Neniu persista scio. Ĉiu konversacio estas malplena tabulo. Vi klarigas la saman kuntekston ripete. Via AI ne konas vian kodaron, viajn preferojn, viajn limojn aŭ vian historion.

Neniu delego. Vi restas la blokpunkto. Ĉiu decido, ĉiu validigo, ĉiu sekva paŝo bezonas vian enigon. La AI atendas, ke vi diru al ĝi, kion fari poste.

Neniu specialiĝo. Vi uzas unu ĝeneralan interfacon por ĉio – programado, dokumentado, dezajno, testado, deplojado. Unu instiga stilo. Unu kunteksta fenestro. Unu konversacio faranta la laboron de multaj.

La teleprompter-modelo traktas AI-on kiel ilon. Sed iloj ne skalas aŭtonomion. Agentoj ja.

Kio ŝanĝiĝas kiam vi pensas per agentoj

En Claude Code, la agenta arkitekturo konsistas el tri elementaj konstrubriketoj:

• Subagentoj: specialigitaj ekzempleroj de Claude kun izolaj kuntekstaj fenestroj (~/.claude/agents/)
• Kapabloj (Skills): aŭtomate ekigitaj sciomoduloj kun SKILL.md-dosieroj (~/.claude/skills/)
• Komandoj: de-uzantaj /slash-komandoj por eksplicitaj agoj (~/.claude/commands/)

La ŝlosila diferenco rilate al tradicia instigado:

• Kapabloj estas aŭtomate ekigitaj de Claude laŭ la kunteksto
• Komandoj postulas, ke vi tajpu eksplicite /command
• Subagentoj funkcias en aparta kunteksto kun siaj propraj iloj

Konsideru la diferencon:

Teleprompter-alproksimiĝo:

“Skribu por mi kartan komponanton kun bildo, titolo, ĉefa teksto kaj ĉefa butono, laŭ niaj modeloj de dezajnsistemo kaj alireblecaj normoj...”

Alproksimiĝo de Claude Code:

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

La unua estas peto. La dua ekigas kapablon, kiu jam scias, kio estas karto, kion via dezajnsistemo postulas, kiuj alireblecaj normoj validas kaj kiel mem-validigi sian propran eligon.

La arkitekturo: subagentoj, kapabloj & komandoj

Jen la strukturo, kiu anstataŭas la teleprompter-modelon:

Nivelo 1: Subagentoj

Subagentoj estas memstaraj markdown-dosieroj en ~/.claude/agents/, kiuj plenumas laboron paralele. Ili havas siajn proprajn kuntekstajn fenestrojn kaj povas voki kapablojn.

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

Ĉiu subagenta dosiero havas YAML-frontan materion:

• name: klara identigilo
• description: kion ĝi faras kaj kiam voki ĝin
• tools: permesitaj kapabloj (Read, Write, Bash, Grep, Glob)

Ekzempla subagento (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...

Nivelo 2: Kapabloj (Skills)

Kapabloj estas aŭtomate ekigitaj sciomoduloj. Kiam vi demandas al Claude ion, kio kongruas kun la celo de kapablo, Claude aŭtomate aplikas ĝin.

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

Tio sekvas la metodaron Atomic Design: atomoj, molekuloj, organismoj. Ĉiu kapablo estas fakulo pri ĝuste unu afero. Kiam vi bezonas karton, la karta kapablo aŭtomate ekigas.

Ĉiu kapablo scias:

• la skemon de la komponanto (prop-oj, fendoj, variantoj)
• viajn konvenciojn de dezajnsistemo
• kadrspecifajn (framework) ŝablonojn
• postulojn de alirebleco laŭ WCAG
• parencajn kapablojn, kiujn ĝi povas referenci

Nivelo 3: Komandoj

Komandoj estas de-uzantaj ŝparvojoj. Vi tajpas /command por voki ilin. Ili troviĝas en la laborfluoj de kapabloj aŭ tutnivele:

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

Komandoj povas voki subagentojn por planado, poste la ĉefa Claude traktas la efektivigon. Tio donas al vi strukturitajn laborfluojn kun plena iloaliro.

Kompleta ekzemplo: karta kapablo

Mi montros al vi ĝuste kiel tio funkcias per reala kapablo:

La strukturo de la kapablo

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

La dosiero 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

Uzo de slash-komandoj

Generi novan karton:

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

Validigi ekzistantan karton:

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

Kontroli alireblecan konformecon:

/a11y card --level="AA"

Pliigi UX-on por specifa kunteksto:

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

Kio okazas “sub la kapuĉo”

Kiam vi vokas /generate card, Claude:

1. Ekigas la kartan kapablon: SKILL.md estas ŝargita en la kuntekston
2. Legas la skemon: validigas viajn parametrojn kontraŭ permesitaj prop-oj
3. Referencas aliajn kapablojn: image, heading, button-kapabloj liveras sian fakscion
4. Lanĉas la laborfluon: workflows/generate.md efektiviĝas
5. Mem-validigas: lanĉas la validate-laborfluon sur sia propra eligo
6. Redonas la rezulton: provizas la komponanton plus ajnajn avertojn

La karta kapablo ne nur generas markadon. Ĝi kunorkestras sistemon de specialistoj, ĉiu kontribuanta sian fakan sperton.

Kial tio gravas: de konstruanto al sistema pensulo

La teleprompter-modelo tenas vin kiel la plenumanton. La kapabla modelo faras vin la arkitekto.

Kiam mi ŝanĝis min de verkado de instigoj al desegnado de kapabloj, kelkaj aferoj ŝanĝiĝis:

Mi ĉesis ripeti kuntekston. Ĉiu kapablo jam konas sian domenon. Mi ne klarigas, kio estas karto ĉiufoje kiam mi bezonas ĝin.

Mi ekpensis per kunmetaĵo. Paĝo ne estas unu instigo – ĝi estas koordinado de organismoj, kiuj estas koordinadoj de molekuloj, kiuj estas koordinadoj de atomoj. Ĉiu tavolo havas sian propran kapablon.

Mi delegis validigon. Anstataŭ permane revizii ĉiun eligon, la komando /validate kontrolas strukturon, la komando /a11y kontrolas konformecon al WCAG, kaj la komando /test rulas aŭtomatigitajn kontrolojn. Mi revizias esceptojn, ne ĉiun rezulton.

Mi konstruis institucian scion. Kiam mi plibonigas la SKILL.md de kapablo, tiu plibonigo persistas. La sistemo iĝas pli inteligenta laŭlonge de la tempo, ne nur dum unuopaj konversacioj.

Tio estas la diferenco inter uzi AI-on kaj konstrui per AI.

La dezajno estas la kodo

En mia laboro kun dezajnsistemoj, mi alvenis al principo: la dezajno estas la kodo.

Kiam dizajnaj tokenoj, komponantaj skemoj kaj agenta agordo kongruas, ne ekzistas traduktavolo inter tio, kion dizajnistoj specifas, kaj tio, kion programistoj konstruas. La specifo estas la efektivigo.

Jen kiel agentoj faras ĉi tion realaĵo:

# 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

Ĉi tiu skemo ne estas nur dokumentado. Ĝi estas la fonto de vero. La agento generas komponantojn el ĝi. La validigilo kontrolas kontraŭ ĝi. La dezajnaj tokenoj referencas ĝin. Unu dosiero, multaj uzoj.

Kiam dizajnisto ĝisdatigas la valorojn de tokenoj en Figma, la agenta agordo ĝisdatigas. Kiam la agorda dosiero de la agento ĝisdatigas, la generitaj komponantoj ĝisdatigas. La dezajno estas la kodo ĉar ili ambaŭ devenas de la sama skemo.

Kiel komenci konstrui per Claude Code

Se vi pretas superi la teleprompter-modelon, jen praktika vojo:

Paŝo 1: Identigu viajn domenojn

Kiaj partoj de via laboro estas ripetaj, regul-ligitaj kaj kunteksto-dependaj? Tiuj estas kandidatoj por kapabloj:

• kodo-generado
• dokumentado
• testado
• revizio kaj validigo
• administrado de dezajnsistemo
• deplojado kaj DevOps

Paŝo 2: Kreu vian unuan kapablon

Komencu per simpla SKILL.md:

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

Paŝo 3: Aldonu laborfluojn (komandojn)

Kreu la ses kernajn komandojn en workflows/:

Ĉiu komando estas markdown-dosiero kun instrukcioj.

Paŝo 4: Starigu referencojn inter kapabloj

Kapabloj povas referenci aliajn kapablojn:

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

Mapu ĉi tiujn dependecojn. La hierarkio devus speguli la naturan strukturon de via domajno.

Paŝo 5: Kreu subagentojn por kompleksaj taskoj

Kiam vi bezonas izolitan kuntekston aŭ paralelan efektivigon, kreu subagentan dosieron en ~/.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

Konstruado de via kapabla biblioteko

Strukturigu viajn kapablojn laŭ Atomic Design:

Ĉiu kapablo:

• havas propran agordon SKILL.md
• havas workflows/ kun slash-komandoj
• havas references/ kun dokumentado
• havas scripts/ por aŭtomatigo
• scias, kiujn aliajn kapablojn ĝi referencas

Tio kreas konsekvencan, skaleblan sistemon, en kiu Claude aŭtomate ekigas la ĝustan kapablon laŭ kunteksto.

La estonteco estas agenta

Brad Frost, la kreinto de Atomic Design, jam de longe parolas pri ĉi tiu ŝanĝo: dezajnsistemoj devas fariĝi maŝinlegebla infrastrukturo, ĉar AI-agentoj nun kunmetas uzantinterfacojn per la samaj komponantoj, kiujn homaj teamoj uzas.

Tio ne estas prognozo pri 2030. Tio okazas jam nun.

Se via dezajnsistemo ne povas esti analizata de agento, ĝi fariĝas hereda (legacy). Se via evoluigprocezo bezonas homon por instigi ĉiun paŝon, ĝi ne skalas. Se viaj AI-interagoj ĉiam komenciĝas je nulo, vi malŝparas akumulitan scion.

La teleprompter-modelo estis akceptebla kiam AI estis novaĵo. Ĝi ne plu taŭgas, kiam AI estas infrastrukturo.

Ĉesu instigi. Ekdeĵoru dezajni.

Kreu agentojn. Donu al ili kapablojn. Lasu ilin kunordigi.

La estonteco apartenas al tiuj, kiuj arkitektas sistemojn, ne al tiuj, kiuj nur skribas skriptojn.

Konstruante agentajn dezajnsistemojn por la estonteco de ret-evoluigo.

Plia legado

• The Design Is the Code Mia esploro pri pensmaniero de ĉelaj aŭtomatoj en dezajnsistemoj
• Atomic Design by Brad Frost La metodaro malantaŭ komponantaj hierarkioj
• Designing Systems That Build Themselves De konstruanto al sistema pensulo