Imported from zawszetujestem/soma-learn (.github/skills/10x-plan/SKILL.md). Install upstream with npx skills add zawszetujestem/soma-learn --skill 10x-plan. Copyright stays with the author.


# Plan implementacji

Twoim zadaniem jest tworzenie szczegółowych planów implementacji poprzez interaktywny, iteracyjny proces. Powinieneś być sceptyczny, dokładny i współpracować z użytkownikiem, aby tworzyć wysokiej jakości specyfikacje techniczne.

## Początkowa odpowiedź

Po wywołaniu tej komendy:

1. **Sprawdź, czy podano parametry**:
   - Jeśli jako parametr podano ścieżkę pliku lub odniesienie do zgłoszenia, pomiń domyślną wiadomość
   - Natychmiast przeczytaj WSZYSTKIE podane pliki
   - Rozpocznij proces badawczy

2. **Jeśli nie podano parametrów**, odpowiedz:

Pomogę Ci stworzyć szczegółowy plan implementacji. Zacznijmy od zrozumienia, co budujemy.

Proszę podać:

Opis zadania/zgłoszenia (lub odniesienie do pliku zgłoszenia)
Wszelkie istotne konteksty, ograniczenia lub specyficzne wymagania
Linki do powiązanych badań lub poprzednich implementacji

Im więcej kontekstu dostarczysz, tym mniej pytań zadam:

Tylko opis zadania → pełne pytania
Zadanie + dokument badawczy (context/changes/<change-id>/research.md) → mniej pytań; nie będę powtarzać tego, co zostało omówione w badaniach
Zadanie + brief ramowy (context/changes/<change-id>/frame.md) → znacznie mniej pytań; problem został już sformułowany
Zadanie + ramka + badania → minimalne pytania; skupiam się tylko na decyzjach dotyczących projektowania rozwiązania, które wymagają Twojego wkładu

Wskazówka: wywołaj bezpośrednio z change-id lub ścieżką — /10x-plan oauth-login lub /10x-plan @context/changes/oauth-login/frame.md Aby uzyskać głębszą analizę, spróbuj: /10x-plan think deeply about @context/changes/oauth-login/research.md


Następnie poczekaj na dane wejściowe od użytkownika.

## Kroki procesu

### Krok 1: Gromadzenie kontekstu i wstępna analiza

#### Krok 1.0: Identyfikacja artefaktów upstream i skalowanie głębokości pytań

Przed jakimkolwiek czytaniem, zidentyfikuj, jakie rodzaje artefaktów upstream przekazał użytkownik. Każdy z nich reprezentuje już podjęte decyzje — nie pytaj o nie ponownie.

- **Frame brief** — ścieżka pasuje do `context/changes/<change-id>/frame.md`, lub zawartość zaczyna się od `# Frame Brief:` / zawiera sekcję `## Reframed`.
- **Research doc** — ścieżka pasuje do `context/changes/<change-id>/research.md`, lub YAML frontmatter zawiera pola `topic:` i `researcher:`.
- **Existing plan** — ścieżka pasuje do `context/changes/<change-id>/plan.md` (tryb wznowienia/dopracowania — poza zakresem tej logiki skalowania).
- **Task description only** — żadne z powyższych.

**Liczba pytań i skala skupienia zmieniają się w zależności od dostarczonych informacji:**

| Artefakty upstream          | NISKI | ŚREDNI | WYSOKI | Co się zmienia w porównaniu do bazowego                                                                                                              |
| --------------------------- | ----- | ------ | ----- | -------------------------------------------------------------------------------------------------------------------------------------- |
| Tylko zadanie (bazowe)        | 4–6   | 7–10   | 11–15 | Pełne pytania we wszystkich odpowiednich kategoriach.                                                                                       |
| Zadanie + badania             | 3–5   | 5–7    | 8–11  | Pomiń pytania, których odpowiedź znajduje się już w dokumencie badawczym. Nie odradzaj podagentów, aby znaleźć to, co już zostało zmapowane w badaniach.            |
| Zadanie + ramka                | 2–3   | 4–6    | 7–9   | Pomiń kategorie [D]iagnostyczne — ramka ustaliła ramy problemu. Traktuj Przeformułowane (lub Potwierdzone) Oświadczenie o Problemie jako autorytatywne.    |
| Zadanie + ramka + badania     | 1–2   | 3–5    | 5–7   | Pomiń oba. Zadawaj tylko pytania dotyczące projektowania rozwiązania [S], które naprawdę wymagają wkładu użytkownika.                                                        |

**Zasada**: każdy przekazany artefakt jest źródłem już podjętych decyzji. Czytanie ich jest równoznaczne ze słuchaniem użytkownika. Nie pytaj użytkownika o to, co już napisał.

**Gdy obecna jest ramka**, przeczytaj ją W CAŁOŚCI i traktuj jako autorytatywną:
- Skopiuj **Zgłoszoną Obserwację** + **Przeformułowane (lub Potwierdzone) Oświadczenie o Problemie** jako definicję zadania. Nie kwestionuj ponownie ram.
- Przenieś tabelę **Badanie Hipotez** i **Sygnały Zwężające** do swojej "Analizy Stanu Obecnego" — ta praca jest już wykonana.
- Jeśli ramka **Confidence: LOW** jest oznaczona, uwzględnij to w "Otwartych Ryzykach i Założeniach" planu i zadaj JEDNO pytanie wyjaśniające, jak postępować (najpierw zweryfikuj, lub planuj z uwzględnieniem ryzyka).
- NIE badaj ponownie ram. Ramka odpowiada za sformułowanie problemu; Ty odpowiadasz za projekt rozwiązania.

**Gdy obecne są badania**, przeczytaj je W CAŁOŚCI i użyj jako bazę kodu:
- Sekcja "Code References" JEST Twoim ugruntowaniem bazy kodu — nie odradzaj agentów Explore, aby znaleźć te same pliki.
- "Architecture Insights" bezpośrednio zasilają "Current State Analysis".
- Odradzaj podagentów tylko w celu uzupełnienia konkretnych luk, których badania nie objęły (np. dokładne pliki, które ten plan zmodyfikuje, jeśli badania były szersze).

#### Krok 1.1: Czytanie i badania

1. **Natychmiast i W CAŁOŚCI przeczytaj wszystkie wymienione pliki**:
   - Pliki referencyjne (np. `context/changes/<change-id>/research.md`, `context/changes/<change-id>/frame.md`)
   - Dokumenty badawcze
   - Briefy ramowe
   - Powiązane plany implementacji
   - Wszelkie wymienione pliki JSON/danych
   - `context/foundation/lessons.md`, jeśli istnieje — traktuj jego zasady jako priorytety podczas badania zakresu, przypadków brzegowych i wyborów architektonicznych; zasady już zaakceptowane przez zespół zawężają, które pułapki projektowe nadal wymagają świeżego kwestionowania.
   - **WAŻNE**: Czytaj pliki BEZ parametrów limit/offset, aby przeczytać całe pliki
   - **KRYTYCZNE**: NIE twórz podzadań przed samodzielnym przeczytaniem tych plików w głównym kontekście
   - **NIGDY** nie czytaj plików częściowo — jeśli plik jest wymieniony, przeczytaj go w całości

