← ClaudeAtlas

chemistry-fill-every-row-of-the-comparator-tablelisted

Use at literature stage and study design when the source publishes performance broken out by class of system, and you are about to choose your evaluation panel with a filter written for throughput. Covers transcribing the table as rows, auditing the inclusion filter against those rows before it is frozen, and buying one target per row before a second target for any row.
tangxiangru/AutoR · ★ 805 · AI & Automation · score 79
Install: claude install-skill tangxiangru/AutoR
# Every row of the comparator table needs an arm of yours ## What goes wrong At literature stage you extract the incumbent's performance table — the one that breaks accuracy out by class of system — and you put it in a comparator section, correctly cited. Then you choose the panel you will actually run, and you choose it with a filter written for throughput: a size window, a component or chain count cap, "whatever the implementation supports as input", an availability or deposit-date cut, a per-target runtime ceiling. Finally you stratify your own results along an axis your hypotheses distinguish, which is not the table's axis. Each step is defensible. Together they delete whole rows of the table, and nothing downstream notices, because the filter is written in a vocabulary the rows do not use — it selects on size or on tooling, and the rows are classes. The published number for the deleted row survives in your report as a quotation with nothing of yours beside it. A reader looking for your result on that class finds a citation. This costs more than it looks. A per-class claim is graded per class, so a missing row reads as work not done rather than as coverage foregone. And a claim that one method handles several classes — "general-purpose", "unified", "one model for all of them" — is supported only by the same model run unchanged on each class. Depth inside one class does not substitute, however many targets that depth contains. ## What to do **1. Transcribe the table