--- name: shelby-summary title: Shelby Summary — Meeting Meta-Analytics description: "Meta-analytical meeting breakdown — not a summary, but an efficiency analysis. Produces signal/noise ratio, decision rate, topic weight distribution, voice distribution, red flags, and a brutal one-sentence Shelby-Musk verdict. Use for meetings over 10 minutes when you need to understand where the time actually went." category: review tags: - spotkania - analityka - efektywność - strategia - meta-analiza source: https://madejski.ai/skilloteka/shelby-summary locale: en license: MIT --- --- name: shelby-summary description: "Meta-analityczne podsumowanie spotkania — nie streszczenie, tylko analiza wagi i efektywności. Używaj gdy Michał mówi 'shelby summary', 'shelby-summary', 'meta analiza spotkania', 'analityka spotkania', 'zrób analityke tego callu', 'ile było konkretu', 'co tu było warte', 'signal to noise', 'efektywność spotkania', 'shelby-musk', albo wkleja transkrypt i chce czegoś więcej niż summary ale krócej niż full meeting-intel. To dopełnienie do zwykłego summary, nie zamiennik. Output to zwięzły HTML artifact z metrykami, wykresami i brutalnym strategicznym wnioskiem w stylu Muska/Shelby'ego. Nie wywołuj tego skilla dla zwykłego podsumowania (użyj meeting-summary) ani dla pełnej analizy strategicznej (użyj my-meeting-intel lub shelby)." --- # Shelby Summary — Meta-Analytics dla 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 Michał chce streszczenia — ma `meeting-summary`. Jeśli chce pełnej intelligence — ma `my-meeting-intel`. Ten skill jest dopełnieniem, nie zamiennikiem. --- ## 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 Michałowi i przekieruj do `meeting-summary`. --- ## Analysis Framework ### Krok 1: Oblicz metryki (Combo A+B+C, ale z summaries, nie raw data) **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. - W przyszłości gdy transkrypty będą labeled po tonie głosu — skill automatycznie użyje twardych danych. Dziś radzi sobie z estymacją. ### 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]` Przykład dobrego verdictu: > "Stoją w miejscu bo nie ma architekta i wolą klikać kafelki w Azure zamiast zdecydować czy to jest edukacja, narzędzie wewnętrzne czy produkt. Dopóki nie odpowiedzą na to jedno pytanie, każde kolejne spotkanie będzie dokładnie takie samo." Przykład złego verdictu (za ogólne, za miękkie): > "Zespół powinien rozważyć lepszą komunikację i być może zaprosić więcej osób do dyskusji." ### 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. --- ## Output Format **Zawsze HTML artifact** renderowany przez visualize:show_widget (interactive module). ### Struktura HTML (obowiązkowa) ``` ┌─────────────────────────────────────┐ │ HEADER │ │ - Tytuł spotkania │ │ - Meta: data | czas | uczestnicy │ ├─────────────────────────────────────┤ │ METRICS STRIP (4 cards) │ │ [Signal/Noise] [Konkret/Meta] │ │ [Decyzje/h] [Czas] │ │ Każda karta: duża liczba + mini │ │ komentarz (1 zdanie) │ ├─────────────────────────────────────┤ │ CHARTS (2 wykresy obok siebie) │ │ 1. Topic weight (horizontal bar) │ │ - % czasu per temat │ │ - Kolor czerwony dla pain point │ │ 2. Voice distribution (donut/bar) │ │ - Kto mówił ile (estymacja) │ │ Każdy wykres: 1-2 zdania komentarza │ ├─────────────────────────────────────┤ │ RED FLAGS (1-3, kolor czerwony) │ │ ⚠ [Flaga 1] — [dlaczego blokuje] │ │ ⚠ [Flaga 2] — ... │ ├─────────────────────────────────────┤ │ SHELBY-MUSK VERDICT │ │ Duża, wyróżniona ramka │ │ Jedno zdanie, krzyczące │ ├─────────────────────────────────────┤ │ QUICK MOVE (opcjonalnie) │ │ → [Jeden konkretny ruch] │ └─────────────────────────────────────┘ ``` ### Style guide dla HTML **Design tokens** (brane z visualize:read_me → interactive module — zawsze ładować przed renderowaniem): - Używaj CSS variables dostarczanych przez visualize (kolory, typografia, spacing) - Nigdy nie hardkoduj kolorów innych niż czerwony pain-point (bo 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 topic weight (czytelniejsze niż pie) - Prosty donut LUB horizontal bar dla voice distribution - 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. --- ## Processing Steps 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. --- ## Anti-Patterns - ❌ **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". Michał 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** — Michał wprost powiedział: nie wulgarne, ale brutalne. Brutalność idzie przez celność i bezkompromisowość, nie przez przekleństwa. --- ## Examples Przykład dobrego verdictu (z kontekstu spotkania o projekt transkrypcji Teams): > "Projekt stoi w miejscu nie dlatego że Graph API jest trudne, tylko dlatego że zespół nie chce zdecydować czy to jest edukacja, narzędzie 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 topic weight: > "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%." --- ## Language Output zawsze po polsku (dopasuj do języka transkryptu — ale Michał mówi po polsku, więc default PL). Technical terms po angielsku jeśli tak są w transkrypcie. Verdict bezwzględnie po polsku — musi uderzyć po polsku.