← Back to Skills

SKILL · workflow

Shelby Summary — Meta-Analytics

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.

spotkaniaanalitykaefektywnośćstrategiameta-analizasignal-to-noisepodejmowanie-decyzji

Install as Claude Code skill

Drop into ~/.claude/skills/<name>/SKILL.md

.skill

Shelby Summary — Meeting Meta-Analytics

What This Is

This is not a meeting summary. It's a meta-analysis of meeting efficiency — analytics that answer the question: "Where did the weight of this time actually go?"

Output is a concise inline-rendered HTML artifact that:

  1. Shows hard metrics (signal/noise, concrete vs. meta-discussion, topic distribution)
  2. Visualizes meeting weight on charts with short commentary
  3. Marks the biggest pain points literally in red
  4. Ends with one screaming strategic verdict in the style of Musk/Shelby

Philosophy: Maximum informativeness for deciding what to do next. Zero summarization. If the user wants a summary — they have meeting-summary. If they want full intelligence — they have my-meeting-intel. This skill is a complement, not a replacement.


When to Use

Invoke when the user says:

  • "shelby summary", "shelby-summary", "shelby-musk"
  • "meeting meta-analysis", "meeting analytics"
  • "analyze this call"
  • "how much substance was there", "what was this worth"
  • "signal to noise", "meeting efficiency"
  • or pastes a transcript wanting more than a summary but shorter than full meeting-intel

When NOT to Use

  • For a standard summary — use meeting-summary
  • For full strategic analysis — use my-meeting-intel or shelby

Input Handling

Accepts any meeting transcript (labeled or not). If speaker labels are missing — estimate, never block. Estimates are marked as estimates, but they are provided.

If the transcript is obviously too short (standup < 10 min, < 500 words) — shelby-summary doesn't make sense. Tell the user and redirect to meeting-summary.


Analysis Framework

Step 1: Calculate Metrics

Metric 1: Signal-to-Noise Ratio (0-100%)

  • Signal = concrete substantive content, facts, decisions, technical details, problem-solving
  • Noise = meta-discussion about process, digressions, repeating what's been said, circling the topic, substitute topics

Metric 2: Concrete vs. Meta-discussion (0-100%)

  • Concrete = talking about what to do / what is / what works / what doesn't
  • Meta = talking about how we should talk / what we should decide / whether this even makes sense
  • Difference vs. signal/noise: meta-discussion can be very signal-rich (important), but it shows the team hasn't decided fundamentals. High % meta = project identity crisis.

Metric 3: Decisions per Hour

  • Number of binding decisions / duration in hours
  • Benchmark: < 1 dec/h = meeting wasted, 1-3 dec/h = normal, 3+ dec/h = efficient
  • If dec/h < 1 — flag on red

Metric 4: Topic Weight Distribution (% of time)

  • Max 5-7 topics. What got the most energy? Does that match what should have gotten it?
  • Flag when an important topic was glossed over while trivia got weight.

Metric 5: Distribution of Voice (estimate)

  • Who spoke what % of the time
  • If transcript is labeled — provide numbers. If not — estimate from speech style, frequency of references to people, fragment length. Mark as "estimate".
  • Analytical comment: who dominated narratively, who was passive, whether distribution matches roles.

Step 2: Identify Pain Points (Red Flags)

Maximum 3 red flags. This is where shelby-summary screams. Each flag is:

  • One sentence stating the problem
  • One sentence explaining why it blocks forward motion

Red flag criteria:

  • Decision deferred again without justification
  • Team is discussing problem X but the real problem is Y, which nobody touches
  • No owner for something critical
  • Recurring pattern of "clicking tiles instead of deciding"
  • Escaping into comfortable technical minutiae when the meta-question is uncomfortable
  • Key person absent while the team makes decisions affecting them

Step 3: Shelby-Musk Verdict

One sentence. Brutal, essential, strategic. Must scream in the HTML (large font, emphasis).

Stylistic inspiration:

  • Musk: first-principles, reducing to the physics of the problem, ignoring convention and politics. "Why does this even exist? Does it solve a problem nobody has?"
  • Shelby: sees the power dynamics, identifies who has leverage, who's playing what, where the real value is. "They're stuck because nobody wants to make the decision that would upset someone."

Pattern: [Diagnosis] — [Consequence] — [One move that changes it]

Step 4: Quick Action (optional)

Maximum 1-2 concrete moves — what to do now so the next meeting isn't the same. Not a full action plan (that's what meeting-intel is for). Just the lever.