2. **Utwórz początkowe zadania badawcze w celu zebrania kontekstu** (pomiń lub zawęź na podstawie Kroku 1.0):
   Zanim zadasz użytkownikowi jakiekolwiek pytania, użyj narzędzia Task z równoległymi podagentami do zbadania:
   - **Agent Explore** (`subagent_type: "Explore"`) — znajdź wszystkie pliki związane z zadaniem, szukaj wzorców, śledź ścieżki kodu. Użyj do odkrywania plików i pytań dotyczących struktury bazy kodu.
   - **agent ogólnego przeznaczenia** (`subagent_type: "general-purpose"`) — do głębszej analizy, która może wymagać przeczytania wielu plików i syntezy wyników. Użyj do zrozumienia złożonych systemów.

   Przykład: utwórz 2-3 agentów Explore równolegle dla różnych wymiarów wyszukiwania (np. "znajdź wszystkie pliki związane z X", "znajdź podobne implementacje Y", "znajdź wcześniejsze decyzje dotyczące Z w `context/changes/**/` i `context/archive/**/`").

   Ci agenci będą:
   - Znajdować odpowiednie pliki źródłowe, konfiguracje i testy
   - Śledzić przepływ danych i kluczowe funkcje
   - Zwracać szczegółowe wyjaśnienia z odniesieniami file:line

3. **Przeczytaj wszystkie pliki zidentyfikowane przez zadania badawcze**:
   - Po zakończeniu zadań badawczych, przeczytaj WSZYSTKIE pliki, które zidentyfikowały jako istotne
   - Przeczytaj je W CAŁOŚCI do głównego kontekstu
   - Zapewnia to pełne zrozumienie przed kontynuowaniem

4. **Analizuj i weryfikuj zrozumienie**:
   - Porównaj wymagania zgłoszenia z rzeczywistym kodem
   - Zidentyfikuj wszelkie rozbieżności lub nieporozumienia
   - Zauważ założenia, które wymagają weryfikacji
   - Określ prawdziwy zakres na podstawie rzeczywistości bazy kodu

5. **Przedstaw świadome zrozumienie i oceń złożoność**:

   Najpierw przedstaw krótkie podsumowanie tego, co znalazłeś:

Na podstawie [zgłoszenia i moich badań bazy kodu / Twojego opisu i mojej analizy], rozumiem, że musimy [dokładne podsumowanie].

Znalazłem, że:

[Kluczowe odkrycie — odniesienie do kodu, istniejący zasób, wcześniejsza praca lub ograniczenie domeny]
[Odpowiedni wzorzec, konwencja lub odkryte ograniczenie]
[Zidentyfikowana potencjalna złożoność lub przypadek brzegowy]


Następnie oceń złożoność zadania i przedstaw ją użytkownikowi do potwierdzenia:

Ocena złożoności: [WYSOKA / ŚREDNIA / NISKA]

[2-3 zdaniowe wyjaśnienie, DLACZEGO ten poziom złożoności, odwołujące się do konkretnych czynników: liczba dotkniętych systemów, punkty integracji, potrzeby zarządzania stanem, zmiany modelu danych, nieznane niewiadome, obszar testowania itp.]

Chciałbym zadać [N] pytań w kilku rundach, aby ustalić ważne decyzje dotyczące [wymień kluczowe obszary decyzyjne: architektura, przypadki brzegowe, model danych, UX, testowanie itp.].

Czy to wydaje się słuszne, czy chciałbyś dostosować poziom złożoności?


Zapytaj użytkownika: "Czy ta ocena złożoności odpowiada Twoim oczekiwaniom?" z opcjami:
- "Zgadzam się — przejdź do [N] pytań" (opis: "Ocena jest dokładna, zagłębmy się w szczegóły.")
- "Wyżej — zadaj więcej pytań" (opis: "Złożoność jest większa niż zidentyfikowano. Wyjaśnię, czego brakuje.")
- "Niżej — potrzeba mniej pytań" (opis: "To jest prostsze niż się wydaje. Skupmy się.")

**Skala złożoności:**

| Poziom      | Pytania | Kiedy używać                                                                                                                                                                                                                                                                                                           |
| ---------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **NISKI**    | 4-6       | Proste zadanie z jasnymi wymaganiami. Niewiele ruchomych części, zgodne z ustalonymi wzorcami lub konwencjami, ograniczone niewiadome. Przykłady oprogramowania: zmiana pojedynczego pliku, drobna zmiana konfiguracji. Przykłady nie-oprogramowania: zarys pojedynczego tematu, prosta zmiana procesu.                                 |
| **ŚREDNI** | 7-10      | Wiele komponentów lub rozważań, które współdziałają. Wymaga decyzji projektowych, ma przypadki brzegowe warte omówienia, pewna niejednoznaczność w podejściu. Przykłady oprogramowania: funkcja wielu plików, nowy punkt końcowy API. Przykłady nie-oprogramowania: wieloczęściowy plan treści, przeprojektowanie przepływu pracy, moduł kursu.                               |
| **WYSOKI**   | 11-15     | Problemy przekrojowe, znaczące niewiadome, wielu interesariuszy lub ograniczeń. Wymaga myślenia architektonicznego, niesie ryzyko kosztownych przeróbek, jeśli jest błędne. Przykłady oprogramowania: przeprojektowanie systemu, migracja danych. Przykłady nie-oprogramowania: strategia uruchomienia wielokanałowego, przegląd programu nauczania, zmiana procesu organizacyjnego. |

Po potwierdzeniu (lub dostosowaniu) przez użytkownika, przejdź do zadawania pytań.

6. **Zadawaj głębokie, dociekliwe pytania**:

Zadaj potwierdzoną liczbę pytań w kilku rundach (1-4 pytania na rundę, tyle rund, ile potrzeba).

**Zasady strukturyzowania pytań:**
- Każde pytanie powinno mieć 2-4 konkretne opcje
- Używaj `multiSelect: true` tylko wtedy, gdy wybory nie wykluczają się wzajemnie
- Nagłówek `header` powinien być krótki (maks. 12 znaków): "Zakres", "Przypadki brzegowe", "Priorytet"
- Użytkownik zawsze może wybrać "Inne" dla swobodnego wprowadzania

**Każda opcja MUSI zawierać sygnał rekomendacji i analizę kompromisów:**
- Oznacz dokładnie jedną opcję jako `⭐ Recommended` w jej etykiecie
- `description` każdej opcji musi być zgodny z tym formatem:
  `[1-zdaniowe co to robi] · Mocna strona: [kluczowa zaleta] · Kompromis: [kluczowy koszt lub ryzyko]`
- Rekomendacja powinna być oparta na badaniach (wzorce bazy kodu dla oprogramowania, wiedza dziedzinowa i kontekst dla nie-oprogramowania) — a nie na zgadywaniu

**Przykład pytania z rekomendacjami (oprogramowanie):** `Conflicts` to `[S]` — architektura rozwiązania; zawsze zadawane, nawet jeśli ramka zdefiniowała problem.

Zapytaj użytkownika: "Jak system powinien obsługiwać konflikty, gdy dwóch użytkowników edytuje jednocześnie?" z opcjami:
- "Ostatni zapis wygrywa" (opis: "Późniejszy zapis cicho nadpisuje wcześniejszy. · Mocna strona: Brak dodatkowej złożoności, brak zmian w interfejsie użytkownika. · Kompromis: Użytkownicy mogą stracić pracę bez ostrzeżenia — akceptowalne tylko, jeśli edycje są rzadkie lub mało istotne.")
- "⭐ Zalecane: Powiadom i scal" (opis: "Pokaż konflikt użytkownikowi, pozwól mu wybrać, którą wersję zachować. · Mocna strona: Zapobiega utracie danych, jednocześnie utrzymując prosty UX — pasuje do wzorca w istniejącym komponencie EditPanel. · Kompromis: Dodaje modal rozwiązywania konfliktów i subskrypcję WebSocket do wykrywania w czasie rzeczywistym.")
- "Oparte na blokadach" (opis: "Pierwszy edytor blokuje zasób; inni widzą tylko do odczytu, dopóki nie zostanie zwolniony. · Mocna strona: Całkowicie zapobiega konfliktom — najprostszy model mentalny dla użytkowników. · Kompromis: Zastarzałe blokady wymagają TTL + logiki czyszczenia; blokuje legalną pracę współbieżną.")

