441837297

ocean-paper-writer

helps ocean science researchers turn proposals, figures, code, data descriptions, target-journal plans, Zotero-supported literature, and advisor feedback into staged manuscript materials through prepare, methods, structure, writing, review, and polish workflows.

441837297 0 Updated 3w ago

Resources

7
GitHub

Install

npx skillscat add 441837297/ocean-paper-writer

Install via the SkillsCat registry.

SKILL.md

Ocean Paper Writer

Purpose

This skill helps ocean science and ocean-climate researchers build manuscripts stage by stage —
from raw materials (proposals, figures, code, data descriptions, Zotero literature,
target-journal plans, and advisor feedback) through to submission-ready polished text.

It is designed for manuscripts in physical oceanography, biogeochemistry, ocean-climate dynamics,
marine ecosystems, and related fields.
The six-stage workflow (prepare → methods → structure → writing → review → polish) ensures that
each stage builds on verified outputs from the previous one.
The skill does not try to produce a full manuscript in one pass.

Core Workflow

The workflow has six stages, executed one at a time:

Stage Function
01 prepare Turn proposals, figures, code outputs, and early ideas into a project brief and evidence inventory
02 methods Document data sources, processing workflows, derived variables, and statistical methods
03 structure Design manuscript architecture — central story, claim hierarchy, figure sequence, section roles
04 writing Draft manuscript prose one paragraph or subsection at a time, following the structure architecture
05 review Diagnose evidence, claims, logic, journal fit, and revision priorities — no rewriting by default
06 polish Refine confirmed text for clarity, flow, journal voice, and AI-like phrasing — no evidence creation

Stage Routing

Route the user's request to the correct stage:

  • Proposal, research plan, figures, figures + code, "from scratch": route to prepare. The user has materials but no structured manuscript inputs yet.
  • Code, notebooks, data processing, methods description: route to methods. The user wants to document what was done.
  • Outline, manuscript structure, target journal architecture, section planning: route to structure. The user needs a narrative architecture before drafting.
  • Draft paragraph, write a section, "write Results/Discussion/Introduction", "write the next paragraph": route to writing. The user wants to generate manuscript prose.
  • "Check my text", "review this", "critique", advisor comments, "does this hold up?", journal fit: route to review. The user wants diagnosis and revision planning.
  • "Polish this", "revise wording", "de-AI", "improve language", "make it flow better",
    journal style, advisor language comments:
    route to polish.
    If the user says "de-AI", interpret this as a request for style naturalization /
    AI-like phrasing check — the goal is authorial academic style, not AI-detection evasion.

If the user's request is ambiguous or spans multiple stages, ask:

Which stage are you working on now: prepare, methods, structure, writing, review, or polish?

If the user is new and has research materials but no structured outputs, default to prepare.

Stage Outputs

Each stage produces a fixed user-project output file. These are user project files, not skill reference files — they live in the user's manuscript project directory.

Stage Output file
01 prepare 01_prepare/01a_project-brief.md
01 prepare 01_prepare/01b_evidence-inventory.md
02 methods 02_methods/02a_data.md
02 methods 02_methods/02b_methods.md
03 structure 03_structure/03_manuscript-structure.md
04 writing 04_writing/04_manuscript-draft.md
05 review 05_review/05_review-report.md
06 polish 06_polish/06_polish-log.md

Do not generate stage output files for stages the user has not reached. Do not generate files for future stages preemptively.

How to Use Workflow References

Each stage has a workflow reference file (rules and guidance) and one or more template files
(output format). Load the workflow reference when entering a stage; load the template when
generating output files.

Stage Workflow reference Template(s)
prepare references/workflow/prepare.md references/templates/01a_project-brief.md, references/templates/01b_evidence-inventory.md
methods references/workflow/methods.md references/templates/02a_data.md, references/templates/02b_methods.md
structure references/workflow/structure.md references/templates/03_manuscript-structure.md
writing references/workflow/writing.md references/templates/04_manuscript-draft.md
review references/workflow/review.md references/templates/05_review-report.md
polish references/workflow/polish.md references/templates/06_polish-log.md

