Szkicownik Makiet HTML

Sketch

Używaj tej umiejętności, gdy użytkownik chce zobaczyć kierunek projektowania przed podjęciem decyzji — eksplorując pomysł UI/UX jako jednorazowe makiety HTML. Celem jest wygenerowanie 2-3 interaktywnych wariantów, aby użytkownik mógł porównać kierunki wizualne obok siebie, a nie tworzenie kodu gotowego do wdrożenia.

Załaduj to, gdy użytkownik mówi rzeczy takie jak „naszkicuj ten ekran”, „pokaż mi, jak X mógłby wyglądać”, „porównaj układ A z B”, „daj mi 2-3 ujęcia tego UI”, „pokaż mi kilka wariantów”, „stwórz makietę zanim zacznę budować”.

Kiedy NIE używać

• Użytkownik chce komponentu produkcyjnego — użyj claude-design lub zbuduj to poprawnie
• Użytkownik chce dopracowanego jednorazowego artefaktu HTML (strona docelowa, prezentacja) — claude-design
• Użytkownik chce diagramu — excalidraw, architecture-diagram
• Projekt jest już zamknięty — po prostu go zbuduj

Jeśli użytkownik ma zainstalowany pełny system GSD

Jeśli gsd-sketch pojawia się jako umiejętność siostrzana (zainstalowana przez npx get-shit-done-cc --hermes), preferuj gsd-sketch dla pełnego przepływu pracy: trwałe .planning/sketches/ z MANIFESTEM, analiza w trybie frontier, audyty spójności w poprzek wcześniejszych szkiców oraz integracja z resztą GSD. Ta umiejętność to lekka, samodzielna wersja — jednorazowe szkicowanie bez mechanizmu stanu.

Główna metoda

wprowadzenie  →  warianty  →  zestawienie bezpośrednie  →  wybór zwycięzcy (lub iteracja)

1. Wprowadzenie (pomiń, jeśli użytkownik już podał wystarczająco dużo)

Przed wygenerowaniem wariantów, uzyskaj trzy rzeczy — po jednym pytaniu na raz, nie wszystkie naraz:

1. Odczucie. „Jakie to powinno mieć odczucie? Przymiotniki, emocje, klimat.” — „spokojne, redakcyjne, jak Linear” mówi więcej niż „minimalistyczne”.
2. Referencje. „Jakie aplikacje, strony lub produkty oddają odczucie, które sobie wyobrażasz?” — rzeczywiste referencje przewyższają abstrakcyjne opisy.
3. Główna akcja. „Jaka jest najważniejsza rzecz, którą użytkownik robi na tym ekranie?” — warianty powinny to dobrze obsługiwać; jeśli nie, są tylko ozdobą.

Krótko odnieś się do każdej odpowiedzi przed następnym pytaniem. Jeśli użytkownik podał wszystkie trzy od razu, przejdź bezpośrednio do wariantów.

2. Warianty (2-3, nigdy 1, rzadko 4+)

Wyprodukuj 2-3 warianty w jednym przebiegu. Każdy wariant to kompletny, samodzielny plik HTML. Nie opisuj wariantów — zbuduj je. Chodzi o porównanie.

Każdy wariant powinien przyjmować inne nastawienie projektowe, a nie różne wartości pikseli. Trzy dobre osie wariantów:

• Gęstość: zwarte / przestronne / supergęste (wybierz dwa kontrastujące bieguny)
• Nacisk: treść przede wszystkim / akcja przede wszystkim / narzędzie przede wszystkim
• Estetyka: redakcyjne / utylitarne / zabawne
• Układ: jednokolumnowy / panel boczny / podzielony panel
• Uziemienie: oparte na kartach / surowa treść / styl dokumentu

Wybierz jedną oś i odciągnij od niej. Dwa warianty różniące się tylko kolorem akcentu to zmarnowany wysiłek — użytkownik nie może ich rozróżnić.

Nazewnictwo wariantów: opisz nastawienie, nie numer.

