appendix-table-writer

Name: appendix-table-writer
Author: WILLOSCAR

33installs39forks

How to install appendix-table-writer?

willoscar/research-units-pipeline-skills/appendix-table-writer

$npx -y skills add WILLOSCAR/research-units-pipeline-skills --skill appendix-table-writer

Installs into the current project.

Summary

Curate reader-facing survey tables for the Appendix (clean layout + high information density), using only in-scope evidence and existing citation keys. Trigger: appendix tables, publishable tables, survey tables, reader tables, 附录表格, 可发表表格, 综述表格. Use when: you have C4 art

Files · 1

View on GitHub

SKILL.md

1	# Appendix Table Writer (publishable survey tables)
2
3	## Why this exists
4
5	The pipeline can produce index tables that are useful for planning/debugging, but read like internal artifacts.
6
7	This skill writes publishable, reader-facing tables that can live in an Appendix:
8	- cleaner layout
9	- higher information density
10	- survey-style organization (methods/benchmarks/risks), not intermediate state
11
12	Index tables remain in `outline/tables_index.md` and should not be copied verbatim into the paper.
13
14	## Inputs
15
16	- `outline/table_schema.md` (table intent + evidence mapping)
17	- `outline/tables_index.md` (internal index; optional but recommended)
18	- `outline/subsection_briefs.jsonl`
19	- `outline/evidence_drafts.jsonl`
20	- `outline/anchor_sheet.jsonl`
21	- `citations/ref.bib`
22	- Optional: `GOAL.md`
23
24	Read as needed:
25	- `references/table_cell_hygiene.md` when Appendix table cells still copy raw paper self-narration or generic result wrappers
26
27	Machine-readable assets:
28	- `assets/table_cell_hygiene.json`
29
30	## Output
31
32	- `outline/tables_appendix.md`
33
34	## Roles (use explicitly)
35
36	### Survey Table Curator (reader lens)
37
38	Mission: choose tables a reader actually wants in a survey Appendix.
39
40	Do:
41	- prefer 2-3 tables that answer big questions (methods, evaluation, risks)
42	- make rows comparable (same row unit across the table)
43	- make the table legible without reading the whole paper
44
45	Avoid:
46	- one-row-per-H3 index dumps
47	- columns named like internal axes ("axes", "blocking_missing", "evidence readiness")
48
49	### Production Editor (layout)
50
51	Mission: make the table look publishable in LaTeX.
52
53	Do:
54	- keep columns <= 4
55	- keep cells short (phrases, not sentences)
56	- use `<br>` sparingly (0-1 per cell; never a list dump)
57
58	Avoid:
59	- 6-8 columns with tiny unreadable text
60	- cells that look like notes (semicolon chains + slash lists + long parentheticals)
61	- slash-separated axis markers (A/B/C) in captions/headers/cells (post-merge voice gate will flag them); use commas or 'and' instead
62	- internal axis jargon that reads like an intermediate artifact once printed (e.g., calling table columns "tokens"); prefer "protocol details/metadata/assumptions"
63
64	### Evidence Steward (verifiability)
65
66	Mission: prevent hallucinations.
67
68	Do:
69	- every row must include citations in a dedicated column (e.g., "Key refs")
70	- only restate what appears in evidence packs / anchor sheet
71	- when evidence is thin, prefer fewer rows with stronger grounding
72
73	Avoid:
74	- "representative works" with no supporting claim in packs/anchors
75	- adding benchmark/method details not present upstream
76
77	## Table contract (publishable, Appendix-ready)
78
79	`outline/tables_appendix.md` must:
80	- contain >=1 Markdown table for `course_paper`, or >=2 for `survey` / `deep`
81	- use a caption line before each table, e.g. `Appendix Table A1. Representative systems by method family and evaluation setting`
82	- contain no headings (`#`, `##`, `###`) inside the file (the merger adds an Appendix heading)
83	- contain no placeholders (`TODO`, `TBD`, `FIXME`, ASCII three-dot ellipsis, unicode ellipsis)
84	- contain citations in rows using `[@BibKey]` (keys must exist in `citations/ref.bib`)
85	- avoid pipeline jargon and index-like column names
86
87	## Workflow (explicit inputs)
88
89	- Start from `GOAL.md` (scope) and `outline/table_schema.md` (what each table must answer).
90	- Read `queries.md:draft_profile` when present; `course_paper` uses one strong reader table by default, while `survey` / `deep` retain at least two.
91	- Use `outline/tables_index.md` as a shortlist source, but do not paste it verbatim.
92	- Fill rows/cells using `outline/subsection_briefs.jsonl`, `outline/evidence_drafts.jsonl`, and `outline/anchor_sheet.jsonl` (no guessing).
93	- Validate every cited key against `citations/ref.bib`.
94
95	## Recommended Appendix tables (default set)
96
97	If you are unsure what to build, start with these two:
98
99	1) Method/architecture map (representative works)
100	- Row unit: work/system line (not H3 id)
101	- Columns (example):
102	- Work (short name)
103	- Core idea (1 short phrase)
104	- Loop + interface assumptions (1 short phrase; reader-facing)
105	- Key refs (2-4 cite keys)
106
107	2) Evaluation protocol / benchmark map
108	- Row unit: benchmark / evaluation setting (or a canonical protocol dimension if benchmarks are thin)
109	- Columns (example):
110	- Benchmark / setting
111	- Task + metric (phrases, not definitions)
112	- Key protocol constraints (budget/cost/latency/steps/tool access/threat model)
113	- Key refs (2-4 cite keys)
114
115	Optional third (only if it stays clean):
116	3) Risk / threat-surface map
117	- Row unit: threat/failure mode category
118	- Columns: surfa