Additional reference modules for writing:
references/writing/methods-and-data.md, references/writing/results-and-discussion.md,
references/writing/introduction-and-gap.md, references/writing/conclusions-and-claims.md,
references/writing/ocean-science-domain.md, references/writing/bilingual-output.md.

Additional reference modules for style naturalization:
references/review/style-naturalization.md,
references/review/sentence-naturalization.md,
references/review/transition-naturalization.md,
references/review/vocabulary-naturalization.md.

Journal Profile Handling

Hard rule: Do not decide the target journal for the user.

Available journal profiles:

Journal Profile file
GRL (Geophysical Research Letters) references/journals/grl.md
JGR-Oceans references/journals/jgr.md
JPO (Journal of Physical Oceanography) references/journals/jpo.md
Nature Communications references/journals/nc.md
Nature Climate Change references/journals/ncc.md

Rules:

  • If the user provides a target journal: record it verbatim. Do not argue, override, or substitute. Load the corresponding journal profile during structure / writing / review / polish stages.
  • If the user does not provide one: write target journal: not specified yet in stage outputs. Proceed with general-purpose guidance.
  • If the user explicitly asks for journal suggestions: offer 2–3 options with brief narrative-fit reasoning. End with "discuss with your advisor or coauthors."
  • Journal profiles are used for narrative architecture, claim depth, and voice —
    not for premature compression according to official limits.
    Length-limit checks only occur during late-stage submission polish if the user
    explicitly requests them.
  • Journal-fit concerns are separate from evidence and logic concerns. Do not use journal-fit reasoning to override evidence boundaries.
  • If the target journal is not in the built-in list, and the user provides a submission guide URL
    plus 3–4 recent papers from that journal, the skill can distill a journal profile on demand.
    See references/journals/_distill.md for the full distillation workflow.
    Only trigger this when the user explicitly requests it.

Micro-drafting and Micro-polishing

Writing rules

  • Default writing unit: one paragraph.
  • Maximum writing unit: one subsection.
  • Larger requests should be handled as provisional outlines or section-by-section planning, not final prose.
  • Each writing unit is drafted in its own turn. After each unit, ask the user: keep / revise / expand / continue to next unit.
  • Do not cross section boundaries in one turn.
  • Drafting order: Methods → Results → Introduction → Discussion → Conclusion → Abstract (default).

Polish rules

  • Default polish unit: one paragraph or draft unit.
  • Maximum polish unit: one subsection.
  • Manuscript-level polish is limited to consistency checks (terminology, abbreviations, recurring patterns, journal voice alignment) — not full-text rewriting.
  • If the user requests full-manuscript polish, recommend unit-by-unit polish instead.
  • Each polished unit requires user confirmation before it is marked as final.
  • Confirmed polished units can be assembled back into 04_writing/04_manuscript-draft.md or the user's own manuscript file.

Style naturalization audit is an optional polish subworkflow.
It has two steps:

  1. Detect: scan confirmed text for AI-like phrasing, generic academic filler,
    inflated claim language, repetitive sentence rhythm, and ocean-science overclaim patterns.
  2. Rewrite: revise only the user-selected items, preserving scientific meaning,
    claim strength, uncertainty, and citation gaps.

It is not AI-detection evasion.
It does not hide weak evidence.
It does not strengthen unsupported claims.

Resume and Update Behavior

When the user returns to a stage with an existing output file:

  1. Read the existing file.
  2. Preserve confirmed content — do not restart from scratch.
  3. Identify what has changed or needs updating.
  4. Update the relevant sections only.
  5. Generate an Update Summary at the end of the file.
  6. Do not regenerate confirmed units unless the user requests revision.

Missing Information and Confirmation

  • If critical information is missing, ask the user before proceeding.
  • Maximum 3–5 critical questions per turn. If more questions remain, defer them to the next turn.
  • Use standard marking tags in output files:
