Od pomysłu do rampy startowejpierwszego wdrożenia

Głowa łańcucha bootstrapu: zamienia „mam pomysł" (greenfield) albo „chcę zmienić ten system" (brownfield) w ustrukturyzowane notatki, z których /10x-prd wygeneruje PRD zgodny z zablokowanym schematem. Skill jest facylitatorem, nie generatorem - nigdy nie pisze wizji, wymagań ani reguł biznesowych, których użytkownik nie powiedział; jego wartość to kształt i kolejność pytań.

Wejście: pomysł w wolnej formie - inline, plik z notatkami albo rozmowa. Wyjście: context/foundation/shape-notes.md z checkpointem we frontmatterze (bieżący etap, etapy ukończone, liczba zebranych wymagań), więc sesję można przerwać i wznowić od następnego etapu zamiast od zera. Na koniec komenda /10x-prd trafia do schowka.

Każdy etap odkrywczy idzie tą samą pętlą:

• otwarcie etapu jednym pytaniem otwartym - pierwszą wersję treści daje użytkownik,
• 3-5 „szarych stref" jako decyzje z realnymi opcjami i kompromisami,
• jedna opcja oznaczona jako rekomendowana plus zawsze opcja „nie wiem",
• potwierdzenie decyzji jednym zdaniem i dopiero wtedy zapis etapu na dysk.

Tryb wykrywany automatycznie z katalogu, na podstawie trzech poziomów sygnałów: historia gita (silny), lockfile (silny), sam manifest (niejednoznaczny - może być świeży npm init). Brownfield dodaje sekcję o istniejącym systemie i pytanie „co NIE może się zepsuć", a potwierdzony context_type steruje dalszym routingiem /10x-prd.

Trzy twarde reguły: nie generuje treści, których użytkownik nie powiedział; nigdy nie przesądza stacku (framework, baza, hosting - to decyzje kroków za /10x-prd); wymaga zainicjalizowanego context/foundation/ - jeśli go brakuje, deleguje scaffold do /10x-init.

Ogon łańcucha bootstrapu (/10x-shape → /10x-prd → /10x-tech-stack-selector → /10x-bootstrapper). Jedno zadanie: zamienić zapisany handoff tech-stacku w projekt postawiony ze startera w bieżącym katalogu, z logiem weryfikacji do przejrzenia. Z rejestru starterów tylko korzysta - startery definiuje /10x-tech-stack-selector.

Wejście: context/foundation/tech-stack.md - twardy warunek wstępny. Bez tego pliku skill odmawia i odsyła do /10x-tech-stack-selector; nie zastąpi go nawet stack omówiony wcześniej w rozmowie - kontraktem jest plik na dysku. Wyjście: pliki projektu z oficjalnego startera plus context/changes/bootstrap-verification/verification.md jako ślad audytowy przebiegu.

Cztery kroki:

• powtórzenie wczytanego handoffu do potwierdzenia lub korekty,
• lekki test świeżości startera (wersja paczki, ostatni push repo) - ostrzega, nie blokuje,
• uruchomienie szablonu komendy oficjalnego CLI według jednej z trzech strategii pracy w katalogu,
• audyt zależności po scaffoldzie z podziałem CRITICAL / HIGH / MODERATE / LOW.

context/ jest zawsze zachowany - scaffold nigdy go nie nadpisze. Istniejące pliki w konflikcie dostają siostrzany plik .scaffold, a .gitignore jest scalany przez dopisanie. Niezerowy kod wyjścia CLI to twardy stop: katalog tymczasowy zostaje do inspekcji, a częściowy log weryfikacji trafia na dysk.

Nie generuje AGENTS.md / CLAUDE.md (to temat onboardingu agenta), nie robi git init, nie naprawia automatycznie znalezisk audytu - informuje, decyzja należy do człowieka.

Generuje AGENTS.md - dokument onboardingowy dla agentów AI pracujących w repozytorium. Krótki, specyficzny dla projektu i uporządkowany według wpływu: najcięższe reguły i najczęściej używane komendy na górze, tak żeby świeży agent przeczytał raz i dalej się nie blokował.

Wejście: samo repo - manifest, README, konfiguracje lint/test, układ katalogów i 30 ostatnich commitów (stąd konwencja komunikatów commitów). Wyjście: AGENTS.md o budżecie 200-400 słów (120-250 dla wariantu katalogowego), z referencjami @ścieżka/do/pliku zamiast wklejek konfiguracji.

Gdy plik już istnieje, skill nie nadpisuje. Datuje go przez git log, porównuje stan repo od ostatniej edycji i klasyfikuje każdą linię: KEEP / UPDATE / REMOVE / MISSING. Potem edytuje chirurgicznie - po zatwierdzeniu listy zmian przez użytkownika - zamiast przepisywać od zera.

Pięć twardych bramek przed zapisem:

• budżet długości - za krótko znaczy brak konkretów, za dużo znaczy wata,
• zero wielolinijkowych snippetów - zamiast nich referencja do pliku,
• każda reguła sprawdzalna na diffie (odpada „clean code" i „best practices"),
• zero wiedzy, którą model i tak wyniósł z treningu,
• reguły krytyczne w pierwszej jednej trzeciej pliku.

Nie wymyśla faktów o projekcie - każde zdanie musi mieć pokrycie w obejrzanym pliku, komendzie albo commicie. Nie powtarza domyślnych ustawień frameworka ani tutoriali języka; tylko wiedza specyficzna dla projektu zasługuje na linię.

Bramka gotowości do wdrożenia na PaaS (Cloudflare, Vercel, Netlify, Fly.io, Railway, Render). Bierze działające repo, klasyfikuje je, dobiera platformę i przepuszcza przez realny preflight - zanim pierwszy deploy zderzy się z limitami platformy w produkcji.

Wejście: repo (zawsze źródło prawdy) plus wskazówki z tech-stack.md i prd.md, jeśli istnieją - przy rozjeździe dokumentu z kodem wygrywa kod, a rozbieżność trafia do raportu. Wyjście: context/foundation/deploy-readiness.md plus minimalny natywny config platformy (wrangler.toml, fly.toml, Dockerfile, workflow GHA - zależnie od toru).

Repo trafia do jednego z sześciu torów (static, edge-js, node-server, container, job, hybrid) na podstawie sygnałów z kodu, nie deklaracji użytkownika. Adapter frameworka potrafi zablokować wybór platformy (config pod inną po prostu by nie działał), a limity platformy są pobierane z jej dokumentacji w momencie uruchomienia - z cytowanym adresem i znacznikiem czasu.

Każde sprawdzenie kończy się jako pass / warn / block, a dowolny block zatrzymuje emisję configów. Uniwersalnie: .gitignore kryje .env, skan sekretów śledzonych przez gita, pokrycie zmiennych środowiskowych względem .env.example. Torowo: build przechodzi, rozmiar bundla lub obrazu kontra limit, zakazane API Node w bundlu edge, healthcheck w kontenerze.

To generator dokumentu i configów, nie deployer - nie pushuje obrazów, nie ustawia sekretów w repo, nie odpala deployu za plecami. Tryb prowadzony (CLI lub MCP) wykonuje kroki wyłącznie z potwierdzeniem per krok, a wartości sekretów nigdy nie przechodzą przez pamięć skilla ani żaden zapisywany plik.