/nature-writing
Draft, restructure, or plan Nature-style manuscript sections from author-provided claims, results, figures, notes, or Chinese drafts. Use when the user wants to write or rebuild an abstract, introduction, results narrative, discussion, conclusion, title, or full manuscript
$ npx -y skills add Galaxy-Dawn/claude-scholar --skill nature-writing --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/nature-writing
Context preview
The summary Claude sees to decide when to auto-load this skill.
Draft, restructure, or plan Nature-style manuscript sections from author-provided claims, results, figures, notes, or Chinese drafts. Use when the user wants to write or rebuild an abstract, introduction, results narrative, discussion, conclusion, title, or full manuscript
SKILL.md
nature-writing.SKILL.mdname: nature-writing
description: Draft, restructure, or plan Nature-style manuscript sections from author-provided claims, results, figures, notes, or Chinese drafts. Use when the user wants to write or rebuild an abstract, introduction, results narrative, discussion, conclusion, title, or full manuscript argument rather than only polish finished prose.
version: 0.2.0
author: Community contribution based on curated Nature/Nature Communications writing patterns and open research-writing notes
Nature-Style Scientific Writing
Use this skill when the user needs help creating or rebuilding manuscript prose, not merely polishing existing sentences.
Core stance
- Author evidence comes first. Do not invent results, mechanisms, references,
methods, novelty, sample sizes, statistics or limitations.
- Write the argument before writing the sentences.
- Make the paper easy to judge: relevance, novelty, trust, reuse and meaning.
- Use ambitious but bounded claims.
- If essential evidence is missing, write a placeholder or ask for the missing
input instead of filling the gap.
When to open extra files
| File | Open when | |---|---| | [references/article-architecture.md](references/article-architecture.md) | You need section-level structure, argument order, or published-article writing patterns | | [references/abstract.md](references/abstract.md) | Drafting or revising an abstract, especially challenge-contribution and challenge-insight-contribution forms | | [references/introduction.md](references/introduction.md) | Drafting or revising an Introduction, task framing, technical challenge, contribution framing, or teaser/pipeline logic | | [references/related-work.md](references/related-work.md) | Rebuilding Related Work as topic synthesis instead of a paper-by-paper list | | [references/method.md](references/method.md) | Writing Method sections, pipeline modules, module motivation, technical advantages, or implementation details | | [references/experiments.md](references/experiments.md) | Planning or writing Experiments/Results around baselines, ablations, metrics, tables, figures, and claim support | | [references/conclusion.md](references/conclusion.md) | Writing a bounded conclusion with contribution, evidence, impact, limitation, and future direction | | [references/paragraph-flow.md](references/paragraph-flow.md) | User asks whether a paragraph flows, makes sense, or is clear; use reverse outlining and paragraph-message checks | | [references/paper-review.md](references/paper-review.md) | Final manuscript self-review, rejection-risk audit, claim-evidence alignment, or reviewer-facing critique | | [references/chinese-author-workflow.md](references/chinese-author-workflow.md) | The user's notes are Chinese, mixed Chinese-English, or organized as lab notes rather than manuscript prose | | [references/examples/index.md](references/examples/index.md) | You need concrete abstract, introduction, or method examples after choosing the relevant guide |
Intake
Before drafting, identify:
- manuscript section: title, abstract, introduction, results, discussion,
conclusion, significance paragraph or full outline
- paper type: mechanism, method, resource, device, model, clinical, materials,
computational or interdisciplinary
- core claim: what the paper actually demonstrates
- evidence: figures, measurements, comparisons, datasets, statistics or examples
- boundary: where the claim stops
- target journal or word limit, if provided
If any of `core claim`, `evidence` or `boundary` is absent, expose the gap before drafting. You may still produce a scaffold with explicit placeholders.
Writing workflow
1. Build a one-sentence argument: `In [system/problem], we show [advance] using [approach], supported by [evidence], with [boundary].` 2. Choose the section architecture from `references/article-architecture.md`. 3. Map each paragraph to one job: context, gap, approach, result, comparison, mechanism, implication or limitation. 4. Draft from evidence outward. Keep claims near the data that support them. 5. Calibrate verbs: `show`, `demonstrate`, `suggest`, `indicate`, `enable`, `may`, `could`. 6. Remove unsupported novelty and universal claims. 7. Run a paragraph-flow check: one paragraph, one message, with a clear first sentence and explicit sentence-to-sentence relation. 8. Return prose plus concise notes on assumptions and missing inputs.
Section defaults
Abstract
Default Nature pattern:
`context/problem -> gap -> approach -> key result -> implication -> boundary`
For technical AI, ML, CV or method-heavy manuscripts, open `references/abstract.md` and choose one of:
- `challenge -> contribution`
- `challenge -> insight -> contribution`
- `multiple contributions`
Keep it compact. Include quantitative or comparative detail when the user provided it. End with what the work enables, not generic importance.
Introduction
Use:
`field scale -> bottleneck -> prior attempts -> unresolved gap -> present study`
For method-heavy papers, open `references/introduction.md` and reason backward from the technical challenge and contribution before drafting forward.
Do not summarize all results. The final paragraph should state what this paper does and how it addresses the gap.
Results narrative
Use an evidence ladder:
`system/workflow -> validation -> main result -> baseline comparison -> mechanism/diagnostic analysis -> application or generalization`
Each subsection should have a claim-first opening and then data support.
For ML/conference-style experiment sections, open `references/experiments.md` and make sure each major claim is backed by comparison, ablation, or stress-test evidence.
Related Work
Use:
`topic scope -> representative methods -> limitation tied to this paper -> distinction`
Group prior work by technical topic and mechanism, not by publication year.
Discussion
Use:
`central advance -> evidence meaning -> relation to prio
Read more
name: nature-writing description: Draft, restructure, or plan Nature-style manuscript sections from author-provided claims, results, figures, notes, or Chinese drafts. Use when the user wants to write or rebuild an abstract, introduction, results narrative, discussion, conclusion, title, or full manuscript argument rather than only polish finished prose. version: 0.2.0 author: Community contribution based on curated Nature/Nature Communications writing patterns and open research-writing notes
Nature-Style Scientific Writing
Use this skill when the user needs help creating or rebuilding manuscript prose, not merely polishing existing sentences.
Core stance
- Author evidence comes first. Do not invent results, mechanisms, references,
methods, novelty, sample sizes, statistics or limitations.
- Write the argument before writing the sentences.
- Make the paper easy to judge: relevance, novelty, trust, reuse and meaning.
- Use ambitious but bounded claims.
- If essential evidence is missing, write a placeholder or ask for the missing
input instead of filling the gap.
When to open extra files
| File | Open when | |---|---| | [references/article-architecture.md](references/article-architecture.md) | You need section-level structure, argument order, or published-article writing patterns | | [references/abstract.md](references/abstract.md) | Drafting or revising an abstract, especially challenge-contribution and challenge-insight-contribution forms | | [references/introduction.md](references/introduction.md) | Drafting or revising an Introduction, task framing, technical challenge, contribution framing, or teaser/pipeline logic | | [references/related-work.md](references/related-work.md) | Rebuilding Related Work as topic synthesis instead of a paper-by-paper list | | [references/method.md](references/method.md) | Writing Method sections, pipeline modules, module motivation, technical advantages, or implementation details | | [references/experiments.md](references/experiments.md) | Planning or writing Experiments/Results around baselines, ablations, metrics, tables, figures, and claim support | | [references/conclusion.md](references/conclusion.md) | Writing a bounded conclusion with contribution, evidence, impact, limitation, and future direction | | [references/paragraph-flow.md](references/paragraph-flow.md) | User asks whether a paragraph flows, makes sense, or is clear; use reverse outlining and paragraph-message checks | | [references/paper-review.md](references/paper-review.md) | Final manuscript self-review, rejection-risk audit, claim-evidence alignment, or reviewer-facing critique | | [references/chinese-author-workflow.md](references/chinese-author-workflow.md) | The user's notes are Chinese, mixed Chinese-English, or organized as lab notes rather than manuscript prose | | [references/examples/index.md](references/examples/index.md) | You need concrete abstract, introduction, or method examples after choosing the relevant guide |
Intake
Before drafting, identify:
- manuscript section: title, abstract, introduction, results, discussion,
conclusion, significance paragraph or full outline
- paper type: mechanism, method, resource, device, model, clinical, materials,
computational or interdisciplinary
- core claim: what the paper actually demonstrates
- evidence: figures, measurements, comparisons, datasets, statistics or examples
- boundary: where the claim stops
- target journal or word limit, if provided
If any of `core claim`, `evidence` or `boundary` is absent, expose the gap before drafting. You may still produce a scaffold with explicit placeholders.
Writing workflow
1. Build a one-sentence argument: `In [system/problem], we show [advance] using [approach], supported by [evidence], with [boundary].` 2. Choose the section architecture from `references/article-architecture.md`. 3. Map each paragraph to one job: context, gap, approach, result, comparison, mechanism, implication or limitation. 4. Draft from evidence outward. Keep claims near the data that support them. 5. Calibrate verbs: `show`, `demonstrate`, `suggest`, `indicate`, `enable`, `may`, `could`. 6. Remove unsupported novelty and universal claims. 7. Run a paragraph-flow check: one paragraph, one message, with a clear first sentence and explicit sentence-to-sentence relation. 8. Return prose plus concise notes on assumptions and missing inputs.
Section defaults
Abstract
Default Nature pattern:
`context/problem -> gap -> approach -> key result -> implication -> boundary`
For technical AI, ML, CV or method-heavy manuscripts, open `references/abstract.md` and choose one of:
- `challenge -> contribution`
- `challenge -> insight -> contribution`
- `multiple contributions`
Keep it compact. Include quantitative or comparative detail when the user provided it. End with what the work enables, not generic importance.
Introduction
Use:
`field scale -> bottleneck -> prior attempts -> unresolved gap -> present study`
For method-heavy papers, open `references/introduction.md` and reason backward from the technical challenge and contribution before drafting forward.
Do not summarize all results. The final paragraph should state what this paper does and how it addresses the gap.
Results narrative
Use an evidence ladder:
`system/workflow -> validation -> main result -> baseline comparison -> mechanism/diagnostic analysis -> application or generalization`
Each subsection should have a claim-first opening and then data support.
For ML/conference-style experiment sections, open `references/experiments.md` and make sure each major claim is backed by comparison, ablation, or stress-test evidence.
Related Work
Use:
`topic scope -> representative methods -> limitation tied to this paper -> distinction`
Group prior work by technical topic and mechanism, not by publication year.
Discussion
Use:
`central advance -> evidence meaning -> relation to prio
Semi-automated research assistant for academic research and software development. Supports Claude Code, Codex CLI, Kimi Code CLI, and OpenCode across ideation, coding, experiments, writing, and publication.
Repo: Galaxy-Dawn/claude-scholar
Other skills on claude-scholar.
- /agent-identifier
Use when creating or configuring Claude Code agents and their frontmatter.
Open skill - /architecture-design
Use only when creating new registrable ML components that require Factory or Registry patterns.
Open skill - /bug-detective
This skill should be used when the user asks to "debug this", "fix this error", "investigate this bug", "troubleshoot this issue", "find the problem", "something is broken", "this isn't working", "why is this failing", or reports errors/exceptions/bugs. Provides systematic
Open skill - /citation-verification
This skill provides reference guidance for citation verification in academic writing. Use when the user asks about "citation verification best practices", "how to verify references", "preventing fake citations", or needs guidance on citation accuracy. This skill supports
Open skill - /code-review-excellence
This skill should be used when the user asks to review a diff or pull request, write review comments, audit code quality, establish review standards, or improve how a team performs code review.
Open skill - /command-development
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in
Open skill