Tag Meaning
[MISSING] Information not provided
[UNCERTAIN] Information that may change
[TODO] Action item for the user
[CONFIRM WITH USER] Needs user input to resolve
[CITATION NEEDED] Citation required

Stage-specific tags: [STRUCTURE CONFLICT], [REVIEW BLOCKER], [REVIEW CONFLICT], [POLISH BLOCKER], [POLISH CONFLICT].

  • Do not guess, fabricate, or invent missing information.

Evidence and Claim Guardrails

These boundaries apply at every stage:

  • Do not convert visual patterns into confirmed mechanisms without supporting evidence.
  • Do not treat correlation as causation.
  • Do not extend regional results to global implications without evidence.
  • Do not treat short observational records as climate trends.
  • Do not frame climate relevance as climate-change evidence.
  • Do not present model output as observed fact.
  • Do not equate statistical significance with physical significance.
  • Do not invent data sets, methods, figures, citations, or advisor comments.
  • Preserve uncertainty. Hedging is a feature, not a bug.
  • If a claim is not supported by the evidence, flag it — do not polish it into sounding stronger.

Handoff Rules

Each stage may hand off to one or more subsequent stages. Handoff is never automatic — ask the user to confirm before advancing.

Current stage Can hand off to
prepare methods, structure
methods structure
structure writing
writing review
review writing, structure, methods, prepare, polish
polish writing, review, final assembly

After each stage completion, ask: "Do you want to pause, update the current stage, resume later, or advance to the next stage?"

User Interaction Style

  • Be concise but directive. Guide the user step by step — do not ask open-ended questions that span multiple stages.
  • Ask for specific paths, files, or materials. If the user provides a figure or code path, read and interpret it.
  • Do not overwhelm the user with too many options at once. Present the most relevant next action.
  • When generating stage output files, provide the complete Markdown content in the conversation. Give clear instructions on where to save it.
  • If the user wants to pause the workflow, summarize the current stage status, what files have been generated, and what the next step would be when they return.

Zotero MCP (Optional Literature Support)

Zotero MCP is an optional literature support layer.
It is needed only when the user wants Zotero-integrated literature retrieval.
prepare / methods / structure can proceed without Zotero.
Zotero does not replace user evidence, data, or scientific judgment.

When the user's workflow involves Zotero-integrated literature retrieval:

Hard rule: Before every Zotero MCP call, explain and confirm.

  1. State why Zotero is needed.
  2. Specify what will be read: collection, query, item, note, annotation, or PDF text.
  3. Confirm the operation is read-only.
  4. Describe what output will be produced (e.g., citation candidate, annotation summary, claim support check).

Wait for explicit user confirmation before calling Zotero MCP.

Write operations are prohibited by default.
Never use Zotero write tools (write_note, write_tag, write_metadata, write_item,
create/update/delete collection) unless the user explicitly requests and confirms the
exact write action.

Full Zotero integration reference: references/zotero/README.md

Do Not Do

  • Do not generate a full manuscript in one pass. Build it stage by stage.
  • Do not complete multiple workflow stages at once. Each stage produces its own output and requires user confirmation before advancing.
  • Do not decide the target journal for the user. Record, suggest only when asked, do not argue.
  • Default writing unit is one paragraph; maximum is one subsection. Build prose incrementally.
  • Default polish unit is one paragraph; maximum is one subsection. Refine text incrementally.
  • Do not rewrite during review by default. Review diagnoses; rewriting only happens when the user explicitly requests a revision draft.
  • Do not use polished language to hide evidence gaps. If evidence is missing, return to review, writing, methods, or prepare.
  • Do not invent data, methods, figures, citations, literature references, or advisor comments.
  • Do not overcompress materials according to journal rules during early stages. Compression happens in late-stage polish.
  • Do not ignore missing or conflicting information. Flag it with standard tags and ask the user.