Skill: Tabular Summary Discipline

Tables where they help comparison, bullets where they read better, and no 1-row 'tables'.

Overview

Pick the right shape for each piece of output. Claude uses a markdown table only when there are three or more rows, three or more columns and comparable units, and bullets otherwise, with sensible exceptions for side-by-side comparisons. Numbers are right-aligned, headers in Title Case, identifiers first, and no cell is left empty.

Use cases

  • Peer comparisons that fit on one screen

    Five peer accounts across industry, employees, stack and spend render as one comparable table with numbers right-aligned, instead of separate bullet groups the reader has to line up in their head.

  • No 1-row tables and no 12-item bullet walls

    A single fact becomes a sentence, a dozen value pairs become a two-column table, and a column that mixes units gets split. The brief stays easy to scan from top to bottom.

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 or more rows. A 1-row "table" is a sentence pretending to be a table. A 2-row table is usually two bullets.
  2. 3 or more columns. With 2 columns, you have a list of pairs, and 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", "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 when you're 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.
  • Header row in Title Case; cells, headings and all other text in sentence case.
  • No empty cells. Fill with "n/a"; an empty cell looks like a rendering bug. Don't use a dash as a filler.
  • Column order: identifier first, then categorical, then quantitative. (Example: company, industry, employees, revenue, stack.)

Anti-patterns

Anti-PatternFix
1-row table with column headersSentence: "Acme Corp has about 12,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 of "n/a"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