write-paper
Skill8 starsChanged 4 months agoMITView on GitHub
Draft a full academic paper from analysis outputs, project spec, and lit review. Use when turning completed analysis into a written paper, not running analysis or reviewing existing writing.
7 other projects use a version of this.
Adopted by
Most recently taken up by
- AndreasADL/ai-papermilltheir own version, first seen Oct 11, 2026
- tsingyuai/scientifytheir own version, first seen Oct 8, 2026
- SebastianElvis/reapertheir own version, first seen Sep 12, 2026
- zhanyinx/skillstheir own version, first seen Sep 3, 2026
- frenzymath/Danustheir own version, first seen Aug 23, 2026
- sunnnybala/Rstacktheir own version, first seen Apr 2, 2026
Other versions7 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 7
- tsingyuai/scientify★ 2.2ksame name
- frenzymath/Danus★ 391same name
- sunnnybala/Rstack★ 69same name
- SebastianElvis/reaper★ 9same name
- mr-devs/cc-research-project-template★ 4same name
- zhanyinx/skills★ 1same name
- AndreasADL/ai-papermill★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository12 other files it gives its agents.
- data-analysisSkill
- data-finderSkill
- lit-reviewSkill
- new-projectSkill
- proofreadSkill
- quality-gateSkill
- research-setupSkill
- review-paperSkill
- review-rSkill
- revise-paperSkill
- session-logSkill
- validate-bibSkill
The file
We split this skill into the rules it gives an agent
8 rules. 0 are common, 4 are distinctive, and 4 are very specific to this project.
0
Common
Most of the 7 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 25
If no spec exists, ask the user for the core research question before proceeding.
- Distinctive: line 63
Write in this order (minimizes backtracking):
- Very specific: line 78
Create manuscripts/ directory if it does not exist.
- Very specific: line 80
Use \input{} for tables and \includegraphics{} for figures — reference the actual files in output/, do not embed content directly.
- Distinctive: line 87
Do this inline (no agent dispatch).
- Very specific: line 111
Do not run a substance review here.
- Distinctive: line 124
Propose outline first: Never start writing without outline approval.
- Very specific: line 126
No fabrication: Only write results that exist in output files.
“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Write Paper Draft
Draft an academic manuscript from existing analysis outputs. Follows propose-first — the outline is always shown for approval before writing begins.
Input: $ARGUMENTS — a paper title, research question, or from spec to read from quality_reports/specs/.
Step 1: Orient
Read project context:
CLAUDE.md— project name, author, institutionreferences/domain-profile.md— field (used to calibrate outline conventions in Step 3)- Most recent file in
quality_reports/specs/— research question and identification strategy - Most recent file in
quality_reports/lit_review_*.md— related literature (if it exists) - Most recent file in
quality_reports/research_ideation_*.md— hypotheses (if it exists)
If no spec exists, ask the user for the core research question before proceeding.
Step 2: Inventory Analysis Outputs
Glob for available outputs:
output/tables/**/*.tex— regression tablesoutput/tables/**/*.html— HTML table versionsoutput/figures/**/*.pdf,output/figures/**/*.png— figuresoutput/**/*.rds,output/**/*.pkl,output/**/*.parquet— saved objects
List what exists. Note any gaps (e.g., "no summary statistics table found").
Step 3: Propose Outline (WAIT FOR APPROVAL)
Draft a paper outline using this standard structure:
1. Abstract
2. Introduction
3. Background
4. Data & Methods
5. Results
6. Discussion
7. Appendix
ReferencesThe structure is flexible. Default to the hardcoded outline above unless (a) the user requests a different structure, or (b) the field in references/domain-profile.md has strong conventions that warrant deviation (e.g., merging Background into Introduction, splitting Data & Methods into separate Data and Empirical Strategy sections, or reordering sections). If you deviate from the default, state explicitly why and confirm with the user before writing.
Adapt the writing style — not the structure, by default — to the field from references/domain-profile.md. A political science paper reads differently than an econometrics paper even with the same section headings: econ prose leads with identification and is terse about theory; poli sci prose leads with theoretical framing and treats measurement validity as a first-class concern; sociology leans on theoretical framework prose. Mirror the conventions of the field's top journals when drafting each section.
Present the outline with a one-sentence description of each section's content, linking specific output files to each section (e.g., "Table 2 → Section 5, Results"). Do NOT start writing until the user approves the outline or requests changes.
Step 4: Draft Section by Section
Write in this order (minimizes backtracking):
- Data & Methods — describe the dataset and summary statistics (reference
output/tables/summary_stats.texif it exists), then the identification or estimation approach from the research spec. - Results — one paragraph per main finding. Reference each table/figure with
\input{}or\includegraphics{}— do NOT copy table content inline. - Discussion — interpret the findings, discuss robustness checks, acknowledge limitations, and state implications.
- Appendix — additional robustness tables, derivations, and supplementary figures. Reference output files only.
- Background — synthesize from the lit review document if one exists; position the contribution against prior work.
- Introduction — write after results are known. State the question, preview the findings, and map the paper.
- Abstract — write last: one sentence each for motivation, question, method, finding, and implication.
Step 5: Save the Draft
Save to manuscripts/[project-name]-draft.tex (or .qmd if the user prefers Quarto).
Create manuscripts/ directory if it does not exist.
Use \input{} for tables and \includegraphics{} for figures — reference the actual files in output/, do not embed content directly.
Step 6: Structural Smoke Test
Before handing off to review skills, run a quick structural check on the draft to catch drafting-artifact errors that full substance review doesn't focus on. This is not a substance review — /review-paper handles that. This catches broken references and left-behind placeholders that would embarrass the author if the draft went out as-is.
Do this inline (no agent dispatch). Read the saved draft and check:
- Table references resolve. For every
\input{...}command in the draft, confirm the referenced file exists inoutput/. Grep the draft for\input\{; for each hit, Glob the referenced path. List any misses. - Figure references resolve. For every
\includegraphics{...}command, confirm the referenced file exists inoutput/figures/. Same approach: grep, then glob. - No placeholders left behind. Grep the draft for
TODO,FIXME,XXX,[placeholder],[TK],???, and square-bracketed all-caps tokens like[PLACEHOLDER]. List every hit with its line number. - Required sections present. Confirm the draft contains an abstract, an introduction, and a conclusion (by section heading or equivalent markup). Flag any missing.
- No fabricated numbers. Grep the draft for numeric patterns in prose (e.g.,
\d+\.\d+%,\$\d+,p\s*<\s*0\.\d+). For each, note whether a corresponding output file was referenced nearby. This is a heuristic — flag likely orphans for the user to verify, not definitive.
Present the results as a short checklist:
## Structural Smoke Test Results
[OK] Table references: 8/8 resolve
[FAIL] Figure references: 3/4 resolve — missing output/figures/heterogeneity.pdf
[OK] No placeholders found
[OK] Required sections present (abstract, introduction, conclusion)
[WARN] 4 numeric claims in prose may lack nearby output references — see list belowDo not run a substance review here. If any structural issues are flagged, offer to fix them before handoff. Bibliography checking is deferred to /validate-bib; claim-to-output traceability is deferred to /quality-gate; substance review is deferred to /review-paper.
Step 7: Recommend Next Steps
Inform the user:
/review-paper— for a full top-journal-style review of the manuscript/validate-bib— to check all citations are in the bibliography/quality-gate— to verify every claim in the paper is backed by an output file
Key Rules
- Propose outline first. Never start writing without outline approval.
- Reference, don't embed. Tables and figures go in
output/; the paper references them by path. - No fabrication. Only write results that exist in output files. If a number isn't in
output/, flag it rather than guessing. - Smoke test, don't substance-review. Step 6 catches drafting artifacts only — broken refs, placeholders, missing sections. Substance review is
/review-paper's job.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

