10X WORKFLOW // DOKUMENTACJA // QUICK SEARCH
Marcin i Przemek łączą dokumentację metodyki, dystrybucję zasobów do repo i porównywanie modeli na danych
EKOSYSTEM WDROŻENIA

Hub mówi, jak pracować. 10x-cli przenosi zasoby do repo. 10xBench pomaga wybrać model.

DOKUMENTACJA // QUICK SEARCH

Cała mapa 10x Workflow w jednym indeksie

W indeksie: M1 Fundament, CSC (M2), skalowanie, M3 Jakość, M4 Legacy, M5 Teamwork - strony, kroki, węzły, lekcje i skille. Wpisz frazę albo naciśnij / - lista filtruje się natychmiast. Escape czyści wyszukiwanie. Pełny katalog skilli toolkitu z opisami: Biblioteka skilli.

START // STRONY MODUŁÓW

Pięć lekcji, które zamieniają mglisty pomysł w projekt gotowy do lotu: PRD, skille, bootstrap, onboarding agenta i pierwszy deploy. Rampa kończy się tam, gdzie startuje CSC.

m1fundamentmoduł 1landingrampa startowa
Detal
Po co istnieje
Mapa modułu 1: skąd biorą się jednostki pracy, zanim pierwsza zmiana wejdzie w new.
Wejście → wyjście
Wejście: pomysł (greenfield) lub istniejące repo (brownfield). Wyjście: prd.md, roadmap.md i środowisko - scaffold, AGENTS.md, działający deploy.
Mechanizm
Pięć lekcji = pięć pytań fundamentu; każda kończy się artefaktem na dysku.

Rdzeń 10x Workflow: sześć kroków jednej jednostki pracy - new → research → plan → implement → review → archive. Każdy krok zostawia artefakt na dysku.

cscworkflowłańcuchmoduł 2landing
Detal
Po co istnieje
Jedna mapa całego łańcucha: pokazuje, po co istnieje każdy krok i co gwarantuje, zanim wejdziesz w szczegóły pojedynczego skilla.
Wejście → wyjście
Wejście: jednostka pracy z fundamentu (prd.md, roadmap.md). Wyjście: przejście new → review z artefaktem na dysku po każdym kroku.
Mechanizm
Kroki komunikują się plikami w context/changes/<change-id>/ - artefakt zatrzymuje maszynę, człowiek zatwierdza, łańcuch rusza dalej.

Warstwa nad łańcuchem: quality gates → goal → loops. Skalowanie to więcej cykli równolegle z bramkami jakości i autonomią - sufit przepustowości wyznacza Twoja zdolność do review.

skalowaniescale tierquality gatesgoalloopslanding
Detal
Po co istnieje
Mapa warstwy „ponad łańcuchem": trzy węzły, które podnoszą rygor i autonomię, gdy rośnie ryzyko i/lub złożoność.
Wejście → wyjście
Wejście: działający łańcuch CSC na pojedynczych jednostkach pracy. Wyjście: więcej cykli równolegle, każdy domykany bramkami i review.
Mechanizm
Łańcuch się nie zmienia - dokładasz mu obstawę: bramki jakości per etap, autonomiczny przelot planu, równoległe cykle w rytmie.

Pięć lekcji o jakości: najpierw ryzyka, nie pliki - chroń najgroźniejsze scenariusze testem, którego asercja realnie pada. Jakość domyka blok 10xBuilder.

m3jakośćmoduł 3testylanding
Detal
Po co istnieje
Mapa modułu 3: jak chronić działający produkt testami według ryzyka, nie według listy plików - i jak nie ufać zieleni, która nie umie zrobić się czerwona.
Wejście → wyjście
Wejście: działający produkt z fundamentu i łańcucha. Wyjście: mapa ryzyk, testy, które realnie padają, warstwy hooków, przeloty E2E i diagnozy z dowodów.
Mechanizm
Pięć lekcji = pięć pytań jakości; zielony test, który nie pada po zepsuciu, niczego nie pilnuje (mutation check).

Pięć lekcji o zastanym kodzie: decyzje architektoniczne z dowodów, nie z intuicji. Kręgosłup modułu: 5-elementowy raport architektoniczny - obronialny, nie przyjęty na wiarę.

m4legacy10xarchitectraport architektonicznylanding
Detal
Po co istnieje
Mapa modułu 4: jak wejść w cudzy, zastany kod z dowodami zamiast intuicji.
Wejście → wyjście
Wejście: zastany system - cudzy kod, brak testów, archeologia decyzji. Wyjście: 5-elementowy raport architektoniczny: architektura kontekstu, mapa projektu, przegląd feature’a + hot spots, okazje refaktorowe, okazje DDD.
Mechanizm
Pięć lekcji = pięć pytań architekta; raport ma być Twój - obronialny, nie przyjęty na wiarę.

Pięć lekcji o pracy zespołowej z agentami: agent zarabia dla zespołu dopiero wtedy, gdy działa bez Ciebie. Artefakty AI to kod - jedno źródło prawdy, wersjonowanie, dystrybucja. Domyka kampanię.

m5teamwork10xchampiondrużynalanding
Detal
Po co istnieje
Mapa modułu 5: od osobistego workflow do zespołu - narzędzia wewnętrzne, agent poza IDE, review w CI, rejestr artefaktów, delegacja zdalna.
Wejście → wyjście
Wejście: workflow działający u Ciebie. Wyjście: agent pracujący dla zespołu - odznakę 10xChampion domyka jeden z dwóch projektów: pipeline CI/CD do review kodu albo rejestr artefaktów.
Mechanizm
Pięć lekcji = pięć pytań zespołowych; dowodem są działające instalacje - pipeline z komentarzem agenta na PR albo rejestr z wydanymi wersjami.

CSC // CORE SKILLS CHAIN // MODUŁ 2

Pytanie: jedna jednostka pracy. Gwarancja: jasny, odwracalny zakres. Tnie zamiar na zmianę na tyle małą, że da się ją ogarnąć i cofnąć.

krok 01newzakreschange.md/10x-new
Detal
Po co istnieje
Bez bramy zadanie „popraw onboarding" rozlewa się na całe repo i nigdy nie wiadomo, co znaczy „zrobione".
Wejście → wyjście
Wejście: luźny pomysł lub zgłoszenie. Wyjście: folder context/changes/<change-id>/ z plikiem change.md - tożsamością zmiany.
Mechanizm
Artefakt zatrzymuje maszynę: człowiek patrzy na zakres i decyduje, czy to jest ta bitwa, zanim cokolwiek poleci dalej.

