Post o hookach opisywał warstwę bezpieczeństwa, te części, które działają w tle i blokują rzeczy. Ten post jest o drugiej stronie: co się dzieje, gdy chcesz żeby Claude robił więcej, a nie mniej. Konkretnie, jak skills i agenty pozwalają budować wielokrotnego użytku przepływy pracy zamiast powtarzać się co sesję.

Skills kontra commands: ważna różnica

Zanim przejdę do mechaniki, warto wyjaśnić, czym skills nie są. Pisałem wcześniej o własnych komendach: /deploy, /morning, /humanize. Commands to rzeczy, które wpisujesz. Wywołujesz je świadomie.

Skills są inne. Mieszkają w .claude/skills/ i Claude ładuje je automatycznie na podstawie warunków wyzwalania. Nie przywołujesz ich sam. Aktywują się, gdy sytuacja pasuje.

Projekt ma sześć skills:

1
2
3
4
5
6
7

.claude/skills/
  devops-diagnosis.md
  security-scan.md
  pr-reviewer.md
  lapa-azure-admin.md
  code-optimizer.md
  text-humanizer.md

Na poziomie użytkownika (~/.claude/skills/) jest ich jeszcze kilka, łącznie z jedną o nazwie claudeception, która uczy Claude jak budować lepsze skills. Ta jest w sposób, który doceniam, samozwrotna.

Jak wygląda plik skill

Skill to plik markdown z blokiem YAML frontmatter i treścią instrukcji. Frontmatter mówi Claude kiedy go załadować i jakich narzędzi może używać. Treść to właściwy przepływ pracy.

Oto skill text-humanizer:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

---
name: text-humanizer
version: 1.0.0
description: |
  Remove signs of AI-generated writing from text. Use proactively whenever
  reviewing or editing text that may contain AI patterns, even if the user
  doesn't explicitly ask for humanization. Trigger when: text uses words like
  "delve", "crucial", "landscape", "tapestry", "testament", "foster",
  "enhance", "pivotal", "showcase", "underscore", "vibrant"; text has em dash
  overuse; text uses "Not only...but...", "serves as", "stands as"; ...
allowed-tools: Read, Grep, Bash
---

Pole description to to, co Claude czyta, żeby zdecydować czy skill jest istotny. Jeśli padnie słowo “delve” albo poprosisz żeby tekst brzmiał naturalnie, skill się ładuje. Jeśli piszesz kod i nigdy nie wspominasz o jakości tekstu, nie ładuje się.

Skill devops-diagnosis jest bardziej rozbudowany. Jego opis zawiera konkretne warunki wyzwalania: logi błędów, stack traces, OutOfMemoryError, connection timeouts, “the app is down”, wyjątki Javy, tracebacki Pythona. Gdy którykolwiek z nich się pojawi, skill ładuje pełny multi-agent pipeline:

  1. Sprawdź Confluence pod kątem istniejących rozwiązań
  2. Uruchom równolegle web research, szukanie dokumentacji i przeszukiwanie kodu
  3. Przekaż wszystkie wyniki do enterprise-app-specialist w celu analizy przyczyn
  4. Zapytaj użytkownika gdzie udokumentować wyniki
  5. Wygeneruj podsumowanie ticketu

To jest treść skilla, i uruchamia się za każdym razem gdy te warunki są spełnione, bez konieczności pamiętania żeby go wywołać. Różnica między “wklejam błąd” a “wklejam błąd i Claude automatycznie zaczyna ustrukturyzowane dochodzenie” to właśnie ten jeden plik.

Strategia rozumowania jest też wbudowana. devops-diagnosis używa cot (chain-of-thought), co oznacza, że Claude przechodzi przez każdy krok diagnostyczny sekwencyjnie i pokazuje swoje rozumowanie. pr-reviewer używa self-refine, robi wstępną recenzję, a potem drugi przebieg żeby wyłapać to, co pominął. text-humanizer używa reflexion: draft, krytyka, poprawka.

Agenty: oddzielne okna kontekstu z własnymi regułami

Agenty to inna sprawa. Skill ładuje instrukcje do bieżącej rozmowy. Agent to subprocess z własnym oknem kontekstu, własnymi uprawnieniami do narzędzi i własnym modelem.

Projekt ma ich aktualnie 19:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

.claude/agents/
  enterprise-app-specialist.md    # model opus, głębokie diagnozowanie
  team-lead.md                    # opus, orchestruje zadania multi-agent
  trigger-dev-task-writer.md      # sonnet, projektowanie zadań Trigger.dev
  deploy-verifier.md              # sonnet, sprawdzanie zdrowia po deploy
  vault-secret-rotator.md         # sonnet, audyt i rotacja sekretów
  confluence-searcher.md          # sonnet, wyszukiwanie w bazie wiedzy
  confluence-writer.md            # sonnet, tworzenie stron
  jira-operations.md              # sonnet, zarządzanie ticketami
  web-researcher.md               # sonnet, web search przez Tavily
  docs-researcher.md              # sonnet, dokumentacja bibliotek przez Context7
  codebase-investigator.md        # sonnet, przeszukiwanie kodu źródłowego
  server-command-advisor.md       # sonnet, komendy na zdalnych serwerach
  log-analyzer.md                 # sonnet, parsowanie i korelacja logów
  github-ops.md                   # sonnet, zarządzanie issues na GitHub
  azure-ops.md                    # sonnet, zarządzanie zasobami Azure
  aws-ops.md                      # sonnet, zdrowie AWS i IAM
  email-writer.md                 # sonnet, pisze maile w moim stylu
  ticket-writer.md                # sonnet, dokumentacja incydentów
  blog-writer.md                  # sonnet, pisze posty na ten blog