People who liked this also viewed

6 picks

Type

appendix-table-writer

33installs39forks

View on GitHub

How to install appendix-table-writer?

willoscar/research-units-pipeline-skills/appendix-table-writer

$npx -y skills add WILLOSCAR/research-units-pipeline-skills --skill appendix-table-writer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Appendix Table Writer (publishable survey tables)
2
3	## Why this exists
4
5	The pipeline can produce index tables that are useful for planning/debugging, but read like internal artifacts.
6
7	This skill writes publishable, reader-facing tables that can live in an Appendix:
8	- cleaner layout
9	- higher information density
10	- survey-style organization (methods/benchmarks/risks), not intermediate state
11
12	Index tables remain in `outline/tables_index.md` and should not be copied verbatim into the paper.
13
14	## Inputs
15
16	- `outline/table_schema.md` (table intent + evidence mapping)
17	- `outline/tables_index.md` (internal index; optional but recommended)
18	- `outline/subsection_briefs.jsonl`
19	- `outline/evidence_drafts.jsonl`
20	- `outline/anchor_sheet.jsonl`
21	- `citations/ref.bib`
22	- Optional: `GOAL.md`
23
24	Read as needed:
25	- `references/table_cell_hygiene.md` when Appendix table cells still copy raw paper self-narration or generic result wrappers
26
27	Machine-readable assets:
28	- `assets/table_cell_hygiene.json`
29
30	## Output
31
32	- `outline/tables_appendix.md`
33
34	## Roles (use explicitly)
35
36	### Survey Table Curator (reader lens)
37
38	Mission: choose tables a reader actually wants in a survey Appendix.
39
40	Do:
41	- prefer 2-3 tables that answer big questions (methods, evaluation, risks)
42	- make rows comparable (same row unit across the table)
43	- make the table legible without reading the whole paper
44
45	Avoid:
46	- one-row-per-H3 index dumps
47	- columns named like internal axes ("axes", "blocking_missing", "evidence readiness")
48
49	### Production Editor (layout)
50
51	Mission: make the table look publishable in LaTeX.
52
53	Do:
54	- keep columns <= 4
55	- keep cells short (phrases, not sentences)
56	- use `<br>` sparingly (0-1 per cell; never a list dump)
57
58	Avoid:
59	- 6-8 columns with tiny unreadable text
60	- cells that look like notes (semicolon chains + slash lists + long parentheticals)
61	- slash-separated axis markers (A/B/C) in captions/headers/cells (post-merge voice gate will flag them); use commas or 'and' instead
62	- internal axis jargon that reads like an intermediate artifact once printed (e.g., calling table columns "tokens"); prefer "protocol details/metadata/assumptions"
63
64	### Evidence Steward (verifiability)
65
66	Mission: prevent hallucinations.
67
68	Do:
69	- every row must include citations in a dedicated column (e.g., "Key refs")
70	- only restate what appears in evidence packs / anchor sheet
71	- when evidence is thin, prefer fewer rows with stronger grounding
72
73	Avoid:
74	- "representative works" with no supporting claim in packs/anchors
75	- adding benchmark/method details not present upstream
76
77	## Table contract (publishable, Appendix-ready)
78
79	`outline/tables_appendix.md` must:
80	- contain >=1 Markdown table for `course_paper`, or >=2 for `survey` / `deep`
81	- use a caption line before each table, e.g. `Appendix Table A1. Representative systems by method family and evaluation setting`
82	- contain no headings (`#`, `##`, `###`) inside the file (the merger adds an Appendix heading)
83	- contain no placeholders (`TODO`, `TBD`, `FIXME`, ASCII three-dot ellipsis, unicode ellipsis)
84	- contain citations in rows using `[@BibKey]` (keys must exist in `citations/ref.bib`)
85	- avoid pipeline jargon and index-like column names
86
87	## Workflow (explicit inputs)
88
89	- Start from `GOAL.md` (scope) and `outline/table_schema.md` (what each table must answer).
90	- Read `queries.md:draft_profile` when present; `course_paper` uses one strong reader table by default, while `survey` / `deep` retain at least two.
91	- Use `outline/tables_index.md` as a shortlist source, but do not paste it verbatim.
92	- Fill rows/cells using `outline/subsection_briefs.jsonl`, `outline/evidence_drafts.jsonl`, and `outline/anchor_sheet.jsonl` (no guessing).
93	- Validate every cited key against `citations/ref.bib`.
94
95	## Recommended Appendix tables (default set)
96
97	If you are unsure what to build, start with these two:
98
99	1) Method/architecture map (representative works)
100	- Row unit: work/system line (not H3 id)
101	- Columns (example):
102	- Work (short name)
103	- Core idea (1 short phrase)
104	- Loop + interface assumptions (1 short phrase; reader-facing)
105	- Key refs (2-4 cite keys)
106
107	2) Evaluation protocol / benchmark map
108	- Row unit: benchmark / evaluation setting (or a canonical protocol dimension if benchmarks are thin)
109	- Columns (example):
110	- Benchmark / setting
111	- Task + metric (phrases, not definitions)
112	- Key protocol constraints (budget/cost/latency/steps/tool access/threat model)
113	- Key refs (2-4 cite keys)
114
115	Optional third (only if it stays clean):
116	3) Risk / threat-surface map
117	- Row unit: threat/failure mode category
118	- Columns: surfa

People who liked this also viewed

6 picks

Type