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:
- 3 or more rows. A 1-row "table" is a sentence pretending to be a table. A 2-row table is usually two bullets.
- 3 or more columns. With 2 columns, you have a list of pairs, and bullets handle that better.
- 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-Pattern | Fix |
|---|---|
| 1-row table with column headers | Sentence: "Acme Corp has about 12,000 employees." |
| Bullet list of 12 (item, value) pairs | 2-column table. |
| Table with mixed units in one column | Split into separate tables, or unify the unit. |
| Table with one filler row of "n/a" | Drop the row; bullets work better. |
Common pitfalls
- Using a table to look "data-driven". If bullets work, bullets win.
- Building a table from a single source then padding columns. Columns should answer different questions.
- Embedding tables 4+ levels deep. Markdown rendering breaks past 2 levels of nesting; flatten.
Reference
- Full docs for LLMs: https://phoenix.hginsights.com/docs/llms-full.txt
- Related skills:
executive-prose-conventions,time-series-plotting