draft-section
Skill17 starsChanged 3 months agoMITView on GitHub
Drafts one manuscript section (intro, theory, data, methods, results, discussion, abstract) to paper/sections/ in the user's configured writing voice, to the substantive bar each section owes the reader — contribution with a number, estimand and identifying assumption stated, results tied to tables with intervals and magnitudes, causal language matched to the design, nulls read against the smallest effect of interest — with numbers checked against output/ and no invented citations. Use when the user asks to write or revise any part of the paper.
In this repository38 other files it gives its agents.
- abstract-shotgunSkill
- analyzeSkill
- archiveSkill
- carefulSkill
- coauthor-reviewSkill
- codebookSkill
- cover-letterSkill
- data-acquireSkill
- data-cleanSkill
- design-researchSkill
- freezeSkill
- guardSkill
- hypothesis-designSkill
- idea-shotgunSkill
- identification-reviewSkill
- journal-fitSkill
- learnSkill
- lit-mapSkill
- llm-checklistSkill
- mstack-initSkill
- mstack-upgradeSkill
- paper-statusSkill
- pdf-ingestSkill
- power-analysisSkill
- preregisterSkill
- r-and-rSkill
- referee-mockSkill
- research-questionSkill
- results-auditSkill
- retroSkill
- robustnessSkill
- scope-challengeSkill
- submission-packSkill
- survey-buildSkill
- theory-buildSkill
- title-shotgunSkill
- unfreezeSkill
- vizSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 0 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 16
Stage: write · Voice: writer, anchored to voice.writing_style in .mstack/config.yaml
- Very specific: line 36
Every number in methods / results prose must match the tables on disk.
- Very specific: line 38
Voice: If voice.writing_style names a skill, invoke it for tone, rhythm, and vocabulary.
- Very specific: line 51
Citations: Only keys already in paper/refs.bib.
- Very specific: line 53
Self-check before saving: every number in the section appears in a table, figure, or the analyze log.
- Very specific: line 71
Before intro, /mstack:lit-map output should exist.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/mstack:draft-section
Stage: write · Voice: writer, anchored to voice.writing_style in .mstack/config.yaml
Draft once results are stable (output/tables/ and output/figures/ no longer changing) and a target journal is set; prose written before results lock gets rewritten.
$ARGUMENTS is the section: intro, theory, data, methods, results, discussion, or abstract. If missing or unrecognized, list these and stop.
Procedure
Load
.mstack/config.yaml(title, target journals, status),.mstack/learnings.jsonl(conventions, variable names, framing), every existing section inpaper/sections/(the manuscript is the context; consistency across sections is a referee's first check), the citable keys ofpaper/refs.bib(grep -o '^@[A-Za-z]*{[^,]*' paper/refs.bib), and the upstream memos the section depends on:Section Upstream memos and artifacts intro.mstack/research-question.md,.mstack/lit-map.md,.mstack/hypotheses.md(estimand), the primary table and figuretheory.mstack/theory.md(mechanism, DAG, rivals, scope),.mstack/hypotheses.mddatadata/codebook.md,data/raw/PROVENANCE.md,data/clean/clean-log.md, the variation figuremethods.mstack/identification-review-*.md,prereg/osf-prereg.md,code/02-analyze.Rresultscode/02-analyze.R,output/tables/*,output/figures/*,output/analyze-log.md,.mstack/robustness-*.mddiscussion.mstack/theory.md(scope, rivals),.mstack/identification-review-*.md,.mstack/robustness-*.mdabstractintro,results,discussionEvery number in
methods/resultsprose must match the tables on disk.- Read
${CLAUDE_PLUGIN_ROOT}/references/writing-conventions.mdfor what the section owes the reader and the referee complaints it must pre-empt. - Voice. If
voice.writing_stylenames a skill, invoke it for tone, rhythm, and vocabulary. If unset, write clean generic academic prose (short sentences, active verbs, no hedge-stuffing, no thesaurus reaches) and tell the user once that they can set a style skill in.mstack/config.yaml. Draft to the section's bar:
Section Bar introOpens with the question and its stake; a contribution paragraph with what we do, what we find (a number in substantive units), and what changes if believed; the design and estimand in one sentence; positioned against the two or three closest papers; roadmap in one sentence or none. The puzzle survives a "so what?" attack in two sentences. theoryMechanism in one sentence and its steps; assumptions; observable implications that separate it from the named rivals; scope conditions as where it fails; hypotheses numbered with direction and estimand. dataUnit and coverage; sources with vintages; each key variable's operationalization with a validity argument; the variation the design uses, shown; missingness and restrictions with counts; every claim cites the codebook. methodsEstimand, then the identifying assumption in one sentence, then the equation with every symbol defined, fixed effects, and clustering; why this comparison isolates the effect; the falsification tests and sensitivity analysis; preregistration status and deviations; the estimator cited. resultsPrimary estimate first, then falsification tests, mechanism, heterogeneity, and a one-paragraph robustness summary with the sensitivity sentence; one claim per table or figure; point estimate, interval, and magnitude against a benchmark; causal verbs only under a design that licenses them; nulls read against the SESOI, never as "no effect"; no "highly significant". discussionThe contribution restated with its evidence; what the result is not (the estimand's limits); the most plausible rival explanation and why the evidence weighs against it; specific limitations; implications proportional to evidence; one concrete next study. abstractQuestion, design with estimand, data, the finding with a number, contribution; within the journal's cap; no citations, no hedging stack. - Citations. Only keys already in
paper/refs.bib. For a missing one, insert\cite{TODO-author-year-keyword}and append% TODO: add ref — <one-line description>. Never fabricate author-year-title combinations. Cite the methods used (estimators, sensitivity tools) where the reference file names them. - Write to
paper/sections/<name>.tex(.qmdif.mstack/config.yamlsaysformat: quarto). Overwrite only if the file is empty or a placeholder comment; otherwise show the candidate and ask whether to overwrite, append, or save aspaper/sections/<name>.candidate.tex. On the first substantive section, setpaper.status: "writing". - Self-check before saving: every number in the section appears in a table, figure, or the analyze log; every table and figure referenced exists; causal language matches
design.type; the estimand named here is the one inhypotheses.md; no citation key is invented.
Outputs
paper/sections/<section>.tex.- Optional
.mstack/draft-log.md— one line per draft: date, section, word count, open TODOs.
Anti-patterns
- Fabricated citations. TODO markers, never inventions.
- Drafting
resultsbefore analysis is stable. Missing tables or figures → stop and run/mstack:analyze. - Generic voice over a configured style. Defer to the style skill; do not paper over it with hedge phrases.
- A literature review where the theory should be.
- Nulls as zeros and associations as effects.
- Filling space. Short and sharp beats long and hedged.
Next
Before intro, /mstack:lit-map output should exist; before methods, /mstack:identification-review. After abstract, /mstack:abstract-shotgun. After all sections, /mstack:coauthor-review then /mstack:referee-mock.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.

