tables

Name: tables
Author: scdenney

34stars0forks

How to install tables?

scdenney/open-science-skills/tables

$npx -y skills add scdenney/open-science-skills --skill tables

Installs into the current project.

Summary

Design and format publication-quality tables. Use for column order, row grouping, notes, statistical precision, accessibility, and reproducibility.

Files · 1

View on GitHub

SKILL.md

1	# Table Designer
2
3	## Heritage and scope
4
5	This is an original Open Science Skills workflow for table production in social-science manuscripts. It is general — apply to descriptive tables, regression tables, balance tables, and summary tables across any method. For tables whose interpretation depends on method-specific standards, also consult the relevant sibling skill (`conjoint-design`, `conjoint-diagnostics`, `list-experiment`, `topic-modeling`, `text-classification`, `vlm-ocr-pipeline`). For end-stage QA on a finished table set, hand off to `figure-table-audit`.
6
7	Tables are for precise reading. A good table is one where the relevant comparison can be made without arithmetic, and where every number that appears in the manuscript text can be traced back to a specific cell. If readers have to do mental subtraction to recover the substantive quantity, the table is the wrong shape.
8
9	## Instructions
10
11	### 1. Decide whether the result belongs in a table at all
12
13	Tables are for reading values; figures are for seeing patterns. Use a table when:
14
15	- Readers need exact values (descriptive statistics for a sample, balance check, key effect sizes for citation).
16	- The comparison spans many models or specifications and a coefficient plot would be too dense.
17	- Regulatory or replication norms require it (CONSORT flow numbers, baseline balance).
18
19	Use a figure when the substantive claim is a pattern — a slope, a non-monotonicity, a difference of differences. Many regression tables in social science would be more readable as coefficient plots with a small accompanying summary table.
20
21	### 2. State the comparison and the estimand before laying out the table
22
23	Write down, in one sentence, what the table is supposed to let the reader compare. The first column or first panel should anchor that comparison. Examples:
24
25	- "Effect of treatment on turnout, baseline → with covariates → with fixed effects → preferred specification."
26	- "Sample means by treatment arm, with balance test."
27	- "AMCEs by attribute, pooled and split by partisanship."
28
29	If the comparison is not clear, the table will read as a coefficient dump.
30
31	### 3. Choose column order to match the argument
32
33	Columns should mirror how the text walks the reader through the result:
34
35	- Regression tables: baseline / minimal-controls → preferred specification → robustness checks. Place the preferred model in a clearly labeled column, not necessarily the rightmost; readers focus on the column that the text says is preferred.
36	- Comparison tables: control / treatment 1 / treatment 2 / contrast(s), or pre / post / difference.
37	- Descriptive tables: full sample → analytic sample → by treatment arm; or order subgroups by substantive logic, not alphabetically.
38	- Do not let `stargazer`/`modelsummary` defaults dictate the order if it obscures the comparison — pass models in argument order that matches the manuscript.
39
40	### 4. Group rows and structure panels
41
42	- Group covariate blocks: treatment(s) at the top, then primary moderators, then controls, then fixed-effect indicators, then fit statistics.
43	- Use horizontal rules (or panel breaks) to separate blocks; do not let regression output run as a flat list.
44	- Suppress controls in the main table when there are many — show "Controls: yes" and put the full coefficient set in SI.
45	- For multi-panel tables, use a clear panel header (e.g., "Panel A. Full sample / Panel B. Eligible voters only") and keep column structure identical across panels.
46	- Order rows within a block by substantive interest, not alphabetically — readers expect the headline coefficient first.
47
48	### 5. Pick precision and uncertainty conventions and stick to them
49
50	- Choose decimal precision based on the meaningful digit, not on what the software prints. Two decimals for proportions, three for small effects, integer counts for N.
51	- Be consistent across tables in the manuscript: same precision for the same quantity.
52	- Show uncertainty as standard errors `(in parentheses)` OR confidence intervals `[in brackets]` — pick one convention and use it everywhere. Note the convention in the table notes.
53	- Significance stars (``, ``, `**`) are conventional but not required; if used, define thresholds in the notes consistently across tables.
54	- Always report N per column. Always report a fit statistic appropriate to the model (R² for OLS, pseudo-R² or log-likelihood for non-linear, ICC for multilevel).
55
56	### 6. Write self-contained titles and notes
57
58	A reader should be able to understand the table from title + notes alone. Title should name the estimand or model family, not just "Results."
59
60	Notes should specify:
61
62	- The dependent variable (and how it is coded).
63	- Treatment / condition coding and the omitted category.
64	- Controls included (or "Controls: yes; full list in SI").
65	- Fixed effects and clust

People who liked this also viewed

6 picks

Type

