outline-construction

Outline Construction

You are designing a paper's argumentative skeleton before any prose is written. The output is a navigable structure: section theses, claim-evidence chains, transitions, word allocation, sanity checks. Not a draft. Not a thesis recommendation. Not a literature search.

You will receive (or look up in papers/<paper-slug>/working/):

• findings.md from the writing-brainstormer (read-only input; never modify)
• A user-chosen thesis (one sentence; use verbatim)
• Target venue (drives skeleton type)
• Total word/page budget

Violating the letter of the rules below is violating the spirit of the rules. "I made the outline slightly more useful than the protocol asked, by adding a topic sentence" is a violation, not a contribution.

1. Choose Skeleton

A paper's skeleton is determined by target venue × paper type, not by author preference. Pick the closest archetype from the table below. If the closest archetype is not obvious from the inputs, ASK the user in ## Open Decisions for User rather than picking silently.

Archetype A: ML conference IMRaD (NeurIPS / ICML / ICLR — methods paper)

#	Section	Job
1	Introduction	Setup → Motivation → Comparison-to-prior → Result-preview
2	Related Work	Comparison chain only
3	Method	Setup chain (definitions, architecture, training objective)
4	Experiments	Setup (tasks, metrics) → Result chain
5	Discussion	Interpretation → Limitation → Implication
6	Conclusion	Synthesis only — no new claims

Archetype B: Benchmark / empirical-comparison paper (NeurIPS Datasets & Benchmarks; many ML conferences)

#	Section	Job
1	Introduction	Setup → Motivation → Result-preview
2	Related Benchmarks / Background	Comparison chain
3	Tasks & Metrics	Setup chain (task definitions, metric definitions, splits)
4	Baselines & Models	Setup → Comparison
5	Results	Result chain (per-task, per-model)
6	Analysis	Result → Interpretation chains; load-bearing claims usually live here
7	Limitations	Limitation chain
8	Conclusion	Synthesis only — no new claims

Archetype C: Theoretical paper

#	Section	Job
1	Introduction	Setup → Motivation → Result-preview (informal theorem statement)
2	Preliminaries	Setup chain (definitions, notation, assumptions)
3	Main Results	Theorem statements + proof sketches; Result + Interpretation
4	Proofs	Setup chain (full proofs, possibly in appendix)
5	Examples / Applications	Interpretation → Implication
6	Discussion	Limitation → Implication
7	Conclusion	Synthesis only — no new claims

Archetype D: Position / opinion paper

#	Section	Job
1	Introduction	Setup → Motivation → Thesis statement
2	Background / Stakes	Setup → Comparison
3	Argument 1	Claim → Evidence (citations, illustrative cases) → Interpretation
4	Argument 2	Same shape
5	Counter-arguments & Rebuttals	Comparison → Limitation → Interpretation
6	Implications	Implication chain
7	Conclusion	Synthesis only — no new claims

Archetype E: Bio-applied ML paper (Bioinformatics, Genome Biology, application track)

#	Section	Job
1	Introduction	Setup → Motivation (biological problem) → Result-preview
2	Background	Setup chain (biological context + relevant ML primer)
3	Method	Setup chain
4	Experiments	Setup → Result chain
5	Biological Validation	Result → Interpretation (does the model recover known biology?)
6	Discussion	Interpretation → Limitation → Implication
7	Conclusion	Synthesis only — no new claims

Selection rule

1. Identify paper type from the thesis: methods, benchmark, theoretical, position, bio-applied.
2. Cross-check with target venue's conventions (e.g., NeurIPS main track usually expects IMRaD or benchmark; a workshop on "Beyond Benchmarks" may welcome position).
3. Pick one archetype. Record the choice in the ## Meta block.
4. If two archetypes are equally plausible (e.g., a paper that is half methods-paper, half benchmark), list both candidates in ## Open Decisions for User and ask — do not silently pick.

You may add or rename a section within an archetype, but do not invent a brand-new archetype here. Novel structures live in a separate "experimental structure" note for the user to consider, not in the main outline.

2. Build Claim-Evidence Chain

For each section in the chosen skeleton, produce this exact block:

## Section <n>: <title> (<word budget>)

### Section thesis
<one sentence: what this section establishes>

### Argument structure
1. Claim: <claim text>
   - Evidence: <Finding F<id> from findings.md / Figure <id> / Table <id> / [CITE: <description>]>
   - Function: <one of: Setup / Motivation / Result / Interpretation / Comparison / Limitation / Implication>
2. Claim: <claim text>
   - Evidence: ...
   - Function: ...
... (more claims as needed)

### Transitions
- From previous: <what claim or evidence does this section inherit from the previous section?>
- To next: <what does this section leave the reader expecting in the next section?>

REQUIRED SUB-SKILL: Use claim-evidence-chain for the claim/evidence/function unit. It defines the three-part unit (CLAIM / EVIDENCE / FUNCTION), the seven allowed Function categories, the evidence-type-vs-supportable-claim table, and the claim quality checklist. Do not paraphrase or simplify those rules here — load and apply them. In particular:

• A claim with no Evidence is hand-waving — find evidence from findings.md or delete it.
• A claim with no Function is decoration — delete it.
• A claim whose Evidence cannot support its scope (e.g., one experiment supporting a "in general" claim) is a mismatch — narrow the claim or strengthen the evidence.

Evidence pointer rules

• Every Evidence pointer must resolve to something already in findings.md (a Finding F-id, a proposed Figure/Table id, or an existing [CITE: ...] marker), or to a fresh [CITE: <description>] marker for a citation slot the draft-writer will fill later.
• Do not invent a figure not in findings.md. If the chain needs a figure that does not exist, add an item to ## Open Decisions for User flagging the gap; do not fabricate.
• Do not write (Smith et al., 2024) from memory. Use [CITE: <one-sentence description of the source needed>]. Citation verification is the agent's downstream job, not the outlining skill's.

Section thesis rules

• Exactly one sentence.
• Specific and falsifiable. Not "we discuss results" — instead "Bag-of-Pfam matches or beats learned embeddings on 3 of 4 OOD task splits."
• Logically derivable from the previous section's thesis (sets up the chain).

Transitions rules

• "From previous" names the specific claim or evidence being inherited, not a topic. Bad: "From previous: builds on the methods discussion." Good: "From previous: inherits the Pfam-feature definition (Section 3, Claim 2) and the OOD-split definition (Section 3, Claim 4)."
• "To next" names the specific question the next section will answer, not a topic. Bad: "To next: discussion." Good: "To next: leaves open whether the OOD gap is driven by representation mismatch or by training data coverage; Section 6 addresses this."

3. Identify Load-Bearing Claims

Mark with [LOAD-BEARING] any claim that the entire paper depends on. Place the tag at the end of the Claim line:

1. Claim: Bag-of-Pfam baselines achieve higher mean OOD AUC than learned embeddings across all 4 splits. [LOAD-BEARING]
   - Evidence: F1 (results-table-1.csv), Figure 1
   - Function: Result

Hard count constraints

• 2-4 load-bearing claims per paper. Not 0. Not 1. Not >6.
• 0-1: the paper has no defensible spine; ask the user to identify which claim the paper actually rests on.
• ≥7: the argument is overloaded — every claim cannot be the most important. Flag this at the top of the output and ASK the user to consolidate, do not silently ship.

A load-bearing claim must:

• Be supported by the strongest single evidence in findings.md (or the strongest verified citation).
• Survive the most hostile reviewer reading you can imagine.
• Be falsifiable: a reader could in principle disagree on the data.

If you cannot identify 2-4 load-bearing claims with confidence, that itself is a finding — surface it in ## Open Decisions for User.

4. Sanity Checks

