# Dr Cook:paper Writer

> Draft academic manuscript sections (IMRaD format). Use when writing or drafting introduction, methods, results, discussion, or abstract sections of a research paper. Adapts to target journal style and research domain. Triggers on: write paper, draft manuscript, write introduction, write methods, write results, write discussion, write abstract, IMRaD, 写论文, 写introduction, 写方法, 写结果, 写讨论, 稿件起草, 论文写作.

- Skill: `wen-chen/dr-cook-paper-writer` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add wen-chen/dr-cook-paper-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wen-chen/dr-cook-paper-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: wen-chen (https://skillmd.com/u/wen-chen)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/wen-chen/dr-cook-paper-writer

---


# paper-writer

## 1. Overview

paper-writer drafts structured academic manuscript sections following the IMRaD format (Introduction, Methods, Results, and Discussion). It supports four manuscript types — original articles, systematic reviews, case reports, and letters to the editor — each with its own structural conventions and reporting standards. Output adapts to the target journal's style by loading constraints from `references/journal-styles.md`, and to the research domain by applying terminology standards and special requirements from `shared/domain-configs.md`. When upstream modules such as literature-reviewer or research-gap-finder have already run, paper-writer automatically inherits their `key_findings` and `references` fields, using them as the content basis for the drafted text. No re-collection of parameters that are already present in `context_output` is needed.

## 2. Parameters

### Required

| Parameter | Values | Description |
|---|---|---|
| `section` | `introduction` \| `methods` \| `results` \| `discussion` \| `abstract` \| `full` | Which section to draft. Use `full` to generate all five sections sequentially. |
| `manuscript_type` | `original_article` \| `review` \| `case_report` \| `letter` | Type of manuscript being written. Determines applicable reporting standards. |
| `domain` | `tcm` \| `bioinformatics` \| `clinical` \| `pharmacology` | Research domain. If not provided by the user, load from `shared/domain-configs.md` defaults or from `context_output.parameters.domain` if available. |

### Optional

| Parameter | Values | Description |
|---|---|---|
| `target_journal` | string | Journal name. If provided, load style constraints from `references/journal-styles.md`. |
| `language` | `en` \| `zh` (default: `en`) | Output language for the drafted text. |
| `output_format` | `markdown` \| `docx` \| `latex` (default: `markdown`) | Format of the generated manuscript section. |

### Parameter collection rule

If required parameters are missing and cannot be inherited from upstream context, ask for them one at a time in this order: `section` first, then `manuscript_type`, then `domain`. Do not ask for optional parameters unless the user has already mentioned a journal name.

## 3. Workflow

**Step 1 — Check upstream context.**
Before asking the user anything, inspect the available `context_output` object. If a prior module (literature-reviewer, research-gap-finder, or any other) has run, extract the following fields and treat them as already-provided values: `domain`, `target_journal`, `language`, `key_findings`, `references`, and any parameters stored in `context_output.parameters`. Fields present in upstream context override the need to ask the user for those values. If upstream `status` is `failed`, halt and inform the user before proceeding.

**Step 2 — Collect missing required parameters.**
Identify which required parameters (`section`, `manuscript_type`, `domain`) are still absent. Ask for each one at a time, in order: `section` → `manuscript_type` → `domain`. Wait for the user's answer before asking for the next.

**Step 3 — Load structure guidance.**
Read `references/imrad-structure.md` to retrieve the structural norms for the requested section. This file defines the expected paragraph roles and logical flow for each IMRaD section (e.g., for Introduction: Background → Gap → Objective; for Discussion: Restatement of main finding → Interpretation → Limitations → Conclusion). Use these norms as the skeleton for the drafted text.

**Step 4 — Load journal style (conditional).**
If `target_journal` is known (from upstream context or user input), read `references/journal-styles.md` and identify the applicable style constraints: word limit per section, abstract type (structured vs. unstructured), maximum number of references, figure and table limits, and reference format (Vancouver vs. APA). Apply these constraints as hard boundaries during drafting.

**Step 5 — Load manuscript type conventions.**
Always read `references/manuscript-types.md` regardless of other parameters. Extract the type-specific requirements for the given `manuscript_type`: PRISMA checklist for systematic reviews, CARE guidelines for case reports, CONSORT flow diagram reference for RCT original articles, and standard IMRaD for original articles and letters. Flag to the user if any mandatory reporting element appears to be missing from the available content.

**Step 6 — Draft the section.**
Compose the manuscript text using the structural skeleton from Step 3, the content material from upstream `key_findings` and `references` (if available), and the constraints gathered in Steps 4 and 5. Apply domain-specific rules from `shared/domain-configs.md`:
- `tcm`: use bilingual EN/ZH terminology as specified in `term-mapping.md`; apply syndrome differentiation (辨证论治) framing where relevant.
- `bioinformatics`: use HGNC-approved gene symbols in italics; include data deposition and code availability notes in Methods.
- `clinical`: use CONSORT, STROBE, or PRISMA language as appropriate; include ethics committee and trial registration references.
- `pharmacology`: use IUPHAR/BPS nomenclature; specify dose units, administration routes, and in vitro vs. in vivo context.
Cite `references` inline using the citation format determined by the domain or journal style. Do not fabricate citations; only cite items present in the `references` list from upstream context or provided by the user.

**Step 7 — Present output.**
Return the drafted text in the requested `output_format`, followed by a structural annotation block listing the role of each paragraph. See Section 4 for the exact output template. If `section: full` was requested, generate all five sections in order — Introduction, Methods, Results, Discussion, Abstract — separated by a horizontal rule.

**Step 8 — Offer iteration.**
Ask the user whether they want to adjust depth, tone, style, or focus. Revise the specific section on request without re-drafting unaffected sections. Repeat until the user is satisfied or moves to the next pipeline stage.

## 4. Output Format

Default (`output_format: markdown`):

```
## [Section Name]

[Draft text — paragraphs separated by blank lines]

---
**Structural notes:**
- Para 1: [paragraph role, e.g., Background]
- Para 2: [paragraph role, e.g., Gap statement]
- Para 3: [paragraph role, e.g., Study objective]

**Style adaptations applied:** [list journal word limits, abstract type, reference format, domain terminology rules applied]
```

For `section: full`, generate all five sections in order: Introduction → Methods → Results → Discussion → Abstract. Separate sections with a horizontal rule (`---`). Include structural notes after each section individually.

## 5. context_output

### Reads from upstream

| Field | Source | Usage |
|---|---|---|
| `domain` | any upstream module | Terminology standard and domain-specific drafting rules |
| `target_journal` | any upstream module | Triggers journal style loading |
| `language` | any upstream module | Output language (en or zh) |
| `key_findings` | literature-reviewer, research-gap-finder | Content basis for Results and Discussion |
| `references` | literature-reviewer, citation-checker | Cited inline in the drafted text |
| `parameters.*` | any upstream module | Prevents re-asking for already-collected values |

### Writes to output

```json
{
  "module": "paper-writer",
  "domain": "<collected>",
  "target_journal": "<collected or null>",
  "language": "<collected>",
  "raw_text": "<drafted manuscript section(s)>",
  "parameters": {
    "section": "<collected>",
    "manuscript_type": "<collected>"
  },
  "status": "success",
  "error_message": "string | null",
  "summary": "Drafted [section] for [manuscript_type] targeting [journal/domain]"
}
```

Downstream readers of `raw_text`: citation-checker, english-polisher, cover-letter-writer.

## 6. References

See `references/` for:
- `imrad-structure.md` — Section structure norms, paragraph roles, logic flows for each IMRaD section
- `journal-styles.md` — Style constraints by journal group (word limits, abstract type, reference format, figure limits)
- `manuscript-types.md` — Type-specific conventions and reporting checklists (PRISMA, CARE, CONSORT, IMRaD variants)