Pytanie: dowody do planu. Gwarancja: fakty zamiast założeń. Plan ma powstać na dowodach z repozytorium, nie na pamięci sprzed trzech refaktorów.

krok 02researchdowodyresearch.md/10x-research
Detal
Po co istnieje
Największy sabotażysta planu to własne „wiem, jak to działa" - research zastępuje je pomiarem repozytorium.
Wejście → wyjście
Wejście: change.md. Wyjście: research.md - ścieżki plików, konwencje, realne punkty zaczepienia.
Mechanizm
Równolegli subagenci przeczesują repo, każdy swój obszar; wynik ląduje na dysku, więc kolejne kroki czytają fakty z pliku zamiast polegać na pamięci rozmowy.

Pytanie: kluczowe decyzje deva. Gwarancja: etapy + warunki sukcesu. Decyzje zapadają przed kodem, gdzie są tanie do zmiany.

krok 03planetapyplan.md/10x-plan
Detal
Po co istnieje
Usuwa ból implementacji „na żywioł", w której kluczowe decyzje zapadają mimochodem, w środku pisania kodu.
Wejście → wyjście
Wejście: research.md. Wyjście: plan.md - etapy z warunkami sukcesu (automatycznymi i ręcznymi) plus sekcja Progress.
Mechanizm
Plan iteruje z człowiekiem, dopóki jest tekstem; zatwierdzony staje się kontraktem, a Progress maszyną stanów dla implementacji.

Pytanie: implementacja etap po etapie. Gwarancja: commitowane, weryfikowalne kroki. Każdy etap to punkt powrotu zamiast jednego wielkiego diffa.

krok 04implementcommityprogress/10x-implement
Detal
Po co istnieje
Usuwa ból jednej wielkiej zmiany bez punktów kontrolnych, której nie da się ani przerwać, ani cofnąć.
Wejście → wyjście
Wejście: zatwierdzony plan.md. Wyjście: commity per etap i odhaczona sekcja Progress.
Mechanizm
Progress jako maszyna stanów - etap kończy się dopiero, gdy warunki sukcesu są zielone i zmiana jest zacommitowana; przerwana sesja wraca od ostatniego zielonego etapu.

Pytanie: czy implementacja realizuje plan? Gwarancja: analiza subagentów: plan vs kod. Konkretny raport rozbieżności zamiast rytualnego „wygląda dobrze".

krok 05reviewdryfplan vs kod/10x-impl-review
Detal
Po co istnieje
Odpowiednikiem rytuału nad niezrozumianą maszyną jest „działa, mergujemy" - review sprawdza, czy kod dotrzymał obietnic planu.
Wejście → wyjście
Wejście: plan.md i gotowy diff. Wyjście: raport review - dryf względem planu, niebezpieczne decyzje, zgodność z konwencjami repo.
Mechanizm
Analiza subagentów - każdy porównuje inny wymiar planu z kodem; człowiek dostaje listę konkretnych rozbieżności.
KROK

Krok 06: archive - domknięcie zmiany

lessons.md + archiwum

Pytanie: domknięcie zmiany. Gwarancja: lekcje w foundation, folder w archiwum. Skończona praca zostawia trwały zapis, a changes/ pokazuje tylko pracę w toku.

krok 06archivedomknięcielessons.md/10x-archive
Detal
Po co istnieje
Bez domknięcia changes/ zapycha się starą pracą i nie widać, co jest w toku; wiedza ze skończonej zmiany ulatuje razem z oknem rozmowy.
Wejście → wyjście
Wejście: ukończona zmiana - plan.md z odhaczonym Progress i commitami. Wyjście: lekcje w context/foundation/lessons.md plus folder w context/archive/.
Mechanizm
Kontrola kompletności - każdy etap powinien mieć commit (SHA); etap czysto ręczny bez commita to ostrzeżenie informacyjne, nie błąd.
SKILL

/10x-new

change.md

Inicjalizuje folder zmiany context/changes/<change-id>/ z plikiem change.md - tożsamością jednostki pracy.

skillkrok 01 · newchange.md
Detal
Po co istnieje
Każda zmiana potrzebuje tożsamości na dysku, zanim ruszy jakakolwiek praca - inaczej zakres żyje tylko w oknie czatu.
Wejście → wyjście
Wejście: identyfikator zmiany plus luźny opis zamiaru. Wyjście: context/changes/<change-id>/change.md.
Mechanizm
Jeden plik z frontmatterem i opisem zakresu; kolejne skille łańcucha czytają go jako punkt startowy.

STRONA SKILLA →

SKILL

/10x-research

research.md

Przeczesuje repozytorium równoległymi subagentami i składa wynik w research.md - kompletny obraz kodu pod plan.

skillkrok 02 · researchsubagenci
Detal
Po co istnieje
Plan pisany z pamięci (modelu albo własnej) dziedziczy jej luki; research zastępuje pamięć pomiarem.
Wejście → wyjście
Wejście: change.md lub pytanie badawcze. Wyjście: research.md obok change.md.
Mechanizm
Fan-out subagentów: każdy bada swój obszar (kod, testy, historia), a wyniki są scalane w jeden dokument z odnośnikami do plików.

STRONA SKILLA →

SKILL

/10x-plan

plan.md

Tworzy szczegółowy plan implementacji przez gruntowny research i iterację z człowiekiem: etapy, warunki sukcesu, sekcja Progress.

skillkrok 03 · planetapy
Detal
Po co istnieje
Kluczowe decyzje deva mają zapaść, gdy są tanie - w tekście, nie w połowie diffa.
Wejście → wyjście
Wejście: change.md + research.md. Wyjście: plan.md z etapami i sekcją Progress.
Mechanizm
Iteracja: czytasz, kwestionujesz, poprawiasz; zatwierdzony plan staje się kontraktem dla /10x-implement.

STRONA SKILLA →

SKILL

/10x-implement

commity per etap

Realizuje plan z context/changes/<change-id>/plan.md etap po etapie, z weryfikacją warunków sukcesu po każdym etapie.

skillkrok 04 · implementprogress
Detal
Po co istnieje
Realizacja planu ma być serią punktów powrotu, nie jednym wielkim diffem, którego nikt nie przeczyta.
Wejście → wyjście
Wejście: zatwierdzony plan.md. Wyjście: kod, commity per etap, odhaczona sekcja Progress.
Mechanizm
Etap po etapie: implementacja, weryfikacja warunków sukcesu, commit; Progress pilnuje, gdzie jesteś po przerwie.