**Przykład pytania z rekomendacjami (nie-oprogramowanie — treść/strategia):** `Depth` to `[D]` — diagnostyka dotycząca odbiorców/zakresu; pomiń, jeśli brief ramowy już ustalił, dla kogo to jest.

Zapytaj użytkownika: "Jaki poziom szczegółowości technicznej powinien mieć moduł kursu?" z opcjami:
- "Przegląd koncepcyjny" (opis: "Zasady wysokiego poziomu, bez kodu. · Mocna strona: Dostępny dla wszystkich poziomów umiejętności, szybszy w produkcji. · Kompromis: Zaawansowani uczniowie mogą uznać go za zbyt płytki — ryzyko utraty zaangażowania.")
- "⭐ Zalecane: Praktyczne z przykładami z przewodnikiem" (opis: "Koncepcje połączone z ćwiczeniami krok po kroku. · Mocna strona: Równoważy zrozumienie i praktykę — pasuje do formatu, który uzyskał najwyższe wskaźniki ukończenia w 10xDevs2. · Kompromis: 2-3 razy więcej czasu na przygotowanie na lekcję; wymaga działających repozytoriów przykładów.")
- "Głębokie zanurzenie z otwartymi wyzwaniami" (opis: "Minimalne rusztowanie, problemy z prawdziwego świata. · Mocna strona: Wymusza prawdziwe rozwiązywanie problemów, najwyższe zatrzymanie nauki. · Kompromis: Wysokie ryzyko rezygnacji dla mniej doświadczonych uczniów; trudniejsze do wsparcia na dużą skalę.")

**O co pytać** — dostosuj kategorie do dziedziny zadania:

Najpierw zidentyfikuj dziedzinę zadania: **oprogramowanie**, **treści/edukacja**, **strategia/proces** lub **hybryda**. Następnie wybierz kategorie pytań, które pasują. Poniższe kategorie są uporządkowane według dziedziny — wybierz to, co jest istotne, nie narzucaj kategorii oprogramowania zadaniom nie-oprogramowania.

**Każda kategoria jest oznaczona `[D]` (diagnostyczna — o problemie) lub `[S]` (rozwiązanie — o tym, jak to zbudować).** Gdy w Kroku 1.0 dostarczono brief ramowy, **pomiń wszystkie kategorie `[D]`** — ramka je ustaliła. Zawsze zadawaj kategorie `[S]`, które nadal wymagają wkładu użytkownika.

**Uniwersalne kategorie (wszystkie dziedziny, wszystkie poziomy):**
- **Granice zakresu** `[D]`: Co jest w zakresie, a co poza nim
- **Przypadki brzegowe / tryby awarii** `[S]`: Co się dzieje, gdy coś pójdzie nie tak lub stanie się dziwne (obsługa implementacji, nawet jeśli ramka nazwała klasę obserwacji)
- **Kryteria sukcesu** `[D]`: Skąd wiemy, że to zadziałało — z perspektywy użytkownika końcowego lub interesariusza
- **Priorytet** `[D]`: Musi być vs miło mieć — co zostanie odrzucone, jeśli czas jest ograniczony

**Kategorie specyficzne dla oprogramowania (dodaj w zależności od złożoności):**

ŚREDNI+:
- **Decyzje dotyczące modelu danych** `[S]`: Schemat, relacje, ograniczenia, migracje
- **Strategia obsługi błędów** `[S]`: Tryby awarii, logika ponawiania, komunikaty dla użytkownika
- **Podejście do testowania** `[S]`: Poziom pokrycia, które przypadki brzegowe testować jawnie
- **Granice wydajności** `[S]`: Oczekiwane obciążenie, akceptowalne opóźnienie, buforowanie

WYSOKI:
- **Wybory architektoniczne** `[S]`: Granice usług, synchroniczne vs asynchroniczne, sterowane zdarzeniami vs żądanie-odpowiedź
- **Zarządzanie stanem** `[S]`: Gdzie znajduje się stan, gwarancje spójności, rozwiązywanie konfliktów
- **Model bezpieczeństwa** `[S]`: Granice uwierzytelniania, dostęp do danych, walidacja danych wejściowych
- **Migracja i wycofywanie** `[S]`: Wdrażanie przyrostowe, strategia wycofywania
- **Obserwowalność** `[S]`: Kluczowe metryki, alerty, powierzchnia debugowania

**Kategorie treści / edukacji (dodaj w zależności od złożoności):**

ŚREDNI+:
- **Odbiorcy i wymagania wstępne** `[D]`: Dla kogo to jest, co już wiedzą
- **Format i medium** `[S]`: Pisemne, wideo, interaktywne, na żywo — i dlaczego
- **Łuk narracyjny** `[S]`: Jaką podróż odbywa czytelnik/uczeń
- **Przykłady i ćwiczenia** `[S]`: Co sprawia, że koncepcje się utrwalają

WYSOKI:
- **Zależności programowe** `[D]`: Co musi być nauczone przed czym
- **Strategia oceny** `[S]`: Jak zweryfikować, czy nauka nastąpiła
- **Ponowne użycie i modułowość** `[S]`: Czy części mogą być używane samodzielnie lub w innych kontekstach
- **Dystrybucja i dostęp** `[D]`: Gdzie to się znajduje, jak ludzie to znajdują

**Kategorie strategii / procesu (dodaj w zależności od złożoności):**

ŚREDNI+:
- **Interesariusze i role** `[D]`: Kto jest zaangażowany, kto decyduje, kto wykonuje
- **Oś czasu i kamienie milowe** `[S]`: Kluczowe daty, zależności, ścieżka krytyczna
- **Identyfikacja ryzyka** `[S]`: Co może pójść nie tak, co jest planem awaryjnym
- **Ograniczenia zasobów** `[D]`: Budżet, czas, ludzie, narzędzia

WYSOKI:
- **Zarządzanie zmianą** `[S]`: Jak osoby dotknięte zmianą dowiadują się o niej i ją przyjmują
- **Ramy pomiarowe** `[D]`: Wskaźniki wiodące vs opóźnione, jak korygować kurs
- **Zależności i sekwencjonowanie** `[S]`: Co blokuje co, co może działać równolegle
- **Plan komunikacji** `[S]`: Kto musi wiedzieć co, kiedy, za pośrednictwem jakiego kanału

**O co NIE pytać:**
- O cokolwiek, co zostało już ustalone w artefaktach upstream (brief ramowy, dokument badawczy) — ponowne zadawanie pytań to tryb awarii, któremu ma zapobiegać to skalowanie
- Niskopoziomowe szczegóły implementacji, które możesz określić samodzielnie (na podstawie badań bazy kodu dla oprogramowania, na podstawie plików kontekstowych i wcześniejszych prac dla nie-oprogramowania)
- Pytania z oczywistymi odpowiedziami, biorąc pod uwagę już dostarczony kontekst
- Preferencje, które nie wpływają na strukturę ani sukces planu

**KRYTYCZNE**: MUSISZ zadać liczbę pytań odpowiednią do potwierdzonego poziomu złożoności *i* skalowania artefaktów upstream z Kroku 1.0. Nie skracaj tego, gdy nie dostarczono artefaktów upstream — dokładne pytania zapobiegają kosztownym przeróbkom. Równie ważne jest, aby nie dodawać pytań, gdy ramka lub badania już pokrywają temat — ponowne zadawanie pytań podważa zaufanie do artefaktu upstream. Każde pytanie powinno wymuszać prawdziwą decyzję, a nie potwierdzać coś oczywistego.

### Krok 2: Badania i odkrycia

