Przestań traktować AI jak teleprompter. Twórz subagentów, skille i polecenia

Od zależności od promptów do inteligentnych systemów agentowych

Większość ludzi wciąż używa AI jak teleprompteru.

Wpisują prompt. Czekają. Dostają odpowiedź. Kopiują ją gdzieś indziej. A potem robią to samo od nowa. I jeszcze raz. Każda rozmowa zaczyna się od zera. Każda zapomina, co było wcześniej.

To nie jest współpraca. To dyktowanie z dodatkowymi krokami.

W 2026 roku, jeśli nadal czytasz swojemu dostawcy AI z teleprompteru, umyka ci cała zmiana, która dzieje się tuż pod twoimi stopami.

Problem teleprompteru

Kiedy używasz AI jak teleprompteru, traktujesz potencjalnie autonomiczny system jak jednorazowy generator tekstu. Wygląda to tak:

1. Piszesz szczegółowy prompt
2. Czekasz na odpowiedź
3. Ręcznie oceniasz wynik
4. Poprawiasz i wysyłasz kolejny prompt
5. Tracisz cały kontekst, gdy zamykasz czat

Ten model ma trzy fatalne wady:

Brak trwałej wiedzy. Każda rozmowa to czysta kartka. W kółko tłumaczysz ten sam kontekst. Twoje AI nie zna twojego kodu, twoich preferencji, ograniczeń ani historii.

Brak delegowania. To ty zostajesz wąskim gardłem. Każda decyzja, każda weryfikacja, każdy kolejny krok wymaga twojego udziału. AI czeka, aż powiesz mu, co robić dalej.

Brak specjalizacji. Jednego, ogólnego interfejsu używasz do wszystkiego: kodowania, dokumentacji, projektowania, testów, wdrożeń. Jeden styl promptów. Jedno okno kontekstu. Jedna rozmowa wykonuje pracę wielu.

Model teleprompteru traktuje AI jak narzędzie. Ale narzędzia nie skalują autonomii. Agenci tak.

Co się zmienia, gdy myślisz agentami

W Claude Code architektura agentowa opiera się na trzech elementach składowych:

• Subagenci: wyspecjalizowane instancje Claude z odizolowanymi oknami kontekstu (~/.claude/agents/)
• Skille: automatycznie uruchamiane moduły wiedzy z plikami SKILL.md (~/.claude/skills/)
• Polecenia: uruchamiane przez użytkownika komendy /slash do jawnych działań (~/.claude/commands/)

Kluczowa różnica względem tradycyjnego promptowania:

• Skille są uruchamiane automatycznie przez Claude na podstawie kontekstu
• Polecenia wymagają, byś jawnie wpisał /command
• Subagenci działają w osobnym kontekście, z własnymi narzędziami

Spójrz na różnicę:

Podejście teleprompteru:

"Napisz mi komponent karty z obrazem, tytułem, tekstem i głównym przyciskiem, zgodny z wzorcami naszego design systemu i standardami dostępności..."

Podejście Claude Code:

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

Pierwsze to prośba. Drugie wywołuje skill, który już wie, czym jest karta, czego wymaga twój design system, jakie standardy dostępności obowiązują i jak zweryfikować własny wynik.

Architektura: subagenci, skille i polecenia

Oto struktura, która zastępuje model teleprompteru:

Poziom 1: Subagenci

Subagenci to samodzielne pliki markdown w ~/.claude/agents/, które wykonują pracę równolegle. Mają własne okna kontekstu i mogą wywoływać skille.

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

Każdy plik subagenta ma frontmatter YAML:

• name: czytelny identyfikator
• description: co robi i kiedy go wywołać
• tools: dozwolone możliwości (Read, Write, Bash, Grep, Glob)

Przykładowy 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...

Poziom 2: Skille

Skille to automatycznie uruchamiane moduły wiedzy. Gdy prosisz Claude o coś, co pasuje do przeznaczenia skilla, Claude stosuje go samodzielnie.

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

Opiera się to na metodologii Atomic Design: atomy, molekuły, organizmy. Każdy skill jest ekspertem w dokładnie jednej dziedzinie. Gdy potrzebujesz karty, skill karty uruchamia się sam.

Każdy skill zna:

• Schemat komponentu (propsy, sloty, warianty)
• Konwencje twojego design systemu
• Wzorce specyficzne dla frameworka
• Wymagania dostępności WCAG
• Powiązane skille, do których może się odwołać

Poziom 3: Polecenia

Polecenia to skróty uruchamiane przez użytkownika. Wpisujesz /command, by je wywołać. Mieszkają w workflow skilli albo globalnie:

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

Polecenia mogą wywoływać subagentów do planowania, a potem główny Claude zajmuje się wykonaniem. Dostajesz uporządkowane workflow z pełnym dostępem do narzędzi.

Pełny przykład: skill Card

Pokażę dokładnie, jak to działa, na prawdziwym skillu:

Struktura skilla

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

Plik 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

Używanie poleceń slash

Wygeneruj nową kartę:

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

Zweryfikuj istniejącą kartę:

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

Sprawdź zgodność z wymogami dostępności:

/a11y card --level="AA"

Popraw UX dla konkretnego kontekstu:

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

Co dzieje się pod maską

Gdy wywołujesz /generate card, Claude:

