agentleFS
matthewdigiuseppematthewdigiuseppe/MStack/skills/draft-section/SKILL.md

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.

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
  1. Very specific:

    Stage: write · Voice: writer, anchored to voice.writing_style in .mstack/config.yaml

    line 16
  2. Very specific:

    Every number in methods / results prose must match the tables on disk.

    line 36
  3. Very specific:

    Voice: If voice.writing_style names a skill, invoke it for tone, rhythm, and vocabulary.

    line 38
  4. Very specific:

    Citations: Only keys already in paper/refs.bib.

    line 51
  5. Very specific:

    Self-check before saving: every number in the section appears in a table, figure, or the analyze log.

    line 53
  6. Very specific:

    Before intro, /mstack:lit-map output should exist.

    line 71

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/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

  1. Load .mstack/config.yaml (title, target journals, status), .mstack/learnings.jsonl (conventions, variable names, framing), every existing section in paper/sections/ (the manuscript is the context; consistency across sections is a referee's first check), the citable keys of paper/refs.bib (grep -o '^@[A-Za-z]*{[^,]*' paper/refs.bib), and the upstream memos the section depends on:

    SectionUpstream memos and artifacts
    intro.mstack/research-question.md, .mstack/lit-map.md, .mstack/hypotheses.md (estimand), the primary table and figure
    theory.mstack/theory.md (mechanism, DAG, rivals, scope), .mstack/hypotheses.md
    datadata/codebook.md, data/raw/PROVENANCE.md, data/clean/clean-log.md, the variation figure
    methods.mstack/identification-review-*.md, prereg/osf-prereg.md, code/02-analyze.R
    resultscode/02-analyze.R, output/tables/*, output/figures/*, output/analyze-log.md, .mstack/robustness-*.md
    discussion.mstack/theory.md (scope, rivals), .mstack/identification-review-*.md, .mstack/robustness-*.md
    abstractintro, results, discussion

    Every number in methods / results prose must match the tables on disk.

  2. Read ${CLAUDE_PLUGIN_ROOT}/references/writing-conventions.md for what the section owes the reader and the referee complaints it must pre-empt.
  3. Voice. If voice.writing_style names 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.
  4. Draft to the section's bar:

    SectionBar
    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.
  5. 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.
  6. Write to paper/sections/<name>.tex (.qmd if .mstack/config.yaml says format: quarto). Overwrite only if the file is empty or a placeholder comment; otherwise show the candidate and ask whether to overwrite, append, or save as paper/sections/<name>.candidate.tex. On the first substantive section, set paper.status: "writing".
  7. 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 in hypotheses.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 results before 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.

Download now (ZIP)

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.