STRONA SKILLA →

SKILL

/10x-impl-review

raport review

Recenzuje implementację względem planu: dryf, niebezpieczne decyzje, zgodność ze wzorcami repo.

skillkrok 05 · reviewdryf
Detal
Po co istnieje
Im większy diff, tym łatwiej o dryf między tym, co plan obiecał, a tym, co kod robi.
Wejście → wyjście
Wejście: plan.md (opcjonalnie konkretny etap) i diff. Wyjście: raport review z listą rozbieżności.
Mechanizm
Subagenci porównują wymiary planu z kodem: zgodność zakresu, bezpieczeństwo decyzji, wzorce repo.

STRONA SKILLA →

SKILL

/10x-archive

lessons.md + archiwum

Domyka skończoną zmianę: sprawdza kompletność (commit per etap), dopisuje lekcje do context/foundation/lessons.md i przenosi folder do context/archive/.

skillkrok 06 · archivelessons.md
Detal
Po co istnieje
Ostatni krok łańcucha, świadomie po review i merge - to, czego nauczyła Cię zmiana, ląduje w foundation, a folder w archiwum.
Wejście → wyjście
Wejście: ukończona zmiana w context/changes/<change-id>/. Wyjście: lekcje w lessons.md plus folder w context/archive/.
Mechanizm
Porównuje deklaracje w Progress z zawartością folderu, zanim cokolwiek przeniesie; nie dotyka kodu i nie zastępuje review - potwierdza kompletność, nie poprawność.

STRONA SKILLA →

SKILL

/10x-frame

frame.md

Kwestionuje ramę problemu przed planowaniem: oddziela obserwację od deklarowanej przyczyny, testuje hipotezy równoległymi subagentami i zapisuje frame.md.

skillframingframe.md
Detal
Po co istnieje
Zgłoszenie w formacie „bug + proponowana poprawka" często przemyca błędną diagnozę; frame domyka ją przed /10x-plan.
Wejście → wyjście
Wejście: obserwacja plus deklarowana przyczyna lub propozycja poprawki. Wyjście: frame.md z przetestowaną ramą problemu.
Mechanizm
Oddziela obserwację od deklarowanej przyczyny i testuje hipotezy równoległymi subagentami; „rama była trafna" to pełnoprawny wynik.
SKILL

/10x-plan-review

plan-review.md

Recenzuje plan w pięciu wymiarach: zgodność ze stanem docelowym, oszczędność wykonania, dopasowanie architektoniczne, martwe pola i kompletność; zapisuje reviews/plan-review.md.

skillkrok 03 · planreview planu
Detal
Po co istnieje
Wada planu wychwycona przed implementacją kosztuje edycję dokumentu; wychwycona w kodzie kosztuje refaktor.
Wejście → wyjście
Wejście: plan.md z context/changes/<change-id>/. Wyjście: reviews/plan-review.md.
Mechanizm
Pięć wymiarów recenzji; ponowne uruchomienie nadpisuje raport, flaga --quick ogranicza review do samego dokumentu.
SKILL

/10x-status

przegląd statusów

Pokazuje status wszystkich zmian: czyta frontmatter change.md i parsuje sekcję Progress każdego planu; wyłącznie odczyt, z ostrzeżeniami o dryfie statusów.

skillstatusprogress
Detal
Po co istnieje
Stan każdego cyklu w jednym miejscu, z ostrzeżeniami o dryfie statusów względem realnego postępu.
Wejście → wyjście
Wejście: foldery zmian w context/changes/. Wyjście: przegląd statusów plus widok szczegółowy per zmiana.
Mechanizm
Czyta frontmatter change.md i parsuje sekcję Progress każdego planu; wyłącznie odczyt - nigdy nie zapisuje, ostrzeżenia nie blokują pracy.

M1 // FUNDAMENT // MODUŁ 1

Pytanie: co naprawdę budujemy? Gwarancja: ustalenia, których kolejne prompty nie podważą. Sesja sokratejska /10x-shape, potem /10x-prd.

lekcja 01prdshape/10x-shape/10x-prd
Detal
Po co istnieje
Bez testu pytań „mam pomysł na apkę" rozpada się przy trzecim prompcie.
Wejście → wyjście
Wejście: luźny pomysł lub istniejący projekt (auto-wykrycie greenfield/brownfield). Wyjście: shape-notes.md, a z niego prd.md.
Mechanizm
Pytania idą przed generowaniem - PRD spisuje ustalenia na dysku, więc kolejne prompty budują na decyzjach, zamiast po cichu je podważać.

Pytanie: czym gra agent? Gwarancja: powtarzalne narzędzia zamiast jednorazowych promptów. Skill to odtwarzalna para kontraktów wejścia/wyjścia.

lekcja 02skillemetapromptingagent
Detal
Po co istnieje
Prompt żyje raz i umiera w historii czatu; powtarzalna praca ma być modułem, nie improwizacją w oknie czatu.
Wejście → wyjście
Wejście: powtarzający się problem, dziś załatwiany coraz dłuższym promptem. Wyjście: skill z kontraktem wejścia/wyjścia, zapisany obok kodu.
Mechanizm
Metaprompting - agent pomaga pisać własne narzędzia; każdy dopracowany skill podnosi jakość wszystkich kolejnych przebiegów.

Pytanie: na czym stawiamy? Gwarancja: starter z oficjalnego CLI, nie boilerplate z generatora. Greenfield: tech-stack-selector → bootstrapper; brownfield: stack-assess → health-check.

lekcja 03bootstrapstackgreenfieldbrownfield
Detal
Po co istnieje
Boilerplate generowany z pamięci modelu psuje się przy pierwszej aktualizacji frameworka - fundamenty kładzie oficjalne CLI.
Wejście → wyjście
Wejście: prd.md (greenfield) albo istniejące repo (brownfield). Wyjście: tech-stack.md i działający scaffold z oficjalnego CLI.
Mechanizm
Delegacja do oficjalnych CLI plus jasna polityka uprawnień: co agent uruchamia sam, a co wymaga człowieka.

Pytanie: co agent ma wiedzieć? Gwarancja: kontekst projektu bez szumu. Tylko to, czego model nie wywnioskuje z pretrainingu.

