---
name: outline-construction
description: Use when designing a paper's argumentative skeleton from a findings inventory and a chosen thesis, before any prose is written. Covers skeleton selection (IMRaD/benchmark/position/bio-applied), section-level claim-evidence chain construction, load-bearing claim identification, word-budget allocation, and conclusion-no-new-claims sanity checks.
---

# 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:

```markdown
# 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.