1. Uruchamia skill karty: SKILL.md ładuje się do kontekstu
2. Czyta schemat:  sprawdza twoje parametry względem dozwolonych propsów
3. Odwołuje się do innych skilli:  skille image, heading i button wnoszą swoją wiedzę
4. Uruchamia workflow: wykonuje się workflows/generate.md
5. Sam się weryfikuje: uruchamia workflow validate na własnym wyniku
6. Zwraca rezultat:  dostajesz komponent wraz z ewentualnymi ostrzeżeniami

Skill karty nie tylko generuje znaczniki. Koordynuje system specjalistów, z których każdy wnosi wiedzę ze swojej dziedziny.

Dlaczego to ważne: od budowniczego do myśliciela systemowego

Model teleprompteru zostawia cię w roli operatora. Model skilli czyni cię architektem.

Kiedy przeszedłem od pisania promptów do projektowania skilli, zmieniło się kilka rzeczy:

Przestałem powtarzać kontekst. Każdy skill zna już swoją dziedzinę. Nie tłumaczę za każdym razem, czym jest karta.

Zacząłem myśleć kompozycją. Strona to nie jeden prompt, to koordynacja organizmów, które są koordynacją molekuł, które są koordynacją atomów. Każda warstwa ma swój skill.

Zdelegowałem weryfikację. Zamiast ręcznie przeglądać każdy wynik, polecenie /validate sprawdza strukturę, /a11y zgodność z WCAG, a /test uruchamia automatyczne kontrole. Przeglądam wyjątki, nie każdy rezultat.

Zbudowałem wiedzę instytucjonalną. Gdy ulepszam SKILL.md, ta poprawka zostaje. System mądrzeje z czasem, a nie tylko w trakcie jednej rozmowy.

Na tym polega różnica między używaniem AI a budowaniem z AI.

Projekt jest kodem

W pracy z design systemami doszedłem do zasady: Projekt jest kodem (The Design Is the Code).

Gdy tokeny projektowe, schematy komponentów i konfiguracje agentów są ze sobą spójne, nie ma warstwy tłumaczenia między tym, co określają projektanci, a tym, co budują programiści. Specyfikacja jest implementacją.

Oto jak agenci to urzeczywistniają:

# 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

Ten schemat to nie tylko dokumentacja. To źródło prawdy. Agent generuje z niego komponenty. Walidator sprawdza zgodność z nim. Tokeny projektowe się do niego odwołują. Jeden plik, wiele zastosowań.

Gdy projektant zmienia wartości tokenów w Figmie, aktualizuje się konfiguracja agenta. Gdy aktualizuje się konfiguracja agenta, aktualizują się wygenerowane komponenty. Projekt jest kodem, bo oba wywodzą się z tego samego schematu.

Jak zacząć budować z Claude Code

Jeśli jesteś gotów odejść od modelu teleprompteru, oto praktyczna droga:

Krok 1: Wskaż swoje dziedziny

Które obszary twojej pracy są powtarzalne, oparte na regułach i zależne od kontekstu? To kandydaci na skille:

• Generowanie kodu
• Dokumentacja
• Testowanie
• Przegląd i weryfikacja
• Zarządzanie design systemem
• Wdrożenia i DevOps

Krok 2: Stwórz swój pierwszy skill

Zacznij od prostego SKILL.md:

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

Krok 3: Dodaj workflow (polecenia)

Utwórz sześć podstawowych poleceń w workflows/:

Każde polecenie to plik markdown z instrukcjami.

Krok 4: Ustal powiązania między skillami

Skille mogą odwoływać się do innych skilli:

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

Zmapuj te zależności. Hierarchia powinna odpowiadać naturalnej strukturze twojej dziedziny.

Krok 5: Twórz subagentów do złożonych zadań

Gdy potrzebujesz izolowanego kontekstu albo równoległego wykonania, utwórz plik subagenta w ~/.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

Budowanie biblioteki skilli

Uporządkuj swoje skille zgodnie z Atomic Design:

Każdy skill:

• Ma własną konfigurację SKILL.md
• Ma workflows/ z poleceniami slash
• Ma references/ z dokumentacją
• Ma scripts/ do automatyzacji
• Wie, do jakich innych skilli się odwołuje

Powstaje spójny, skalowalny system, w którym Claude automatycznie uruchamia właściwy skill na podstawie kontekstu.

Przyszłość jest agentowa

Brad Frost, twórca Atomic Design, mówi o tej zmianie od dawna: design systemy muszą stać się infrastrukturą czytelną dla maszyn, ponieważ agenci AI składają dziś interfejsy z tych samych komponentów, z których korzystają zespoły ludzi.

To nie jest prognoza na rok 2030. To dzieje się teraz.

Jeśli twojego design systemu nie potrafi sparsować agent, staje się on przeżytkiem. Jeśli twój proces tworzenia oprogramowania wymaga, by człowiek podpowiadał każdy krok, nie da się go skalować. Jeśli twoje interakcje z AI za każdym razem zaczynają się od zera, marnujesz zgromadzoną wiedzę.

Model teleprompteru był w porządku, gdy AI było nowinką. Nie jest w porządku, gdy AI jest infrastrukturą.

Przestań promptować. Zacznij projektować.

Buduj agentów. Daj im skille. Pozwól im się koordynować.

Przyszłość należy do tych, którzy projektują systemy, a nie do tych, którzy piszą skrypty.

Buduję agentowe design systemy dla przyszłości tworzenia stron internetowych.

Do dalszej lektury

• The Design Is the Code  Moja eksploracja myślenia automatów komórkowych w design systemach
• Atomic Design by Brad Frost  Metodologia stojąca za hierarchiami komponentów
• Designing Systems That Build Themselves  Od budowniczego do myśliciela systemowego