The tables people work in — scannable rows, sortable and filterable, paginated not endless, responsive on a phone, and honest about loading, empty, and error.
Free & open · no signup · read-only — it ends by asking · nothing leaves your machine
You are working inside this repo. Mission: audit every table and data grid the product renders — the surfaces where users scan, sort, filter, and act on rows — and find the ones that overwhelm, hide their controls, or fall apart on a phone.
Read-only pass. Drive the tables in the running app or read their components, column configs, and data hooks; your only write is the report file.
Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.
alignment (numbers right, text left), row height and zebra, the column the eye needs first; the wall of same-weight text
sorting, filtering, and search on the columns people actually query; the 500-row table with no way to narrow it
pagination, infinite scroll, or virtualization at scale; the grid that renders every row and janks
sensible defaults, widths that fit content, control over which columns show; horizontal scroll that hides the key column
per-row and bulk actions reachable and clear; the action hidden until hover, invisible to touch
loading (skeleton rows), empty, error, and filtered-to-nothing all designed, not a blank grid
what a table becomes on a phone: horizontal scroll, stacked cards, or priority columns — not a crushed desktop grid
real table semantics, header associations, sort announced, keyboard movement across cells and controls
One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.
Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.
List every table and grid.
Cite the table and component for every finding.
Rank by how much each blocks real work.
Create TABLES.md at repo root.
Copy it and paste it into your agent inside the repo you want checked.
Install the goal plugin once — two commands — then just type /goal:tables-data-grid.
/plugin marketplace add GhostlyGawd/goal-prompts/plugin install goal@goal-promptsOr install only this Goal Prompt as /goal-tables-data-grid:
curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=147 shLet an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.
https://goal-prompts.vercel.app/raw/147.mdNothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.
# Goal: Tables & Data-Grid Audit You are working inside this repo. Mission: audit every table and data grid the product renders — the surfaces where users scan, sort, filter, and act on rows — and find the ones that overwhelm, hide their controls, or fall apart on a phone. Read-only pass. Drive the tables in the running app or read their components, column configs, and data hooks; your only write is the report file. ## Phase 1 — Inventory the tables - List every table and grid: what data it shows, how many rows and columns it can reach, and who works in it. - For each, note the features present: sort, filter, search, pagination, row selection, inline edit, column controls, export. - Capture how it is built (hand-rolled, grid library) and how it behaves at 10 rows versus 10,000. ## Phase 2 — Audit through 8 lenses Cite the table and component for every finding. 1. **Scannability** — alignment (numbers right, text left), row height and zebra, the column the eye needs first; the wall of same-weight text 2. **Find & sort** — sorting, filtering, and search on the columns people actually query; the 500-row table with no way to narrow it 3. **Volume & pagination** — pagination, infinite scroll, or virtualization at scale; the grid that renders every row and janks 4. **Column discipline** — sensible defaults, widths that fit content, control over which columns show; horizontal scroll that hides the key column 5. **Row actions & selection** — per-row and bulk actions reachable and clear; the action hidden until hover, invisible to touch 6. **State honesty** — loading (skeleton rows), empty, error, and filtered-to-nothing all designed, not a blank grid 7. **Responsive** — what a table becomes on a phone: horizontal scroll, stacked cards, or priority columns — not a crushed desktop grid 8. **Accessibility** — real table semantics, header associations, sort announced, keyboard movement across cells and controls ## Phase 3 — Curate - Rank by how much each blocks real work: no way to find a row in a large table outranks a cosmetic alignment nit. - Separate "unscannable", "cannot find/sort", "does not scale", and "broken on mobile"; fix find and scale first. - For each, name the table and the fix. ## Phase 4 — Report Create `TABLES.md` at repo root: 1. **Table inventory** — table · rows/cols reachable · features present · how built 2. **Findings** — each: lens · table · what the user cannot do · the fix 3. **Scale & mobile** — the tables that break under volume or on a phone, first 4. **The one rule** — the table pattern (sort/filter/paginate/responsive defaults) this codebase should adopt Start the report with today's date. If `TABLES.md` already exists from a previous run, read it first and lead with what changed since. ## Rules - Every finding names the table and the component behind it - A table you cannot sort, filter, or search is a list that happens to have columns - No tables or data grids in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding. - If a `reports/` directory exists at the repo root, write the report there instead of the root. - Before asking, present the top findings as a ranked list in plain words - Report only — end by asking which table fixes to make
reports/ directory exists at the repo root, write the report there instead of the root.Curated neighbors — briefs that answer the adjacent question, worth running in the same session.
Whether a dashboard answers its question in one glance — the metric that matters winning the top-left, signal over decoration, and density chosen, not accidental.
The spacing scale nobody wrote down — margins and paddings inventoried, grid discipline checked, alignment breaks found, and density judged screen by screen.
Every chart, graph, and metric put to the truth test — right form, honest axes, labeled and legible, accessible beyond color, and numbers that match their source.
Walk the product the way assistive-tech users do — keyboard only, then with a screen reader — and find every place that path breaks.
Where the eye actually goes versus where it should — focal points, size and weight and contrast doing real work, and the screens where everything shouts at once.
The type scale, or the lack of one — sizes, weights, line lengths and heights, font loading, and every place text is asked to do a job at the wrong size.
The palette as it actually ships — every hex in the codebase, contrast ratios computed, semantic drift named, and whether dark mode is a theme or an apology.
The spacing scale nobody wrote down — margins and paddings inventoried, grid discipline checked, alignment breaks found, and density judged screen by screen.
Runs inside these playbooks — curated sequences you can launch with one paste: