Document

Kiedy uzywac

Uruchom /impeccable document, gdy masz juz wystarczajaco duzo systemu wizualnego do udokumentowania: kolory, typografia, przynajmniej przycisk i karta. Komenda skanuje twoja baze kodu, wyciaga znalezione tokeny i wzorce komponentow i pisze DESIGN.md w korzeniu projektu, ktory podaza za formatem Google Stitch DESIGN.md, szesc sekcji w stalym porzadku, interoperacyjny z kazdym innym narzedziem DESIGN.md-aware.

Sigmnij po to, gdy:

• Wlacznie uruchomiles /impeccable teach i PRODUCT.md juz istnieje. Document to dopasowany plik wizualny.
• Komenda skierowala cie do niego. Live, craft i polish czytaja DESIGN.md. Jesli go brakuje, umiejetnosc sugeruje uruchomienie document najpierw.
• Projekt odjechal od starszego DESIGN.md i plik juz nie opisuje zyjqcego systemu.
• Przed duzym przeprojektowaniem, aby uchwycic aktualny stan jako referencje dla nastepnego kierunku.

Dla projektow jeszcze bez kodu (swiezy przebieg teach, nic nie zbudowane), istnieje tryb zalążkowy: /impeccable document --seed zadaje piec szybkich pytan strategicznych (strategia kolorow, kierunek typografii, energia ruchu, referencje, antyreferencje) i pisze szkielet. Ponownie uruchom w trybie skanowania, gdy pojawi sie kod.

Jak to dziala

Przebieg skanowania znajduje zasoby projektowe w kolejnosci priorytetu: CSS custom properties, konfiguracja Tailwind, motywy CSS-in-JS, pliki tokenow projektowych, zrodlo komponentow, globalny stylesheet i na koniec obliczone style z wyrenderowanego wyniku, jesli przegladarka jest dostepna. Automatycznie wyciaga wszystko, co sie da, potem zadaje jedno zgrupowane pytanie dla czesci, ktore potrzebuja kreatywnego wejscia: Kreatywna Gwiazda Polarna (pojedyncza nazwana metafora dla calego systemu, jak “Sanktuarium Redakcyjne”), opisowe nazwy kolorow, filozofia elewacji i charakter komponentow.

Wynikiem jest DESIGN.md z dokladnie szescioma sekcjami: Overview, Colors, Typography, Elevation, Components, Do’s and Don’ts. Naglowki sa stale znak-po-znaku, aby plik byl parsowalny przez inne narzedzia. Obok, DESIGN.json jest zapisany jako czytelny maszynowo sidecar. Ten sidecar to, czego uzywa panel projektowy live-mode do renderowania tego projektu faktycznych kafelkow przyciskow, pol wejsciowych, nawigacji i kart zamiast generycznej aproksymacji.

Kazda inna komenda czyta DESIGN.md przy wywolaniu. Warianty, polerowania, audyty i nowe funkcje dziedzicza system wizualny bez bycia informowanym.

Wyprobuj

/impeccable document

Na projekcie z juz zdefiniowanymi tokenami, to zajmuje okolo dwie minuty: skan znajduje twoja palete i stos typograficzny, wybierasz Gwiazde Polarna z 2 lub 3 opcji, potwierdzasz opisowe nazwy kolorow (“Gluchy Tonowany Morsko-Niebieskawy”, nie “niebieski-800”) i plik lduje w korzeniu projektu.

Na swiezym projekcie:

/impeccable document --seed

Piec pytan, okolo pieciu minut. Plik jest szkieletem, oznaczony komentarzem <!-- SEED -->, wiec jest szczery o tym, czym jest. Ponownie uruchom bez flagi, gdy zaimplementujesz tokeny.

Pulapki

• Uruchamianie zbyt wczesnie. Na projekcie bez zaimplementowanych tokenow, tryb seed jest wlasciwy. Nie fabrykuj pelnej specyfikacji, ktorej kod nie moze potwierdzic. Falszywy DESIGN.md jest gorszy niz brak DESIGN.md.
• Traktowanie DESIGN.md jako dokumentacji tylko dla ludzi. To jest glownie dla AI. Kazda inna komenda to czyta. Stanowczosc formatu (“nigdy”, “zawsze”, Nazwane Zasady) jest celowa.
• Dodawanie sekcji najwyzszego poziomu Layout / Motion / Responsive. Specyfikacja ma szesc sekcji, w stalym porzadku, ze stalymi nazwami. Wloz tresc o ukladzie lub ruchu do Overview (zasady na poziomie filozofii) lub Components (zachowanie per komponent).
• Nadpisywanie istniejacego DESIGN.md po cichu. Document zawsze potwierdza najpierw. Jesli chcesz zaczac od nowa, zmien nazwe istniejacego pliku lub wprost powiedz umiejetnosci, by nadpisac.