lekcja 04agents.mdonboardingai rules
Detal
Po co istnieje
Kontekst bez szumu decyduje, czy pracuje z Tobą weteran, czy rekrut po złej odprawie.
Wejście → wyjście
Wejście: repo po bootstrapie. Wyjście: AGENTS.md z /10x-agents-md, oceniony przez /10x-rule-review.
Mechanizm
Pętla feedbacku: każde potknięcie agenta to kandydat na regułę; przegląd reguł wycina szum, zanim zagłuszy sygnał.
LEKCJA

Lekcja 05: Z localhosta na produkcję - gdzie i jak wypływamy?

infrastructure.md + roadmap.md + deploy

Pytanie: gdzie i jak wypływamy? Gwarancja: działający deploy zamiast wiecznego localhosta. Kalkulacja przed skokiem: infra-research, roadmap, deployment.

lekcja 05deployprodukcjainfrastrukturaroadmap
Detal
Po co istnieje
Deploy to świadoma decyzja infrastrukturalna, nie odruch - i dopiero produkcja ją weryfikuje.
Wejście → wyjście
Wejście: działający projekt na localhoście plus prd.md. Wyjście: infrastructure.md, roadmap.md i pierwszy działający deploy.
Mechanizm
Platforma wybrana z dowodów (/10x-infra-research), roadmapa wyznacza kolejność, /10x-deployment domyka bramkę gotowości preflightem.
SKILL

/10x-init

katalog context/

Stawia szkielet katalogu context/ (changes, archive, foundation) z uniwersalnymi plikami README - stałe miejsce artefaktów workflow, zanim powstanie pierwsza zmiana.

skilllekcja 01context/
Detal
Po co istnieje
Każdy artefakt workflow dostaje stałe miejsce na dysku, zanim powstanie pierwsza zmiana.
Wejście → wyjście
Wejście: repo bez katalogu context/. Wyjście: context/{changes,archive,foundation}/ z plikami README.
Mechanizm
Idempotentny scaffold - ponowne uruchomienie na gotowym projekcie niczego nie zmienia; lessons.md i contract-surfaces.md zakładają się same przy pierwszym użyciu /10x-lesson i /10x-contract.
SKILL

/10x-shape

shape-notes.md

Prowadzi ustrukturyzowaną rozmowę odkrywczą, która zamienia pomysł - greenfield lub brownfield, wykrywane z repo - w shape-notes.md, wejście do /10x-prd.

skilllekcja 01fundamentdiscovery
Detal
Po co istnieje
Pomysł bez spisanych ustaleń rozmywa się z każdym promptem; sesja sokratejska wyciąga decyzje, zanim powstanie kod.
Wejście → wyjście
Wejście: pomysł lub istniejący projekt. Wyjście: shape-notes.md.
Mechanizm
Rozmowa prowadzona pytaniami; kontekst (greenfield/brownfield) wykrywany automatycznie z katalogu roboczego.
SKILL

/10x-prd

prd.md

Generuje context/foundation/prd.md z shape-notes.md według zamkniętego schematu; sam trafia w szablon greenfield (10 sekcji) lub brownfield (11 sekcji).

skilllekcja 01prdfundament
Detal
Po co istnieje
PRD zgodny ze schematem to wspólny język dalszych skilli - roadmapa i wybór stacku czytają go bez zgadywania.
Wejście → wyjście
Wejście: shape-notes.md (lub surowe notatki). Wyjście: context/foundation/prd.md.
Mechanizm
Routing po context_type z shape-notes.md albo auto-detekcji; schemat PRD jest zamknięty, nie negocjowany per projekt.
SKILL

/10x-tech-stack-selector

tech-stack.md

Wybiera starter i stack dla projektu greenfield po PRD: czyta prd.md, przechodzi rejestr starterów przez cztery bramki jakości i zapisuje tech-stack.md.

skilllekcja 03stackgreenfield
Detal
Po co istnieje
Stack pod agenta musi przejść bramki: typowany, oparty na konwencjach, popularny, dobrze udokumentowany.
Wejście → wyjście
Wejście: context/foundation/prd.md. Wyjście: context/foundation/tech-stack.md.
Mechanizm
Rejestr starterów świadomy języka plus cztery bramki jakości; wynik to hand-off dla /10x-bootstrapper.
SKILL

/10x-bootstrapper

scaffold + log

Stawia scaffold w bieżącym katalogu po wyborze stacku: czyta tech-stack.md, uruchamia CLI oficjalnego startera i zapisuje log weryfikacji.

skilllekcja 03bootstrapcli
Detal
Po co istnieje
Fundamenty kładzie oficjalne CLI startera, nie generowany z pamięci boilerplate.
Wejście → wyjście
Wejście: context/foundation/tech-stack.md. Wyjście: działający scaffold plus log weryfikacji.
Mechanizm
Twarda polityka konfliktów: katalog context/ zawsze przeżywa uruchomienie startera.
SKILL

/10x-stack-assess

stack-assessment.md

Ocenia stack istniejącego projektu pod agenta według 4 bramek jakości; zapisuje stack-assessment.md z ocenami per komponent, lukami i gotowymi wpisami do CLAUDE.md/AGENTS.md.

skilllekcja 03brownfield
Detal
Po co istnieje
Brownfieldowy odpowiednik wyboru stacku: zanim agent zacznie pracę, trzeba wiedzieć, gdzie stack mu pomoże, a gdzie podłoży nogę.
Wejście → wyjście
Wejście: istniejące repo. Wyjście: context/foundation/stack-assessment.md.
Mechanizm
Cztery bramki jakości (typowany, oparty na konwencjach, popularny, udokumentowany) oceniane per komponent stacku.
SKILL

/10x-health-check

health-check.md

Audyt zdrowia istniejącego projektu: zależności, bezpieczeństwo, wykrycie test runnera, CI/CD i brakująca konfiguracja; kończy się werdyktem gotowości na agenta.

skilllekcja 03brownfieldaudyt
Detal
Po co istnieje
Agent w chorym repo mnoży problemy zamiast je rozwiązywać - najpierw diagnoza, potem praca.
Wejście → wyjście
Wejście: istniejące repo (po /10x-stack-assess). Wyjście: context/foundation/health-check.md z priorytetami napraw.
Mechanizm
Audyt zależności i bezpieczeństwa, detekcja test runnera, analiza CI/CD i brakującej konfiguracji - z priorytetyzacją.
SKILL

/10x-agents-md

AGENTS.md

Generuje AGENTS.md - zwięzły przewodnik po repo dla agentów AI: konwencje, komendy, pułapki; krytyczne reguły na górze.