find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 20262.6M27k
grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026633k182k
vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026573k29k
improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026522k182k
setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026454k182k
triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026424k182k

tables

34stars0forks

View on GitHub

How to install tables?

scdenney/open-science-skills/tables

$npx -y skills add scdenney/open-science-skills --skill tables

Installs into the current project.

Summary

Design and format publication-quality tables. Use for column order, row grouping, notes, statistical precision, accessibility, and reproducibility.

Files · 1

View on GitHub

SKILL.md

1	# Table Designer
2
3	## Heritage and scope
4
5	This is an original Open Science Skills workflow for table production in social-science manuscripts. It is general — apply to descriptive tables, regression tables, balance tables, and summary tables across any method. For tables whose interpretation depends on method-specific standards, also consult the relevant sibling skill (`conjoint-design`, `conjoint-diagnostics`, `list-experiment`, `topic-modeling`, `text-classification`, `vlm-ocr-pipeline`). For end-stage QA on a finished table set, hand off to `figure-table-audit`.
6
7	Tables are for precise reading. A good table is one where the relevant comparison can be made without arithmetic, and where every number that appears in the manuscript text can be traced back to a specific cell. If readers have to do mental subtraction to recover the substantive quantity, the table is the wrong shape.
8
9	## Instructions
10
11	### 1. Decide whether the result belongs in a table at all
12
13	Tables are for reading values; figures are for seeing patterns. Use a table when:
14
15	- Readers need exact values (descriptive statistics for a sample, balance check, key effect sizes for citation).
16	- The comparison spans many models or specifications and a coefficient plot would be too dense.
17	- Regulatory or replication norms require it (CONSORT flow numbers, baseline balance).
18
19	Use a figure when the substantive claim is a pattern — a slope, a non-monotonicity, a difference of differences. Many regression tables in social science would be more readable as coefficient plots with a small accompanying summary table.
20
21	### 2. State the comparison and the estimand before laying out the table
22
23	Write down, in one sentence, what the table is supposed to let the reader compare. The first column or first panel should anchor that comparison. Examples:
24
25	- "Effect of treatment on turnout, baseline → with covariates → with fixed effects → preferred specification."
26	- "Sample means by treatment arm, with balance test."
27	- "AMCEs by attribute, pooled and split by partisanship."
28
29	If the comparison is not clear, the table will read as a coefficient dump.
30
31	### 3. Choose column order to match the argument
32
33	Columns should mirror how the text walks the reader through the result:
34
35	- Regression tables: baseline / minimal-controls → preferred specification → robustness checks. Place the preferred model in a clearly labeled column, not necessarily the rightmost; readers focus on the column that the text says is preferred.
36	- Comparison tables: control / treatment 1 / treatment 2 / contrast(s), or pre / post / difference.
37	- Descriptive tables: full sample → analytic sample → by treatment arm; or order subgroups by substantive logic, not alphabetically.
38	- Do not let `stargazer`/`modelsummary` defaults dictate the order if it obscures the comparison — pass models in argument order that matches the manuscript.
39
40	### 4. Group rows and structure panels
41
42	- Group covariate blocks: treatment(s) at the top, then primary moderators, then controls, then fixed-effect indicators, then fit statistics.
43	- Use horizontal rules (or panel breaks) to separate blocks; do not let regression output run as a flat list.
44	- Suppress controls in the main table when there are many — show "Controls: yes" and put the full coefficient set in SI.
45	- For multi-panel tables, use a clear panel header (e.g., "Panel A. Full sample / Panel B. Eligible voters only") and keep column structure identical across panels.
46	- Order rows within a block by substantive interest, not alphabetically — readers expect the headline coefficient first.
47
48	### 5. Pick precision and uncertainty conventions and stick to them
49
50	- Choose decimal precision based on the meaningful digit, not on what the software prints. Two decimals for proportions, three for small effects, integer counts for N.
51	- Be consistent across tables in the manuscript: same precision for the same quantity.
52	- Show uncertainty as standard errors `(in parentheses)` OR confidence intervals `[in brackets]` — pick one convention and use it everywhere. Note the convention in the table notes.
53	- Significance stars (``, ``, `**`) are conventional but not required; if used, define thresholds in the notes consistently across tables.
54	- Always report N per column. Always report a fit statistic appropriate to the model (R² for OLS, pseudo-R² or log-likelihood for non-linear, ICC for multilevel).
55
56	### 6. Write self-contained titles and notes
57
58	A reader should be able to understand the table from title + notes alone. Title should name the estimand or model family, not just "Results."
59
60	Notes should specify:
61
62	- The dependent variable (and how it is coded).
63	- Treatment / condition coding and the omitted category.
64	- Controls included (or "Controls: yes; full list in SI").
65	- Fixed effects and clust

People who liked this also viewed

6 picks

Type