sketches/
├── 001-spokojne-redakcyjne/
│   ├── index.html
│   └── README.md
├── 001-utylitarne-zwarte/
│   ├── index.html
│   └── README.md
└── 001-zabawne-podzielone/
    ├── index.html
    └── README.md

3. Zrób z tego prawdziwy HTML

Każdy wariant to pojedynczy samodzielny plik HTML:

• Wbudowany <style> — bez kroku budowania, bez zewnętrznego CSS
• Czcionki systemowe lub jedna Google Font przez <link>
• Tailwind przez CDN (<script src="https://cdn.tailwindcss.com"></script>) jest w porządku
• Realistyczna fałszywa treść — rzeczywiste zdania, rzeczywiste nazwy, nie „Lorem ipsum”
• Interaktywny: klikalne linki, działające stany hover, co najmniej jedno przejście stanu (otwórz/zamknij, filtruj, przełącz). Zamrożony statyczny obraz jest gorszą próbą niż niechlujna animowana.

Otwórz to w przeglądarce. Jeśli wygląda to źle, napraw to przed pokazaniem użytkownikowi.

Weryfikuj warianty wizualnie — użyj narzędzi przeglądarki Hermesa. Nie tylko pisz HTML i licz, że się wyrenderuje; załaduj każdy wariant i spójrz na niego:

browser_navigate(url="file:///absolute/path/to/sketches/001-spokojne-redakcyjne/index.html")
browser_vision(question="Czy ten układ wygląda na czysty i czytelny? Czy są jakieś widoczne błędy (nakładający się tekst, nieostylowane elementy, uszkodzone obrazy)?")

browser_vision zwraca opis AI tego, co faktycznie jest na stronie, plus ścieżkę zrzutu ekranu — wyłapuje błędy układu, które pomija czysta inspekcja źródła (np. import czcionki, który cicho zawiódł, kontener flex, który się zwinął). Naprawiaj i nawiguj ponownie, aż każdy wariant będzie wyglądał dobrze.

Domyślny reset CSS + stos czcionek systemowych na szybki start:

<style>
  * { box-sizing: border-box; margin: 0; padding: 0; }
  body {
    font-family: -apple-system, BlinkMacSystemFont, „Segoe UI”, Roboto,
                 „Helvetica Neue”, Arial, sans-serif;
    -webkit-font-smoothing: antialiased;
    color: #1a1a1a;
    background: #fafafa;
    line-height: 1.5;
  }
</style>

4. README wariantu

README.md każdego wariantu odpowiada na:

## Wariant: {nazwa nastawienia}

### Nastawienie projektowe
Jedno zdanie o zasadzie napędzającej ten wariant.

### Kluczowe wybory
- Układ: ...
- Typografia: ...
- Kolor: ...
- Interakcja: ...

### Kompromisy
- Mocne strony: ...
- Słabe strony: ...

### Najlepszy dla
- Rodzaj użytkownika lub przypadek użycia, któremu ten wariant faktycznie służy

5. Zestawienie bezpośrednie

Po zbudowaniu wszystkich wariantów, przedstaw je jako porównanie. Nie tylko wymieniaj — wyraź opinię:

## Trzy ujęcia ekranu głównego

| Wymiar | Spokojne redakcyjne | Utylitarne zwarte | Zabawne podzielone |
|-----------|----------------|-------------------|---------------|
| Gęstość   | Niska            | Wysoka              | Średnia        |
| Widoczność głównej akcji | Niska | Wysoka | Średnia |
| Skanowalność | Wysoka | Średnia | Niska |
| Odczucie | Spokojne, zaufane | Ostre, narzędziowe | Zapraszające, energetyczne |

**Moja opinia:** Utylitarne zwarte dla zaawansowanych użytkowników, spokojne redakcyjne dla odbiorców skoncentrowanych na treści. Zabawne podzielone jest najsłabsze — próbuje robić jedno i drugie, a nie angażuje się w żadne.