skilllekcja 04onboardingagents.md
Detal
Po co istnieje
Agent bez kontekstu projektu wnioskuje z pretrainingu - a pretraining nie zna Twoich konwencji ani pułapek.
Wejście → wyjście
Wejście: repo (manifest, README, skrypty, konfiguracja lintu/testów, układ, historia commitów). Wyjście: AGENTS.md.
Mechanizm
Dokument mały, precyzyjny, z odsyłaczami zamiast powtórzeń - agent czyta raz i nie blokuje się na oczywistościach.
SKILL

/10x-rule-review

scorecard reguł

Ocenia kondycję pliku reguł AI (CLAUDE.md, AGENTS.md, .cursor/rules i podobne) i wystawia 5-punktowy scorecard z konkretnymi poprawkami.

skilllekcja 04ai rulesscorecard
Detal
Po co istnieje
Rozdęte lub nieaktualne reguły obciążają każdą sesję agenta - przegląd wskazuje, co wyciąć i co doprecyzować.
Wejście → wyjście
Wejście: plik reguł AI (CLAUDE.md, AGENTS.md, .cursor/rules i podobne). Wyjście: 5-punktowy scorecard z konkretnymi poprawkami.
Mechanizm
Działa niezależnie od narzędzia, na które celują reguły; generowanie nowego AGENTS.md należy do /10x-agents-md.
SKILL

/10x-roadmap

roadmap.md

Generuje roadmap.md z PRD jako uporządkowany zestaw pionowych wycinków end-to-end - kolejne widoczne dla użytkownika kamienie milowe do oddania w /10x-plan.

skilllekcja 05roadmapfundament
Detal
Po co istnieje
Holistyczny PRD nie mówi, co budować najpierw - roadmapa tnie go na kolejność, którą da się odhaczać.
Wejście → wyjście
Wejście: context/foundation/prd.md (po wyborze stacku/bootstrapie, gdy dotyczy). Wyjście: context/foundation/roadmap.md.
Mechanizm
Pionowe wycinki end-to-end zamiast warstw technicznych; każdy wycinek jest kandydatem na jednostkę pracy dla łańcucha CSC.
SKILL

/10x-infra-research

infrastructure.md

Krótki wywiad plus równoległy research platform do deploymentu MVP, z kontrolą biasu źródeł; zapisuje infrastructure.md z punktowanym porównaniem i rejestrem ryzyk.

skilllekcja 05infrastrukturaplatforma
Detal
Po co istnieje
Wybór platformy „bo wszyscy tak robią" to decyzja bez dowodów - a decyzję o infrastrukturze trudno potem cofnąć.
Wejście → wyjście
Wejście: prd.md lub tech-stack.md plus krótki wywiad. Wyjście: context/foundation/infrastructure.md.
Mechanizm
Równoległy research webowy z kontrolą biasu źródeł; wynik to punktowane porównanie plus rejestr ryzyk.
SKILL

/10x-deployment

raport gotowości + config

Bramka gotowości do deployu na PaaS (Cloudflare, Vercel, Netlify, Fly.io, Railway, Render): realny preflight, raport gotowości, natywna konfiguracja platformy, opcjonalny deploy z CLI.

skilllekcja 05deploypaas
Detal
Po co istnieje
„U mnie działa" nie jest bramką - deploy ma przejść preflight, zanim dotknie produkcji.
Wejście → wyjście
Wejście: projekt plus wybrana platforma PaaS. Wyjście: raport gotowości, konfiguracja platformy, opcjonalnie deploy przez CLI.
Mechanizm
Realny preflight zamiast checklisty z pamięci: build, konfiguracja, zmienne środowiskowe, dopiero potem zielone światło.

SKALOWANIE // SCALE TIER

Pytanie: co pilnuje jakości, gdy Ciebie nie ma? Gwarancja: żaden etap nie przechodzi na czerwono. Lint i typecheck po każdej edycji, testy per etap, commit tylko na zielono.

węzeł 01quality gatesbramkigom dżabbardeliberate-break
Detal
Po co istnieje
Bez bramek autonomia oznacza kod, którego nikt nie sprawdził w chwili powstania - jedyną bramką jesteś Ty i musisz patrzeć na wszystko.
Wejście → wyjście
Wejście: plan z warunkami sukcesu. Wyjście: etap domknięty automatycznie - lint/typecheck per edycja, testy per etap, commit na zielono.
Mechanizm
Deliberate-break check: celowo psujesz implementację i potwierdzasz, że test pada - bramce można zaufać dopiero wtedy, gdy widziałeś, jak się zamyka.
WĘZEŁ

Węzeł 02: goal - plan wykonuje się bez autora

commity per etap + run report

Pytanie: jak plan wykonuje się bez Ciebie? Gwarancja: commit per etap na zielono albo uczciwy STOP. Autonomiczne przejście planu przez /10x-goal-implement pod /goal.

węzeł 02goalautonomiaseldonstop-blok/10x-goal-implement
Detal
Po co istnieje
Bez tego węzła siedzisz między etapami jako klikacz „dalej" i autonomia kończy się na pierwszym pytaniu.
Wejście → wyjście
Wejście: zatwierdzony plan.md. Wyjście: commit per etap na zielono albo uczciwy STOP - plus run report.
Mechanizm
Etapy wykonują się same, Progress pracuje jak maszyna stanów, a przy strukturalnym rozjeździe wykonanie zatrzymuje się STOP-blokiem zamiast improwizować.

Pytanie: ile cykli naraz udźwigniesz? Gwarancja: więcej przepustowości bez nierecenzowanego kodu. Równoległe cykle plan → implement → review z izolacją kontekstu; rytm zamiast na żądanie.

węzeł 03loopsrównoległośćizolacja kontekstu/loop
Detal
Po co istnieje
Eskadra nie skaluje się przez wsadzenie dwunastu pilotów do jednego myśliwca - więcej cykli równolegle z izolacją kontekstu, nie więcej agentów na jednym wycinku.
Wejście → wyjście
Wejście: kilka niezależnych jednostek pracy. Wyjście: osobny cykl per tor - change-folder plus raport review, bez nierecenzowanego kodu.
Mechanizm
Cykle biegną w rytmie (/loop), każdy we własnym kontekście (worktree/sesje), a wszystkie zbiegają do jednej bramy - Twojego review; sufit wyznacza dowódca, nie liczba maszyn.
SKILL

/10x-goal-implement

commity + checklist

