Workflow·Content Management

Paper Writing

Name: Paper Writing
Author: SNL-UCSB

Research paper writing assistant that enforces Arpit Gupta's editorial principles, voice profile, and writing workflow.

You say

Buy it · $15 Read it before you buy $15 Written by SNL-UCSB · unverified publisher

Context cost: 61.9k tokensestimated from the bundle, loaded when it triggers
Bundle: 30 files · 247.7 kBtext throughout, nothing executable
Licence: MITpaid listing
Last change: —no release on file
Servers it uses: Noneruns standalone

What it does

Research paper writing assistant that enforces Arpit Gupta's editorial principles, voice profile, and writing workflow. MANDATORY TRIGGERS: Use this skill whenever the user mentions writing a paper, drafting a section, revising a section, editing a paper, reviewing a draft, rewriting an introduction, writing an evaluation, polishing prose, compressing text, or any task involving .tex files, Overleaf, conference submissions, or paper deadlines. Also trigger when the user mentions any paper by name (NetBurst, NetForge, BQT+, TurboTest, etc.) in a writing context.

Installed, it changes the agent in these ways.

What this skill changes about the agent is not written down here yet. The listing was collected from its source, and the description is in its own SKILL.md.

Workflow

Runs a procedure end to end.

academic-writingeditinglatex

Filed under

Content Management

The skill itself

This is the whole product. A skill is instructions the model reads, so there is nothing behind the listing you cannot see first — the front matter loads with every session, and the body below it loads when the skill triggers.

SKILL.md33.8 kB · 367 lines

--- name: paper-writing description: "Research paper writing assistant that enforces Arpit Gupta's editorial principles, voice profile, and writing workflow. MANDATORY TRIGGERS: Use this skill whenever the user mentions writing a paper, drafting a section, revising a section, editing a paper, reviewing a draft, rewriting an introduction, writing an evaluation, polishing prose, compressing text, or any task involving .tex files, Overleaf, conference submissions, or paper deadlines. Also trigger when the user mentions any paper by name (NetBurst, NetForge, BQT+, TurboTest, etc.) in a writing context. This skill should activate for ANY research writing task — sections, abstracts, rebuttals, camera-ready edits, cover letters, or response to reviewers." ---

6# Paper Writing Skill

8## How This Skill Works

