Architecting a scientific paper — IMRaD logic, storyline design, and paragraph-level structure that reviewers follow.
Scanned 9/29/2026
npx -y skills add aicodedecode/awesome-muse-skills --skill paper-structure --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Paper Structure?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/aicodedecode-paper-structure)More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.
---
name: paper-structure
description: Architecting a scientific paper — IMRaD logic, storyline design, and paragraph-level structure that reviewers follow.
category: scientific
---
## Overview
A paper is a persuasive document with a fixed architecture: it must
establish a gap, fill it credibly, and state what changed. This skill
covers designing the storyline before writing (the "story arc"),
structuring each IMRaD section to do its job, paragraph-level
organization (topic sentences, evidence, interpretation), and the
revision passes that turn a draft into a submission.
## When to use
- Planning a paper: turning results into a coherent storyline
- Structuring Introduction, Methods, Results, Discussion for maximum clarity
- Diagnosing why a draft feels muddled or gets "unclear" reviews
- Outlining before writing to avoid the blank-page stall
- Revising: systematic passes for logic, evidence, and language
## Core concepts
- **The story arc:** status quo → gap/complication → what you did → key findings → what it means. Every section serves this arc; material that doesn't advance it gets cut or moved to supplement.
- **IMRaD as contract:** Introduction (why this matters, what's unknown, what you did — ending with the paper's claims), Methods (enough to reproduce), Results (what you found, no interpretation), Discussion (what it means, limitations, what's next). Reviewers check each contract.
- **Paragraph discipline:** one idea per paragraph; topic sentence first, evidence middle, interpretation/linking sentence last. A paragraph whose first and last sentences don't connect is two paragraphs.
- **Claim–evidence pairing:** every substantive claim in Introduction/Discussion must be traceable to a cited source or your own result — unanchored claims are what reviewers attack.
- **The "need to know" filter:** readers need motivation, method essentials, results, and meaning — in that order. Interesting-but-irrelevant material (however hard-won) goes to the supplement or out.
- **Title and headings as signposts:** headings should telegraph content ("X increases Y under Z", not "Results"); the title names the finding or the question, not the topic area.
- **The "hourglass" shape:** broad context → narrow methods/results → broad implications — the classic IMRaD arc; each section's breadth should match its position in the hourglass.
- **Signposting:** explicit roadmaps ("We first show X, then demonstrate Y, finally establish Z") at section openings — readers navigate long papers via signposts, not memory.
- **The title as a claim:** the strongest titles state the finding, not the topic ("X drives Y via Z" beats "Studies on X") — the title is the paper's narrowest, sharpest summary.
## Practical workflow
### 1. Design the story before drafting
1. Write the 5-sentence story: (1) big-picture context, (2) specific gap, (3) what you did, (4) key result, (5) implication. If you can't, you're not ready to write.
2. List your 3–5 key findings in order; each becomes a Results subsection and ideally a figure.
3. Draft the figures first — the paper's skeleton; write text to serve the figures, not vice versa.
### 2. Draft section by section
1. **Results first:** describe each figure in order — what was done (briefly), what was observed, with numbers. No interpretation beyond what's needed to follow.
2. **Methods:** full reproducibility detail; move routine protocols to supplement but keep the novel/decision-critical parts in main text.
3. **Introduction:** funnel from broad to specific — field context (1–2 paragraphs), the gap with citations (the "however"/"unknown" paragraph), your approach and claims (final paragraph maps to Results order).
4. **Discussion:** restate key findings (briefly), interpret each (mechanism, comparison with literature — agreement and disagreement explained), limitations (stated plainly, with why they don't sink the conclusions), broader implications and next steps.
### 3. Revise in passes
1. **Logic pass:** does every paragraph advance the arc? Cut or relocate the rest. Check claim–evidence pairing throughout.
2. **Reviewer pass:** read as a skeptical reviewer — where would you object? Preempt with data, caveats, or citations.
3. **Language pass:** active voice where the actor matters, precise verbs, no hedging stacks ("might possibly suggest"); consistent terminology (pick one term per concept).
4. **Fresh-eyes pass:** after a break, read only topic sentences — the paper's argument should be fully visible in them.
### 4. Final checks
1. Every figure/table cited in order; every citation in the reference list and vice versa.
2. Numbers consistent between text, figures, tables, and abstract.
3. Authorship, contributions, data/code availability statements complete.
### 5. Structure the Discussion to persuade
1. Open with the 2–3 sentence takeaway — what the results establish, plainly stated before any caveats.
2. Interpret each key result: mechanism, comparison with literature (agreement and disagreement, both explained), and what rules out alternatives.
3. State limitations as boundary conditions ("our conclusions hold for X; beyond that..."), then close with the forward look — what this enables next.
### 6. Quick-reference checklist
- [ ] Hourglass shape maintained (broad → narrow → broad)
- [ ] Title states the finding, not the topic
- [ ] Every Introduction claim is delivered by the Results/Discussion
- [ ] Signposts at each section opening
- [ ] Methods contain everything a replicator needs
- [ ] Discussion argues and interprets, not just summarizes
- [ ] Limitations stated as boundary conditions
- [ ] Target journal's format checked before final layout
## Common pitfalls
- **Writing before the story exists:** drafting as a substitute for thinking — produces a data dump, not a paper.
- **Results–Discussion bleed:** interpreting in Results and re-reporting in Discussion — keep the contract; cross-reference instead.
- **The "and then" structure:** chronological lab-diary ordering instead of logical ordering — organize by finding, not by when you did it.
- **Gap inflation:** overselling novelty ("for the first time ever") — reviewers know the literature; precise positioning beats hype.
- **Limitation amnesia:** omitting weaknesses reviewers will spot — stated limitations disarm; hidden ones detonate.
- **Abstract–paper mismatch:** claims in the abstract that the body doesn't support — the fastest route to rejection.
- **Introduction promises the Discussion doesn't keep:** claims previewed up front that results never deliver — align the two before submission; reviewers check.
- **Methods in the Results:** procedural detail interrupting the findings narrative — move it to Methods, keep only what's needed to interpret the result.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!