Dołącz do Akademii Automatyzacji → - 1200 osób uczy się u nas automatyzacji i AI na prawdziwych wdrożeniach, nie na teorii.

Claude Code Starter

Gotowy system pracy z Claude Code. Kopiujesz jeden folder do swojego projektu i Claude przestaje pisać kod na ślepo - dostaje skille, agentów i reguły, dzięki którym prowadzi projekt od pomysłu do działającej aplikacji.

Do czego to służy

Sami na tym budujemy własne aplikacje w Akademii Automatyzacji. Po skopiowaniu folderu .claude/ Twój Claude:

• Pomaga doprecyzować, CO budujesz - zanim powstanie linijka kodu, przepyta Cię o wymagania i rozpisze plan techniczny.
• Implementuje fazami i sam sprawdza swoją robotę - każdą fazę przegląda 8 niezależnych agentów-reviewerów (bezpieczeństwo, wydajność, architektura, testy), a błędy naprawia.
• Zapamiętuje wnioski - rozwiązane problemy trafiają do docs/solutions/, więc w kolejnych zadaniach nie wpada na te same miny.

Całość jest zestrojona pod stack React 19 + TypeScript + Supabase + Vite + Tailwind v4. Budujesz na czymś innym? Rdzeń systemu (pipeline, review, baza wiedzy) zadziała, tylko skille techniczne będą do podmiany.

Jak to działa

Zaczynasz od pomysłu, kończysz na działającej, sprawdzonej aplikacji. Po drodze wygląda to tak:

1. Opisujesz pomysł - /dev-brainstorm przepytuje Cię pytanie po pytaniu, aż będzie jasne, co dokładnie ma powstać. Efekt: dokument wymagań.
2. Claude rozpisuje plan - /dev-plan skanuje repo i dzieli robotę na fazy z konkretnymi krokami. Ty tylko zatwierdzasz.
3. /dev-docs przygotowuje zadanie - tworzy branch feature/[nazwa] i 3 pliki robocze (plan, kontekst, lista zadań), z których pipeline będzie korzystał przez całą implementację.
4. Odpalasz autopilot - dev-autopilot-wf wykonuje fazy jedna po drugiej: implementacja, review, naprawa błędów. Wracasz do gotowej zmiany z raportem, co i dlaczego zostało zrobione.

Klucze do tego rozwiązania

• Spec-Driven + Test-Driven Development - najpierw powstaje specyfikacja i plan, dopiero potem kod. Każda faza kończy się testami i pełnym pokryciem testowym.
• Pełna dokumentacja techniczna w dwóch dokumentach - Dev Plan (plan techniczny z /dev-plan) i DevDocs (dokumentacja wykonawcza z /dev-docs: plan, kontekst, lista zadań), aktualizowane na bieżąco w trakcie implementacji.
• Review robi 8 niezależnych agentów naraz (bezpieczeństwo, wydajność, architektura, zgodność ze specyfikacją, prostota, testy) - a każde poważne znalezisko przechodzi jeszcze przez agenta-sceptyka, który próbuje je obalić. Zostają tylko prawdziwe błędy.
• Sterowanie trzyma kod, nie model - kolejność faz, bramki jakości i limity napraw są zapisane w deterministycznych workflowach JS. Claude wykonuje zadania, ale nie decyduje, czy może pominąć review.
• Reguły kodowania i katalog anty-patternów AI (.claude/rules/) pilnują jakości od pierwszej linijki - m.in. zakaz osłabiania testów i obniżania progów, żeby “przeszło”.

Czego system uczy się w trakcie projektu

• Każdy rozwiązany problem ląduje w docs/solutions/ - następnym razem Claude sięga po gotowe rozwiązanie zamiast kombinować od zera.
• Powtarzalne wnioski zamieniają się w reguły (learned-patterns.md), które czytają wszyscy agenci w kolejnych zadaniach.
• Pojęcia z Twojej domeny trafiają do słownika docs/CONCEPTS.md - dzięki temu Claude nie “naprawia” rzeczy, które celowo działają nietypowo.

Im dłużej pracujesz w projekcie, tym mniej błędów Claude powtarza.