Pozwól użytkownikowi wybrać zwycięzcę, lub połącz dwa w hybrydę, albo poproś o kolejną rundę.

Tematyzacja (gdy projekt ma tożsamość wizualną)

Jeśli użytkownik ma istniejący motyw (kolory, czcionki, tokeny), umieść wspólne tokeny w sketches/themes/tokens.css i zaimportuj je w każdym wariancie. Utrzymaj tokeny minimalnie:

/* sketches/themes/tokens.css */
:root {
  --color-bg: #fafafa;
  --color-fg: #1a1a1a;
  --color-accent: #0066ff;
  --color-muted: #666;
  --radius: 8px;
  --font-display: „Inter”, sans-serif;
  --font-body: -apple-system, BlinkMacSystemFont, sans-serif;
}

Nie przesadzaj z tokenizacją jednorazowego szkicu — trzy kolory i jedna czcionka zwykle wystarczą.

Poprzeczka interaktywności

Szkic jest wystarczająco interaktywny, gdy użytkownik może:

1. Kliknąć główną akcję i coś widocznego się dzieje (zmiana stanu, modal, toast, pozorowana nawigacja)
2. Zobaczyć jedno znaczące przejście stanu (filtrowanie listy, przełączanie trybu, otwieranie/zamykanie panelu)
3. Najechać na rozpoznawalne afordancje (przyciski, wiersze, karty)

Więcej niż to to nadmierna inżynieria dla jednorazówki. Mniej niż to to zrzut ekranu.

Tryb frontier (wybieranie, co naszkicować dalej)

Jeśli szkice już istnieją, a użytkownik mówi „co powinienem naszkicować dalej?”:

• Luki spójności — dwa zwycięskie warianty z różnych szkiców dokonały niezależnych wyborów, które nie zostały jeszcze ze sobą skomponowane
• Nienaszkicowane ekrany — wspomniane, ale nigdy niezbadane
• Pokrycie stanów — naszkicowano ścieżkę szczęśliwą, ale nie pustą / ładowanie / błąd / 1000 elementów
• Luki responsywności — zweryfikowano w jednym widokowym obszarze; czy trzyma się na urządzeniu mobilnym / ultraszerokim?
• Wzorce interakcji — istnieją układy statyczne; przejścia, przeciąganie, zachowanie przewijania nie

Zaproponuj 2-4 nazwanych kandydatów. Pozwól użytkownikowi wybrać.

Wyjście

• Utwórz sketches/ (lub .planning/sketches/ jeśli użytkownik stosuje konwencje GSD) w korzeniu repozytorium
• Jeden podkatalog na wariant: NNN-nazwa-nastawienia/index.html + README.md
• Powiedz użytkownikowi, jak je otworzyć: open sketches/001-spokojne-redakcyjne/index.html na macOS, xdg-open na Linuxie, start na Windowsie
• Utrzymuj warianty jako jednorazowe — szkic, który poczułeś potrzebę zachowania, powinien być awansowany do rzeczywistego kodu projektu, a nie kuratorowany jako zasób

Typowa sekwencja narzędzi dla jednego wariantu:

terminal("mkdir -p sketches/001-spokojne-redakcyjne")
write_file("sketches/001-spokojne-redakcyjne/index.html", "<!doctype html>...")
write_file("sketches/001-spokojne-redakcyjne/README.md", "## Wariant: Spokojne redakcyjne\n...")
browser_navigate(url="file://$(pwd)/sketches/001-spokojne-redakcyjne/index.html")
browser_vision(question="Jak to wygląda? Jakieś oczywiste problemy z układem?")

Powtórz dla każdego wariantu, a następnie przedstaw tabelę porównawczą.

Atrybucja

Zaadaptowano z przepływu pracy /gsd-sketch projektu GSD (Get Shit Done) — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). Pełny system GSD dostarcza trwały stan szkicu, referencje motywów/wariantów oraz przepływy pracy audytu spójności; zainstaluj przez npx get-shit-done-cc --hermes --global.