Hou op om jou KI-verskaffer te voorskryf soos met ’n teleprompter en skep subagente, vaardighede en opdragte

Beweeg van promptafhanklikheid na intelligente agentstelsels

Die meeste mense gebruik steeds KI soos ’n teleprompter.

Hulle tik ’n prompt. Hulle wag. Hulle kry ’n reaksie. Hulle kopieer-plak dit êrens. Dan doen hulle dit weer. En weer. Elke interaksie begin van voor af. Elke gesprek vergeet wat voorheen gekom het.

Dit is nie samewerking nie. Dis diktasie met ekstra stappe.

In 2026, as jy nog jou KI-verskaffer “teleprompter”, mis jy die hele verskuiwing wat onder jou voete plaasvind.

Die Teleprompter-probleem

Wanneer jy KI as ’n teleprompter gebruik, behandel jy ’n potensieel outonome stelsel as ’n eenmalige teksgenerator. Die patroon lyk só:

1. Jy skryf ’n gedetailleerde prompt
2. Jy wag vir die reaksie
3. Jy evalueer die uitset handmatig
4. Jy verfyn en prompt weer
5. Jy verloor alle konteks wanneer jy die klets venster toemaak

Hierdie model het drie dodelike gebreke:

Geen volhoubare kennis nie. Elke gesprek is ’n skoon lei. Jy verduidelik dieselfde konteks oor en oor. Jou KI ken nie jou kodebasis, jou voorkeure, jou beperkings of jou geskiedenis nie.

Geen delegeer nie. Jy bly die bottleneck. Elke besluit, elke validering, elke volgende stap benodig jou inset. Die KI wag vir jou om vir dit te sê wat om volgende te doen.

Geen spesialisasie nie. Jy gebruik een generiese koppelvlak vir alles – kodering, dokumentasie, ontwerp, toetsing, ontplooiing. Een promptstyl. Een konteksvenster. Een gesprek wat die werk van vele doen.

Die teleprompter-model behandel KI as ’n hulpmiddel. Maar hulpmiddels skaal nie outonomie nie. Agente doen.

Wat verander wanneer jy in agente dink

In Claude Code bestaan die agent-argitektuur uit drie primitiewe:

• Subagente: Gespesialiseerde Claude-instansies met geïsoleerde konteksvensters (~/.claude/agents/)
• Vaardighede (Skills): Outo-gestoorde kennismodules met SKILL.md-lêers (~/.claude/skills/)
• Opdragte (Commands): Gebruiker-gestoorde /slash-opdragte vir eksplisiete aksies (~/.claude/commands/)

Die kernverskil met tradisionele prompting:

• Vaardighede word outomaties deur Claude geaktiveer op grond van konteks
• Opdragte vereis dat jy eksplisiet /command intik
• Subagente loop in ’n afsonderlike konteks met hul eie gereedskap

Oorweeg die verskil:

Teleprompter-benadering:

“Skryf vir my ’n kaartkomponent met ’n beeld, titel, liggaamstekst en ’n primêre knoppie wat ons ontwerpstelselpatrone en toeganklikheidstandaarde volg...”

Claude Code-benadering:

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

Die eerste is ’n versoek. Die tweede roep ’n vaardigheid op wat reeds weet wat ’n kaart is, wat jou ontwerpstelsel vereis, watter toeganklikheidstandaarde geld, en hoe om sy eie uitset te valideer.

Die Argitektuur: Subagente, Vaardighede & Opdragte

Hier is die struktuur wat die teleprompter-model vervang:

Vlak 1: Subagente

Subagente is selfstandige markdown-lêers in ~/.claude/agents/ wat werk parallel uitvoer. Hulle het hul eie konteksvensters en kan vaardighede ontbied.

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

Elke subagent-lêer het YAML-voorblad:

• name: Duidelike identifiseerder
• description: Wat dit doen en wanneer dit ontbied moet word
• tools: Toegelate vermoëns (Read, Write, Bash, Grep, Glob)

