Verified against ChatGPT · 2026-08-14
Build an academic paper outline around the argument's skeleton, not just section headers
Produces an academic outline where every section is defined by the specific claim it needs to establish and what evidence would support it, instead of generic headers like Introduction and Discussion with no argumentative content.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Build an outline for this paper — but every section needs to be defined by what it has to argue or establish, not just a generic academic header. A section labeled "Discussion" with no stated content is not an outline, it's a template. PAPER TOPIC AND THESIS Arguing that asynchronous code review practices reduce senior engineer burnout without measurably slowing merge times, based on internal team data. REQUIRED SECTIONS OR FORMAT Standard IMRaD format: Introduction, Methods, Results, Discussion, Conclusion, per the target venue's submission guidelines. EVIDENCE OR SOURCES ALREADY AVAILABLE 6 months of merge-time data across two teams, one using async review and one using synchronous review, plus an anonymous burnout survey from both teams. KNOWN WEAK POINT IN THE ARGUMENT The two teams weren't randomly assigned to review styles — the async team happened to also be working on a less time-pressured project during the study period. For each required section from Standard IMRaD format: Introduction, Methods, Results, Discussion, Conclusion, per the target venue's submission guidelines., state the specific claim that section exists to establish, in one sentence, before listing sub-points under it. Under each claim, note which piece of 6 months of merge-time data across two teams, one using async review and one using synchronous review, plus an anonymous burnout survey from both teams. would support it and flag any claim that doesn't yet have supporting evidence lined up. Build in an explicit place in the outline to address The two teams weren't randomly assigned to review styles — the async team happened to also be working on a less time-pressured project during the study period. — do not let the outline quietly avoid the paper's own weak point by never mentioning it; a reviewer will find it whether the outline plans for it or not, so plan for it deliberately, ideally in the section where it does the least damage to the overall argument (usually addressed head-on rather than left for a rebuttal to raise first). Make sure each section's claim actually builds toward Arguing that asynchronous code review practices reduce senior engineer burnout without measurably slowing merge times, based on internal team data. — a section that doesn't move the thesis forward, however conventionally expected it is in this type of paper, should be flagged as filler rather than included silently. WHAT NOT TO DO Do not write full prose for any section — this is a skeleton of claims and evidence pointers, not a draft. Do not include a section just because papers in this format conventionally have one if it isn't earning its place in this specific argument. OUTPUT FORMAT Section-by-section: 1) section name, 2) the one-sentence claim it exists to establish, 3) bullet sub-points, 4) which available evidence supports it or a flag that none does yet. Close with a note on where The two teams weren't randomly assigned to review styles — the async team happened to also be working on a less time-pressured project during the study period. is addressed and why that placement was chosen.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
A generic academic outline defaults to the conventional section names for the paper's format because those are the most heavily represented pattern in any training data covering that genre, and generic headers require no actual engagement with the argument to produce — which is exactly why an outline built this way so often turns out to be hollow scaffolding once someone sits down to actually write the Discussion section and realizes it has no defined content. Requiring a one-sentence claim per section forces the model to work out what each section is actually for in this specific argument before naming it, which is a meaningfully different and harder task than just recalling that papers in this format conventionally have a Discussion section. Tying each claim to specific available evidence, and flagging gaps where none exists yet, surfaces the outline's actual weaknesses at the cheapest possible stage — before a full draft has been written around a claim nobody can actually support with the data on hand. The instruction to deliberately place the acknowledged weakness rather than let it go unaddressed matters because a model given a thesis to argue for will, absent explicit instruction otherwise, tend to build the outline as pure advocacy for that thesis, since that's the straightforward way to satisfy "help me argue for X" — deliberately building in the paper's own weak point, and choosing where to address it head-on, produces a more credible outline than one that silently hopes a reviewer won't notice the confound, which they will.
What you get back
Methods section — Claim: the study design isolates review-style effects on merge time and burnout while being transparent about its limitations. Evidence: 6 months of merge-time data, both teams' burnout surveys. Weakness placement: the confound (async team also had a lighter project load) is addressed directly in Methods rather than left for Discussion, framed as a limitation the Results section's interpretation must account for rather than a surprise raised later.
Verified against
ChatGPT GPT-5.1 · 2026-08-14
Changelog
- 2026-08-14 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
