--- name: shelby-summary-meta-analytics title: Shelby Summary — Meta-Analityka description: "Meta-analityczny rozkład spotkania — nie streszczenie, tylko analiza efektywności. Generuje stosunek sygnału do szumu, wskaźnik decyzji, dystrybucję wagi tematów, dystrybucję głosu, czerwone flagi i brutalny jednozdaniowy werdykt Shelby-Musk. Używaj do spotkań powyżej 10 minut, gdy chcesz zrozumieć na co faktycznie poszedł czas." category: workflow tags: - spotkania - analityka - efektywność - strategia - meta-analiza - signal-to-noise - podejmowanie-decyzji source: https://madejski.ai/pl/skilloteka/shelby-summary-meta-analytics locale: pl license: MIT --- # Shelby Summary — Meta-Analityka spotkań ## Czym to jest To **nie jest** podsumowanie spotkania. To meta-analiza efektywności spotkania — analityka, która odpowiada na pytanie: *"Na co faktycznie poszła waga tego czasu?"* Output to zwięzły HTML artifact renderowany inline, który: 1. Pokazuje twarde metryki (signal/noise, konkret vs. meta-dyskusja, dystrybucja tematów) 2. Wizualizuje wagę spotkania na wykresach z krótkimi komentarzami 3. Oznacza największe pain pointy literalnie na czerwono 4. Kończy się jednym krzyczącym strategicznym wnioskiem w stylu Muska/Shelby'ego **Filozofia:** Maksimum informatywności do podjęcia decyzji co dalej. Zero streszczenia. Jeśli użytkownik chce streszczenia — ma `meeting-summary`. Jeśli chce pełnej intelligence — ma `my-meeting-intel`. Ten skill jest dopełnieniem, nie zamiennikiem. --- ## Kiedy używać Wywołuj gdy użytkownik mówi: - "shelby summary", "shelby-summary", "shelby-musk" - "meta analiza spotkania", "analityka spotkania" - "zrób analitykę tego callu" - "ile było konkretu", "co tu było warte" - "signal to noise", "efektywność spotkania" - albo wkleja transkrypt i chce czegoś więcej niż summary ale krócej niż full meeting-intel ## Kiedy NIE używać - Dla zwykłego podsumowania — użyj `meeting-summary` - Dla pełnej analizy strategicznej — użyj `my-meeting-intel` lub `shelby` --- ## Input Handling Przyjmuje dowolny transkrypt spotkania (labeled lub nie). Jeśli nie ma labelek mówców — estymujemy, nigdy nie blokujemy. Szacunki są oznaczone jako szacunki, ale są podane. Jeśli transkrypt jest ewidentnie za krótki (standup < 10 min, < 500 słów) — shelby-summary nie ma sensu. Powiedz użytkownikowi i przekieruj do `meeting-summary`. --- ## Framework analizy ### Krok 1: Oblicz metryki **Metryka 1: Signal-to-Noise Ratio (0-100%)** - **Signal** = konkretna treść merytoryczna, fakty, decyzje, techniczne szczegóły, rozwiązywanie problemu - **Noise** = meta-dyskusja o procesie, dygresje, powtarzanie tego co już powiedziano, krążenie wokół tematu, zastępcze tematy **Metryka 2: Konkret vs. Meta-dyskusja (0-100%)** - **Konkret** = rozmowa o *co zrobić / co jest / co działa / co nie* - **Meta** = rozmowa o *jak powinniśmy rozmawiać / co powinniśmy zdecydować / czy to w ogóle ma sens* - Różnica vs. signal/noise: meta-dyskusja może być bardzo signal-rich (ważna), ale pokazuje że zespół nie zdecydował fundamentów. Wysoki % meta = kryzys tożsamości projektu. **Metryka 3: Decyzje na godzinę** - Liczba wiążących decyzji / czas trwania w godzinach - Benchmark: < 1 dec/h = spotkanie marnowane, 1-3 dec/h = normalne, 3+ dec/h = efektywne - Jeśli dec/h < 1 — flag on red **Metryka 4: Dystrybucja wagi tematów (% czasu)** - Max 5-7 tematów. Co dostało najwięcej energii? Czy to się zgadza z tym, co *powinno* dostać? - Wskaż gdy ważny temat został prześlizgnięty, a pierdoły dostały wagę. **Metryka 5: Distribution of voice (szacunek)** - Kto mówił ile % czasu - Jeśli transkrypt labeled — podaj liczby. Jeśli nie — estymuj po stylu wypowiedzi, częstotliwości zwrotów do osób, długości fragmentów. Oznacz jako "estymacja". - Analityczny komentarz: kto dominował narracyjnie, kto był pasywny, czy dystrybucja pasuje do ról. ### Krok 2: Zidentyfikuj pain pointy (czerwone flagi) Maksymalnie **3 czerwone flagi**. To jest miejsce gdzie shelby-summary krzyczy. Każda flaga to: - Jedno zdanie co jest problemem - Jedno zdanie dlaczego to blokuje ruch do przodu Kryteria czerwonej flagi: - Decyzja odroczona po raz kolejny bez uzasadnienia - Zespół rozmawia o problemie X ale prawdziwy problem to Y, którego nikt nie dotyka - Brak właściciela czegoś krytycznego - Powtarzający się wzorzec "klikania kafelków zamiast decydowania" - Ucieczka w komfortowe techniczne niuanse gdy meta-pytanie jest niewygodne - Kluczowa osoba nieobecna, a zespół podejmuje decyzje jej dotyczące ### Krok 3: Shelby-Musk Verdict **Jedno zdanie.** Brutalne, esencjonalne, strategiczne. Musi krzyczeć w HTMLu (duża czcionka, wyróżnienie). Inspiracja stylistyczna: - **Musk**: pierwszoprincypialne, redukujące do fizyki problemu, ignorujące konwencje i politykę. "Dlaczego to w ogóle istnieje? Czy rozwiązuje problem którego nikt nie ma?" - **Shelby**: widzi układ sił, identyfikuje kto ma leverage, kto gra w co, gdzie jest realna wartość. "Stoją w miejscu bo nikt nie chce podjąć decyzji która kogoś zdenerwuje." **Wzorzec:** `[Diagnoza] — [Konsekwencja] — [Jeden ruch który to zmienia]` ### Krok 4: Quick action (opcjonalnie) Maksymalnie **1-2 konkretne ruchy** — co zrobić *teraz* żeby kolejne spotkanie nie było takie samo. Nie pełen action plan (od tego jest meeting-intel). Tylko dźwignia. --- ## Format wyjściowy **Zawsze HTML artifact** renderowany przez visualize:show_widget (interactive module). ### Struktura HTML (obowiązkowa) ``` ┌─────────────────────────────────────┐ │ HEADER │ │ - Tytuł spotkania │ │ - Meta: data | czas | uczestnicy │ ├─────────────────────────────────────┤ │ METRICS STRIP (4 karty) │ │ [Signal/Noise] [Konkret/Meta] │ │ [Decyzje/h] [Czas] │ │ Każda karta: duża liczba + mini │ │ komentarz (1 zdanie) │ ├─────────────────────────────────────┤ │ WYKRESY (2 obok siebie) │ │ 1. Waga tematów (horizontal bar) │ │ - % czasu per temat │ │ - Kolor czerwony dla pain point │ │ 2. Dystrybucja głosu (donut/bar) │ │ - Kto mówił ile (estymacja) │ │ Każdy wykres: 1-2 zdania komentarza │ ├─────────────────────────────────────┤ │ CZERWONE FLAGI (1-3) │ │ ⚠ [Flaga 1] — [dlaczego blokuje] │ │ ⚠ [Flaga 2] — ... │ ├─────────────────────────────────────┤ │ SHELBY-MUSK VERDICT │ │ Duża, wyróżniona ramka │ │ Jedno zdanie, krzyczące │ ├─────────────────────────────────────┤ │ QUICK MOVE (opcjonalnie) │ │ → [Jeden konkretny ruch] │ └─────────────────────────────────────┘ ``` ### Styl HTML - Używaj CSS variables z visualize (kolory, typografia, spacing) - Nigdy nie hardkoduj kolorów innych niż czerwony pain-point (czerwony to semantyka, nie style) - Czerwony: jedyny kolor akcentowy dla negatywnych sygnałów. Reszta stonowana. - Typografia: monospaced numbers dla metryk (tabular-nums) - Brak emoji (poza ⚠ dla red flag) - Brak ozdobników, brak gradientów, brak cieni. Czysto analitycznie. ### Wykresy - Inline SVG, nie biblioteki zewnętrzne (lightweight, kopiowalne) - Horizontal bar dla wagi tematów (czytelniejsze niż pie) - Prosty donut LUB horizontal bar dla dystrybucji głosu - Każdy wykres ma label procentowe bezpośrednio na/obok słupków — nie osobna legenda ### Komentarze pod wykresami - Max 2 zdania - Nie opisują co widać na wykresie (to widać). Opisują *co to znaczy*. - Przykład zły: "Temat architektury dostał 45% czasu." - Przykład dobry: "45% czasu poszło na temat architektury — ale żadna decyzja nie zapadła, więc to była dyskusja o dyskusji." ### Verdict box - Minimalne grube obramowanie - Typografia 1.4-1.6x większa od reszty tekstu - Tekst: maksymalnie 2 zdania, optymalnie 1 - Podpis pod spodem mniejszą czcionką: "— Shelby-Musk Verdict" ### Tryby - **Default (`shelby-summary`)**: pełen HTML artifact jak wyżej, ok. 1 strona renderu - **Deep (`shelby-summary --deep`)**: dodaje sekcję "TOPIC BREAKDOWN" przed verdict — dla każdego z top 3 tematów: co się działo + kto dominował + dlaczego to nie poszło dalej. Nadal HTML, nadal zwięzłe, ok. 1.5-2 strony. --- ## Kroki przetwarzania 1. **Przeczytaj transkrypt w całości.** Nie streszczaj — klasyfikuj fragmenty. 2. **Zaklasyfikuj każdy fragment** do jednej z kategorii: [signal | noise | meta-dyskusja | decyzja | dygresja]. To daje bazę do metryk. 3. **Oblicz metryki.** Signal/noise, konkret/meta, decyzje/h, dystrybucja tematów, dystrybucja voice. 4. **Zidentyfikuj top 3 pain pointy.** Nie szukaj problemów na siłę — jeśli spotkanie było dobre, napisz że było dobre. Ale jeśli widzisz wzorzec "klikania kafelków zamiast decydowania" — krzycz. 5. **Napisz Shelby-Musk verdict.** Jedno zdanie. Testuj: czy Musk mógłby to napisać? Czy redukuje problem do pierwszej zasady? Czy Shelby widziałby w tym układ sił? 6. **(Jeśli deep)** Zbuduj topic breakdown dla top 3 tematów. 7. **Załaduj `visualize:read_me` z modułem `interactive`** (jeśli jeszcze nie załadowany w tej konwersacji). 8. **Wywołaj `visualize:show_widget`** z gotowym HTML. 9. **Krótka wiadomość pod artifactem** (max 2-3 zdania) — NIE powtarzaj co jest w artifaccie. Możesz zapytać czy deep dive. --- ## Antywzorce - **Streszczenie** — jeśli piszesz "omówiono temat X" — źle. To jest meta-analiza, nie summary. - **Miękki verdict** — "zespół mógłby rozważyć" = nie shelby. "Stoją w miejscu bo X" = shelby. - **Tuzin red flags** — max 3. Priorytetyzuj. Dwanaście to nie meta-analiza, to wyrzut żalu. - **Udawanie twardych danych** — jeśli estymujesz, powiedz że estymujesz. Disclaimer przy voice distribution jest obowiązkowy gdy transkrypt nie jest labeled. - **Korpo-język** — "synergia", "leverage", "stakeholderzy zaangażowani w proces". Użytkownik chce brutalnej esencji, nie McKinsey brief. - **Za długie komentarze pod wykresami** — max 2 zdania. - **Pomijanie strategicznego wniosku** — verdict jest wymagany. Bez verdictu to tylko wykresy. - **Kolorowanie wszystkiego** — tylko pain pointy na czerwono. Reszta stonowana. - **Wulgaryzmy w outputie** — nie wulgarne, ale brutalne. Brutalność idzie przez celność i bezkompromisowość, nie przez przekleństwa. --- ## Przykłady Przykład dobrego verdictu: > "Projekt stoi w miejscu nie dlatego że Graph API jest trudne, tylko dlatego że zespół nie chce zdecydować czy to jest edukacja, narzędzie wewnętrzne czy produkt — a bez tej decyzji każda architektura jest uzasadniona i żadna nie jest." Przykład dobrego red flag: > ⚠ **Jacek trzyma klucz do odblokowania projektu od miesiąca i nie było go dziś na spotkaniu.** Zespół debatuje o kierunku bez osoby, która kontroluje jedyne wyjście z martwego punktu. Przykład dobrego komentarza pod wykresem: > "35% czasu poszło na compliance i uprawnienia admina — ale to jest ucieczka w komfortowe techniczne niuanse. Prawdziwe pytanie 'po co to w ogóle robimy' dostało 5%." --- ## Język Output zawsze po polsku (dopasuj do języka transkryptu — ale default PL). Technical terms po angielsku jeśli tak są w transkrypcie. Verdict bezwzględnie po polsku — musi uderzyć po polsku.