Voorbeeld-subagent (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...

Vlak 2: Vaardighede

Vaardighede is outo-gestoorde kennismodules. Wanneer jy iets vra wat by ’n vaardigheid se doel pas, pas Claude dit outomaties toe.

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

Dit volg die Atomic Design-metodologie: atome, molekules, organismes. Elke vaardigheid is ’n kenner in presies een ding. Wanneer jy ’n kaart nodig het, aktiveer die kaart-vaardigheid outomaties.

Elke vaardigheid weet:

• Die komponent se skema (props, slots, variante)
• Jou ontwerpstelsel-konvensies
• Raamwerk-spesifieke patrone
• WCAG-toeganklikheidsvereistes
• Verwante vaardighede waarna dit kan verwys

Vlak 3: Opdragte

Opdragte is gebruiker-gestoorde kortpaaie. Jy tik /command om hulle te roep. Hulle leef in vaardigheid-workflows of globaal:

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

Opdragte kan subagente vir beplanning ontbied, dan hanteer die hoof-Claude die uitvoering. Dit gee jou gestruktureerde workflows met volle toegang tot gereedskap.

Volledige voorbeeld: Kaart-vaardigheid

Laat ek presies wys hoe dit werk met ’n werklike vaardigheid:

Die Vaardigheidstruktuur

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

Die SKILL.md-lêer

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

Gebruik van Slash-opdragte

Genereer ’n nuwe kaart:

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

Valideer ’n bestaande kaart:

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

Toets toeganklikheidsnakoming:

/a11y card --level="AA"

Verbeter UX vir ’n spesifieke konteks:

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

Wat agter die skerms gebeur

Wanneer jy /generate card oproep, doen Claude die volgende:

1. Aktiveer die kaart-vaardigheid: SKILL.md word in konteks gelaai
2. Lees die skema:  Valideer jou parameters teenoor toegelate props
3. Verwys na ander vaardighede:  beeld-, opskrif- en knoppie-vaardighede lewer hul kundigheid
4. Laat loop die workflow: workflows/generate.md word uitgevoer
5. Self-valideer: Laat loop die validate-workflow op sy eie uitset
6. Gee die resultaat terug:  Verskaf die komponent plus enige waarskuwings

Die kaart-vaardigheid genereer nie net markup nie. Dit orkestreer ’n stelsel van spesialiste, elk met hul eie domeinkennis.

Hoekom dit saak maak: Van bouer na stelseldenker

Die teleprompter-model hou jou as die operateur. Die vaardigheidsmodel maak jou die argitek.

Toe ek geskuif het van die skryf van prompts na die ontwerp van vaardighede, het verskeie dinge verander:

Ek het opgehou om konteks te herhaal. Elke vaardigheid ken reeds sy domein. Ek verduidelik nie elke keer wat ’n kaart is wanneer ek een nodig het nie.

Ek het begin in samestelling dink. ’n Bladsy is nie een prompt nie – dit is ’n koördinering van organismes, wat koördineringe van molekules is, wat koördineringe van atome is. Elke laag het sy eie vaardigheid.

Ek het validering gedelegeer. In plaas daarvan om elke uitset handmatig te hersien, kontroleer die /validate-opdrag struktuur, die /a11y-opdrag kontroleer WCAG-nakoming, en die /test-opdrag laat outomatiese toetse loop. Ek hersien uitsonderings, nie elke resultaat nie.

Ek het institusionele kennis opgebou. Wanneer ek ’n vaardigheid se SKILL.md verbeter, hou daardie verbetering stand. Die stelsel word oor tyd slimmer, nie net tydens ’n enkele gesprek nie.

Dit is die verskil tussen KI gebruik en met KI bou.

Die Ontwerp ís die Kode

In my werk met ontwerpstelsels het ek by ’n beginsel uitgekom: Die Ontwerp ís die Kode.

Wanneer ontwerptokens, komponent-skemas en agentkonfigurasies belyn is, is daar geen vertaallaag tussen wat ontwerpers spesifiseer en wat ontwikkelaars bou nie. Die spesifikasie is die implementering.

So maak agente dit werklik:

# 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

Hierdie skema is nie net dokumentasie nie. Dit is die bron van waarheid. Die agent genereer komponente daaruit. Die validator kontroleer daarteen. Die ontwerptokens verwys daarna. Een lêer, vele gebruike.

Wanneer ’n ontwerper die tokenwaardes in Figma opdateer, word die agentkonfigurasie opgedateer. Wanneer die agentkonfigurasie opdateer, word die gegenereerde komponente opgedateer. Die ontwerp is die kode omdat albei uit dieselfde skema afgelei word.

Hoe om te begin bou met Claude Code

As jy gereed is om verby die teleprompter-model te beweeg, is hier ’n praktiese pad:

Stap 1: Identifiseer jou domeine

Watter areas van jou werk is repetitief, reël-gebind en konteksafhanklik? Dit is vaardigheid-kandidate:

• Kodegenerering
• Dokumentasie
• Toetsing
• Hersien en validering
• Ontwerpstelselbestuur
• Ontplooiing en DevOps

Stap 2: Skep jou eerste vaardigheid

Begin met ’n eenvoudige SKILL.md:

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

Stap 3: Voeg Workflows (Opdragte) by

Skep die ses kernopdragte in workflows/:

Elke opdrag is ’n markdown-lêer met instruksies.

Stap 4: Vestig Vaardigheid-verwysings

Vaardighede kan na ander vaardighede verwys:

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

Kaart hierdie afhanklikhede uit. Die hiërargie moet jou domein se natuurlike struktuur volg.

Stap 5: Skep Subagente vir komplekse take

Wanneer jy geïsoleerde konteks of parallelle uitvoering nodig het, skep ’n subagent-lêer in ~/.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

Bou jou Vaardigheid-biblioteek

Struktureer jou vaardighede volgens Atomic Design:

Elke vaardigheid:

• Het sy eie SKILL.md-konfigurasie
• Het workflows/ met slash-opdragte
• Het references/ met dokumentasie
• Het scripts/ vir outomatisering
• Weet watter ander vaardighede dit verwys

Dit skep ’n konsekwente, skaalbare stelsel waar Claude outomaties die regte vaardigheid op grond van konteks aktiveer.

Die Toekoms is Agenties

Brad Frost, die skepper van Atomic Design, praat al lank oor hierdie skuif: ontwerpstelsels moet masjien-leesbare infrastruktuur word omdat KI-agente nou UI’s saamstel met dieselfde komponente wat menslike spanne gebruik.

Dit is nie ’n voorspelling vir 2030 nie. Dit gebeur nou.

As jou ontwerpstelsel nie deur ’n agent ontleed kan word nie, raak dit nalatenskap-tegnologie. As jou ontwikkelingswerkvloei vereis dat ’n mens elke stap prompt, skaal dit nie. As jou KI-interaksies elke keer van nul af begin, mors jy opgehoopte kennis.

Die teleprompter-model was aanvaarbaar toe KI ’n nuwigheid was. Dit is nie aanvaarbaar wanneer KI infrastruktuur is nie.

Hou op prompt. Begin ontwerp.

Bou agente. Gee vir hulle vaardighede. Laat hulle koördineer.

Die toekoms behoort aan dié wat stelsels argitekteer, nie dié wat skripte skryf nie.

Bou agentiese ontwerpstelsels vir die toekoms van webontwikkeling.

Verdere leesstof

• The Design Is the Code  My verkenning van sellulêre-outomata-denke in ontwerpstelsels
• Atomic Design by Brad Frost  Die metodologie agter komponent-hiërargieë
• Designing Systems That Build Themselves  Van bouer tot stelseldenker