Jak zacząć - 4 kroki

1. Sklonuj repo: git clone https://github.com/AIBiz-Automatyzacje/claude-code-starter.git
2. Skopiuj folder .claude/ do swojego projektu.
3. Włącz Dynamic Workflows: wpisz /config i ustaw Dynamic workflows na true. Bez tego Claude nie widzi plików z .claude/workflows/, więc dev-autopilot-wf w ogóle nie da się odpalić - a to on prowadzi całą implementację. Objaw: pliki *-wf.js leżą w projekcie, ale Claude twierdzi, że nie zna workflow o tej nazwie, albo komenda nic nie robi.
4. Odpal Claude Code i wpisz /dev-brainstorm - opisz, co chcesz zbudować. Resztą pokieruje pipeline.

Chcesz zrozumieć, jak to działa pod maską? Niżej masz pełną dokumentację: pipeline dev-*, workflowy, wszystkich 15 agentów i pułapki, na które sami wpadliśmy.

Bonus: Output Style „adhd"

Masz dość gadatliwych odpowiedzi? W output-styles/adhd.md znajdziesz gotowy Output Style, który sprawia, że Claude zaczyna od konkretu zamiast ściany tekstu. Napisany według wytycznych Anthropic dla modeli z serii 5 (zero zakazów — opisany cel, resztę model wyprowadza sam). Inspiracja: skill i-have-adhd z wiralowego wątku na r/ClaudeAI.

1. Skopiuj output-styles/adhd.md do folderu .claude/output-styles/ w swoim projekcie (albo do ~/.claude/output-styles/ globalnie).
2. Zrestartuj sesję Claude Code.
3. Wpisz /config, wybierz Output style → adhd i zatwierdź enterem.

---

Co dostajesz

Sklonuj → skopiuj katalog .claude/ do swojego projektu → masz gotowy, spójny system pracy z Claude Code. A gdy szablon się rozwinie — jedno /sync-template zaciąga zmiany z tego repo do projektu (bez ręcznego dyktowania linku):

• Pipeline dev-* — od ideacji, przez plan, po autonomiczną implementację z review i naprawami (dev-autopilot-wf).
• Skille techniczne pod stack — React/Tailwind, Supabase, UX/UI, bezpieczeństwo, Sentry — z aktualnymi wzorcami (React 19, Tailwind v4, Zod v4, OWASP 2025).
• 15 wyspecjalizowanych agentów — buildery warstw, reviewerzy, research.
• Knowledge compounding — rozwiązane problemy (docs/solutions/), reguły (learned-patterns.md) i żywy słownik domenowy (docs/CONCEPTS.md).
• Reguły kodowania i katalog anty-patternów AI (.claude/rules/coding-rules.md).

---

Pipeline dev-* — przegląd

/dev-ideate → /dev-brainstorm → /dev-prep → /dev-plan → /dev-docs → [ dev-autopilot-wf ] → gotowe
  (pomysły)     (CO budować)   (CO ma       (JAK)      (struktura)   (cały pipeline auto)
                                dostarczyć
                                człowiek)

dev-autopilot-wf orkiestruje:
  bootstrap → per faza( execute-wf → review-wf + adversarial verify → fix ) → compound-wf → compound-refresh(scoped) → complete-wf

Zasady ogólne:

• Skille dev-* działają BEZ argumentów (wyciągają kontekst z sesji). Argumenty są opcjonalne.
• Skille bez disable-model-invocation mogą być wołane programowo przez inne skille i agentów.
• Fazę implementacji domyślnie prowadzi dev-autopilot-wf (dynamic workflow). Skille /dev-docs-execute i /dev-docs-review możesz odpalać też ręcznie, faza po fazie.

Dynamic Workflows (-wf)