Wybór modelu jest istotny i celowy. Większość agentów używa sonnet: szybki, sprawny, nie jest przerostem formy nad treścią do dobrze zdefiniowanych zadań. Dwa używają opus: enterprise-app-specialist (głębokie rozumowanie nad złożonymi problemami infrastrukturalnymi) i team-lead (orchestrowanie wielu agentów i synteza ich wyników). Opus wszędzie byłoby wolniejsze. Sonnet wszędzie dałoby gorsze wyniki przy trudnych problemach diagnostycznych.

Każdy plik agenta ma też frontmatter:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

---
name: enterprise-app-specialist
description: |
  Use this agent when troubleshooting production application issues, planning
  migrations, or diagnosing connectivity problems on RHEL, AWS, or Azure.
model: opus
maxTurns: 25
hooks:
  PreToolUse:
    - matcher: "Bash"
      hooks:
        - type: command
          command: /home/user/.claude/hooks/pre-tool-safety.sh
---

Limit maxTurns zapobiega niekontrolowanemu wzrostowi kontekstu. Hook na poziomie agenta oznacza, że kontrole bezpieczeństwa działają nawet wewnątrz subprocessu. Opis, podobnie jak w skilla, to to, co Claude czyta żeby zdecydować czy użyć tego agenta.

Dlaczego izolowane okno kontekstu jest ważne

Głównym powodem delegowania do agentów nie jest zdolność, lecz czystość. Pliki logów są duże. Wyniki wyszukiwania są zaszumione. Jeśli poproszę Claude o analizę pliku logu z 50 000 linii w głównej rozmowie, ten kontekst przepada. Rozmowa zwalnia, a jakość kolejnych odpowiedzi spada.

Gdy deleguję do log-analyzer, uruchamia się we własnym oknie kontekstu, ładuje log, robi robotę i zwraca ustrukturyzowane podsumowanie. Główna rozmowa dostaje trzy akapity wyników, nie pięćdziesiąt tysięcy linii tekstu.

Tak samo z web-researcher. Robi przeszukiwania przez Tavily, filtruje szum i zwraca to, co istotne. Moja główna rozmowa nie gromadzi śmieci z wyszukiwarek.

Agent codebase-investigator robi to samo dla przeszukiwania kodu źródłowego. Jeśli trzeba znaleźć wszystkie użycia klasy w dużym projekcie, to sporo wyjścia z grepa. Agent to ogarnia, ja dostaję podsumowanie.

Teamy agentów i orchestracja

Agent team-lead to miejsce gdzie robi się ciekawie. Używa narzędzia Task do uruchamiania innych agentów i ich koordynowania.

Oto wzorzec incident response z jego pliku:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Uruchom równolegle:
1. log-analyzer        -- analiza logów w poszukiwaniu przyczyny
2. confluence-searcher -- znalezienie istniejących runbooków
3. web-researcher      -- szukanie znanych problemów
4. jira-operations     -- sprawdzenie powiązanych ticketów

Potem sekwencyjnie:
5. enterprise-app-specialist -- głęboka diagnoza z zebranym kontekstem
6. ticket-writer             -- dokumentacja incydentu
7. jira-operations           -- tworzenie/aktualizacja ticketów

Kroki 1-4 działają równolegle, bo od siebie nie zależą. Krok 5 działa potem, bo potrzebuje wyników z pierwszych czterech. Team-lead syntezuje wszystko na końcu, nie konkatenując po prostu outputów, ale szukając korelacji między tym, co znalazł każdy agent. Log pokazujący connection timeouts w tym samym czasie co ticket Jira o zmianie sieciowej to inny sygnał niż każde z nich osobno.

Wzorzec pełnego audytu systemu uruchamia trzy agenty równolegle (zdrowie deployów, audyt sekretów, aktualność dokumentacji) i produkuje ujednolicony raport. Uruchamiam to od czasu do czasu, i to najbliższy ekwiwalent daily standup z zespołem, który nie potrzebuje spania.

Praktyczne wzorce

Kilka rzeczy, które warto robić:

Trzymaj skills skoncentrowane. Skill z dwudziestoma warunkami wyzwalania ładuje się kiedy nie powinien, a instrukcje konkurują z bieżącym zadaniem. text-humanizer ma jedno zadanie. devops-diagnosis ma jeden pipeline. Gdy skill próbuje pokryć zbyt wiele, staje się szumem.

Dopasuj model do zadania, nie do ego. Kuszące jest użycie opus wszędzie bo jest lepszy. Ale email-writer na sonnet jest ok. Maile nie wymagają głębokiego rozumowania. enterprise-app-specialist na opus jest warte swojej ceny, bo produkcyjna diagnostyka na RHEL jest naprawdę trudna i jakość modelu widać.

Agent do brudnej roboty, główna rozmowa do decyzji. Nie proszę Claude o analizę logów bezpośrednio w chatie. Nie robię web research w głównym kontekście. Wszystko, co produkuje dużo surowego outputu, idzie do agenta. To, co wraca, to zawsze podsumowanie.

Skills jako pamięć instytucjonalna. Skill lapa-azure-admin zawiera wszystko specyficzne dla środowiska Azure jednego klienta: tenant ID, strukturę subskrypcji, konwencje nazewnicze, które reguły firewalla są istotne. Bez tego skilla musiałbym na nowo tłumaczyć środowisko co sesję. Z nim Claude już to wie.

Powiązane: Moje środowisko Claude Code | Własne komendy | Hooki i system uprawnień