draft-polisher

Name: draft-polisher
Author: WILLOSCAR

489stars39forks

How to install draft-polisher?

willoscar/research-units-pipeline-skills/draft-polisher

$npx -y skills add WILLOSCAR/research-units-pipeline-skills --skill draft-polisher

Installs into the current project.

Summary

Audit-style editing pass for output/DRAFT.md: remove template boilerplate, improve coherence, and enforce citation anchoring. Trigger: polish draft, de-template, coherence pass, remove boilerplate, 润色, 去套话, 去重复, 统一术语. Use when: a first-pass draft exists but reads like s

Files · 1

View on GitHub

SKILL.md

1	# Draft Polisher (Audit-style editing)
2
3	Goal: turn a first-pass draft into readable survey prose without breaking the evidence contract.
4
5	This is a local polish pass: de-template + coherence + terminology + redundancy pruning.
6
7	Note: if the main issue is structural redundancy from section accumulation, push the change upstream to `sections/` and use `paragraph-curator` before merge. `draft-polisher` should not be the primary place where you decide which paragraphs to keep.
8
9
10
11	## Role cards (use explicitly)
12
13	### Style Harmonizer (editor)
14
15	Mission: remove generator voice and make prose read like one author wrote it.
16
17	Do:
18	- Delete narration openers and slide navigation; replace with argument bridges.
19	- Vary rhythm; remove repeated template stems.
20	- Collapse repeated disclaimers into one front-matter methodology paragraph.
21
22	Avoid:
23	- Adding or removing citation keys.
24	- Moving citations across subsections.
25
26	### Evidence Contract Guard (skeptic)
27
28	Mission: prevent polishing from inflating claims beyond evidence.
29
30	Do:
31	- Keep quantitative statements scoped (task/metric/constraint) or weaken them.
32	- Treat missing evidence as a failure signal; route upstream rather than rewriting around gaps.
33
34	Avoid:
35	- Overconfident language when evidence is abstract-only.
36
37
38	## Role prompt: Style Harmonizer (editor expert)
39
40	```text
41	You are the style and coherence editor for a technical survey.
42
43	Your goal is to make the draft read like one careful author wrote it, without changing the evidence contract.
44
45	Hard constraints:
46	- do not add/remove citation keys
47	- do not move citations across ### subsections
48	- do not strengthen claims beyond what existing citations support
49
50	High-leverage edits:
51	- delete generator voice (This subsection..., Next we move..., We now turn...)
52	- replace navigation with argument bridges (content-bearing handoffs)
53	- collapse repeated disclaimers into one methodology paragraph in front matter
54	- keep quantitative statements well-scoped (task/metric/constraint in the same sentence)
55
56	Working style:
57	- rewrite sentences so they carry content, not process
58	- vary rhythm, but avoid “template stems” repeating across H3s
59	```
60
61	## Inputs
62
63	- `output/DRAFT.md`
64	- Optional context (read-only; helps avoid “polish drift”):
65	- `outline/outline.yml`
66	- `outline/subsection_briefs.jsonl`
67	- `outline/evidence_drafts.jsonl`
68	- `citations/ref.bib`
69
70	## Outputs
71
72	- `output/DRAFT.md` (in-place refinement)
73	- `output/citation_anchors.prepolish.jsonl` (baseline, generated on first run by the script)
74
75	## Non-negotiables (hard rules)
76
77	1) Citation keys are immutable
78	- Do not add new `[@BibKey]` keys.
79	- Do not delete citation markers.
80	- If `citations/ref.bib` exists, do not introduce any key that is not defined there.
81
82	2) Citation anchoring is immutable
83	- Do not move citations across `###` subsections.
84	- If you must restructure across subsections, stop and push the change upstream (outline/briefs/evidence), then regenerate.
85
86	3) No evidence inflation
87	- If a sentence sounds stronger than the evidence level (abstract-only), rewrite it into a qualified statement.
88	- When in doubt, check the subsection’s evidence pack in `outline/evidence_drafts.jsonl` and keep claims aligned to snippets.
89
90	4) Citation shape normalization
91	- Merge adjacent citation blocks in the same sentence (avoid `[@a] [@b]`).
92	- Deduplicate keys inside one block (avoid `[@a; @a]`).
93	- Avoid tail-only citation dumps: keep some citations in the claim sentence itself (mid-sentence), not only paragraph end.
94
95	5) Quantitative claim hygiene
96	- If you keep a number, ensure the sentence also states (without guessing): task type + metric definition + relevant constraint (budget/cost/tool access), and the citation is embedded in that sentence.
97	- Avoid ambiguous model naming (e.g., “GPT-5”) unless the cited paper uses that exact label; otherwise use the paper’s naming or a neutral description.
98
99	6) No pipeline voice
100	- Remove scaffolding phrases like:
101	- “We use the following working claim …”
102	- “The main axes we track are …”
103	- “abstracts are treated as verification targets …”
104	- “Method note (evidence policy): …” (avoid labels; rewrite as plain survey methodology)
105	- “this run is …” (rewrite as survey methodology: “This survey is …”)
106	- “Scope and definitions / Design space / Evaluation practice …”
107	- “Next, we move from …”
108	- “We now turn to …”
109	- “From <X> to <Y>, ...” (title narration; rewrite as an argument bridge)
110	- “In the next section/subsection …”
111	- “Therefore/As a result, survey synthesis/comparisons should …” (rewrite as lit

People who liked this also viewed

6 picks

Type

draft-polisher

489stars39forks

View on GitHub

How to install draft-polisher?

willoscar/research-units-pipeline-skills/draft-polisher

$npx -y skills add WILLOSCAR/research-units-pipeline-skills --skill draft-polisher

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Draft Polisher (Audit-style editing)
2
3	Goal: turn a first-pass draft into readable survey prose without breaking the evidence contract.
4
5	This is a local polish pass: de-template + coherence + terminology + redundancy pruning.
6
7	Note: if the main issue is structural redundancy from section accumulation, push the change upstream to `sections/` and use `paragraph-curator` before merge. `draft-polisher` should not be the primary place where you decide which paragraphs to keep.
8
9
10
11	## Role cards (use explicitly)
12
13	### Style Harmonizer (editor)
14
15	Mission: remove generator voice and make prose read like one author wrote it.
16
17	Do:
18	- Delete narration openers and slide navigation; replace with argument bridges.
19	- Vary rhythm; remove repeated template stems.
20	- Collapse repeated disclaimers into one front-matter methodology paragraph.
21
22	Avoid:
23	- Adding or removing citation keys.
24	- Moving citations across subsections.
25
26	### Evidence Contract Guard (skeptic)
27
28	Mission: prevent polishing from inflating claims beyond evidence.
29
30	Do:
31	- Keep quantitative statements scoped (task/metric/constraint) or weaken them.
32	- Treat missing evidence as a failure signal; route upstream rather than rewriting around gaps.
33
34	Avoid:
35	- Overconfident language when evidence is abstract-only.
36
37
38	## Role prompt: Style Harmonizer (editor expert)
39
40	```text
41	You are the style and coherence editor for a technical survey.
42
43	Your goal is to make the draft read like one careful author wrote it, without changing the evidence contract.
44
45	Hard constraints:
46	- do not add/remove citation keys
47	- do not move citations across ### subsections
48	- do not strengthen claims beyond what existing citations support
49
50	High-leverage edits:
51	- delete generator voice (This subsection..., Next we move..., We now turn...)
52	- replace navigation with argument bridges (content-bearing handoffs)
53	- collapse repeated disclaimers into one methodology paragraph in front matter
54	- keep quantitative statements well-scoped (task/metric/constraint in the same sentence)
55
56	Working style:
57	- rewrite sentences so they carry content, not process
58	- vary rhythm, but avoid “template stems” repeating across H3s
59	```
60
61	## Inputs
62
63	- `output/DRAFT.md`
64	- Optional context (read-only; helps avoid “polish drift”):
65	- `outline/outline.yml`
66	- `outline/subsection_briefs.jsonl`
67	- `outline/evidence_drafts.jsonl`
68	- `citations/ref.bib`
69
70	## Outputs
71
72	- `output/DRAFT.md` (in-place refinement)
73	- `output/citation_anchors.prepolish.jsonl` (baseline, generated on first run by the script)
74
75	## Non-negotiables (hard rules)
76
77	1) Citation keys are immutable
78	- Do not add new `[@BibKey]` keys.
79	- Do not delete citation markers.
80	- If `citations/ref.bib` exists, do not introduce any key that is not defined there.
81
82	2) Citation anchoring is immutable
83	- Do not move citations across `###` subsections.
84	- If you must restructure across subsections, stop and push the change upstream (outline/briefs/evidence), then regenerate.
85
86	3) No evidence inflation
87	- If a sentence sounds stronger than the evidence level (abstract-only), rewrite it into a qualified statement.
88	- When in doubt, check the subsection’s evidence pack in `outline/evidence_drafts.jsonl` and keep claims aligned to snippets.
89
90	4) Citation shape normalization
91	- Merge adjacent citation blocks in the same sentence (avoid `[@a] [@b]`).
92	- Deduplicate keys inside one block (avoid `[@a; @a]`).
93	- Avoid tail-only citation dumps: keep some citations in the claim sentence itself (mid-sentence), not only paragraph end.
94
95	5) Quantitative claim hygiene
96	- If you keep a number, ensure the sentence also states (without guessing): task type + metric definition + relevant constraint (budget/cost/tool access), and the citation is embedded in that sentence.
97	- Avoid ambiguous model naming (e.g., “GPT-5”) unless the cited paper uses that exact label; otherwise use the paper’s naming or a neutral description.
98
99	6) No pipeline voice
100	- Remove scaffolding phrases like:
101	- “We use the following working claim …”
102	- “The main axes we track are …”
103	- “abstracts are treated as verification targets …”
104	- “Method note (evidence policy): …” (avoid labels; rewrite as plain survey methodology)
105	- “this run is …” (rewrite as survey methodology: “This survey is …”)
106	- “Scope and definitions / Design space / Evaluation practice …”
107	- “Next, we move from …”
108	- “We now turn to …”
109	- “From <X> to <Y>, ...” (title narration; rewrite as an argument bridge)
110	- “In the next section/subsection …”
111	- “Therefore/As a result, survey synthesis/comparisons should …” (rewrite as lit

People who liked this also viewed

6 picks

Type