Część pipeline’u to deterministyczne orkiestratory w JavaScript w .claude/workflows/*.js (suffix -wf, by uniknąć kolizji nazw ze skillami). Orkiestrator trzyma plan i sterowanie w kodzie, a buildery/reviewerzy to leaf-agenci wołani przez agentType.

Wymagane włączenie w Claude Code. Dynamic Workflows są funkcją samego Claude Code, sterowaną przez /config → Dynamic workflows. Gdy jest ustawione na false, Claude nie widzi żadnego pliku z .claude/workflows/ - dev-autopilot-wf nie istnieje dla niego, mimo że leży w projekcie. Tego nie da się dowieźć w szablonie: to ustawienie Twojego klienta, nie repozytorium (.claude/settings.json go nie obsługuje). Skopiowanie folderu .claude/ nie włącza tego za Ciebie - sprawdź /config przed pierwszym uruchomieniem. Skille dev-* (/dev-brainstorm, /dev-plan, /dev-docs) działają niezależnie od tego przełącznika; blokuje on wyłącznie workflowy -wf.

Jak odpalać: toolem Workflow, np. Workflow({scriptPath: ".claude/workflows/dev-autopilot-wf.js"}, args). RESUME po przerwanym runie: Workflow({scriptPath, resumeFromRunId}) + ZAWSZE przekaż args ponownie (te same, np. ścieżkę zadania — args NIE przeżywa między wywołaniami). Stan wznowienia czyta z .autopilot-state.json (źródło prawdy); checkboxy w .md to tylko widok dla człowieka.

---

Skille — pełna lista

Pipeline dev-*

Discovery

/dev-ideate — generowanie pomysłów na ulepszenia. 4 agenty skanują projekt z różnych perspektyw (tech debt, UX, performance, product), Devil’s Advocate filtruje słabe. → docs/ideation/

/dev-brainstorm (opcjonalny — „pusta kartka") — walidacja pomysłu (CO budować). Interaktywny dialog: jedno pytanie na raz, pressure test, eksploracja podejść. → docs/brainstorms/*-requirements.md

• Kiedy: nowy feature bez wymagań, kilka konkurencyjnych kierunków, niejasno ujęty problem. Kiedy nie: wymagania już są (etap w zbiorczym mvp-requirements.md, lista poprawek z feedbacku, bug/tech-debt, „zrób jak w X") — wtedy od razu /dev-plan, który czyta takie źródła bezpośrednio.
• Nie oferuje skoku do implementacji z pominięciem planu — kod powstaje tylko z Implementation Units.

Planowanie

/dev-prep (opcjonalny — nowy etap) — operator checklist etapu (CO CZŁOWIEK MUSI DOSTARCZYĆ, zanim ruszy implementacja). Czyta etap zbiorczego dokumentu wymagań (docs/brainstorms/mvp-requirements.md#etap-17), skanuje repo read-only (route’y, docs/DESIGN.md, SPEC.md, nazwy zmiennych z .env.example, wcześniejsze checklisty etapów) i zapisuje jeden dokument z czterema sekcjami: decyzje (pytania zamknięte z opcjami, [blokuje planowanie]), konta/konsole/sekrety (🔓 publiczne vs 🔒 sekrety, notatka o kolejności zależnych kroków, „Gdzie to ląduje"), assety i treści ([~] = świadomy dług), makiety (nazwa ekranu = klucz, stany, breakpointy, puste URL Figma:). Nie planuje — zero IU, zero architektury. → docs/operator/-przygotowanie.md

• Kiedy: startujesz etap wymagający kont zewnętrznych, assetów albo makiet i chcesz je zamówić, zanim usiądziesz do planowania. Kiedy nie: bugfix, tech-debt, zmiana czysto backendowa — wtedy wprost /dev-plan, który utworzy krótką listę sam.
• Dziedziczy nazewnictwo zastanej serii: gdy w docs/operator/ leżą już checklisty etapów (np. e1-operator-checklist.md, e2-operator-checklist.md), nowy plik dostaje ten sam wzorzec nazwy z identyfikatorem bieżącego etapu — zamiast wstawiać w środek serii obcy -przygotowanie.md. Dwa konkurencyjne wzorce = pytanie do użytkownika, pusty katalog = nazwa domyślna. Cały pipeline odnajduje ten plik po frontmatterze (origin:, feature_slug:) i po operator_prep: w planie, nigdy po nazwie — więc dowolna konwencja działa bez zmian w /dev-plan i /dev-docs.
• To ten sam plik, który uzupełnia /dev-plan — nie powstaje drugi dokument przygotowawczy. /dev-prep zakłada listę bez numerów faz (jeszcze ich nie ma), /dev-plan dopisuje do niej numery blokowanych faz i pozycje wynikłe z IU (3.7 → 5.2b, edycja w miejscu, [x] nietknięte). Gdy wszystkie ekrany mają wklejone URL-e Figmy, /dev-plan nie pyta o Figmę — fetchuje wprost z listy (1.6 krok C).

/dev-plan — planowanie techniczne (JAK budować). Źródłem wymagań jest requirements doc z docs/brainstorms/, sekcja zbiorczego dokumentu (np. docs/brainstorms/mvp-requirements.md#etap-17) albo lista wymagań z requestu. Skanuje repo agentami research, tworzy Implementation Units (Goal, Files, Approach, Test scenarios, Verification) pogrupowane w numerowane fazy (### Faza N — …, obowiązkowe — autopilot wykonuje plan fazami, /dev-docs przenosi je 1:1). Klasyfikację UI/pure-data wyprowadza z plików, bez pytania. Czyta docs/CONCEPTS.md dla terminologii domenowej. Dla scenariuszy [E2E] stosuje konwencję zarządzanego harnessu: scenariusz opisany w nośnej linii Test: [E2E] \` — → (agent-browser wykonuje go z opisu; identyfikator flow w backtickach), seede2e/seeds/-seed.sqljako deliverable **buildera**. →docs/plans/`

• Przygotowanie dla operatora (dokument #1): sekcja „Wymagania wstępne operatora" w planie + plik docs/operator/-przygotowanie.md — wyłącznie to, czego Claude nie zrobi sam (konsole OAuth, sekrety w .env, .env.e2e wg .claude/templates/e2e-env/ gdy plan ma [E2E], assety graficzne, migracje na projekcie głównym, decyzje do podjęcia). Każda pozycja: po co / jak / dowód wykonania + co blokuje ([blokuje start] albo numer fazy). Frontmatter operator_prep:.

/dev-docs — transformacja planu technicznego w zadanie dla autopilota, bez nowej treści (zero własnych ryzyk/szacunków — to, czego nie ma w planie, nie pojawi się w zadaniu; brak planu → odesłanie do /dev-plan). Branch feature/[nazwa] (bezpiecznie: istniejący → checkout, brudne drzewo → STOP) + 3 pliki w docs/active/[nazwa]/: plan (mapa faz 1:1 z planem), kontekst (pliki, decyzje, wzorce, designerski kontekst SPEC.md/DESIGN.md/Figma), zadania (checkboxy wg kontraktu parserów: impl. / Test: / Weryfikacja: / ## Operator checklist faza N, jedna nośna linia Test: [E2E] per scenariusz).

• Handoff = autopilot: na końcu bramka gotowości ([E2E] vs .env.e2e, niezaznaczone blokery z docs/operator/-przygotowanie.md, branch) i gotowe wywołanie Workflow({scriptPath: ".claude/workflows/dev-autopilot-wf.js", args: "docs/active/[nazwa]"}). Ścieżka ręczna (/dev-docs-execute → /dev-docs-review) tylko jako alternatywa.

Implementacja

dev-autopilot-wf docs/active/[nazwa] (workflow, domyślna ścieżka) — automatyczne wykonanie WSZYSTKICH faz z review i naprawami. Buduje PlanState + kolejkę faz, per faza woła dev-docs-execute-wf → dev-docs-review-wf → (przy P1/P2) cykl fix. Po fazach: compound → scoped refresh → complete.

• Resumability: po awarii runu (crash/kill) — Workflow({scriptPath, resumeFromRunId}) + te same args (cache odtwarza ukończone kroki). Po STOP bramki (środowisko E2E, fix FAIL, nierozwiązane P1), gdy coś naprawiłeś — świeży run bez resume (stan faz i tak wznowi się z .autopilot-state.json; resume zwróciłby porażkę bramki z cache).
• Stop conditions: P1 po cyklu fix (limit fix = 1 — drugi cykl naprawiał 0 findingów przy koszcie pełnego re-review; każdy P1/KOD po fixie przechodzi dodatkowo niezależny targeted verify), błąd buildu/testów, git conflict.
• Myk: walidację brancha robisz w sesji PRZED odpaleniem — workflow nie pyta o branch switch.

/dev-docs-execute docs/active/[nazwa] (workflow: dev-docs-execute-wf) — wykonanie jednej fazy. Każdy IU delegowany do buildera przez agentType (pole Delegate to: w IU): feature-builder-ui | feature-builder-data | feature-builder-fullstack. Strategia serial (zależne) / parallel (niezależne). Dla IU dotykających UI doklejany mandatory kontekst designerski. Na końcu: System-Wide Test Check, checkboxy, incremental commits.

/dev-docs-review docs/active/[nazwa] [faza] (workflow: dev-docs-review-wf — skill jest cienkim wrapperem wołającym workflow) — code review fazy. context-packager (mapa zmian + flagi warstw raz) → do 8 reviewerów równolegle (Security, Performance, Architecture, TypeScript, Spec-compliance, Simplicity/YAGNI, Test-coverage, E2E) → dedup → adversarial verify każdego P1/P2 (sceptycy próbują obalić finding; P1 = 3 sceptyków, P2 = 1) → scribe zapisuje raport + ## Przebieg review + bookkeeping checkboxów Weryfikacja: → severity gate (P1 blokuje / P2 zastrzeżenia / P3 OK).

• Routing domenowy: rdzeń (Security, Spec-compliance, Simplicity, Test-coverage) odpala się zawsze; Performance / Architecture / TypeScript / E2E tylko gdy faza tyka ich domeny — np. projekt bez ani jednego .ts nie płaci za reviewera typów, a faza czysto backendowa nie budzi testera przeglądarki. Gdy packager nie zwróci flag → pełny skład (fail-open). Pominięcie E2E blokuje odznaczanie browserowych checkboxów Weryfikacja: (idą do Operator checklist).
• Myk E2E: feature-tester-e2e testuje w prawdziwej przeglądarce (agent-browser) na dev serverze Vite (localhost:5173), nie w headless symulacji. Preflight: curl localhost:5173. Zwraca jawny przebieg per checkbox [E2E] (przebiegi[] PASS/FAIL/SKIP z dowodem, oba prefiksy Test:/Weryfikacja:) i nie pisze do pliku zadań — odznacza scribe, wyłącznie z wpisu PASS. Przy figma_screens robi side-by-side visual diff z mockupami (manualna akceptacja = finding OPERATOR, nie auto-checkbox). Bez .env.e2e weryfikacje E2E lądują jako OPERATOR (do ręcznego sprawdzenia).

/dev-docs-update docs/active/[nazwa] — zapis stanu przed kompaktowaniem kontekstu. Commituje WIP, aktualizuje 3 pliki zadania, dokumentuje niedokończoną pracę.

Zamknięcie

/dev-docs-complete [nazwa] — archiwizacja ukończonego zadania. Weryfikuje ukończenie, wyciąga wnioski, przenosi docs/active/ → docs/completed/, aktualizuje docs projektu. W trybie ręcznym skill wykonuje procedurę inline w sesji (smoke → archiwizacja); dev-docs-complete-wf jest wołany przez autopilot i czyta ten skill jako referencję procedury. → sugeruje /dev-compound.

• Smoke operatora (dokument #2): przed archiwizacją generuje docs/operator/--smoke.md — listę wyłącznie tego, czego automat nie sprawdził (niezaznaczone ## Operator checklist faza N, scenariusze [Manual], findingi OPERATOR z raportów review, known-issues, P3 widoczne dla użytkownika), z sekcją „0. Przygotowanie" (właściwy projekt Supabase — nie e2e, konto testowe nazwą zmiennej, dev server) i ramką „Jak kontynuować w nowej sesji". Niezaznaczone [E2E] trafiają na górę jako ⚠️ E2E nieuruchomione — nigdy nie są cicho odhaczane. Autopilot loguje ścieżkę i zwraca ją w smokeOperatora.

Knowledge capture

/dev-compound — dokumentowanie rozwiązanego problemu. Bez argumentów = wyciąga kontekst z sesji autonomicznie. Compact mode domyślny, --full dla pełnego formatu. Jeśli problem jest rule-worthy → dodaje regułę do learned-patterns.md. Jeśli pojawił się termin domenowy → dopisuje hasło do docs/CONCEPTS.md (Krok 4.5). → docs/solutions/[category]/

• Kategorie: build-errors, runtime-errors, supabase-issues, auth-issues, ui-bugs, performance-issues, typescript-errors, deployment-issues, testing-issues.

/dev-compound-refresh — przegląd aktualności bazy wiedzy. Autonomicznie przegląda docs/solutions/: Keep / Update / Replace / Archive. Przegląda learned-patterns.md (usuwa po Archive, aktualizuje po Replace, dedup, limit ~50) oraz docs/CONCEPTS.md (usuwa martwe hasła, scala duplikaty).

• Myk: pełny refresh (bez argumentu) przegląda całą bazę — uruchamiaj okresowo. W autopilocie odpala się automatycznie, ale scoped (tylko dotknięta kategoria + CONCEPTS.md, i tylko gdy compound coś zapisał).

Skille techniczne (guidelines pod stack)

Ładowane on-demand (progressive disclosure: SKILL.md + resources/). Preładowane do odpowiednich builderów/reviewerów.

Skille narzędziowe

---

Agenci — pełna lista (15)

Buildery warstw (wołane przez dev-docs-execute-wf)

Reviewerzy (wołani przez dev-docs-review-wf — 8 równolegle)

Test-coverage w review-wf pokrywa domyślny agent (happy path, invalid inputs, boundary, brakujące testy).

Research (wołani przez dev-plan, dev-brainstorm, dev-ideate)

---

Słownik domenowy — docs/CONCEPTS.md

Żywy glosariusz pojęć o znaczeniu specyficznym dla projektu (encje, nazwane procesy, statusy/enumy o niestandardowym sensie). Forma: cienki indeks — ## Termin + 1-2 zdania + link do szczegółów w CLAUDE.md. Tylko słownik, nie spec.

• Zasilany przez /dev-compound (Krok 4.5) — automatycznie łapie nowe terminy domenowe.
• Czytany przez dev-plan, dev-docs, buildery i learnings-researcher — żeby nie „naprawiać" zachowania wbrew definicjom (klasyczny błąd: „poprawianie" statusu, który celowo działa nietypowo).
• Utrzymywany przez /dev-compound-refresh (dedup, usuwanie martwych haseł).
• Seed: przy pierwszym /dev-compound w projekcie z bogatą domeną generuje startowy słownik z CLAUDE.md + schematu bazy.

---

Reguły, hooki, szablony

• .claude/rules/coding-rules.md — 14 sekcji reguł (rozmiar plików, testowanie, error handling, type safety, bezpieczeństwo, performance, async/race, architektura) + katalog 10 anty-patternów AI. Ładowane do każdej sesji.
• .claude/rules/learned-patterns.md — reguły wyprodukowane przez /dev-compound (tworzone per projekt, limit ~50).
• .claude/hooks/ — hooki harnessa (walidacje/automatyzacje przy wywołaniach narzędzi).
• .claude/templates/e2e-env/ — opcjonalne środowisko E2E (agent-browser na dedykowanej bazie Supabase e2e). Opt-in przez .env.e2e.
• .claude/templates/smoke-autopilot/ — smoke-test po każdej zmianie .claude/workflows/*-wf.js.

---

Struktura katalogów

docs/
├── ideation/                 ← pomysły z /dev-ideate
├── brainstorms/              ← requirements docs z /dev-brainstorm (lub zbiorczy, np. mvp-requirements.md)
├── plans/                    ← plany techniczne z /dev-plan (IU w fazach)
├── operator/                 ← dokumenty dla człowieka: -przygotowanie.md (z /dev-prep, uzupełniany
│                                przez /dev-plan — PRZED implementacją) i --smoke.md
│                                (z /dev-docs-complete, PO autopilocie)
├── CONCEPTS.md               ← słownik domenowy (żywy)
├── solutions/                ← rozwiązane problemy z /dev-compound
│   ├── build-errors/  runtime-errors/  supabase-issues/  auth-issues/
│   ├── ui-bugs/  performance-issues/  typescript-errors/  deployment-issues/
│   ├── testing-issues/
│   └── _archived/
├── active/                   ← aktywne zadania z /dev-docs
│   └── [nazwa]/  { plan.md · kontekst.md · zadania.md }   + branch feature/[nazwa]
└── completed/                ← zarchiwizowane z /dev-docs-complete
    └── [nazwa]/  { plan · kontekst · zadania · podsumowanie }

---

Typowe scenariusze

1. Pełny autopilot (ścieżka domyślna)

/dev-brainstorm lazy loading            ← tylko gdy wymagań jeszcze nie ma („pusta kartka")
/dev-plan                               ← plan techniczny (IU w fazach) + docs/operator/-przygotowanie.md
# odhacz przygotowanie dla operatora (konsole, sekrety, .env.e2e wg templates/e2e-env gdy plan ma [E2E])
/dev-docs                               ← zadania z planu + branch + bramka gotowości → gotowe wywołanie autopilota
dev-autopilot-wf docs/active/lazy-loading   ← execute→review→fix→compound→refresh→complete
# po runie: docs/operator/-lazy-loading-smoke.md → przejdź ręcznie w przeglądarce → PR

2. Nowy feature krok po kroku (ręczna kontrola)

/dev-ideate  →  (/dev-brainstorm)  →  /dev-plan  →  /dev-docs
/dev-docs-execute docs/active/nazwa
/dev-docs-review  docs/active/nazwa 1
/dev-docs-execute docs/active/nazwa          ← faza 2 …
/dev-docs-complete nazwa                     ← też generuje smoke operatora

3. Szybki feature (bez pełnego pipeline’u)

[rozmowa + plan mode]  →  /dev-docs  →  /dev-docs-execute docs/active/nazwa  →  /dev-docs-complete nazwa

4. Bugfix z dokumentacją

/bugfix [opis lub link Sentry]
/dev-compound                           ← udokumentuj rozwiązanie do docs/solutions/

5. Maintenance bazy wiedzy

/dev-compound-refresh                   ← przejrzyj całość
/dev-compound-refresh supabase-issues   ← tylko jedna kategoria

---

Myki i pułapki (najważniejsze)

• Autopilot: waliduj branch PRZED odpaleniem — workflow nie pyta o branch switch.
• RESUME tylko po awarii runu (zawsze z tymi samymi args — nie przeżywają między wywołaniami). Po STOP bramki (środowisko E2E, fix FAIL), gdy coś naprawiłeś — świeży run bez resumeFromRunId: resume zwróciłby porażkę bramki z cache; stan faz i tak wznowi się z .autopilot-state.json (źródło prawdy), checkboxy .md to tylko widok. Ręczne edycje .autopilot-state.json też wymagają świeżego runu.
• E2E to prawdziwa przeglądarka, nie symulacja — wymaga żywego dev servera (localhost:5173). Bez .env.e2e weryfikacje E2E → OPERATOR.
• Limit cyklu fix = 1 — drugi cykl historycznie naprawiał 0 findingów przy koszcie pełnego re-review. Po fixie każdy P1/KOD przechodzi niezależny targeted verify (weryfikator sprawdza kod, nie self-report fixa).
• compound-refresh w autopilocie jest scoped (tylko dotknięta kategoria + CONCEPTS.md) — pełny refresh całej bazy odpalaj osobno, okresowo.
• Nie autoryzuj po user_metadata (Supabase) — jest edytowalne przez usera; używaj app_metadata lub tabeli ról (reguła w coding-rules §9).
• Po każdej zmianie .claude/workflows/*-wf.js odpal smoke-test z .claude/templates/smoke-autopilot/.
• Skille dev-* działają bez argumentów — argument jest opcjonalnym doprecyzowaniem, nie wymogiem.

---

Changelog

Ostatnia aktualizacja: 2026-08-24

Źródła inspiracji: compound-engineering-plugin (EveryInc) + mattpocock/skills, zaadaptowane i spolszczone pod nasz stack. Szczegóły adaptacji: lokalna notatka ZRODLA-SZABLONU.md (gitignored).