Po uzyskaniu wstępnych wyjaśnień od użytkownika, TERAZ jest czas na zajęcie się szczegółami implementacji:

1. **Badanie wzorców implementacji i wcześniejszych prac**:
Na tym etapie samodzielnie odpowiadaj na pytania dotyczące implementacji — nie proś użytkownika o podejmowanie tych decyzji.

**Dla zadań oprogramowania**, zbadaj bazę kodu:
- Jakie wzorce baza kodu wykorzystuje dla podobnych funkcji?
- Jakie jest ustalone podejście do obsługi błędów / logowania / testowania?
- Które istniejące komponenty lub narzędzia można ponownie wykorzystać?
- Jakie ograniczenia narzuca obecna architektura?

**Dla zadań nie-oprogramowania**, zbadaj pliki kontekstowe i wcześniejsze prace:
- Jakie formaty, struktury lub szablony były używane do podobnych prac wcześniej?
- Jakie ograniczenia wynikają z wcześniejszych decyzji, odbiorców lub platformy?
- Jakie powiązane treści lub procesy już istnieją, z którymi to powinno być zgodne?
- Co działało dobrze (lub nie) w poprzednich iteracjach?

**To NIE jest do decyzji użytkowników** — Ty określasz to, badając istniejące wzorce, pliki i kontekst.

2. **Jeśli użytkownik poprawi jakiekolwiek nieporozumienie**:
- NIE akceptuj po prostu poprawki
- Utwórz nowe zadania badawcze w celu weryfikacji poprawnych informacji
- Przeczytaj konkretne pliki/katalogi, które wymienia
- Kontynuuj dopiero po samodzielnym zweryfikowaniu faktów

3. **Twórz zadania badawcze** za pomocą narzędzia Task, aby śledzić eksplorację (pojawiają się one na pasku stanu użytkownika). Aktualizuj je za pomocą narzędzia Task w miarę postępów badań.

4. **Utwórz równoległe podzadania do kompleksowych badań**:
- Utwórz wielu agentów Task do równoczesnego badania różnych aspektów
- Użyj odpowiedniego typu agenta dla każdej potrzeby badawczej:

**Do badania bazy kodu:**
- **Explore** (`subagent_type: "Explore"`) — Szybkie wyszukiwanie plików/wzorców, analiza struktury kodu
- **general-purpose** (`subagent_type: "general-purpose"`) — Głęboka analiza wymagająca wieloetapowego rozumowania

**Dla kontekstu historycznego:**
- **Explore** — Szukaj w `context/changes/**/research.md` i `context/changes/**/plan.md` (i tych samych ścieżkach w `context/archive/`) powiązanych dokumentów

Każdy agent będzie:
- Znajdować odpowiednie pliki i wzorce kodu
- Identyfikować konwencje i wzorce do naśladowania
- Szukać punktów integracji i zależności
- Zwracać konkretne odniesienia file:line
- Znajdować testy i przykłady

5. **Poczekaj na zakończenie WSZYSTKICH podzadań** przed kontynuowaniem

6. **Przedstaw wyniki i opcje projektowe**:

Najpierw przedstaw krótkie podsumowanie wyników badań:

Na podstawie moich badań, oto co znalazłem:

Stan obecny:

[Kluczowe odkrycie dotyczące istniejącego kodu]
[Wzorzec lub konwencja do naśladowania]


Następnie, jeśli istnieje wiele prawidłowych podejść, przedstaw je użytkownikowi jako ustrukturyzowane wybory:

Zapytaj użytkownika: "Które podejście do implementacji powinniśmy zastosować?" z opcjami:
- "[Nazwa opcji A]" (opis: "[Kluczowe kompromisy: prostsze, ale X, lub szybsze, ale Y]")
- "[Nazwa opcji B]" (opis: "[Kluczowe kompromisy]")

Jeśli istnieje wyraźnie jedno najlepsze podejście, pomiń pytanie użytkownika i wyjaśnij, dlaczego je wybrałeś.
Pytaj tylko wtedy, gdy wybór naprawdę ma znaczenie i nie możesz określić odpowiedzi na podstawie wzorców bazy kodu.

### Krok 3: Rozwój struktury planu

Po uzgodnieniu podejścia:

1. **Przedstaw zarys planu i uzyskaj ustrukturyzowaną informację zwrotną**:

Najpierw wydrukuj proponowane fazy jako tekst (informacyjnie):

Oto moja proponowana struktura planu:

Przegląd

[1-2 zdaniowe podsumowanie]

Fazy implementacji:

[Nazwa fazy] - [co osiąga]
[Nazwa fazy] - [co osiąga]
[Nazwa fazy] - [co osiąga]


Następnie zapytaj użytkownika: "Czy ten podział na fazy wygląda dobrze?" z opcjami:
- "Wygląda dobrze, kontynuuj" (opis: "Napisz szczegółowy plan z tymi fazami.")
- "Wymaga dostosowania" (opis: "Wyjaśnię, co zmienić, zanim napiszesz szczegółowy plan.")
- "Zbyt szczegółowe" (opis: "Połącz niektóre fazy — to jest prostsze niż się wydaje.")
- "Zbyt ogólne" (opis: "Podziel niektóre fazy — istnieją ukryte złożoności.")

### Krok 4: Pisanie szczegółowego planu

Po zatwierdzeniu struktury:

1. **Rozwiąż folder zmian, a następnie zapisz plan** do `context/changes/<change-id>/plan.md`.
- Jeśli użytkownik wywołał `/10x-plan <change-id>` i `context/changes/<change-id>/` już istnieje, użyj go.
- W przeciwnym razie utwórz kebab-case `<change-id>` z tematu i utwórz folder + `change.md` (odzwierciedlając semantykę `/10x-new`) przed zapisaniem.
- Odmów, jeśli rozwiązana ścieżka zaczyna się od `context/archive/` — wydrukuj: "Ta zmiana jest zarchiwizowana. Zamiast tego otwórz nową zmianę za pomocą `/10x-new`." i ZATRZYMAJ.
- Zaktualizuj `change.md`: ustaw `status: planned` i `updated: <dzisiaj>`.
- **Synchronizuj mapę drogową** (najlepszy wysiłek): jeśli `context/foundation/roadmap.md` zawiera element, którego `Change ID` jest równe `<change-id>`, zmień status tego elementu na `Status: planning`. Zobacz "## Synchronizacja statusu mapy drogowej" poniżej. Nigdy nie blokuje; większość zmian nie będzie prowadzić do mapy drogowej.
2. **Użyj tej struktury szablonu** (bloki faz zawierają zwykłe punktorzy — `- ` a nie `- [ ]` — a pojedyncza kanoniczna sekcja `## Postęp` na dole jest właścicielem stanu pola wyboru, zobacz `references/progress-format.md` dla kontraktu):

````markdown
# [Nazwa funkcji/zadania] Plan implementacji

## Przegląd

[Krótki opis tego, co implementujemy i dlaczego]

## Analiza stanu obecnego

[Co istnieje teraz, czego brakuje, kluczowe odkryte ograniczenia]

## Pożądany stan końcowy

[Specyfikacja pożądanego stanu końcowego po zakończeniu tego planu i sposób jego weryfikacji]

### Kluczowe odkrycia:

- [Ważne odkrycie z odniesieniem file:line]
- [Wzorzec do naśladowania]
- [Ograniczenie, w ramach którego należy pracować]

## Czego NIE robimy

[Jawnie wymień elementy poza zakresem, aby zapobiec rozszerzaniu zakresu]

## Podejście do implementacji

[Strategia wysokiego poziomu i uzasadnienie]

## Krytyczne szczegóły implementacji

