paper-notes

Name: paper-notes
Author: WILLOSCAR

489stars39forks

How to install paper-notes?

willoscar/research-units-pipeline-skills/paper-notes

$npx -y skills add WILLOSCAR/research-units-pipeline-skills --skill paper-notes

Installs into the current project.

Summary

Write structured notes for each paper in the core set into papers/paper_notes.jsonl (summary/method/results/limitations). Trigger: paper notes, structured notes, reading notes, 论文笔记, paper_notes.jsonl. Use when: survey 的 evidence 阶段（C3），已有 papers/core_set.csv（以及可选 ful

Files · 1

View on GitHub

SKILL.md

1	# Paper Notes
2
3	Produce consistent, searchable paper notes that later steps (claims, visuals, writing) can reliably synthesize.
4
5	This is still NO PROSE: keep notes as bullets / short fields, not narrative paragraphs.
6
7	## Load Order
8
9	Always read:
10	- `references/overview.md`
11	- `references/note_schema.md`
12
13	Read by task:
14	- `references/limitation_taxonomy.md` when writing or reviewing limitations (avoid boilerplate)
15	- `references/result_extraction_examples.md` when extracting key_results (good vs bad examples)
16	- `references/source_text_hygiene.md` when result/limitation fields still preserve paper self-narration or author-result wrappers
17
18	Machine-readable assets:
19	- `assets/note_schema.json` — JSONL record schema for validation
20	- `assets/evidence_tags.json` — evidence bank tagging categories (extensible without code changes)
21	- `assets/source_text_hygiene.json` — note-field source sentence cleanup policy
22
23	## Script Boundary
24
25	Use `scripts/run.py` only for:
26	- deterministic scaffold generation from core_set + metadata
27	- priority selection based on mapping coverage
28	- evidence bank construction from structured note fields
29
30	Do not treat `run.py` as the place for:
31	- paper-specific limitation prose (use `references/limitation_taxonomy.md` for guidance)
32	- domain-specific evaluation heuristics hidden in code
33	- reader-facing narrative text
34
35	## Role cards (prompt-level guidance)
36
37	- Close Reader
38	- Mission: extract what is specific and checkable (setup, method, metrics, limits).
39	- Do: name concrete tasks/benchmarks and what the paper actually measures.
40	- Avoid: generic summary boilerplate that could fit any paper.
41
42	- Results Recorder
43	- Mission: capture evaluation anchors that later writing needs.
44	- Do: record task + metric + constraints (budget/tool access) whenever available.
45	- Avoid: copying numbers without the evaluation setting that makes them meaningful.
46	- Avoid: promoting artifact introductions (`X enables ...`, `our framework features ...`) into `key_results`.
47	- Avoid: promoting benchmark-positioning, field-motivation, or author-navigation lines (`we apply ... and show ...`, `we then discuss how ...`) into `key_results`.
48
49	- Limitation Logger
50	- Mission: capture the caveats that change interpretation.
51	- Do: write paper-specific limitations (protocol mismatch, missing ablations, threat model gaps).
52	- Avoid: repeated generic limitations like “may not generalize” without specifics.
53
54
55	## When to use
56
57	- After you have a core set (and ideally a mapping) and need evidence-ready notes.
58	- Before writing a survey draft.
59
60	## Inputs
61
62	- `papers/core_set.csv`
63	- Optional: `outline/mapping.tsv` (to prioritize)
64	- Optional: `papers/fulltext_index.jsonl` + `papers/fulltext/*.txt` (if running in fulltext mode)
65
66	## Outputs
67
68	- `papers/paper_notes.jsonl` (JSONL; one record per paper)
69	- `papers/evidence_bank.jsonl` (JSONL; addressable evidence snippets derived from notes; profile target: course paper >=4, A150++ >=7 items/paper on average)
70
71	## Decision: evidence depth
72
73	- If you have extracted text (`papers/fulltext/*.txt`) → enrich key papers using fulltext snippets and set `evidence_level: "fulltext"`.
74	- If you only have abstracts (default) → keep long-tail notes abstract-level, but still fully enrich high-priority papers (see below).
75
76	## Workflow (heuristic)
77	Uses: `outline/mapping.tsv`, `papers/fulltext_index.jsonl`.
78
79
80	1. Ensure coverage: every `paper_id` in `papers/core_set.csv` must have one JSONL record.
81	2. Use mapping to choose high-priority papers:
82	- heavily reused across subsections
83	- pinned classics (ReAct/Toolformer/Reflexion… if in scope)
84	3. For high-priority papers, capture:
85	- 3–6 summary bullets (what’s new, what problem setting, what’s the loop)
86	- `method` (mechanism and architecture; what differs from baselines)
87	- `key_results` (benchmarks/metrics; include numbers if available)
88	- `limitations` (specific assumptions/failure modes; avoid generic boilerplate)
89	4. For long-tail papers:
90	- keep summary bullets short (abstract-derived is OK)
91	- still include at least one limitation, but make it specific when possible
92	5. Assign a stable `bibkey` for each paper for citation generation.
93
94	## Quality checklist
95
96	- [ ] Coverage: every `paper_id` in `papers/core_set.csv` appears in `papers/paper_notes.jsonl`.
97	- [ ] High-priority papers have non-`TODO` method/results/limitations.
98	- [ ] Limitations are not copy-pasted across many papers.
99	- [ ] `evidence_level` is set correctly (`abstract` vs `fulltext`).
100
101	- [ ] Evidence bank: `papers/evidence_bank.jsonl` exists and meets the selected profile (course paper >=

People who liked this also viewed

6 picks

Type

paper-notes

489stars39forks

View on GitHub

How to install paper-notes?

willoscar/research-units-pipeline-skills/paper-notes

$npx -y skills add WILLOSCAR/research-units-pipeline-skills --skill paper-notes

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Paper Notes
2
3	Produce consistent, searchable paper notes that later steps (claims, visuals, writing) can reliably synthesize.
4
5	This is still NO PROSE: keep notes as bullets / short fields, not narrative paragraphs.
6
7	## Load Order
8
9	Always read:
10	- `references/overview.md`
11	- `references/note_schema.md`
12
13	Read by task:
14	- `references/limitation_taxonomy.md` when writing or reviewing limitations (avoid boilerplate)
15	- `references/result_extraction_examples.md` when extracting key_results (good vs bad examples)
16	- `references/source_text_hygiene.md` when result/limitation fields still preserve paper self-narration or author-result wrappers
17
18	Machine-readable assets:
19	- `assets/note_schema.json` — JSONL record schema for validation
20	- `assets/evidence_tags.json` — evidence bank tagging categories (extensible without code changes)
21	- `assets/source_text_hygiene.json` — note-field source sentence cleanup policy
22
23	## Script Boundary
24
25	Use `scripts/run.py` only for:
26	- deterministic scaffold generation from core_set + metadata
27	- priority selection based on mapping coverage
28	- evidence bank construction from structured note fields
29
30	Do not treat `run.py` as the place for:
31	- paper-specific limitation prose (use `references/limitation_taxonomy.md` for guidance)
32	- domain-specific evaluation heuristics hidden in code
33	- reader-facing narrative text
34
35	## Role cards (prompt-level guidance)
36
37	- Close Reader
38	- Mission: extract what is specific and checkable (setup, method, metrics, limits).
39	- Do: name concrete tasks/benchmarks and what the paper actually measures.
40	- Avoid: generic summary boilerplate that could fit any paper.
41
42	- Results Recorder
43	- Mission: capture evaluation anchors that later writing needs.
44	- Do: record task + metric + constraints (budget/tool access) whenever available.
45	- Avoid: copying numbers without the evaluation setting that makes them meaningful.
46	- Avoid: promoting artifact introductions (`X enables ...`, `our framework features ...`) into `key_results`.
47	- Avoid: promoting benchmark-positioning, field-motivation, or author-navigation lines (`we apply ... and show ...`, `we then discuss how ...`) into `key_results`.
48
49	- Limitation Logger
50	- Mission: capture the caveats that change interpretation.
51	- Do: write paper-specific limitations (protocol mismatch, missing ablations, threat model gaps).
52	- Avoid: repeated generic limitations like “may not generalize” without specifics.
53
54
55	## When to use
56
57	- After you have a core set (and ideally a mapping) and need evidence-ready notes.
58	- Before writing a survey draft.
59
60	## Inputs
61
62	- `papers/core_set.csv`
63	- Optional: `outline/mapping.tsv` (to prioritize)
64	- Optional: `papers/fulltext_index.jsonl` + `papers/fulltext/*.txt` (if running in fulltext mode)
65
66	## Outputs
67
68	- `papers/paper_notes.jsonl` (JSONL; one record per paper)
69	- `papers/evidence_bank.jsonl` (JSONL; addressable evidence snippets derived from notes; profile target: course paper >=4, A150++ >=7 items/paper on average)
70
71	## Decision: evidence depth
72
73	- If you have extracted text (`papers/fulltext/*.txt`) → enrich key papers using fulltext snippets and set `evidence_level: "fulltext"`.
74	- If you only have abstracts (default) → keep long-tail notes abstract-level, but still fully enrich high-priority papers (see below).
75
76	## Workflow (heuristic)
77	Uses: `outline/mapping.tsv`, `papers/fulltext_index.jsonl`.
78
79
80	1. Ensure coverage: every `paper_id` in `papers/core_set.csv` must have one JSONL record.
81	2. Use mapping to choose high-priority papers:
82	- heavily reused across subsections
83	- pinned classics (ReAct/Toolformer/Reflexion… if in scope)
84	3. For high-priority papers, capture:
85	- 3–6 summary bullets (what’s new, what problem setting, what’s the loop)
86	- `method` (mechanism and architecture; what differs from baselines)
87	- `key_results` (benchmarks/metrics; include numbers if available)
88	- `limitations` (specific assumptions/failure modes; avoid generic boilerplate)
89	4. For long-tail papers:
90	- keep summary bullets short (abstract-derived is OK)
91	- still include at least one limitation, but make it specific when possible
92	5. Assign a stable `bibkey` for each paper for citation generation.
93
94	## Quality checklist
95
96	- [ ] Coverage: every `paper_id` in `papers/core_set.csv` appears in `papers/paper_notes.jsonl`.
97	- [ ] High-priority papers have non-`TODO` method/results/limitations.
98	- [ ] Limitations are not copy-pasted across many papers.
99	- [ ] `evidence_level` is set correctly (`abstract` vs `fulltext`).
100
101	- [ ] Evidence bank: `papers/evidence_bank.jsonl` exists and meets the selected profile (course paper >=

People who liked this also viewed

6 picks

Type