Output Format

Always an HTML artifact rendered via visualize:show_widget (interactive module).

HTML Structure (mandatory)

┌─────────────────────────────────────┐
│ HEADER                              │
│ - Meeting title                     │
│ - Meta: date | duration | attendees │
├─────────────────────────────────────┤
│ METRICS STRIP (4 cards)             │
│ [Signal/Noise] [Concrete/Meta]      │
│ [Decisions/h]  [Duration]           │
│ Each card: big number + mini        │
│ comment (1 sentence)                │
├─────────────────────────────────────┤
│ CHARTS (2 charts side by side)      │
│ 1. Topic weight (horizontal bar)    │
│    - % time per topic               │
│    - Red color for pain point       │
│ 2. Voice distribution (donut/bar)   │
│    - Who spoke how much (estimate)  │
│ Each chart: 1-2 sentence commentary │
├─────────────────────────────────────┤
│ RED FLAGS (1-3, red color)          │
│ ⚠ [Flag 1] — [why it blocks]        │
│ ⚠ [Flag 2] — ...                    │
├─────────────────────────────────────┤
│ SHELBY-MUSK VERDICT                 │
│ Large, emphasized frame             │
│ One sentence, screaming             │
├─────────────────────────────────────┤
│ QUICK MOVE (optional)               │
│ → [One concrete move]               │
└─────────────────────────────────────┘

HTML Style Guide

  • Use CSS variables from visualize (colors, typography, spacing)
  • Never hardcode colors other than red pain-point (red is semantic, not style)
  • Red: the only accent color for negative signals. Rest is subdued.
  • Typography: monospaced numbers for metrics (tabular-nums)
  • No emoji (except ⚠ for red flag)
  • No decorations, no gradients, no shadows. Purely analytical.

Charts

  • Inline SVG, no external libraries (lightweight, copyable)
  • Horizontal bar for topic weight (more readable than pie)
  • Simple donut OR horizontal bar for voice distribution
  • Each chart has percentage labels directly on/next to bars — no separate legend

Verdict Box

  • Minimal thick border
  • Typography 1.4-1.6x larger than the rest of the text
  • Text: maximum 2 sentences, optimally 1
  • Signature below in smaller font: "— Shelby-Musk Verdict"

Modes

  • Default (shelby-summary): full HTML artifact as above, ~1 rendered page
  • Deep (shelby-summary --deep): adds "TOPIC BREAKDOWN" section before verdict — for each top 3 topic: what happened + who dominated + why it didn't go further. Still HTML, still concise, ~1.5-2 pages.

Processing Steps

  1. Read the entire transcript. Don't summarize — classify fragments.
  2. Classify each fragment into one category: [signal | noise | meta-discussion | decision | digression]. This provides the base for metrics.
  3. Calculate metrics. Signal/noise, concrete/meta, decisions/h, topic distribution, voice distribution.
  4. Identify top 3 pain points. Don't force problems — if the meeting was good, say it was good. But if you see the "clicking tiles instead of deciding" pattern — scream.
  5. Write the Shelby-Musk verdict. One sentence. Test: could Musk write this? Does it reduce the problem to first principles? Would Shelby see the power dynamics?
  6. (If deep) Build topic breakdown for top 3 topics.
  7. Load visualize:read_me with interactive module (if not already loaded in this conversation).
  8. Call visualize:show_widget with the finished HTML.
  9. Short message under the artifact (max 2-3 sentences) — DON'T repeat what's in the artifact. You can ask about deep dive.

Anti-Patterns

  • Summarizing — if you're writing "topic X was discussed" — wrong. This is meta-analysis, not summary.
  • Soft verdict — "the team could consider" = not shelby. "They're stuck because X" = shelby.
  • A dozen red flags — max 3. Prioritize. Twelve isn't meta-analysis, it's a grievance dump.
  • Faking hard data — if you're estimating, say you're estimating. Voice distribution disclaimer is mandatory when transcript isn't labeled.
  • Corporate-speak — "synergy", "leverage", "stakeholders engaged in the process". The user wants brutal essence, not a McKinsey brief.
  • Overly long chart comments — max 2 sentences.
  • Skipping the strategic conclusion — verdict is required. Without verdict it's just charts.
  • Coloring everything — only pain points in red. Rest is subdued.
  • Profanity in output — not vulgar, but brutal. Brutality comes through precision and uncompromisingness, not through expletives.