Autonomiczna realizacja planu pod /goal - bez człowieka między etapami; rodzeństwo /10x-implement do przebiegów nienadzorowanych i headless.

skillskalowaniewęzeł 02 · goalautonomia
Detal
Po co istnieje
Skalowanie łańcucha: gdy plan jest dobry, przejście etapów nie wymaga człowieka - wymaga bramek.
Wejście → wyjście
Wejście: zatwierdzony plan.md. Wyjście: commity per etap (Conventional Commits) plus lista rzeczy do ręcznego sprawdzenia na koniec.
Mechanizm
Subagent na etap plus automatyczny stos bramek jakości (warunki planu, kontrola celowo psutego testu, pełny zestaw testów); commit dopiero po zielonym.

M3 // JAKOŚĆ

Pytanie: co zabija projekt najpierw? Gwarancja: najgroźniejsze scenariusze chronione najpierw. Mapa ryzyk wpływ × prawdopodobieństwo; ryzyko opisane jako awaria u usera.

lekcja q-01plan testówmapa ryzykfremeni/10x-test-plan
Detal
Po co istnieje
Zamiast pokrywać pliki po kolei, mapuje ryzyka na osi wpływ × prawdopodobieństwo - „koszyk gubi pozycje przy odświeżeniu", nie „brak testów w cart.ts".
Wejście → wyjście
Wejście: działający produkt i PRD. Wyjście: context/foundation/test-plan.md - mapa ryzyk pocięta na etapy rolloutu, od najgroźniejszych scenariuszy w dół.
Mechanizm
/10x-test-plan orkiestruje dowiezienie testów, nie pisze ich sam - każdy etap prowadzi przez research → plan → implement, a ponowne uruchomienie wznawia od następnego etapu.

Pytanie: skąd test wie, co jest poprawne? Gwarancja: asercja, która realnie pada na zepsutym kodzie. Wyrocznia z wymagań i researchu, nie z kodu; mutation check.

lekcja q-02wyroczniamutationanti-patterny/10x-tdd
Detal
Po co istnieje
Test odczytujący oczekiwaną wartość z implementacji tylko ją powiela - przyklepie każdy bug, który już tam mieszka; anti-patterny: asercje spisane z kodu, snapshoty bez zrozumienia, mocki testujące mocki.
Wejście → wyjście
Wejście: jedno ryzyko z test-plan.md. Wyjście: test, którego asercja realnie pada na zepsutym kodzie.
Mechanizm
Mutation check: zepsuj chronione zachowanie celowo i potwierdź czerwień; /10x-tdd wymusza kolejność - czerwony test przed kodem, zieleń jako dowód, refactor na osłoniętym gruncie.

Pytanie: co łapie błąd, zanim go zobaczysz? Gwarancja: dryf wykryty sekundy po powstaniu, nie na końcu etapu. Warstwowa obrona według kosztu: per-edit → pre-commit → pre-push.

lekcja q-03hookitarczelinttypecheck
Detal
Po co istnieje
Im dalej błąd doleci, tym drożej kosztuje jego zestrzelenie - obrona jest uporządkowana według kosztu, warstwa za warstwą, od najtańszej na zewnątrz.
Wejście → wyjście
Wejście: reguły jakości projektu - lint, typecheck, szybkie testy. Wyjście: hooki zapięte na zdarzenia - per-edit, pre-commit i pre-push, każdy z własnym budżetem czasu.
Mechanizm
Self-checking pipeline - dryf wykrywany sekundy po powstaniu, w tle, bez udziału człowieka; do końca etapu dolatuje tylko to, czego żadna warstwa nie mogła złapać wcześniej.

Pytanie: czy całość naprawdę leci? Gwarancja: przelot end-to-end tam, gdzie unit by skłamał. Najtańszy test dający sygnał - E2E tylko tam, gdzie mock by skłamał; coverage nie jest celem.

lekcja q-04e2eplaywrightrocinanteseed test/10x-e2e
Detal
Po co istnieje
Przelot przez wszystkie moduły naraz - UI, API, dane - dokładnie tam, gdzie mock by skłamał; jeśli wystarcza test jednostkowy, E2E jest przepychem.
Wejście → wyjście
Wejście: działająca aplikacja i ryzyko z planu, którego nie pokryje nic tańszego. Wyjście: testy Playwright plus seed test przygotowujący dane pod przelot.
Mechanizm
/10x-e2e prowadzi ryzyko przez plan → generate → review → verify na uruchomionej aplikacji, multimodalnie - agent czyta DOM i patrzy na zrzuty ekranu jednocześnie.
LEKCJA

Lekcja 05: Debugowanie - co mówią wszystkie przyrządy naraz?

diagnoza + test przypinający naprawę

Pytanie: co mówią wszystkie przyrządy naraz? Gwarancja: diagnoza z dowodów, nie z przeczucia. Synteza dowodów z wielu źródeł: Sentry, wrangler logs, konsola i network z Playwrighta.

lekcja q-05debugowaniesentrypielgrzymiwranglermulti-source
Detal
Po co istnieje
Żadne pojedyncze źródło niczego nie wyjaśnia - wszystkie naraz wskazują to samo miejsce; liczy się synteza dowodów, nie mistrzostwo w jednym narzędziu.
Wejście → wyjście
Wejście: objaw - błąd u usera, czerwony test, alert. Wyjście: diagnoza poparta dowodami i naprawa przypięta testem, żeby regresja nie wróciła.
Mechanizm
Zbierz odczyty wszystkich przyrządów naraz i szukaj przecięcia opowieści; po drodze wytęp połykanie błędów - try/catch zwracający 200 to zamiatanie dowodów (OWASP A10:2025).
SKILL

/10x-test-plan

test-plan.md

Etapowy orkiestrator wdrażania testów w istniejącym produkcie: pisze test-plan.md i prowadzi każdy etap rolloutu przez pełny łańcuch CSC.

skilllekcja q-01 · plan testówtestybrownfieldorkiestrator
Detal
Po co istnieje
Pokrycie testami istniejącego produktu to seria zmian, nie jeden zryw - potrzebuje stanu i kolejności.
Wejście → wyjście
Wejście: PRD i roadmapa istniejącego produktu. Wyjście: context/foundation/test-plan.md plus kolejne etapy rolloutu jako zmiany CSC.
Mechanizm
Każdy etap przechodzi /10x-new → research → plan → implement; ponowne uruchomienie wznawia od następnego etapu zapisanego w test-plan.md.
SKILL

/10x-tdd

testy + kod