10This skill encodes the writing methodology of the [Systems and Networking Lab (SNL)](https://github.com/SNL-UCSB) at UC Santa Barbara, derived from forensic analysis of 6 papers (8 submissions), 7,600+ Overleaf edits, 100+ tex file versions, and 5 peer review processes. See [*The Paper Behind the Paper*](https://sites.cs.ucsb.edu/~arpitgupta/blog/the-paper-behind-the-paper.html) for the full analysis. It works out of the box — the default rules are calibrated and battle-tested.

12### Three Layers

141. **The pipeline (fixed)**: A five-stage writing workflow. Does not change between users or papers.

162. **The voice and editorial rules (defaults provided, customizable)**: Sentence-level style, structural rules, compression patterns, section checklists. These ship with the SNL lab's rules as defaults. Students may customize by editing files in author_profile/ — see the README for what to change.

183. **The project context (per paper)**: Identity sentence, venue, contribution claims, locked decisions. Lives in a project_context.md in the paper's working directory.

20### How This Skill Connects to the Research Pipeline

22This skill does not operate in isolation. It is part of a three-skill family, and the artifacts from the other two skills are direct inputs to the writing process:

24**From the [literature-survey-skill](https://github.com/SNL-UCSB/literature-survey-skill):**

25- **Gap analysis** → feeds Brainstorming Phase 1 (Problem Discovery). The gaps the survey identified — missing quadrants, shared assumptions that break, unexplored combinations — are the structural limitations that motivate your paper.

26- **Writing craft extractions** (Pass 3+) → feed the Architecture stage and section drafting. The introduction anatomy, evaluation architecture, and design craft you extracted from the best papers in your area are the models for your own paper's structure.

27- **Competitive positioning** → feeds Brainstorming Phase 4. The invariant matrix and dependency graph from synthesis show exactly where your paper sits relative to existing work.

29**From the [data-visualization-skill](https://github.com/SNL-UCSB/data-visualization-skill):**

30- **Exploration** (exploration_log.md) → feeds Brainstorming Phase 3 (Evaluation Design). The exploration forced you to look at your data from multiple angles before forming hypotheses. The surprises you found — distributions you didn't expect, subgroups that behaved differently — shape what claims are defensible and where the real contribution lives.

31- **Brainstorm** (braindump.md) → feeds the figure/table plan. Each braindump articulates what question a figure answers, what you expected to see, and what would surprise you. These are the hypotheses your evaluation must validate.

32- **Plan + Execute** (plot_context.md) → feeds the Architecture stage's figure/table plan. Each plot_context records intent, variable mappings, plot type rationale, and design decisions — ready-made entries for the paper's figure plan.

33- **Analyze** (WALTER narrations) → feeds Evaluation Move 4 (Takeaway Synthesis). The WALTER Result — "what is the takeaway? does it connect back to the hypothesis?" — is a first draft of the Takeaway paragraph for that experiment cluster.

35The three skills create a closed loop: the literature survey reveals the gap and teaches you how accepted papers communicate; data visualization forces you to understand what your evidence actually shows and what hypotheses it validates; paper writing turns both into a publishable argument. **If the student has artifacts from the other skills, Claude MUST load them.**

37### When This Skill Triggers, Claude MUST:

391. Read this SKILL.md (already loaded)

402. Read ALL files in author_profile/ — these are the source of truth for editorial rules

413. Ask which paper the user is working on

424. Look for a project_context.md in the paper's working directory

435. If found, read it and treat it as binding constraints

446. If not found, run the **Structured Brainstorming** workflow below to create one

457. Check for artifacts from sibling skills — survey paper notes with craft extractions, exploration_log.md, braindump.md, plot_context.md, WALTER narrations. If found, load them as reference material for the relevant pipeline stages

47---

49## Structured Brainstorming — The Skill's Centerpiece

51**The biggest obstacle for students isn't writing — it's that their ideas live as unstructured intuitions.** They know something is interesting but can't articulate what or why. The brainstorming process transforms scattered thinking into a precise project context that drives every section of the paper.

53### How It Works

55Claude MUST read brainstorming_guide.md and walk the student through its 6 phases interactively. The phases are:

57| Phase | Focus | Key outcome |

58|-------|-------|-------------|

59| 1. Problem Discovery | Who suffers, what breaks, why it breaks structurally | The opening paragraph's stakes and the Problem Gap |

60| 2. Contribution Crystallization | Core claim, headline number, key abstraction name | The identity sentence and contribution list |

61| 3. Evaluation Design | Baselines, metrics, datasets, experiment-to-claim mapping | The evaluation plan that constrains what the introduction can promise |

62| 4. Positioning and Framing | Venue fit, competitive positioning, category creation vs. competition | The Related Work positioning sentence |

63| 5. Architecture and Constraints | Design pipeline, locked decisions, open questions | The Design section's structure and the project's scope |

64| 6. Narrative Spine | Story arc, the "inevitable" moment, the tweet-length pitch | The thread connecting every section |

66### Rules for Running Brainstorming

68- **Go phase by phase.** Don't skip ahead. Phase 1 (the problem) must be clear before Phase 2 (the contribution) makes sense.

69- **"I don't know" is a valid answer.** Flag it as an open question and move on. Gaps discovered now are cheap to fix; gaps discovered during review are expensive.

70- **Push back on vague answers.** "It's faster" → "Faster for whom? By how much? On what workload?" Every answer should be specific enough to appear in the paper.

71- **Distinguish structural from quantitative.** "Existing tools aren't accurate enough" is quantitative — it motivates more experiments. "Existing tools assume stationarity, which fails on bursty data" is structural — it motivates a new approach. Papers need structural gaps.

72- **After all phases, generate project_context.md** using the template in examples/project_context.md. See examples/netburst_project_context.md for a real example of what a complete project context looks like.

74---

76## Voice and Editorial Rules

78Claude MUST read these files from this skill's directory. They contain the detailed rules with examples.

80| File | What it controls |

81|---|---|

82| author_profile/editorial_principles.md | 14 cross-paper principles with evidence (introduction-twice, named-over-vague, what→why→so-what headings, compress-after-expanding, etc.) |

83| author_profile/craft_reference.md | **How to write (the positive layer).** Sentence-level style (~21-word mean, claim-first, active voice, named-over-vague, no filler), composition craft, and three registers: base/terse, conceptual/position, warm/narrative. Read while drafting a paragraph. |

84| author_profile/gate_mechanical.md | **The single mechanical grep gate (M1–M18).** Em-dashes, antithesis, intensifiers, banned + pompous + fancy verbs, throat-clearing, passive voice, wordiness, qualifiers, term-drift — one grep script. Run on every tex edit; the passive-voice scan also runs in the base gate. |

85| author_profile/gate_semantic.md | **The single reader-judgment gate (S1–S31).** Define-before-use, followability, parse-accessibility, thesis-tie, lexical + decomposition consistency, non-duplication, rigor/grounding, honest positioning, figures, and the **closure gate**. Runs in the red-team/loop pass. |

86| author_profile/compression_patterns.md | 7 compression operations with before/after examples and quantitative benchmarks |

87| author_profile/rhetorical_moves.md | Cross-section move sequences for introduction (6 moves), design (5 moves), evaluation (6 moves), related work (3 moves) |

88| author_profile/intervention_types.md | 7 types of advisor interventions — use this to simulate advisor feedback on drafts |

89| red_team_protocol.md | **Independent adversarial red-team** (evidence-gated): after the mechanical audit, a reviewer that did NOT write the text re-runs gate_mechanical.md and applies gate_semantic.md, and must return CLEAN before text ships. |

90| loop_mode.md | Resumable /loop audit-and-fix protocol: a disk-backed ledger, one section per iteration, self-terminating when clean. |

92### Quick Reference: Non-Negotiable Voice Rules

94These are extracted from the detailed files above. In case of conflict, the files are the source of truth.

96- Mean sentence length: ~21 words. Maximum: ~40 words (contribution lists only).

97- Topic sentences assert claims. Never open a paragraph with background or context.

98- Zero hedging. "We show" not "We believe." "X reduces Y by 13×" not "X may help reduce Y."

99- Active voice everywhere — no exceptions. Passive voice obscures agency and weakens prose.

100- No filler adjectives: never use "novel," "significant," "state-of-the-art," "comprehensive," "robust," "substantial," "promising," "impressive." Replace with specific numbers or delete.

101- Signpost through claims: section openers may state the section's conclusion ("This section shows that X reduces Y by 13×") but never use content-free placeholders ("In this section, we describe..."). The test: does the opener tell a skim-reader what the section *concludes*?

102- No exclamation marks. No rhetorical questions outside introductions.

103- Paragraphs: 4–6 sentences. Every paragraph does exactly one of: make a claim, present evidence, synthesize a takeaway.

104- Headings are claims, not topics. "Event-centric decomposition reduces error 13×" not "Experimental Results."

105- Named over vague: every mechanism, baseline, metric must have a proper name. If a term could apply to any paper in the field, it doesn't belong in this paper.

106- Interpret figures, don't just cite. "Figure 3 shows that X, confirming Y" not "See Figure 3."

107- Every evaluation subsection ends with a Takeaway paragraph.

108- Every design choice justified immediately. Not "we use X" but "we use X because Y."

109

110### Venue Adaptation

111

112- **Systems venues (NSDI, SIGCOMM, CoNEXT, IMC)**: Use \smartparagraph{} labels. Systems evaluation (latency, throughput, memory). Frame contributions as operational impact. Post-evaluation related work.

113- **ML venues (NeurIPS, ICLR, ICML)**: No \smartparagraph. Colon-style subtitles. Reproducibility checklist. Frame as methodological advances. Integrated related work.

114- **Workshop/short papers (HotNets, ANRW)**: Compress everything 50%. Lead with the intellectual provocation.

115

116---

117

118## Mandatory Style Audit (GATE — applies to ALL tex edits)

119

120**Before presenting or committing ANY new or modified tex content, Claude MUST run a sentence-level style audit.** This is not optional, not triggered by the user, and not limited to full section drafts — it applies to every edit, including paragraph-level changes, subsection additions, and overview rewrites.

121

122The audit checks every changed sentence against author_profile/gate_mechanical.md, author_profile/compression_patterns.md, and author_profile/craft_reference.md. Specifically, scan for and fix:

123

1240. **Mechanical gate (gate_mechanical.md) — run FIRST, with its greps.** Em-dashes (---, —, -- ) are BANNED. Antithesis/mirror flourishes ("X, not Y"; "whatever it is called"), editorializing closers ("the saving is the point", "is not real"), vacuous intensifiers ("in effect", "at its core"), rule-of-three decoration, throat-clearing openers ("Moreover", "Notably"), banned/pompous/fancy words, and content-free openers ("In this paper, we…") are BANNED. Target the plain, short, declarative register (craft_reference.md). Do NOT report the audit as passed without running the grep gate in that file.

1251. **Negation-first constructions**: "not X" or "rather than X" where the sentence should assert what something IS. Reframe positively.

1262. **Throat-clearing**: "We address this problem by", "To address this issue", "In order to", "It should be noted that", "Note that". Delete and lead with the action.

1273. **Hedging**: "can potentially", "can be expected to", "may help reduce", "it is possible that". Replace with assertive voice ("produces", "reduces", "achieves").

1284. **Generic adjectives**: "significant", "substantial", "highly desirable", "novel", "robust", "comprehensive". Replace with specific numbers or delete.

1295. **Sentence length**: Flag any sentence exceeding 40 words. Split or compress.

1306. **Passive voice**: "accuracy was achieved by X" → "X achieves". "Experiments were conducted on X" → "We evaluate on X". Active voice everywhere — no exceptions, including methods and evaluation. Run the passive-detection grep from author_profile/gate_mechanical.md (§Part C, M11) in this base gate; fix or justify every hit.

1317. **Missing citations**: Technical claims restated from other sections must carry forward their citations (Principle 14).

132

133**Process**: After writing, (a) run the grep gate in gate_mechanical.md Part C and fix every hit, then (b) read the changed text line by line for the items above. Report a summary table of violations found and fixed (category, count), INCLUDING the grep counts (em-dashes, flourishes) — not just "audited". Never claim the audit passed on a mental pass alone. Then (c) run the **independent adversarial red-team** (red_team_protocol.md): a reviewer that did NOT write the text re-runs gate_mechanical.md and applies author_profile/gate_semantic.md (define-before-use, followability, thesis-tie, lexical + decomposition consistency, non-duplication, mappability, honest positioning, and the closure gate) with a fresh-reader lens, returning a findings list, not a yes/no. Only text that survives (a) + (b) + (c), with the grep output pasted as evidence, is presented or committed. Per gate_semantic.md's **closure gate** (S31), iterate the red-team after every substantive change until a final closure reviewer returns zero CRITICAL/MAJOR; never defer residual items as "done."

134

135This gate is SEPARATE from and IN ADDITION TO the structural section checklists below.

136

137**Loop mode.** When invoked via /loop (e.g. "apply the paper-writing skill iteratively", "audit with loop"), follow loop_mode.md: a resumable, ledger-backed audit → red-team → fix cycle that processes one section per iteration and stops itself when every in-scope section is clean. The user need not specify which checks to run or when to stop — the protocol supplies those.

138

139---

140

141## Section Checklists

142

143After generating ANY section draft, Claude MUST also read the corresponding structural checklist and run it:

144

145| Section | Checklist file |

146|---|---|

147| Introduction | writing_checklists/intro_questions.md |

148| Evaluation | writing_checklists/evaluation_questions.md |

149| Design / Method | writing_checklists/design_questions.md |

150| Related Work | writing_checklists/related_work_questions.md |

151

152Flag every violation before presenting the draft. Severity levels: CRITICAL (structural — will cause rejection), MAJOR (visible to reviewers), MINOR (polish-level).

153

154## Section Rhetorical Moves

155

156For detailed guidance on move sequences within each section type, read from section_rhetorical_moves/:

157

158| Section | File | Key moves |

159|---|---|---|

160| Introduction | section_rhetorical_moves/introduction.md | Stakes → Problem Gap → Key Abstraction → Design Intuition → Contributions → Results Preview |

161| Evaluation | section_rhetorical_moves/evaluation.md | Setup Anchoring → Head-to-Head → Deep Dive → Takeaway Synthesis → Ablation → Robustness |

162| Design | section_rhetorical_moves/design.md | Abstraction Introduction → Design Justification → Component Architecture → Key Design Decision → Robustness |

163| Related Work | section_rhetorical_moves/related_work.md | Category Clustering → Per-Category Limitation → Positioning Sentence |

164

165These contain actionable guidance with concrete examples showing what works and what doesn't, drawn from accepted and rejected systems and ML papers.

166

167---

168

169## The Five-Stage Pipeline

170

171Every paper goes through these stages in order. Claude identifies which stage the user is in and enforces that stage's rules.

172

173### Stage 1: Structured Brainstorming → Project Context Creation

174

175**Gate**: The user must have a one-sentence identity statement and contribution claims written as results. If they don't, read brainstorming_guide.md and walk them through all 6 phases interactively. Don't rush — this is the most important stage. A vague project context produces a vague paper.

176

177After brainstorming, generate a project_context.md file using the template in examples/project_context.md and save it in the paper's working directory. See examples/netburst_project_context.md for a real example.

178

179**Important:** After creating project_context.md, add it to the project's .gitignore (create the file if it doesn't exist). This file contains strategic framing notes and advisor commentary that should not be committed to shared repositories by default.

180

181### Stage 2: Architecture

182

183**Gate**: Section outline with claim assignments, per-section narrative arcs, figure/table plan, evaluation structure, and page budget.

184

185**Craft reference**: If the student has run a literature survey (using the [literature-survey-skill](https://github.com/SNL-UCSB/literature-survey-skill) or manually), check for Pass 3+ paper notes with writing craft extractions — introduction anatomy, evaluation architecture, design section structure, and figure design choices from the strongest papers in their area. Load these as reference material for the architecture. The section structure of the best paper at your target venue is a better starting point for your outline than a generic template. Reading and writing develop together: craft patterns extracted during deep reading feed directly into the architecture of your own paper.

186

187**Figure/table plan from visualization artifacts**: If the student has been working with the [data-visualization-skill](https://github.com/SNL-UCSB/data-visualization-skill), check for plot_context.md files and WALTER narrations. Each plot_context.md records the intent, variable mappings, plot type rationale, and design decisions for a figure — these are ready-made entries for the figure/table plan below. Each WALTER narration (Hypothesis → Axes → Look here → Trend → Exception → Result) maps directly to the evaluation prose that will accompany the figure. The iteration the student did in the viz skill — exploring what the data shows, forming predictions, confronting surprises — has already determined which figures carry the argument. The architecture should reflect that.

188

189Output a structured table:

190

192|---------|-------|-----------|----------------|

193| ... | ... | ... | ... |

194

195**Non-data figure specs**: For each figure in the plan that is NOT a data figure (architecture diagrams, pipeline illustrations, concept diagrams, comparison schematics), read figure_synthesis_guide.md and run spec mode to produce a figure_spec.md. Data figures (CDFs, bar charts, heatmaps, scatter plots) should be routed to the [data-visualization-skill](https://github.com/SNL-UCSB/data-visualization-skill). The boundary is clear: if the figure requires experimental data to render, it goes through /viz; if it illustrates structure, flow, or concepts, it goes through figure synthesis.

196

197### Stage 3: Section Drafts

198

199**Enforced order**: Draft 0 Introduction → Evaluation → Design/Method → Background → Related Work → Final Introduction → Abstract.

200

201The introduction is written **twice**. This is the most impactful principle in the entire system (Principle 1).

202

203**Draft 0 Introduction** comes first. It is a framing scaffold — stakes, problem gap, rough contribution claims — that sets guardrails for the evaluation. Draft 0 clarifies what the paper is *trying* to show. It is explicitly disposable: it probably will not survive to the final version. Writing is a thinking tool, not just a communication tool — Draft 0 forces the student to externalize their framing before designing experiments.

204

205**The evaluation** comes next, constrained by Draft 0's guardrails. Then Design, Background, and Related Work.

206

207**The final introduction** is rewritten from scratch after the evaluation is complete. It promises exactly what the evidence supports — no more, no less. Draft 0 is reference material, not a starting point for editing. If the user asks to skip Draft 0 and go straight to evaluation, explain that evaluation without framing guardrails produces experiments that don't build toward a unified argument.

208

209**Per-section scaffolding**: Before writing any section's full prose, write the topic sentences first. Read them in sequence — they should form a coherent argument on their own. If the topic sentences don't flow, the paragraphs won't either. Fill in the full paragraphs only after the topic-sentence sequence holds together. In LaTeX, a practical technique is to annotate each paragraph with a purpose comment before writing prose:

210

211```latex

212\section{Introduction}

213% Stakes: who suffers and why the domain matters.

214...

215% Problem gap: structural limitation of current approaches.

216...

217% Key abstraction: named concept that captures our insight.

218...

219% Contributions: numbered, claim-first list.

220...

221```

222

223Each comment is a contract: the paragraph that follows must deliver on it. If a paragraph doesn't fit any comment, either the paragraph doesn't belong or a comment is missing.

224

225**Per-section audit**: After generating a draft, read and run the appropriate checklist. Flag every violation with severity level before presenting the draft.

226

227### Stage 4: Integration

228

229Cross-section consistency pass:

230- **Terminology drift**: Is the same concept called by the same name everywhere?

231- **Claim-evidence mapping**: Does every introduction claim map to an evaluation subsection?

232- **Key abstraction propagation**: Does the named concept from Introduction Move 3 appear in Design Move 1, Evaluation setup, and Related Work positioning?

233- **Heading consistency**: Do section headings reflect the contribution order from the introduction?

234- **Identity stability**: Read the first sentence of every section — do they tell a coherent story?

235- **Flow audit**: Read the last sentence of paragraph N and the first sentence of paragraph N+1, throughout the paper. Does each transition work? Composition — the logical flow a reader can follow — is the most important aspect of technical writing. Readers forgive imperfect grammar but cannot follow broken logical progression. Structure produces flow, but structure alone doesn't guarantee it — the transitions between structural units matter.

236- **Signposting check**: Does each section open with a claim-bearing sentence that tells a skim-reader what the section concludes? Is there an outline paragraph at the end of the introduction? Are figures distributed throughout pages rather than clustered?

237- **Visual balance (landscaping)**: Check figure distribution across pages, paragraph length variation, and whitespace. Break up walls of text with signposts, figures, and paragraph headings. Avoid orphaned section headings at page bottoms.

238

239### Stage 5: Compression

240

241Read author_profile/compression_patterns.md for the 7 specific operations. Apply in order:

2421. Sentence shortening (remove subordinate clauses, qualifiers, throat-clearing)

2432. Paragraph merging (multiple examples of same point → one best example)

2443. Generic adjective removal ("significant" → specific number or delete)

2454. Tutorial deletion (remove explanations the venue audience already knows)

2465. Claim-first conversion (rewrite buried paragraphs so claim leads)

2476. Takeaway insertion (add synthesis paragraphs after experiment clusters)

2487. Figure/table promotion (move dense numerical comparisons from prose to visuals)

249

250Target: 30–50% reduction from first draft. Report character count before and after.

251

252**Do not pad to fill page limits.** If the paper is under the page limit after compression, that is fine. A short paper with appropriate content is better than a padded paper that reaches the limit. Padding introduces filler that weakens the argument.

253

254### Pre-Submission Mechanical Checklist (Automated)

255

256After compression and before submission, Claude MUST automatically run these checks using shell commands on the paper's .tex and compiled .pdf files. Do not ask the student to run them manually — execute them and report results.

257

258**1. Page count.** Extract page count from the compiled PDF and compare against the venue's limit (from project_context.md). Flag whether references/appendices count — this varies by venue.

259```bash

260pdfinfo paper.pdf | grep Pages

261```

262

263**2. Broken references.** Search .tex source files for unresolved references that will render as [?] or ?? in the PDF. Also check the .log file for LaTeX warnings about undefined references and citations.

264```bash

265grep -n "LaTeX Warning.*undefined" paper.log

266grep -rn '\\cite{' *.tex | grep -v '%' # list all citations for cross-check

267```

268

269**3. Embedded fonts.** Verify all fonts are embedded. Non-embedded fonts cause rendering differences across machines and are rejected by some submission systems.

270```bash

271pdffonts paper.pdf | grep -v "yes"

272```

273If any font shows no in the emb column, flag it and suggest adding \usepackage[T1]{fontenc} or compiling with GS_OPTIONS=-dPDFSETTINGS=/prepress.

274

275**4. Figure quality.** Check that all included figure files are vector format (PDF/EPS) or high-resolution raster. List all figures referenced in the source and verify they exist.

276```bash

277grep -rn '\\includegraphics' *.tex # list all figure references

278file figures/*.pdf figures/*.png 2>/dev/null # check file types

279```

280Flag any PNG/JPG figures — these should be vector unless they are photographs or screenshots.

281

282**5. Anonymization (if double-blind).** Search all .tex files for author names, institution names, grant numbers, acknowledgment sections, and self-citations that could reveal identity.

283```bash

284grep -rni 'AUTHOR_NAMES_HERE\|INSTITUTION_HERE\|\\thanks\|acknowledgment' *.tex

285```

286Replace AUTHOR_NAMES_HERE and INSTITUTION_HERE with actual names from project_context.md before running.

287

288**6. Column balancing.** Check whether the balance package is loaded (for two-column formats). If not, suggest adding \usepackage{balance} and \balance before \bibliography.

289```bash

290grep -rn 'balance' *.tex

291```

292

293**7. Common LaTeX issues.** Scan for frequently missed mechanical problems:

294```bash

295grep -rn '\\cite{.*}' *.tex | grep -v '~\\cite' # missing ~ before \cite (dangling references)

296grep -rn 'et al\.' *.tex | grep -v '~' # missing ~ after "et al."

297grep -rn '\\label{' *.tex | sort | uniq -d # duplicate labels

298```

299

300**Report format**: Run all checks, then present a single summary table:

301

302| Check | Status | Details |

303|-------|--------|---------|

304| Page count | ✓ or ✗ | N pages (limit: M) |

305| Broken refs | ✓ or ✗ | List of undefined refs |

306| Embedded fonts | ✓ or ✗ | List of non-embedded fonts |

307| Figure quality | ✓ or ✗ | List of raster figures |

308| Anonymization | ✓ or ✗ | List of leaks found |

309| Column balance | ✓ or ✗ | Package present/missing |

310| LaTeX issues | ✓ or ✗ | Count of dangling refs, duplicate labels |

311

312Fix what can be fixed automatically (e.g., adding ~ before \cite). Flag what requires student decision (e.g., replacing a raster figure with vector).

313

314---

315

316## How to Respond to Common Requests

317

318### "Help me write section X of paper Y"

3191. Load the paper's project_context.md

3202. Read all author_profile/ files

3213. Read the section's rhetorical moves from section_rhetorical_moves/

3224. Identify which stage the paper is in — enforce introduction-twice ordering (Draft 0 intro → Evaluation → Design → Background → Related Work → Final intro → Abstract)

3235. Write topic sentences first; verify they form a coherent argument before filling paragraphs

3246. Generate the draft following the move sequence

3257. Run the section checklist and flag violations with severity levels

326

327### "Review / critique this draft"

3281. Load project_context.md

3292. Read author_profile/intervention_types.md for the 7 intervention types

3303. Apply in order: framing → structural rewrite → background deletion → evaluation strengthening → terminology tightening → claim-first conversion → compression

3314. Give numbered feedback with severity (CRITICAL / MAJOR / MINOR), the specific principle violated (by number from editorial_principles.md), and a concrete rewrite

332

333### "Compress / tighten this section"

3341. Read author_profile/compression_patterns.md

3352. Apply the 7 operations in order

3363. Show before/after with character counts

3374. Normal compression: 30-50%. Over 50% signals a framing problem, not a wordiness problem.

338

339### "I want to get feedback on this draft"

3401. **First readings are precious.** Someone can read your work for the first time only once. Don't send your first draft to everyone simultaneously — chain your feedback. Send to one reader, incorporate their feedback, then send the revised version to the next reader. Each iteration strengthens the draft before it reaches the next pair of fresh eyes.

3412. Help the student plan their feedback chain: who reads first (someone outside the subfield for framing clarity), who reads second (a domain expert for technical correctness), who reads last (the advisor, who sees the strongest version).

3423. When asking a reader for feedback, tell them what to focus on: "Is the narrative in the introduction clear?" is more useful than "any thoughts?" Unfocused feedback wastes a first reading.

3434. Use Claude's review mode (author_profile/intervention_types.md) to simulate a round of feedback *before* spending a human reader's first reading on an early draft.

344

345### "Help me respond to reviewers"

3461. Load project_context.md and the reviews

3472. Classify each concern by severity: framing (most dangerous) → design → scope → rigor (most manageable)

3483. For each concern: acknowledge → explain what changed → point to specific section/figure

3494. Never be defensive. Never dismiss a concern. If a reviewer misunderstood, that's a WRITING failure to fix, not a reviewer failure to criticize.

350

351### "I'm starting a new paper — where do I begin?"

3521. Welcome them. Explain the five-stage pipeline — especially the introduction-twice principle.

3532. Read brainstorming_guide.md and walk through all 6 phases to create their first project_context.md.

3543. Emphasize: the brainstorming phase is the most important. A precise project context saves weeks of revision later.

3554. After brainstorming: write a **Draft 0 introduction** — a disposable framing scaffold (stakes, problem gap, rough contributions) that sets guardrails for the evaluation. Then point them to section_rhetorical_moves/evaluation.md — they'll write the evaluation next, constrained by Draft 0.

3565. Remind them: "Your first draft should be comprehensive — include everything. Compression comes later. The goal is to get material on paper, not to be concise. Draft 0 of the introduction will probably not survive — that's the point. It clarifies your thinking."

357

358### "I need a non-data figure (architecture diagram, pipeline illustration, etc.)"

3591. Load the paper's project_context.md

3602. Read figure_synthesis_guide.md and the relevant files in figure_templates/

3613. Classify the figure by archetype (architecture overview, pipeline flow, component detail, concept illustration, comparison schematic, taxonomy, deployment diagram)

3624. Select the generation backend: AI image generation (for visually rich figures like architecture overviews and concept illustrations) or TikZ (for precise structural figures like pipeline flows and taxonomy matrices). The guide has defaults per archetype, but the student can override.

3635. Run spec mode — walk through archetype-specific questions to produce a figure_spec.md

3646. Run generate mode — assemble an AI prompt or TikZ code, produce the figure

3657. Run critique mode — check against claims, venue formatting, and design principles, and enforce caption terseness (G7: a bold takeaway plus at most one clause; flag captions over ~3 lines), and verify legibility by inspecting the rendered image (a checklist-green figure can still be an illegible mess)

3668. **NOTE**: Data figures (CDFs, scatter plots, bar charts, heatmaps) should go through /viz, not through figure synthesis

367

In the file

SKILL.md4,784 words

Files30

LicenceMIT

Why you can read it

Nothing in a skill executes. The client loads the text and the model follows it, so a skill can be audited the way a runbook is — by reading it.

What it costs in context

Skills are not billed by the call. They are paid for in context: every token the instructions occupy is a token your code, your diff and your conversation cannot use. Here is what this one takes and when it takes it.

≈190

always loaded

The name and description, so the model knows the skill exists and when to reach for it.

61,735

on trigger

The instruction body and 29 supporting files, read only when the skill fires.

31.0%

of a 200k window

Ten skills this size would take about 310% of the window before you open a file.

050k100k150k200k context window

61.9k tokens, estimated from the bundle at four bytes to the token, held for the rest of the session once it triggers. Heavy. Teams tend to install this one per project rather than globally, and load it only when the job comes up.

Servers bill, skills cost

A server charges by the month. A skill charges once per session, in context, and then keeps charging it for as long as the session lives.

Before and after

The same question, put to the same model twice: once as it comes, and once with these instructions loaded.

No worked example has been published for this skill yet.

Adoption

Installsnone yet

Ratingno reviews yet

The procedure it runs

The procedure has not been published here. It is in the skill’s own SKILL.md, which its author has not sent to the marketplace yet.

Prose, not code

These steps are written for a model to follow, not executed by a runtime. It can still be told to skip one, and it will say so when it does.

Servers it uses

None. This skill calls no MCP servers at all.

Everything it needs is in the instructions, so it works in a project with nothing connected — the model reads the file and changes how it works with what it can already reach.

It writes no files and reaches no network. All it changes is how the model reasons and writes.

What it asks for

Writes filesno

Network accessno

Read from the allowed-tools line of this skill’s own SKILL.md. A skill grants no permissions of its own — it can only ask for tools your client already has.

What it will not do

Every skill is narrow, and the useful ones say where they stop. These are the jobs this one is the wrong tool for.

What this skill is not for has not been published here. Nothing is implied by that: it is a section the author has not filled in.

If this is not it

12 other skills in Content Management

What is in the bundle

30 files, 247.7 kB on disk. A bundle is text throughout: the instructions the model reads, plus the templates it fills in.

CHANGELOG.md3.7 kB
CLAUDE.md5.3 kB
DESIGN.md9.3 kB
README.md7.7 kB
SKILL.md33.8 kB
brainstorming_guide.md15.1 kB
figure_synthesis_guide.md16.9 kB
loop_mode.md3.8 kB
red_team_protocol.md2.8 kB
author_profile/compression_patterns.md4.8 kB
author_profile/craft_reference.md12.3 kB
author_profile/editorial_principles.md14.0 kB
author_profile/gate_mechanical.md12.4 kB
author_profile/gate_semantic.md13.1 kB
author_profile/intervention_types.md3.8 kB
author_profile/rhetorical_moves.md5.0 kB
examples/netburst_project_context.md25.1 kB
examples/project_context.md3.8 kB
figure_templates/figure_spec_template.md3.5 kB
figure_templates/prompt_templates.md9.6 kB
figure_templates/tikz_skeletons.md7.4 kB
figure_templates/venue_styles.md5.1 kB
section_rhetorical_moves/design.md3.3 kB
section_rhetorical_moves/evaluation.md6.7 kB
section_rhetorical_moves/introduction.md6.7 kB
section_rhetorical_moves/related_work.md3.1 kB
writing_checklists/design_questions.md2.0 kB
writing_checklists/evaluation_questions.md3.0 kB
writing_checklists/intro_questions.md2.6 kB
writing_checklists/related_work_questions.md2.0 kB

What is not in it

No dependencies and nothing executable: a skill is text the agent reads, so the bundle is 30 files you can review in full before installing. The MIT licence covers the templates and examples as well as the instructions.

Install

Installing copies the bundle into your project. Nothing runs at install time — the files sit on disk until the model reads them.

$15 once

Paper Writing · MIT · SNL-UCSB

one-time

Price$15 once

LicenceMIT — the author’s, unchanged by this purchase

Paid throughStripe, once, on the card you add at the checkout

Keeps workingfor good — the files are yours once they are on disk

Updatesevery update its author ships, delivered through this account

You can read the whole bundle before paying — the SKILL.md above is the product, not a preview of it. What the money buys is the delivery: the folder packaged and handed to your machine by key, every update its author ships, and our support if it does not do what this listing says. The terms of use are MIT, set by the author and unchanged by buying it here.

Payment runs through Stripe, on a page like this one rather than a redirect. Once there is an account it joins the same mcprush invoice as everything else you run, so there is never a second card to enter.

Which clients pick it up on their own

A skill is a folder of text. A client with a skills folder reads it without being told; everywhere else the same text works, it is just handed to the model rather than found.

Claude Code.claude/skills/

Claude Desktop

ChatGPT

Cursor.cursor/skills/

VS Code.github/skills/

Codex CLI.agents/skills/

Gemini CLI.gemini/skills/

Grok.grok/skills/

Zed.agents/skills/

Windsurf.windsurf/skills/

Agent SDK.claude/skills/

HTTP / API

This release

Versionnot versioned

Publishedno release date on file

Price$15

Referencesnl-ucsb/paper-writing

Versions

Its author publishes no version number, so there is nothing here to pin to: what you install is the folder as it stands today. Instructions change more often than APIs do — a skill can be rewritten entirely without anything it depends on moving.

No earlier releases have been published to the marketplace.

Pinning

Nothing to pin to: this skill carries no version number of its own. What you install is what the folder holds on the day you install it.

Reviews

—no reviews yet · no installs yet

Nobody has reviewed this skill yet. The rating is the mean of the reviews written here, so there is none until somebody writes the first.

Who can post

Only accounts that have had the skill installed for fourteen days, so a review is written after living with it rather than after reading it. Publishers may reply once.

Who wrote it

SNL-UCSB

Publishes on mcprush.

0 servers listed1 skill listednot claimed

Profile

Publisher

Servers0