268 lines
13 KiB
Markdown
268 lines
13 KiB
Markdown
---
|
|
name: material-writing
|
|
description: Draft, restructure, polish, or audit materials-science manuscript sections using evidence-first, high-impact-journal writing logic, with optional Zotero/Obsidian/DeepSeek literature-note routing. Use for materials chemistry, nanomaterials, functional materials, devices, catalysis, energy storage, biomaterials, sensors, flexible electronics, MOF/COF, MXene, perovskite, polymer, composite, and interface/mechanism papers, especially when the user provides Chinese notes, figures, characterization data, Zotero literature notes, DeepSeek-generated paper notes, target-journal questions, or wants Nature-like but materials-specific academic prose.
|
|
version: 0.1.0
|
|
author: Local skill modeled after nature-writing/nature-polishing workflows for materials-science manuscripts
|
|
---
|
|
|
|
# Materials-Science Manuscript Writing
|
|
|
|
Use this skill when the user wants to write, rebuild, polish, translate, or
|
|
review manuscript prose for materials-science papers. The goal is not generic
|
|
English polish, but a materials-specific argument that connects composition,
|
|
structure, properties, mechanism, device/application performance, and limits.
|
|
|
|
It can also route through the user's Zotero/Obsidian literature-note workflow:
|
|
extract keywords from the manuscript topic or draft, use DeepSeek to screen
|
|
existing Zotero child notes or Obsidian-linked notes, separate strongly related
|
|
and weakly related papers, then use those papers to improve positioning,
|
|
introduction logic, comparison, novelty framing, and citations.
|
|
|
|
## Core stance
|
|
|
|
- Evidence comes first. Do not invent synthesis details, mechanisms,
|
|
characterization results, performance metrics, controls, references, or
|
|
novelty.
|
|
- Build the materials logic before polishing language.
|
|
- Separate `what was made`, `what structure it has`, `what property changes`,
|
|
`why it changes`, and `what it enables`.
|
|
- Keep claims ambitious but bounded by the provided data.
|
|
- For missing values, figure numbers, journal names, references, or controls,
|
|
use `xxx` placeholders or state the gap explicitly.
|
|
- If the user's input is Chinese or mixed Chinese-English, produce polished
|
|
English first unless they ask for Chinese output; then add brief Chinese notes
|
|
on structure or missing evidence.
|
|
|
|
## When to open extra files
|
|
|
|
| File | Open when |
|
|
|---|---|
|
|
| [references/materials-architecture.md](references/materials-architecture.md) | Planning a full paper, abstract, introduction, results storyline, discussion, title, or journal positioning |
|
|
| [references/evidence-chain.md](references/evidence-chain.md) | Checking whether characterization, controls, mechanism, and performance data support the claims |
|
|
| [references/section-patterns.md](references/section-patterns.md) | Drafting or revising specific sections such as abstract, introduction, results, discussion, conclusion, title, or methods |
|
|
| [references/chinese-author-workflow.md](references/chinese-author-workflow.md) | Rebuilding Chinese notes, figure notes, lab-record style drafts, or direct Chinese-to-English manuscript prose |
|
|
| [references/review-audit.md](references/review-audit.md) | User asks for reviewer-style critique, rejection-risk audit, novelty check, claim-evidence map, or pre-submission self-review |
|
|
| [references/comparative-review-audit.md](references/comparative-review-audit.md) | User wants a Nature-response-like pre-review based on comparison with strongly related papers, including missing experiments, format, figures, spelling, and terminology consistency |
|
|
| [references/submission-package-audit.md](references/submission-package-audit.md) | User provides or mentions a submission package with manuscript, Supporting Information, highlights, cover letter, figures, SI figures, TOC, graphical abstract, or related Word/PPT files |
|
|
| [references/literature-routing.md](references/literature-routing.md) | User wants Zotero/Obsidian/DeepSeek note search, strong/weak related-paper screening, keyword extraction, or literature-grounded rewriting |
|
|
| [references/word-citation-comments.md](references/word-citation-comments.md) | User wants citation insertion guidance in Word, reference placement, DOI-only comments, or annotated `.docx` citation suggestions |
|
|
| [references/zotero-obsidian-subskill.md](references/zotero-obsidian-subskill.md) | User asks to generate new Zotero notes, batch process newly imported papers, link Zotero notes into Obsidian, or operate the prior Zotero-Obsidian workflow |
|
|
| [references/journal-positioning.md](references/journal-positioning.md) | Target journal is missing, uncertain, or needs recommendation and writing-position adjustment |
|
|
|
|
## Intake
|
|
|
|
Before drafting or rewriting, identify:
|
|
|
|
- target section: title, abstract, introduction, results, discussion,
|
|
conclusion, graphical TOC text, cover letter, or full outline
|
|
- material system: composition, phase, morphology, substrate, interface,
|
|
additive, defect, heterostructure, or device architecture
|
|
- application: energy storage, catalysis, sensing, flexible electronics,
|
|
triboelectric/piezoelectric, photodetector, membrane, biomedical, structural,
|
|
environmental, or other use
|
|
- central advance: what is new compared with prior materials or designs
|
|
- evidence: synthesis, microscopy, spectroscopy, diffraction, surface analysis,
|
|
mechanical/electrical/electrochemical tests, simulations, controls, durability
|
|
and statistics
|
|
- boundary: where the mechanism, generality, performance, or application claim
|
|
stops
|
|
- target journal and word limit, if provided
|
|
- literature source: Zotero child notes, Obsidian linked notes, Zotero item
|
|
metadata/full text, uploaded papers, or external searches
|
|
|
|
If the central advance, decisive evidence, or boundary is absent, expose the gap
|
|
before drafting. You may still produce a manuscript-ready scaffold with
|
|
placeholders.
|
|
|
|
## Writing workflow
|
|
|
|
1. Build a one-sentence materials argument:
|
|
`In [application/problem], we design [material/interface/architecture] to
|
|
address [bottleneck], supported by [structure evidence], [property evidence],
|
|
and [application evidence], with [boundary].`
|
|
2. Choose the section architecture from
|
|
`references/materials-architecture.md`.
|
|
3. Map each paragraph to one job: field need, materials bottleneck, design
|
|
principle, synthesis, structure validation, property change, mechanism,
|
|
application performance, comparison, limitation, or implication.
|
|
4. Draft from evidence outward. Keep mechanism claims close to the data that
|
|
support them.
|
|
5. Calibrate verbs: `show`, `demonstrate`, `indicate`, `suggest`, `attribute`,
|
|
`enable`, `may`, `could`.
|
|
6. Run an overclaim check for novelty, universality, mechanism causality,
|
|
durability, scalability, and practical relevance.
|
|
7. Return polished prose plus concise notes on assumptions and missing inputs.
|
|
|
|
## Literature-note routing workflow
|
|
|
|
Use this when the user wants the manuscript optimized using previous
|
|
DeepSeek/AwesomeGPT Zotero notes.
|
|
|
|
1. Extract manuscript keywords from the topic, draft, abstract, figures, or SI:
|
|
material names, material family, device/application, mechanism, performance
|
|
metrics, synthesis strategy, target journal, and competing concepts.
|
|
2. If the target journal is absent, ask the author for it. If they want advice,
|
|
open `references/journal-positioning.md` and recommend several tiers.
|
|
3. Open `references/literature-routing.md` and prepare a DeepSeek screening
|
|
brief for existing notes.
|
|
4. Screen notes into:
|
|
- `strongly related`: same material, same material family plus same device,
|
|
same mechanism, same target journal/neighbor journal, or direct benchmark.
|
|
- `weakly related`: same direction, adjacent material family, same
|
|
characterization logic, similar device architecture, or useful writing
|
|
pattern.
|
|
5. Use strongly related papers for novelty, gap, introduction, benchmark, and
|
|
citation placement.
|
|
6. Use weakly related papers for broader field framing, mechanism language,
|
|
section architecture, and cautious comparison.
|
|
7. For Word manuscript citation suggestions, open
|
|
`references/word-citation-comments.md` and add native Word comments that
|
|
contain DOI strings only.
|
|
8. Return a source map before or with the manuscript revision. Never cite a
|
|
paper only because the title seems similar.
|
|
|
|
## Comparative pre-review workflow
|
|
|
|
Use this when the user asks for reviewer-style checking, `nature-response`
|
|
functionality, pre-submission audit, 格式检查, 图片检查, 拼写错误, or terminology
|
|
consistency.
|
|
|
|
If the user provides a submission package, not just one manuscript file, open
|
|
`references/submission-package-audit.md` first and audit the files as a single
|
|
submission set.
|
|
|
|
Do not judge the manuscript from general intuition alone. First use the
|
|
strongly related papers identified by `references/literature-routing.md` as the
|
|
comparison set, then open `references/comparative-review-audit.md`.
|
|
|
|
Workflow:
|
|
|
|
1. Build or reuse a strong-related-paper set: same material, same device,
|
|
same mechanism, benchmark paper, or same target-journal positioning.
|
|
2. Compare the manuscript against that set for missing evidence, missing
|
|
controls, weaker mechanism support, weaker benchmarking, figure organization,
|
|
and journal-format differences.
|
|
3. Audit figures separately: panel logic, labels, scale bars, statistics,
|
|
units, color/style consistency, caption completeness, resolution risk, and
|
|
whether each figure supports the claimed conclusion.
|
|
4. Audit language mechanically: spelling, abbreviation definitions, inconsistent
|
|
sample names, inconsistent units, tense, capitalization, hyphenation, and
|
|
terminology drift.
|
|
5. Produce a tracker with issue ID, comparison basis, severity, location,
|
|
fix, and whether author input is needed.
|
|
6. For a Word manuscript, put local sentence-level citation suggestions as
|
|
DOI-only comments; put broader review findings in Markdown.
|
|
|
|
## Citation comments in Word
|
|
|
|
When the user wants citation insertion help for a `.docx`, do not directly
|
|
create Zotero citation fields. Add native Word comments at the relevant sentence
|
|
or clause instead.
|
|
|
|
Default comment content:
|
|
|
|
```text
|
|
10.xxxx/xxxxx
|
|
10.xxxx/yyyyy
|
|
```
|
|
|
|
Rules:
|
|
|
|
- DOI only, one DOI per line.
|
|
- No explanation, title, author, journal, Zotero key, or citation reason inside
|
|
the Word comment.
|
|
- If a candidate paper has no DOI, omit it unless the user explicitly permits a
|
|
title or Zotero key fallback.
|
|
- The annotated file must be saved as a copy; never overwrite the original
|
|
manuscript.
|
|
- Put any reasoning, claim-to-reference planning, or reviewer notes in a
|
|
separate Markdown report, not inside the Word comment.
|
|
|
|
## Zotero/Obsidian child-note subskill
|
|
|
|
When the user imports new papers and asks to generate notes, use
|
|
`references/zotero-obsidian-subskill.md`.
|
|
|
|
Important defaults:
|
|
|
|
- Generate or update Zotero child notes first.
|
|
- Obsidian comes second through Zotero Integration links and Dataview.
|
|
- Keep API keys in local private config, not in chat.
|
|
- Treat Zotero local API as read-oriented unless a write-capable Web API,
|
|
connector, or helper path is explicitly configured.
|
|
- Batch work must be resumable and skip already processed papers.
|
|
|
|
## Materials-specific logic
|
|
|
|
### Abstract
|
|
|
|
Use:
|
|
|
|
`application need -> materials bottleneck -> design strategy -> key structure or
|
|
interface evidence -> performance result -> mechanism or implication -> boundary`
|
|
|
|
Include quantitative metrics when provided. Avoid abstract-only phrases such as
|
|
`excellent performance`, `simple method`, or `broad application prospects`
|
|
without evidence.
|
|
|
|
### Introduction
|
|
|
|
Use:
|
|
|
|
`field demand -> current material limitation -> prior design strategies -> why
|
|
they remain insufficient -> this material design -> what it proves`
|
|
|
|
Do not turn the Introduction into a list of material classes. Group prior work
|
|
by mechanism, limitation, or design strategy.
|
|
|
|
### Results narrative
|
|
|
|
Use an evidence ladder:
|
|
|
|
`material design -> synthesis/structure confirmation -> composition/interface
|
|
evidence -> property change -> mechanism test -> device/application performance
|
|
-> durability/generalization`
|
|
|
|
Each subsection should open with a claim-first sentence, then provide the
|
|
figure-backed evidence.
|
|
|
|
### Mechanism paragraphs
|
|
|
|
Separate:
|
|
|
|
- observed phenomenon
|
|
- structural or chemical origin
|
|
- supporting characterization
|
|
- alternative explanations that controls rule out
|
|
- remaining uncertainty
|
|
|
|
Use `suggests` or `is consistent with` when the data are indirect.
|
|
|
|
### Discussion and conclusion
|
|
|
|
Discussion interprets why the material works and where the interpretation may
|
|
fail. Conclusion states the contribution, decisive evidence, implication, and
|
|
boundary. Do not introduce new data.
|
|
|
|
### Title
|
|
|
|
Prefer:
|
|
|
|
`material/system + design action/mechanism + application/capability`
|
|
|
|
Avoid slogans, unsupported `high-performance`, and titles that hide the material
|
|
identity.
|
|
|
|
## Output format
|
|
|
|
Default output:
|
|
|
|
1. `Draft:` with the requested manuscript prose.
|
|
2. `Materials argument:` one compact sentence.
|
|
3. `Claim-evidence map:` major claims with evidence and status.
|
|
4. `Missing inputs or risks:` only material gaps.
|
|
5. `Revision notes:` brief Chinese notes if the input was Chinese or mixed.
|
|
|
|
For reviewer-style tasks, lead with findings ordered by severity, then provide
|
|
fixes and a concise revised version if requested.
|