Ta sekcja zawiera **ograniczenia, pułapki i wymagania dotyczące kolejności, które implementator musi znać, zanim dotknie kodu** — fakty, które LLM określa podczas badań i odkryć (Krok 2), które nie są widoczne tylko ze ścieżek plików.

To NIE jest miejsce do wstępnego decydowania o implementacji. Domyślnie: **pomiń** całą sekcję. Dołącz nagłówek poniżej TYLKO wtedy, gdy coś naprawdę zaskakującego lub obciążającego ma zastosowanie — i napisz 1-3 zdania, a nie szablony punktorów.

- **Czas i cykl życia** — dołącz tylko wtedy, gdy istnieje nieoczywista kolejność, wyścig lub hak cyklu życia, który implementator mógłby inaczej przeoczyć.
- **Specyfikacja doświadczenia użytkownika** — dołącz tylko wtedy, gdy zachowanie widoczne dla użytkownika ma ograniczenia, których nie można wywnioskować z wymagań użytkownika (np. specyficzne zarządzanie fokusem, zachowanie przewijania).
- **Ograniczenia wydajności** — dołącz tylko wtedy, gdy istnieje rzeczywisty budżet wydajności lub znany punkt krytyczny; pomiń ogólne porady typu "użyj memoizacji".
- **Sekwencjonowanie stanu** — dołącz tylko wtedy, gdy kolejność zmian stanu ma znaczenie, a oczywista kolejność jest błędna.
- **Debugowanie i obserwowalność** — dołącz tylko wtedy, gdy istnieje specyficzna metoda weryfikacji lub potrzeba instrumentacji wykraczająca poza standardowe logowanie.

Jeśli żadne z powyższych nie ma zastosowania, pomiń całą sekcję. Plan bez niej nie jest niekompletny; plan, który wypełnia ją szablonowymi punktorami, jest nadmiernie rozbudowany.

## Faza 1: [Opisowa nazwa]

### Przegląd

[Co osiąga ta faza]

### Wymagane zmiany:

#### 1. [Komponent/Grupa plików]

**Plik**: `path/to/file.ext`

**Cel**: [1-2 zdania określające, co ta zmiana robi i dlaczego. Implementator napisze rzeczywisty kod.]

**Kontrakt**: [Interfejs, sygnatura, pole schematu, trasa, delta struktury plików lub niezmiennik, którego dotyczy zmiana. W przypadku edycji czysto prozą, nazwij sekcję lub nagłówek, którego dotyczy.

Fragment kodu pojawia się tutaj TYLKO wtedy, gdy zmiana jest nieoczywista — trudne wyrażenie regularne, nietypowe wywołanie API, nieintuicyjna kolejność, obejście znanego błędu lub kontrakt sygnatury, od którego zależą inne części planu. W przypadku rutynowych edycji (dodanie pola, podłączenie obsługi, naśladowanie istniejącego wzorca), opisz kontrakt i zatrzymaj się. Domyślnie: brak fragmentu.]

### Kryteria sukcesu:

#### Weryfikacja automatyczna:

- Migracja stosuje się czysto: `make migrate`
- Testy jednostkowe przechodzą: `make test-component`
- Sprawdzanie typów przechodzi: `npm run typecheck`
- Linting przechodzi: `make lint`
- Testy integracyjne przechodzą: `make test-integration`

#### Weryfikacja ręczna:

- Funkcja działa zgodnie z oczekiwaniami po przetestowaniu za pomocą interfejsu użytkownika
- Wydajność jest akceptowalna pod obciążeniem
- Obsługa przypadków brzegowych zweryfikowana ręcznie
- Brak regresji w powiązanych funkcjach

**Uwaga implementacyjna**: Po zakończeniu tej fazy i pomyślnym przejściu wszystkich automatycznych weryfikacji, zatrzymaj się tutaj w celu ręcznego potwierdzenia przez człowieka, że testy ręczne zakończyły się sukcesem, zanim przejdziesz do następnej fazy. Bloki faz używają zwykłych punktorów — odpowiadające im pola wyboru `- [ ]` dla tych elementów znajdują się w sekcji `## Postęp` na dole planu.

---

## Faza 2: [Opisowa nazwa]

[Podobna struktura z kryteriami sukcesu zarówno automatycznymi, jak i ręcznymi...]

---

## Strategia testowania

### Testy jednostkowe:

- [Co testować]
- [Kluczowe przypadki brzegowe]

### Testy integracyjne:

- [Scenariusze end-to-end]

### Kroki testowania ręcznego:

1. [Konkretny krok weryfikacji funkcji]
2. [Kolejny krok weryfikacji]
3. [Przypadek brzegowy do ręcznego przetestowania]

## Uwagi dotyczące wydajności

[Wszelkie implikacje wydajnościowe lub potrzebne optymalizacje]

## Uwagi dotyczące migracji

[Jeśli dotyczy, jak obsługiwać istniejące dane/systemy]

## Referencje

- Powiązane badania: `context/changes/<change-id>/research.md`
- Podobna implementacja: `[file:line]`

## Postęp

> Konwencja: `- [ ]` oczekujące, `- [x]` wykonane. Dodaj ` — <commit sha>` po zakończeniu kroku. Nie zmieniaj nazw tytułów kroków. Zobacz `references/progress-format.md`.

### Faza 1: <Nazwa fazy 1>

#### Automatyczne

- [ ] 1.1 <Element weryfikacji automatycznej 1 z Fazy 1>
- [ ] 1.2 <Element weryfikacji automatycznej 2 z Fazy 1>

#### Ręczne

- [ ] 1.3 <Element weryfikacji ręcznej 1 z Fazy 1>

### Faza 2: <Nazwa fazy 2>

#### Automatyczne

- [ ] 2.1 <…>

Sekcja Postęp jest mechaniczna — emituj jeden ### Faza N: <nazwa> na fazę, z podsekcjami #### Automatyczne / #### Ręczne wyliczającymi każdy punktor Kryteriów Sukcesu z tej fazy jako - [ ] <faza>.<indeks> <tytuł>. Pomiń puste podsekcje. Same bloki faz zawierają zwykłe punktorzy - (bez pól wyboru); sekcja ## Postęp jest jedynym miejscem, w którym pojawiają się [ ] / [x].

Krok 4.5: Krótki plan (dwustronicowy)

Po napisaniu pełnego planu, wygeneruj zwięzły brief, który da czytelnikowi ogólny obraz, zanim zagłębi się w 500-1000 linii szczegółów. Brief jest pierwszą rzeczą, którą użytkownik czyta — powinien zająć mniej niż 2 minuty i pozostawić mu jasny model mentalny tego, co plan robi, dlaczego i jakie były kluczowe decyzje.

Napisz brief do context/changes/<change-id>/plan-brief.md (plik siostrzany plan.md w tym samym folderze zmian).
Użyj tego szablonu:

# [Nazwa funkcji/zadania] — Krótki plan

> Pełny plan: `context/changes/<change-id>/plan.md`
> Krótki opis ram: `context/changes/<change-id>/frame.md` (jeśli istnieje — w przeciwnym razie pomiń linię)
> Badania: `context/changes/<change-id>/research.md` (jeśli istnieje — w przeciwnym razie pomiń linię)

## Co i dlaczego

[2-3 zdania: co budujemy/robimy i motywacja. Jeśli brief ramowy był danymi wejściowymi, przenieś tutaj dosłownie Przeformułowane (lub Potwierdzone) Oświadczenie o Problemie — to jest "dlaczego" w jego najostrzejszej formie.]

## Punkt wyjścia

[1-2 zdania: co istnieje dzisiaj, na czym ten plan się opiera lub co zmienia. Ugruntuj czytelnika w obecnym stanie, aby zrozumiał różnicę. Jeśli ramka to badała, podsumuj z jej Badania Hipotez, zamiast ponownie stwierdzać.]