Prowadzi zatwierdzony plan etap po etapie test-first, przez red → green → refactor - tylko etapy, które da się TDD-ować; resztę kieruje do /10x-implement.

skilllekcja q-02 · wyroczniakrok 04 · implementtddtesty
Detal
Po co istnieje
Wariant implementacji dla logiki, którą opłaca się przybić testem, zanim powstanie.
Wejście → wyjście
Wejście: zatwierdzony plan.md. Wyjście: testy plus kod, wspólna sekcja Progress z /10x-implement.
Mechanizm
Red → green → refactor per etap; etapy, których nie da się prowadzić test-first, wracają do /10x-implement.
SKILL

/10x-e2e

testy E2E

Prowadzi przeglądarkowe (E2E) etapy planu na działającej aplikacji, ryzyko po ryzyku: plan → generacja → review → weryfikacja.

skilllekcja q-04 · e2ekrok 04 · implemente2eplaywright
Detal
Po co istnieje
Część ryzyk widać dopiero w przeglądarce - ale tylko tę część; reszta należy do /10x-tdd i /10x-implement.
Wejście → wyjście
Wejście: plan.md z etapami E2E plus zbudowany feature. Wyjście: testy E2E, wspólna sekcja Progress.
Mechanizm
Jedno ryzyko na raz; skill sam odsyła etapy, które nie potrzebują przeglądarki, do tańszych narzędzi.

M4 // LEGACY (10XARCHITECT)

Pytanie: ile kontekstu naraz uniesie agent? Gwarancja: kontekst racjonowany, nie wylewany. Nie „co agent ma wiedzieć?", tylko „co agent ma wiedzieć TERAZ?".

lekcja a-01kontekstfiltrfrakagents.mdcontext/
Detal
Po co istnieje
Okno kontekstu jest zasobem jak woda na pustyni - wylany zapas nie wraca; kontekst trzeba racjonować, nie wylewać.
Wejście → wyjście
Wejście: repozytorium z kontekstem rozlanym po README, wiki i głowach ludzi. Wyjście: lean root AGENTS.md plus context/ jako system-of-record - fakty dociągane na żądanie, nie w jednym przeładowanym prompcie.
Mechanizm
Drabina dojrzałości - od zera do systemu, w którym każda dawka kontekstu ma swoje miejsce i swój moment podania.

Pytanie: jak wygląda teren, zanim wejdziesz? Gwarancja: mapa z dowodów, nie z folderów. Szeroki skan: historia gita, wyszukiwania strukturalne, grafy zależności.

lekcja a-02mapa projektusondywide scangit churn
Detal
Po co istnieje
Struktura folderów kłamie - mapa ma powstać z dowodów: które moduły są deep, a które shallow, co jest core, co peripheral, co load-bearing.
Wejście → wyjście
Wejście: nieznane repozytorium. Wyjście: mapa projektu (pozycja ① raportu) - deep vs shallow, core vs peripheral, load-bearing.
Mechanizm
Równoległe sondy - /10x-research wysyła subagentów, git log i churn pokazują, gdzie projekt naprawdę żyje, a graf zależności - co się zawali, gdy pociągniesz nitkę.

Pytanie: gdzie kod pęka najczęściej? Gwarancja: ryzyko wskazane z dowodów, nie na wyczucie. Hot spot = złożoność × częstość zmian; semantykę domyka deterministyczne CLI.

lekcja a-03hot spotsceresast-grepchange couplingtornhill
Detal
Po co istnieje
Awarie nie rozkładają się równo po repozytorium - wracają w te same miejsca; tam, gdzie skomplikowane spotyka często dotykane, ryzyko rośnie najszybciej.
Wejście → wyjście
Wejście: mapa projektu i jeden feature. Wyjście: przegląd feature’a + hot spots (pozycje ② i ③ raportu) - przepływ danych end-to-end plus lista miejsc, które pękają najczęściej.
Mechanizm
Deterministyczne CLI domyka semantykę - ast-grep znajduje wzorce w składni, code-maat liczy change coupling, observability dokłada dowody z produkcji; agent interpretuje, pomiar jest maszynowy.

Pytanie: jak przebudować bez zatrzymywania maszyny? Gwarancja: każdy krok odwracalny i osobno zielony. Strangler Fig, Branch by Abstraction, Mikado, ADR-y - zamiast big-bangu.

lekcja a-04refaktorstrangler figmikadoadrfowler
Detal
Po co istnieje
Wielki przepisujący skok kończy się katastrofą, bo nie ma z niego drogi powrotu - sekwencja małych, osobno zielonych kroków ma ją zawsze.
Wejście → wyjście
Wejście: hot spot z dowodami i test chroniący zachowanie - napisany, zanim ruszy refaktor. Wyjście: okazje refaktorowe (pozycja ④ raportu) plus ADR-y dokumentujące decyzje.
Mechanizm
Wzorce odwracalności - Strangler Fig (nowe oplata stare, zanim je zastąpi), Branch by Abstraction, metoda Mikado - a /10x-plan tnie ścieżkę na etapy, z których każdy kończy się zielenią albo cofnięciem kroku, nie planu.

Pytanie: czy model mówi językiem domeny? Gwarancja: granice i język, których zespół potrafi bronić. Event Storming, ubiquitous language, bounded contexts, inwarianty.

lekcja a-05dddevent stormingbounded contextubiquitous languageevans
Detal
Po co istnieje
Bounded contexts działają, gdy granice są ostre, a język jednoznaczny - „zamówienie" w magazynie i „zamówienie" w płatnościach to dwa różne pojęcia i mają prawo mieć dwa różne modele.
Wejście → wyjście
Wejście: chaos pojęć zastanej domeny. Wyjście: okazje DDD (pozycja ⑤ raportu) - kandydaci na bounded contexts, glosariusz ubiquitous language, inwarianty, entities vs value objects.
Mechanizm
AI jako coach DDD - agent prowadzi Event Storming, proponuje granice i nazwy, ale to człowiek broni każdej decyzji; model, którego zespół nie potrafi obronić, nie jest modelem, tylko notatką.

M5 // TEAMWORK (10XCHAMPION)

Pytanie: co zbudować, a co kupić? Gwarancja: najmniejsze narzędzie, które zamyka realną lukę. Zostań przy SaaS tam, gdzie niesie odpowiedzialność platformową; buduj wokół lokalnej luki zespołu.