Produce this exact checklist at the top of the output (in ## Sanity Check Results). Mark each item [x] (passed) or [ ] (failed). For any [ ], include a one-line flag explaining the failure.

• Figure/table usage is appropriate. Every Figure/Table from findings.md referenced in this outline is appropriate for its assigned section, used as primary evidence in exactly one section, not orphaned (every figure proposed in findings.md is either assigned to a section or explicitly deferred in ## Open Decisions for User).
• Word budgets sum within 10% of total. Sum of per-section word budgets is between 0.9 × total and 1.1 × total. (Show the actual sum and the target in the flag line if failed.)
• Section theses chain logically. Each section's thesis depends on the previous section's thesis or evidence; the dependency is named in the "From previous" transition.
• Conclusion introduces no new claims. Every claim in the Conclusion (or final synthesis section, whatever it is named in the chosen archetype) has its Evidence already cited in an earlier section's claim chain. No new findings, no new figures, no new [CITE: ...] markers introduced for the first time in the Conclusion.
• Load-bearing claim count is 2-4. Count [LOAD-BEARING] tags across the outline; the count is in [2, 4]. (If 0-1 or ≥5, flag and ask the user.)

If any check fails, flag the failure explicitly at the top of the output (do not bury it in a section). Do not silently proceed and do not "fix" by deleting evidence — surface the failure and ask the user.

5. Output Format

Write to papers/<paper-slug>/working/outline.md — exactly that path, including the working/ segment. Create parent directories if missing (this path is inside the agent's allowed write zone). Do not write anywhere else.

Use this exact top-level structure:

# Outline — <paper title> — <YYYY-MM-DD>

## Meta
- Thesis: <user-supplied thesis verbatim>
- Venue: <target venue>
- Word budget: <total>
- Skeleton type: <archetype A/B/C/D/E or named variant>

## Sanity Check Results
- [x] Figure/table usage is appropriate.
- [x] Word budgets sum within 10% of total. (Sum: <n> / Target: <total>)
- [x] Section theses chain logically.
- [x] Conclusion introduces no new claims.
- [x] Load-bearing claim count is 2-4. (Count: <n>)
<one-line flag for each [ ] item, if any>

## Sections
<full claim-evidence chain block per Section 2 of this skill, one block per section>

## Open Decisions for User
- <points where multiple framings are viable; user must choose>
- <gaps you noticed in findings.md that block a clean chain>
- <skeleton-type ambiguities, if you raised any>
- <load-bearing-count issues, if any>

After writing the file, give the user a short chat summary that points to the file path and lists any sanity-check failures and open decisions explicitly. Do not paste the full outline into chat — the file is the artifact.

6. What You Must NOT Do

• No prose. No paragraphs, no topic sentences, no "In this section, we will...", no "We argue that..." — every line under ## Sections is a structural heading, a claim label, an Evidence pointer, a Function tag, or a transition statement. Prose belongs in the draft phase.
• No findings modification. findings.md is read-only. If you think a finding is mis-titled, mis-categorized, or missing context, raise it in ## Open Decisions for User — do not edit the file.
• No new findings or figures. Every Evidence pointer must resolve to something already in findings.md (Finding F-id, Figure id, Table id) or to a [CITE: ...] marker for a literature slot. Do not invent Figure 4: t-SNE of embeddings because the chain needs it; either find it in findings.md, or add it as an Open Decision and ask the user.
• No literature search. Do not run WebSearch / WebFetch to find concrete citations during outlining. Use [CITE: <description>] markers; verifying and filling them is the agent's downstream job.
• No thesis selection or re-litigation. The user supplied the thesis. Use it verbatim in ## Meta. Do not soften it, sharpen it, swap it for one of the candidate hooks in findings.md, or write a competing thesis "for completeness." If you believe the thesis is unsupported by findings.md, raise that as a single item in ## Open Decisions for User — do not pick a different one.
• No silent skeleton picks under genuine ambiguity. If two archetypes are equally plausible, ask in ## Open Decisions for User. Do not pick one because "it's faster."
• No silent sanity-check failures. A failed check appears as [ ] with a one-line flag at the top of the file. Not buried. Not "I'll fix it later." Not deleted from the checklist.
• No collapsed output sections. All four top-level sections (Meta, Sanity Check Results, Sections, Open Decisions for User) must be present and in order, even if Open Decisions is empty (then say (none)).

Rationalization table

Rationalization	Counter
"The thesis is slightly off; I'll just sharpen the wording in Meta."	The user picked the thesis. Use it verbatim. If you think it's wrong, raise an Open Decision; don't rewrite it.
"I added a one-paragraph topic sentence to each section so the draft-writer has a starting point."	That's prose. Delete it. The draft-writer is a different phase with different rules.
"Figure 4 (t-SNE of embeddings) makes the analysis section much stronger."	If it's not in findings.md, you cannot reference it. Add it to Open Decisions and ask.
"I tagged 8 claims as load-bearing — they really are all critical."	More than 6 means the argument is overloaded. Flag and ask the user to consolidate.
"Word budgets sum to 8800 on an 8000 budget — that's basically 10%."	"Basically" isn't 10%. 8800/8000 = 1.10 exactly; 8801 fails. Be precise or rebalance.
"The Conclusion should preview the natural next paper — that's standard."	"Future work" framing must be supported by an earlier-section claim. New claims in the Conclusion is the rule's exact target. Move the claim earlier or cut it.
"I picked benchmark-paper skeleton because the data looks like benchmark data."	Pick from venue + paper type, not from "looks like." If genuinely ambiguous, ask.
"The user is AFK; I'll pick a skeleton and let them course-correct in review."	Make progress on the structural design that doesn't require a silent pick — fill ## Open Decisions for User and stop. The structured ask is progress.

7. Red Flags — STOP if you catch yourself doing any of these

These signals mean you have drifted out of skeleton-building and into a different phase. Stop, delete the offending text, and resume in the right mode.

• "I started writing 'In this section we will...'" → STOP. You are constructing a skeleton, not a draft. Delete and resume with claim/evidence/function lines.
• "I'm reaching for WebSearch to find a paper to cite for this claim." → STOP. Use [CITE: <description>]; literature search is a later phase.
• "I'm typing a paragraph under the section thesis to explain it." → STOP. The thesis is one sentence. The argument structure is the explanation.
• "The user's thesis isn't quite right; let me write a slightly better one." → STOP. Use the thesis verbatim. Raise concerns in Open Decisions, don't substitute.
• "I'm about to invent Figure 4 because the chain needs it." → STOP. Either find it in findings.md or flag it as an Open Decision.
• "I'm tagging this claim load-bearing too — that makes 9, but they're all important." → STOP. Consolidate or ask the user.
• "I'll skip the sanity check at the top and 'just be careful' instead." → STOP. The checklist is the artifact. Produce it.
• "The Conclusion needs a forward-looking claim to feel complete; I'll add one." → STOP. New claims in the Conclusion violate the no-new-claims rule. Move the claim earlier or cut.
• "I'll edit findings.md to re-tag F2 as more important." → STOP. findings.md is read-only here. Surface the concern in Open Decisions.
• "Two archetypes both fit; I'll pick the more common one and move on." → STOP. Ask the user via Open Decisions; silent picks under ambiguity are forbidden.

If you catch any of these, the right move is the same: stop, undo the drift, and resume in skeleton-construction mode.