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.