table-schema_skill
- Python
109
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill willoscar/research-units-pipeline-skills --skill table-schema- SKILL.md5.7 KB
Overview
This skill designs evidence-first, two-layer table schemas for surveys so tables are answerable and verifiable before typesetting. It produces both internal index tables for coverage/debugging and reader-facing Appendix tables suitable for publication. The schema maps every column to concrete upstream evidence fields and enforces short, non-paragraph cells.
How this skill works
I inspect the outline, subsection briefs, and evidence drafts (plus an optional GOAL) to choose table questions, row units, and columns that can be filled without guessing. For each table I specify the question it answers, the row unit, column definitions and cell-style constraints, and an explicit evidence mapping to upstream fields. I output a two-layer schema: at least two index tables and two Appendix tables, each with publishable captions and fillability guarantees.
When to use it
- After evidence packs exist and you need verifiable tables before LaTeX (Stage C4).
- When you want reader-focused tables, not pipeline/internal logs.
- To ensure every table column can be filled from existing evidence without invention.
- When the paper outline and subsection briefs are stable and you can ground table axes.
Best practices
- Make each table answer one clear reader question; avoid mega-tables.
- Map every column to a specific upstream field (no TODOs or placeholders).
- Keep cell style to short phrases or controlled tokens; avoid paragraph cells.
- Separate two layers: exhaustive internal index vs. concise, publishable Appendix.
- Prefer small, fillable tables over broad, unfillable ones.
Example use cases
- Create an index table mapping H3 subsections to axes and representative works for internal evidence scans.
- Design an Appendix method map: one row per work with core idea, interface assumptions, and key refs.
- Produce an Appendix benchmark map listing task+metric, protocol constraints, and canonical refs.
- Validate that a planned Appendix column (e.g., 'key protocol constraint') is actually present in evidence_drafts before committing.
FAQ
Reject or redesign the column. Every column must map to concrete upstream fields; otherwise move the item to an internal audit or collect additional evidence first.
How many tables are required?
Non-negotiable minimum: at least two index tables and two Appendix tables. Prefer multiple small tables that each answer a single question.