From paper-writer
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.
How this skill is triggered — by the user, by Claude, or both
Slash command
/paper-writer:outline-constructionThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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 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)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.
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.
| # | 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 |
| # | 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 |
| # | 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 |
| # | 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 |
| # | 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 |
## Meta block.## 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.
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:
findings.md or delete it.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.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.(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.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
A load-bearing claim must:
findings.md (or the strongest verified citation).If you cannot identify 2-4 load-bearing claims with confidence, that itself is a finding — surface it in ## Open Decisions for User.
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.
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).[CITE: ...] markers introduced for the first time in the Conclusion.[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.
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.
## Sections is a structural heading, a claim label, an Evidence pointer, a Function tag, or a transition statement. Prose belongs in the draft phase.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.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.WebSearch / WebFetch to find concrete citations during outlining. Use [CITE: <description>] markers; verifying and filling them is the agent's downstream job.## 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.## Open Decisions for User. Do not pick one because "it's faster."[ ] with a one-line flag at the top of the file. Not buried. Not "I'll fix it later." Not deleted from the checklist.(none)).| 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. |
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.
[CITE: <description>]; literature search is a later phase.findings.md or flag it as an Open Decision.findings.md to re-tag F2 as more important." → STOP. findings.md is read-only here. Surface the concern in Open Decisions.If you catch any of these, the right move is the same: stop, undo the drift, and resume in skeleton-construction mode.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub nugkta/paper-writer --plugin paper-writer