Biblioteka
Prompt to konkretna instrukcja dla modelu, która prowadzi do konkretnego efektu. Dobre prompty są opinionated i wąsko ograniczone: dają modelowi rolę, format, i furtkę bezpieczeństwa gdy nie wie. Pomyśl o każdym jak o krótkim kontrakcie — Ty wiesz o co prosiłeś, model wie co jest Ci winien. Prompty w tej bibliotece to pobieralne pliki .md z YAML frontmatter: wrzuć do czatu albo skopiuj treść do własnego workflow. Nic nie jest przywiązane do Claude — te same kontrakty działają z każdym sensownym modelem.
Ritual startu nowej sesji Claude Code. 5 minut czytania przed dotknięciem czegokolwiek — w ustalonej kolejności. Rozwiązuje "cold start bias": agent skacze do kodu zanim zrozumie stan. Lista źródeł prawdy, kolejność, checklista infra.
Trzy ścieżki podejmowania decyzji: (1) jedna sensowna opcja → propozycja + "widzisz luki?", (2) 2-3 realne opcje → klasyczny format 3-liniowy + TL;DR, (3) > 3 opcje → zawęź. Eliminuje sztuczne A/B/C i mnożenie wariantów ponad potrzebę, ale zachowuje dyscyplinę dla prawdziwych decyzji.
Główny manifest working mode dla Claude Code w rozbudowanych projektach. Neutralna wersja osobistego harness'u z projektu GroqeSTT — auto-loaded w CLAUDE.md na starcie każdej sesji. Zawiera diagnozę typowych wad agenta, zasady nienegocjowalne, check-listy przed/w trakcie/po tasku, red flags, stery użytkownika oraz taksonomię dokumentów.
Dopracowany prompt do bezpiecznej instalacji OpenClaw na wyizolowanym serwerze Linux. Obejmuje threat model oparty o audyty Microsoft, Kaspersky, Cisco Talos i CrowdStrike, hardening konfiguracji, sandboxing i pełny plan krok-po-kroku. Uwaga na świeżość — aktualne na moment tworzenia (Q1 2026), wersje CVE mogą się zmienić.
Pętla Buduj → Krytykuj → Dopracuj na wypadek, gdy „wystarczająco dobre" nie wystarczy. Zamiast liczyć na idealny pierwszy output, planuj 2-3 iteracje od początku. Każda runda ma konkretny fokus: pierwsza na strukturę i poprawność, druga na jakość i edge case'y, trzecia na szlif i wydajność. Działa dla kodu, pisania, architektury i designu.
Napisz specyfikację zanim napiszesz kod. Ten prompt wymusza pętlę spec → plan → build → weryfikacja, która zapobiega pełzaniu zakresu, dryftowi architektonicznemu i sytuacjom „działa, ale nie tak jak chcieliśmy." Specyfikacja jest kontraktem między tym, czego chcesz a tym, co zostanie zbudowane. Każda decyzja implementacyjna odwołuje się do wymagania w specyfikacji.
Strategia zarządzania długimi sesjami AI bez utraty kontekstu lub jakości. Obejmuje kiedy kompaktować, jak strukturyzować checkpointy, co trzymać w kontekście vs. zrzucić do plików i jak przekazywać między sesjami. Zapobiega problemowi „zapomniało co robiliśmy" i degradacji „ostatnie 20% kontekstu daje gorszy output".
Systematyczna metoda szybkiego zrozumienia nieznanego codebase'u. Zamiast czytać kod od góry do dołu, śledź przepływ danych: punkty wejścia → routing → logika biznesowa → warstwa danych → integracje zewnętrzne. Tworzy mapę architektury, listę kluczowych abstrakcji i przewodnik „gdzie szukać" w mniej niż 30 minut. Działa dla dowolnego stacku.
Wzorzec dekompozycji złożonych zadań na równoległą pracę agentów. Zamiast jednego AI robiącego wszystko sekwencyjnie, podziel pracę na niezależne strumienie działające jednocześnie. Obejmuje dekompozycję zadań, mapowanie zależności, briefing agentów, syntezę wyników i rozwiązywanie konfliktów. Zamienia 4-godzinną sekwencyjną pracę w 30-minutową równoległą egzekucję.
Wzorzec dwóch wątków do pracy z AI: jeden wątek buduje, drugi audytuje. Prowadź sesję dev i równoległą sesję review na tym samym codebase. Wątek dev implementuje funkcje; wątek audytu łapie bugi, problemy bezpieczeństwa i dryft architektoniczny w czasie rzeczywistym. Daje wyższą jakość kodu niż sekwencyjne buduj-potem-recenzuj, bo reviewer ma zerowe zanieczyszczenie kontekstem.