HG Insights|Phoenix

Skill: Tabular Summary Discipline

Outputs shaped to compress signal — tables where they help, bullets where they read better.

Overview

Pick the shape that fits the data, every time. Claude renders structured comparisons (3+ rows, 3+ columns, comparable units) as markdown tables and lighter content as bullets — instead of forcing a misshapen 1-row 'table' or buying a 12-item bullet list that should've been a 4-column table.

Use cases

  • Peer comparisons that fit on one screen

    5 peer accounts × 4 attributes (industry / employees / stack / spend) renders as a single comparable table — not a wall of bullet groups asking the reader to mentally align the 'industry' bullet with each company name.

  • No more 1-row 'tables' or 12-item bullet walls

    The output uses each shape where it actually helps. A two-fact comparison is a sentence. A 12-row install density is a table. The visual rhythm of the brief stays clean instead of veering between under- and over-formatted sections.

View full skill

Tabular Summary Discipline

When to use

  • Authoring a workflow output and choosing between a table and a bullet list.
  • Reviewing a generated section that uses one shape when the other would be clearer.

Decision rule

A markdown table is the right shape when all three are true:

  1. ≥ 3 rows. A 1-row "table" is a sentence pretending to be a table. A 2-row table is usually two bullets.
  2. ≥ 3 columns. With 2 columns, you have a list of pairs — bullets handle that better.
  3. Comparable units. Each column's cells answer the same question with the same units. A column that mixes "$1.2M" and "TBD" and "see notes" defeats the point.

If any of the three fails: use bullets.

When to break the rule

  • 2 rows × 4 columns of comparable units is fine — comparing two specific things side-by-side. Example: "Your account vs. closest peer" with 4 facts each.
  • 3 rows × 2 columns is also fine if the second column is dense (e.g., a description). The decision rule has a margin.

Layout conventions

  • Right-align numbers, left-align everything else.
  • Headers in title case, cells in sentence case.
  • No empty cells — fill with "—" or "n/a"; an empty cell looks like a rendering bug.
  • Column order: identifier first, then categorical, then quantitative. (Example: company / industry / employees / revenue / stack.)

Anti-patterns

Anti-patternFix
1-row table with column headersSentence: "Siemens has 316,000 employees."
Bullet list of 12 (item, value) pairs2-column table.
Table with mixed units in one columnSplit into separate tables, or unify the unit.
Table with one filler row "—"Drop the row; bullets work better.

Common pitfalls

  1. Using a table to look "data-driven". If bullets work, bullets win.
  2. Building a table from a single source then padding columns. Columns should answer different questions.
  3. Embedding tables 4+ levels deep. Markdown rendering breaks past 2 levels of nesting; flatten.

Reference