lekcja t-01build vs buypasiarzehelper
Detal
Po co istnieje
Tam, gdzie SaaS niesie odpowiedzialność platformową - auth, billing, compliance - zostajesz przy SaaS; budujesz dopiero wokół luki, której żaden produkt z półki nie zna.
Wejście → wyjście
Wejście: realna luka w przepływie zespołu. Wyjście: najmniejsze narzędzie, które ją zamyka - i decyzja build vs buy podjęta świadomie, nie z rozpędu.
Mechanizm
Zanim powstanie pierwsza linijka, pada pytanie, kto poniesie odpowiedzialność, gdy narzędzie zawiedzie - jeśli platforma, kupujesz; jeśli luka jest wasza, budujesz najmniejszą rzecz, która działa.

Pytanie: z czego składa się agent, gdy zdejmiesz IDE? Gwarancja: agent złożony świadomie, z licznikiem kosztów. Zejście poziom niżej, do prymitywów SDK; koszty i metryki od pierwszego dnia.

lekcja t-02sdkdrużynakosztymetryki
Detal
Po co istnieje
Nowego członka zespołu składasz sam - model, narzędzia, pętla, kontekst - więc rozumiesz jego zachowanie, zamiast ufać czarnej skrzynce.
Wejście → wyjście
Wejście: prymitywy SDK agentowego. Wyjście: agent złożony świadomie, z licznikiem kosztów i metrykami od pierwszego dnia.
Mechanizm
Pierwsze rozwidlenie projektu - ready-made SDK vs assemble-it-yourself - rozstrzyga, ile kontroli potrzebujesz; agent bez licznika to członek zespołu, którego pensji nikt nie zna.

Pytanie: kto pilnuje każdego PR, gdy śpisz? Gwarancja: review na każdym PR, nie tylko gdy masz czas. Agent jako krok pipeline’u, uruchamiany bez Ciebie; severity × impact i triage.

lekcja t-03obserwatorci/cdpipelinepr/10x-impl-review-ci
Detal
Po co istnieje
Przewagę ma stały obserwator: agent widzi każdą zmianę - także PR wysłany o trzeciej w nocy, także ten, którego nie miałbyś siły przeczytać.
Wejście → wyjście
Wejście: PR w repozytorium zespołu. Wyjście: pipeline CI, w którym agent zostawia komentarz na każdym PR - review przestaje zależeć od Twojego kalendarza.
Mechanizm
/10x-impl-review-ci na GitHub Actions ocenia zmiany po severity × impact, a triage odróżnia znaleziska warte poprawki od szumu - recenzent zgłaszający wszystko jest tak samo bezużyteczny jak ten, który nie zgłasza niczego.
LEKCJA

Lekcja 04: Shared AI Registry - skąd zespół bierze wspólne skille?

rejestr paczek: definicja + wydane wersje

Pytanie: skąd zespół bierze wspólne skille? Gwarancja: jedna wersja prawdy zamiast dryfujących kopii. Artefakty AI to kod: jedno źródło prawdy, wersjonowanie, auth, dystrybucja.

lekcja t-04encyklopediarejestrwersjonowanie/10x-contract
Detal
Po co istnieje
Skille, komendy i reguły mają mieć jedno źródło prawdy, wersje i mechanizm dystrybucji - zamiast dryfujących kopii wklejanych między maszynami.
Wejście → wyjście
Wejście: skille i reguły rozproszone po komputerach zespołu. Wyjście: rejestr paczek - repo z definicją paczki, wydanymi wersjami i auth, z którego każdy instaluje tę samą prawdę.
Mechanizm
Install / update / uninstall jak w menedżerze pakietów, z dostarczaniem do wielu narzędzi - kanał dystrybucji dobierasz według audytorium, nie według efektowności demo.
LEKCJA

Lekcja 05: Async i remote agents - jak delegować pracę na odległość?

zadanie delegowane zdalnie + raport w review

Pytanie: jak delegować pracę na odległość? Gwarancja: granice ustawione, zanim agent ruszy, kontrola wraca w review. Delegacja z odroczoną kontrolą: sandbox, granice sieci i sekretów przed startem.

lekcja t-05flotaasyncsandboxremotemonitoring
Detal
Po co istnieje
Rozkazy idą przed bitwą - w trakcie nikt już nie negocjuje zasięgu dział; granice sieci i sekretów ustawia się, zanim agent wystartuje.
Wejście → wyjście
Wejście: zadanie, które nie wymaga Twojej obecności. Wyjście: agent pracujący zdalnie w sandboxie z jawnie zakreślonymi granicami - i raport, który wraca do review.
Mechanizm
Odpowiedzialność nie znika z delegacją, tylko zmienia moment - wraca w monitoringu i review; kontrolujesz wynik, nie każdy ruch.
SKILL

/10x-impl-review-ci

impl-review.md + komentarz na PR

Uruchamia review implementacji nieinterakcyjnie w CI na PR: znajduje plan, sprawdza dryf, bezpieczeństwo, wzorce i pokrycie testami, commituje raport na branch PR i zostawia komentarz z podsumowaniem.

skilllekcja t-03 · review w cici/cdgithub actionspr
Detal
Po co istnieje
Review na każdym PR bez człowieka w pętli - CI-owa wersja /10x-impl-review, stały obserwator zespołu.
Wejście → wyjście
Wejście: PR z planem w context/changes/<change-id>/. Wyjście: reviews/impl-review.md zacommitowany na branch PR plus komentarz z podsumowaniem.
Mechanizm
Nieinterakcyjny przebieg w GitHub Actions (Claude Code Action): odnajduje plan, porównuje dryf, bezpieczeństwo, wzorce i pokrycie testami.
SKILL

/10x-contract

contract-surfaces.md

Rejestruje nośne nazwy i schematy (kontrakty) w docs/reference/contract-surfaces.md - powierzchnie, których zmiana łamie konsumentów w dole strumienia.

skilllekcja t-04 · registrykontraktywersjonowanie
Detal
Po co istnieje
Wspólne artefakty żyją dłużej niż sesja - zmiana nośnej nazwy lub schematu łamie cudzy kod, więc kontrakt musi być zarejestrowany.
Wejście → wyjście
Wejście: świeżo utworzony lub rozpoznany wiążący kontrakt (nazwa, schemat). Wyjście: wpis w docs/reference/contract-surfaces.md.
Mechanizm
Rejestr powierzchni kontraktowych czytany przed refaktorami - zmiana przechodzi świadomie, z wersją, nie przypadkiem.

BRAK WYNIKÓW // ZMIEŃ FRAZĘ ALBO FILTRY