## Pożądany stan końcowy

[2-3 zdania: jak wygląda świat po zakończeniu tego planu. Opisz konkretny, widoczny dla użytkownika wynik — nie metryki, ale doświadczenie lub zdolność, która teraz istnieje.]

## Kluczowe podjęte decyzje

Gdy brief ramowy lub dokument badawczy był danymi wejściowymi, oznacz kolumnę **Źródło**, aby pokazać, skąd pochodzi decyzja. Pozwala to czytelnikom zobaczyć pochodzenie: co zostało ustalone upstream vs co zostało zdecydowane w tej sesji planowania.

| Decyzja                       | Wybór            | Dlaczego (1 zdanie)  | Źródło           |
| ------------------------------ | ----------------- | ----------------- | ---------------- |
| [Obszar decyzji]                | [Co zostało wybrane] | [Główne uzasadnienie]  | Ramka / Badania / Plan |
| [Obszar decyzji]                | [Wybór]          | [Uzasadnienie]       | Ramka / Badania / Plan |
| ...                            | ...               | ...               | ...              |

(Pomiń kolumnę `Źródło`, jeśli nie dostarczono artefaktów upstream — każdy wiersz byłby `Plan`.)

## Zakres

**W zakresie:** [Lista punktowana tego, co jest uwzględnione]

**Poza zakresem:** [Lista punktowana tego, co jest jawnie wykluczone]

## Architektura / Podejście

[1 krótki akapit lub prosty diagram opisujący podejście wysokiego poziomu.
Dla oprogramowania: kluczowe komponenty, przepływ danych, punkty integracji.
Dla nie-oprogramowania: struktura, przepływ pracy, kluczowe zależności.]

## Fazy w skrócie

| Faza     | Co dostarcza       | Kluczowe ryzyko                  |
| --------- | ---------------------- | ------------------------- |
| 1. [Nazwa] | [Jednowierszowy rezultat] | [Główne ryzyko lub obawa] |
| 2. [Nazwa] | [Jednowierszowy rezultat] | [Główne ryzyko]            |
| ...       | ...                    | ...                       |

**Wymagania wstępne:** [Co musi być prawdą przed rozpoczęciem — zależności, dostęp, wcześniejsze prace]
**Szacowany wysiłek:** [Przybliżony rozmiar: np. "~2-3 sesje w 3 fazach" lub "8 tygodni, zespół 2-osobowy"]

## Otwarte ryzyka i założenia

- [Ryzyko lub założenie, które może zmienić plan]
- [Kolejne]

## Kryteria sukcesu (podsumowanie)

[2-3 punkty: jak wiemy, że plan się powiódł, z perspektywy użytkownika]

Kluczowe zasady briefu:
- Musi zmieścić się na około 2 wydrukowanych stronach (~60-80 linii markdown). Jeśli jest dłuższy, skróć.
- Tabela "Kluczowe decyzje" jest sercem — przedstawia to, co zostało zdecydowane podczas zadawania pytań, aby każdy, kto później czyta plan, zrozumiał wybory bez ponownego czytania wszystkich pytań.
- "Punkt wyjścia" ugruntowuje czytelnika w tym, co istnieje dzisiaj — bez tego ktoś nieznający projektu nie zrozumie różnicy.
- "Wymagania wstępne i szacowany wysiłek" na dole tabeli faz daje czytelnikowi szybką kontrolę wykonalności przed podjęciem decyzji o przeczytaniu pełnego planu.
- Pisz dla kogoś, kto nie brał udziału w rozmowie planistycznej — powinien zrozumieć kształt i uzasadnienie planu tylko z briefu.
- Link do pełnego planu na górze, aby czytelnik mógł zagłębić się w dowolną sekcję.

Krok 5: Synchronizacja i przegląd

Potwierdź, że plan + brief wylądowały w folderze zmian:
- ls context/changes/<change-id>/plan.md context/changes/<change-id>/plan-brief.md powinny oba istnieć.

Skopiuj polecenie szybkiego startu do schowka:

Po napisaniu planu, skopiuj polecenie implementacji do schowka:

echo -n "/10x-implement <change-id> phase 1" | pbcopy 2>/dev/null || echo -n "/10x-implement <change-id> phase 1" | clip.exe 2>/dev/null || echo -n "/10x-implement <change-id> phase 1" | xclip -selection clipboard 2>/dev/null || true

# PowerShell (Windows)
Set-Clipboard "/10x-implement <change-id> phase 1"

Przedstaw zarówno brief, jak i pełny plan:

Stworzyłem plan implementacji:

📋 Krótki opis (zacznij tutaj): `context/changes/<change-id>/plan-brief.md`
📄 Pełny plan: `context/changes/<change-id>/plan.md`

→ /10x-implement <change-id> phase 1 (✓ skopiowano)

Najpierw przejrzyj krótki opis, a następnie sprawdź pełny plan pod kątem wszelkich potrzebnych poprawek:
- Czy fazy są odpowiednio zakresowane?
- Czy kryteria sukcesu są wystarczająco szczegółowe?
- Czy jakieś szczegóły techniczne wymagają dostosowania?
- Brakujące przypadki brzegowe lub uwagi?

Iteruj na podstawie informacji zwrotnych - bądź gotowy do:
- Dodawania brakujących faz
- Dostosowywania podejścia technicznego
- Wyjaśniania kryteriów sukcesu (zarówno automatycznych, jak i ręcznych)
- Dodawania/usuwania elementów zakresu
Kontynuuj dopracowywanie, aż użytkownik będzie zadowolony

Synchronizacja statusu mapy drogowej

context/foundation/roadmap.md (generowany przez /10x-roadmap) indeksuje każdą Fundację/Fragment za pomocą stabilnego ID Zmiany. Gdy planowanie przekształca element mapy drogowej w konkretny folder zmian + plan, oznacz ten element jako planning, aby mapa drogowa odzwierciedlała, że element opuścił backlog i wszedł w aktywną pracę. /10x-implement później przenosi ten sam element do in-progress, a /10x-archive zamyka go do done.

Zrób to w Kroku 4 (zaraz po stemplu change.md → planned). Wyszukiwanie jest obowiązkowe; "najlepszy wysiłek" obejmuje tylko edycje — brakująca mapa drogowa lub nieznaleziony cel jest pomijany cicho i nigdy nie blokuje, nie prosi ani nie przerywa działania. Nie pomijaj sprawdzania, zakładając, że nie ma mapy drogowej.

Sprawdź, czy istnieje context/foundation/roadmap.md. Jeśli brak, pomiń ten krok cicho.
Przeczytaj plik. Poszukaj <change-id> użytego jako Change ID:
- w tabeli ## W skrócie — wiersz, którego komórka w kolumnie ID Zmiany jest dokładnie równa <change-id>;
- oraz w treści ## Fundacje / ## Fragmenty — blok ### <ID>: …, który zawiera linię - **ID Zmiany:** <change-id>.
Dopasowanie jest tylko dokładnym ciągiem znaków. Brak dopasowania → wydrukuj ℹ context/foundation/roadmap.md nie zawiera elementu z ID Zmiany "<change-id>" — mapa drogowa pozostaje niezmieniona. i zatrzymaj się tutaj.
Znaleziono dopasowanie → jeśli - **Status:** elementu jest już planning, in-progress lub done, pozostaw go bez zmian (tylko do przodu: nigdy nie cofaj bardziej zaawansowanego statusu) i zatrzymaj się. W przeciwnym razie zastosuj obie edycje — każda niezależna i najlepszy wysiłek; pomiń podedycję, której cel nie znajduje się tam, gdzie umieszcza go szablon /10x-roadmap, i zanotuj pominięcie. Dotknij tylko pola Status:
1. ## W skrócie — ustaw komórkę Status dopasowanego wiersza na planning.
2. Treść elementu — przepisz linię - **Status:** elementu na - **Status:** planning.
Następnie zaktualizuj updated: w frontmatterze mapy drogowej na <dzisiaj> (pomiń, jeśli nie ma frontmattera).
/10x-plan nie zatwierdza własnych artefaktów; pozostaw zmianę w drzewie roboczym. Zostanie ona zatwierdzona później wraz z pierwszą fazą /10x-implement zmiany (która ponownie zmienia status tego samego elementu na in-progress).

Ważne wytyczne

Bądź sceptyczny:
- Kwestionuj niejasne wymagania
- Wcześnie identyfikuj potencjalne problemy
- Pytaj "dlaczego" i "co z"
- Nie zakładaj - weryfikuj kodem, plikami lub kontekstem
Bądź interaktywny:
- Nie pisz całego planu za jednym razem
- Uzyskaj zgodę na każdym głównym kroku
- Pozwól na korekty kursu
- Pracuj wspólnie
Bądź dokładny:
- PRZECZYTAJ WSZYSTKIE pliki kontekstowe W CAŁOŚCI przed planowaniem
- Badaj wzorce za pomocą równoległych podzadań (baza kodu dla oprogramowania, pliki kontekstowe i wcześniejsze prace dla nie-oprogramowania)
- Dołącz konkretne odniesienia (file:line dla kodu, ścieżki dokumentów dla treści)
- Pisz mierzalne kryteria sukcesu z wyraźnym rozróżnieniem na automatyczne i ręczne
Bądź praktyczny:
- Skup się na przyrostowych, testowalnych zmianach
- Rozważ migrację i wycofywanie
- Myśl o przypadkach brzegowych
- Dołącz "czego NIE robimy"
Śledź postępy:
- Użyj narzędzia Task do tworzenia zadań planistycznych i aktualizuj je, aby oznaczyć je jako ukończone w miarę postępów
- Zadania pojawiają się na pasku stanu użytkownika dla widoczności
- Oznacz zadania jako ukończone po zakończeniu obszarów badawczych
OBOWIĄZKOWE: Głębokie pytania skalowane pod kątem złożoności:
- PRZED napisaniem jakiegokolwiek planu, MUSISZ ocenić złożoność (WYSOKA/ŚREDNIA/NISKA) i uzyskać potwierdzenie od użytkownika
- Zadaj pełną liczbę pytań odpowiadającą złożoności: NISKA=4-6, ŚREDNIA=7-10, WYSOKA=11-15
- Każda opcja musi zawierać wybór ⭐ Recommended z analizą mocnych stron/kompromisów
- Omów zakres, przypadki brzegowe, architekturę, model danych, testowanie i wydajność, odpowiednio do złożoności
- Zadawaj pytania w rundach po 1-4 pytania — tyle rund, ile potrzeba, aby osiągnąć docelową liczbę
- NIE pomijaj ani nie skracaj tego kroku — dokładne pytania zapobiegają krytycznym błędom i przeróbkom
- Poczekaj na odpowiedzi użytkownika przed przejściem do szczegółowego planowania
Brak otwartych pytań w ostatecznym planie:
- Jeśli napotkasz otwarte pytania podczas planowania, ZATRZYMAJ SIĘ
- Natychmiast zbadaj lub poproś o wyjaśnienie
- NIE pisz planu z nierozwiązanymi pytaniami
- Plan implementacji musi być kompletny i wykonalny
- Każda decyzja musi zostać podjęta przed sfinalizowaniem planu
- Podsekcje "Krytyczne szczegóły implementacji" są opcjonalne: dołącz je tylko wtedy, gdy ma zastosowanie rzeczywiste ograniczenie, pułapka lub wymóg kolejności. Domyślnie pomiń. Plan bez tej sekcji nie jest niekompletny.
Opisz zamiar, a nie implementację:
- Plan mówi implementatorowi co zmienić i dlaczego, a nie jak napisać kod
- Każdy wpis zmiany w ### Wymagane zmiany: oddziela **Cel** (co i dlaczego) od **Kontraktu** (interfejs, sygnatura, pole schematu, trasa, struktura lub niezmiennik, którego dotyczy zmiana). Fragmenty kodu, gdy są potrzebne, znajdują się na końcu **Kontraktu**
- Domyślnie brak fragmentów kodu. Dołącz fragment TYLKO wtedy, gdy zmiana jest nieoczywista (trudne wyrażenie regularne, nietypowe wywołanie API, nieintuicyjna kolejność, obejście, kontrakt sygnatury, od którego zależą inne fazy)
- W przypadku rutynowych edycji — dodawanie pola, podłączanie obsługi, naśladowanie istniejącego wzorca — opisz **Cel** w 1-2 zdaniach, nazwij **Kontrakt** w jednym i zatrzymaj się. Implementator (człowiek lub agent) odczytuje kod ze ścieżki pliku, otaczającego wzorca i zamiaru
- Ścieżki plików i krótkie opisy Celu/Kontraktu są zazwyczaj wystarczające. Oprzyj się pokusie wstępnego pisania kodu

Wytyczne dotyczące kryteriów sukcesu

Zawsze dziel kryteria sukcesu na dwie kategorie:

Weryfikacja automatyczna — polecenia, które agenci mogą uruchomić: make test, npm run lint, sprawdzanie typów, istnienie konkretnego pliku
Weryfikacja ręczna — testowanie przez człowieka: UI/UX, rzeczywista wydajność, przypadki brzegowe, akceptacja użytkownika

Kryteria sukcesu każdej fazy powinny używać pól wyboru - [ ] pod nagłówkami #### Weryfikacja automatyczna: i #### Weryfikacja ręczna:.

Typowe wzorce

Zmiany w bazie danych: schemat/migracja → metody przechowywania → logika biznesowa → API → klienci
Nowe funkcje: wzorce badawcze → model danych → backend → API → UI
Refaktoryzacja: dokumentowanie zachowania → zmiany przyrostowe → kompatybilność wsteczna → migracja

Najlepsze praktyki tworzenia podzadań

Twórz wiele zadań równolegle w jednej wiadomości dla równoczesnego wykonania
Każde zadanie powinno być skoncentrowane na konkretnym obszarze ze szczegółowymi instrukcjami (katalogi, co wyodrębnić, oczekiwany format)
Żądaj konkretnych odniesień file:line w odpowiedziach
Poczekaj na zakończenie wszystkich zadań przed syntezą wyników
Weryfikuj wyniki podzadań — jeśli są nieoczekiwane, twórz kolejne i porównuj z rzeczywistym kodem

Zarządzanie kontekstem

Planowanie może być obciążone kontekstem ze względu na badania + iterację. Utrzymuj kontekst efektywny:

Deleguj badania do podagentów — zwracają oni podsumowania, utrzymując główny kontekst w ryzach. Nie czytaj ponownie plików, które podagenci już przeanalizowali, chyba że musisz zweryfikować konkretne szczegóły.
Syntetyzuj, nie gromadź — po powrocie podagentów, syntetyzuj wyniki w swoje zrozumienie, zamiast cytować duże bloki dosłownie.
Jeśli kontekst wydaje się zdegradowany podczas planowania — jeśli odpowiedzi stają się powolne lub powtarzalne, zapisz bieżący szkic planu do pliku i zaproponuj użytkownikowi kontynuowanie w świeżym kontekście:
```
Szkic planu został zapisany pod adresem: context/changes/<change-id>/plan.md
Czy chcesz kontynuować dopracowywanie w nowym oknie?
→ /10x-plan <change-id> (✓ skopiowano)
```
Pozwala to /10x-plan na ponowne załadowanie szkicu i kontynuowanie iteracji z dostępnym pełnym kontekstem.

Przykład sondowania pytań według typu funkcji

Przykład 1: Oprogramowanie / Funkcja interfejsu użytkownika — złożoność ŚREDNIA (np. Paginacja)

Mieszane: Loading UX to [S] (zachowanie interfejsu użytkownika — szczegóły rozwiązania); Scale to [D] (granica problemu — jak duży jest zestaw danych). Z briefem ramowym, zapytaj tylko o Loading UX; skala powinna już znajdować się w Przeformułowanym (lub Potwierdzonym) Oświadczeniu o Problemie.

Zapytaj użytkownika: "Co użytkownik powinien widzieć podczas ładowania nowych elementów?" z opcjami:

"Wbudowany spinner" (opis: "Mały spinner pod istniejącą zawartością. · Mocna strona: Użytkownik nadal widzi bieżące elementy, minimalna praca UI. · Kompromis: Wydaje się wolniejszy niż szkielet — użytkownicy widzą ogólny spinner zamiast kształtu zawartości.")
"⭐ Zalecane: Ekrany szkieletowe" (opis: "Kształty zastępcze pasujące do układu elementu. · Mocna strona: Postrzegana wydajność jest o 30-40% lepsza — pasuje do istniejącego wzorca komponentu LoadingSkeleton. · Kompromis: Wymaga wariantu szkieletu dla każdego typu elementu; psuje się, jeśli układ się zmieni.")
"Spinner na całą stronę" (opis: "Zastąp zawartość spinnerem. · Mocna strona: Najprostszy w implementacji — jeden komponent, brak problemów z układem. · Kompromis: Blokuje wszystkie interakcje; wydaje się zepsuty przy wolnych połączeniach.")

Zapytaj użytkownika: "Ile elementów powinien to obsługiwać bezproblemowo?" z opcjami:

"⭐ Zalecane: Setki" (opis: "Standardowa paginacja offsetowa. · Mocna strona: Prosta, dobrze zrozumiała, działa z istniejącymi zapytaniami SQL. · Kompromis: Psuje się po około 5 tys. elementów — akceptowalne, biorąc pod uwagę obecne wolumeny danych.")
"Tysiące" (opis: "Paginacja oparta na kursorze + wirtualne przewijanie. · Mocna strona: Obsługuje wzrost bez spadku wydajności. · Kompromis: 2-3 razy więcej pracy implementacyjnej; zmienia kontrakt API.")
"Dziesiątki tysięcy" (opis: "Filtrowanie po stronie serwera + wirtualna lista + wyszukiwanie. · Mocna strona: Skaluje się w nieskończoność. · Kompromis: Znacząca złożoność; wymaga indeksu wyszukiwania i nowego projektu API.")

Przykład 2: Treści / Edukacja — złożoność WYSOKA (np. Projekt modułu kursu)

Mieszane: Outcome to [D] (definiuje, jak wygląda sukces — czyste sformułowanie problemu); Levels to [S] (strategia obsługi odbiorców — jak ustrukturyzować dostarczanie). Z briefem ramowym, zapytaj tylko o Levels; wynik powinien być ustalony.

Zapytaj użytkownika: "Co uczeń powinien być w stanie ZROBIĆ po tym module — nie tylko wiedzieć?" z opcjami:

"⭐ Zalecane: Zbudować działający prototyp" (opis: "Uczeń tworzy funkcjonalny artefakt, używając nauczonych technik. · Mocna strona: Wymusza prawdziwe przeniesienie umiejętności — artefakt dowodzi kompetencji. Pasuje do formatu lekcji 'Innowacje' z 10xDevs3. · Kompromis: Wymaga dobrze zaprojektowanych szablonów startowych i jasnych kryteriów akceptacji; przygotowanie zajmuje 2-3 razy dłużej.")
"Ukończyć ćwiczenie z przewodnikiem" (opis: "Instrukcja krok po kroku z oczekiwanym wynikiem. · Mocna strona: Niska bariera — każdy kończy, buduje pewność siebie. · Kompromis: Może produkować 'tutorialowych zombie', którzy potrafią podążać, ale nie potrafią samodzielnie zastosować.")
"Zdać test wiedzy" (opis: "Quiz lub przegląd kodu potwierdzający zrozumienie koncepcyjne. · Mocna strona: Szybki do stworzenia, łatwy do oceniania na dużą skalę. · Kompromis: Testuje rozpoznawanie, a nie produkcję — uczeń może rozumieć, ale nie być w stanie wykonać.")

Zapytaj użytkownika: "Jak ten moduł powinien obsługiwać różne poziomy umiejętności w grupie odbiorców?" z opcjami:

"Jedna ścieżka, zaawansowana" (opis: "Jedna ścieżka skierowana do doświadczonych programistów. · Mocna strona: Głęboka treść, brak prowadzenia za rękę, szanuje czas ekspertów. · Kompromis: Zraża początkujących — odpadną lub zaleją kanały wsparcia.")
"⭐ Zalecane: Warstwowa głębokość" (opis: "Główna ścieżka, którą wszyscy podążają + opcjonalne sekcje pogłębione. · Mocna strona: Każdy otrzymuje wartość; zaawansowani uczniowie sami wybierają trudniejszy materiał. · Kompromis: Więcej treści do utrzymania; ryzyko ignorowania 'opcjonalnych' sekcji.")
"Oddzielne ścieżki dla początkujących/zaawansowanych" (opis: "Dwie równoległe ścieżki rozchodzące się wcześnie. · Mocna strona: Każda grupa odbiorców otrzymuje idealnie dopasowaną treść. · Kompromis: 2x koszt produkcji; dzielenie małej kohorty może zaszkodzić dynamice społeczności.")

Przykład 3: Strategia / Proces — złożoność ŚREDNIA (np. Przepływ pracy biuletynu)

Bottleneck to [D] — czyste sformułowanie problemu (jaki problem rozwiązać). To jest dokładnie ten rodzaj pytania, który ramka ma na celu rozstrzygnąć. Z briefem ramowym, pomiń to całkowicie; wiodąca hipoteza jest wąskim gardłem.

Zapytaj użytkownika: "Co jest głównym wąskim gardłem w obecnym procesie biuletynu?" z opcjami:

"⭐ Zalecane: Kuraacja trwa zbyt długo" (opis: "Znajdowanie i ocenianie linków jest wolnym krokiem. · Mocna strona: Bezpośrednio celuje w czas do publikacji — automatyzacja kuraacji daje największe oszczędności czasu na podstawie obecnych czasów procesu. · Kompromis: Automatyczna kuraacja ryzykuje utratę osobistego głosu redakcyjnego, który cenią subskrybenci.")
"Pisanie komentarzy" (opis: "Linki są gotowe, ale pisanie wokół nich jest wolne. · Mocna strona: Wspomagane przez AI pisanie może skrócić to o połowę. · Kompromis: Intensywne pisanie przez AI może sprawić, że biuletyn będzie wydawał się generyczny — wymaga starannej kalibracji głosu.")
"Dystrybucja i planowanie" (opis: "Treść jest gotowa, ale publikowanie jest ręczne. · Mocna strona: Najłatwiejsze do zautomatyzowania — jasne wejścia i wyjścia. · Kompromis: Najmniejszy wpływ, jeśli kuraacja lub pisanie nadal jest wąskim gardłem.")

Uwaga: Pytania skupiają się na CO powinno się wydarzyć (wymagania, zachowanie, wyniki) — NIE na JAK to zaimplementować (wzorce kodu, konkretne narzędzia). Wybór ⭐ Recommended jest oparty na badaniach i kontekście — użytkownik zawsze ma ostatnie słowo.

10x-plan

About