Initial material writing skill
This commit is contained in:
commit
7ef52758b9
|
|
@ -0,0 +1,6 @@
|
||||||
|
config/config.local.json
|
||||||
|
state/
|
||||||
|
__pycache__/
|
||||||
|
*.pyc
|
||||||
|
*.tmp
|
||||||
|
*.log
|
||||||
|
|
@ -0,0 +1,267 @@
|
||||||
|
---
|
||||||
|
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.
|
||||||
|
|
@ -0,0 +1,3 @@
|
||||||
|
display_name: Materials Writing
|
||||||
|
short_description: Audit materials submission packages, compare with strong papers, and add DOI-only Word comments.
|
||||||
|
default_prompt: Help me audit this materials-science submission package using my evidence and Zotero/Obsidian DeepSeek literature notes. Check Manuscript, Figures, Supporting Information, Highlights, Cover Letter, and TOC as one consistent package, identify strongly related papers, compare my manuscript with them for missing evidence, figure problems, format issues, spelling errors, and terminology inconsistency, and for Word citation suggestions add native comments containing DOI strings only.
|
||||||
|
|
@ -0,0 +1,22 @@
|
||||||
|
{
|
||||||
|
"deepseek": {
|
||||||
|
"api_key": "",
|
||||||
|
"base_url": "https://api.deepseek.com",
|
||||||
|
"model": "deepseek-chat"
|
||||||
|
},
|
||||||
|
"zotero": {
|
||||||
|
"local_api": "http://127.0.0.1:23119/api/users/0",
|
||||||
|
"web_api_key": "",
|
||||||
|
"user_id": "",
|
||||||
|
"library_type": "user"
|
||||||
|
},
|
||||||
|
"obsidian": {
|
||||||
|
"vault_path": "",
|
||||||
|
"zotero_integration_note_folder": ""
|
||||||
|
},
|
||||||
|
"workflow": {
|
||||||
|
"manifest_path": "state/material-writing-literature-manifest.jsonl",
|
||||||
|
"skip_existing_notes": true,
|
||||||
|
"batch_size": 10
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
@ -0,0 +1,41 @@
|
||||||
|
# Chinese Author Workflow
|
||||||
|
|
||||||
|
Use this file when the user provides Chinese notes, mixed Chinese-English
|
||||||
|
drafts, figure notes, lab-record text, or asks to translate a Chinese materials
|
||||||
|
manuscript into polished English.
|
||||||
|
|
||||||
|
## Workflow
|
||||||
|
|
||||||
|
1. Identify the intended section and journal style.
|
||||||
|
2. Extract claims, data, figure numbers, material names, controls, and missing
|
||||||
|
values.
|
||||||
|
3. Convert Chinese chronology into manuscript logic:
|
||||||
|
`why -> design -> evidence -> mechanism -> implication`.
|
||||||
|
4. Replace unsupported Chinese intensifiers with evidence-backed English.
|
||||||
|
5. Preserve technical terms, sample names, and units exactly unless they are
|
||||||
|
clearly inconsistent.
|
||||||
|
6. Use `xxx` for missing values, references, figure numbers, or unclear sample
|
||||||
|
names.
|
||||||
|
7. Return polished English first, then short Chinese notes.
|
||||||
|
|
||||||
|
## Common conversions
|
||||||
|
|
||||||
|
- `显著提高` -> use a number if available; otherwise `increased` or
|
||||||
|
`substantially increased` only when supported.
|
||||||
|
- `证明了` -> use `demonstrates` only for direct evidence; otherwise use
|
||||||
|
`suggests` or `indicates`.
|
||||||
|
- `由于/归因于` -> require mechanism evidence. If absent, use `may be attributed
|
||||||
|
to` or expose the gap.
|
||||||
|
- `具有广阔应用前景` -> replace with a specific application implication and
|
||||||
|
boundary.
|
||||||
|
- `首次提出/首次实现` -> only keep if literature evidence supports priority.
|
||||||
|
|
||||||
|
## Output style
|
||||||
|
|
||||||
|
Default:
|
||||||
|
|
||||||
|
1. `Draft:` polished English.
|
||||||
|
2. `中文说明:` explain structural changes and missing evidence.
|
||||||
|
3. `需要补充:` list only concrete missing values, controls, or figure links.
|
||||||
|
|
||||||
|
Do not over-explain grammar unless the user asks for language teaching.
|
||||||
|
|
@ -0,0 +1,162 @@
|
||||||
|
# Comparative Review Audit
|
||||||
|
|
||||||
|
Use this file when the user wants a Nature-response-like review function before
|
||||||
|
submission, but the review must be grounded in strong related papers rather than
|
||||||
|
general judgment.
|
||||||
|
|
||||||
|
If the user provides multiple submission files, open
|
||||||
|
`submission-package-audit.md` first and use this file for the comparative review
|
||||||
|
layer inside that package audit.
|
||||||
|
|
||||||
|
## Core rule
|
||||||
|
|
||||||
|
Do not simply say whether the manuscript is good or bad. Compare it against a
|
||||||
|
small set of strongly related papers and identify what is missing, weaker,
|
||||||
|
unclear, or inconsistent.
|
||||||
|
|
||||||
|
Strong related papers should come from `literature-routing.md` and usually
|
||||||
|
include:
|
||||||
|
|
||||||
|
- same material or named composite
|
||||||
|
- same material family and same device/application
|
||||||
|
- same mechanism or characterization chain
|
||||||
|
- direct benchmark paper
|
||||||
|
- same target journal or close journal positioning
|
||||||
|
|
||||||
|
## Comparison dimensions
|
||||||
|
|
||||||
|
### 1. Story and novelty
|
||||||
|
|
||||||
|
Compare:
|
||||||
|
|
||||||
|
- how each strong paper states the bottleneck
|
||||||
|
- whether the manuscript states a sharper or weaker gap
|
||||||
|
- whether the claimed novelty is composition, interface, morphology, mechanism,
|
||||||
|
device architecture, application, or integration
|
||||||
|
- whether the manuscript's novelty is visible in title, abstract, introduction,
|
||||||
|
and first Results figure
|
||||||
|
|
||||||
|
Findings should say:
|
||||||
|
|
||||||
|
`Compared with [paper DOI/title], this manuscript lacks / weakens / obscures xxx.`
|
||||||
|
|
||||||
|
### 2. Evidence and missing experiments
|
||||||
|
|
||||||
|
Compare whether strong papers include:
|
||||||
|
|
||||||
|
- synthesis and composition confirmation
|
||||||
|
- morphology and interface evidence
|
||||||
|
- control samples
|
||||||
|
- mechanism diagnostics
|
||||||
|
- statistics and reproducibility
|
||||||
|
- durability, cycling, bending, humidity, temperature, or operational stability
|
||||||
|
- fair benchmark tables under comparable conditions
|
||||||
|
- supplementary controls or methods detail
|
||||||
|
|
||||||
|
Classify missing items:
|
||||||
|
|
||||||
|
- `critical`: likely reviewer blocker
|
||||||
|
- `major`: weakens novelty or mechanism
|
||||||
|
- `minor`: improves clarity or completeness
|
||||||
|
- `optional`: useful but not necessary for the target journal
|
||||||
|
|
||||||
|
Do not claim an experiment was done unless the manuscript provides it.
|
||||||
|
|
||||||
|
### 3. Figure audit
|
||||||
|
|
||||||
|
Check each figure and caption for:
|
||||||
|
|
||||||
|
- clear conclusion for the whole figure
|
||||||
|
- logical panel order
|
||||||
|
- panel labels present and consistent
|
||||||
|
- axis labels, units, scale bars, legends, and error bars
|
||||||
|
- sample names matching the manuscript
|
||||||
|
- image contrast and cropping problems
|
||||||
|
- repeated or redundant panels
|
||||||
|
- missing controls
|
||||||
|
- caption explains what is shown, not just technique names
|
||||||
|
- figure supports the claim made in the text
|
||||||
|
- resolution, font size, line width, and color consistency risks
|
||||||
|
|
||||||
|
Use this format:
|
||||||
|
|
||||||
|
`Figure issue: Fig. xxx | Problem: xxx | Comparison basis: strong papers usually show xxx | Fix: xxx`
|
||||||
|
|
||||||
|
### 4. Formatting and journal compliance
|
||||||
|
|
||||||
|
Check:
|
||||||
|
|
||||||
|
- title length and style
|
||||||
|
- abstract structure and word count if known
|
||||||
|
- heading hierarchy
|
||||||
|
- figure citation order
|
||||||
|
- reference style consistency if visible
|
||||||
|
- abbreviations defined at first use
|
||||||
|
- SI references and numbering
|
||||||
|
- units formatted consistently
|
||||||
|
- methods detail sufficient for reproduction
|
||||||
|
- data availability, author contributions, competing interests if required
|
||||||
|
|
||||||
|
If exact target-journal instructions may have changed, verify the current
|
||||||
|
journal page before final advice.
|
||||||
|
|
||||||
|
### 5. Spelling and terminology consistency
|
||||||
|
|
||||||
|
Check mechanically:
|
||||||
|
|
||||||
|
- spelling errors
|
||||||
|
- inconsistent sample names
|
||||||
|
- inconsistent material names and formulas
|
||||||
|
- inconsistent abbreviation capitalization
|
||||||
|
- hyphenation variants, e.g. `self-powered` vs `self powered`
|
||||||
|
- unit variants, e.g. `mA cm-2`, `mA/cm2`, `mA cm^-2`
|
||||||
|
- plural/singular drift
|
||||||
|
- tense drift between Results and Discussion
|
||||||
|
- inconsistent use of `show`, `demonstrate`, `suggest`, `indicate`
|
||||||
|
|
||||||
|
Prefer a terminology table:
|
||||||
|
|
||||||
|
| Term family | Variants found | Recommended form | Locations |
|
||||||
|
|---|---|---|---|
|
||||||
|
|
||||||
|
## Output format
|
||||||
|
|
||||||
|
Return a Markdown report:
|
||||||
|
|
||||||
|
```text
|
||||||
|
Comparative basis
|
||||||
|
- Strong papers used:
|
||||||
|
- Target journal:
|
||||||
|
- Manuscript materials/device:
|
||||||
|
|
||||||
|
Issue tracker
|
||||||
|
| ID | Severity | Area | Location | Comparison basis | Problem | Fix | Author input needed |
|
||||||
|
|---|---|---|---|---|---|---|---|
|
||||||
|
|
||||||
|
Missing evidence compared with strong papers
|
||||||
|
- ...
|
||||||
|
|
||||||
|
Figure and caption audit
|
||||||
|
- ...
|
||||||
|
|
||||||
|
Format and consistency audit
|
||||||
|
- ...
|
||||||
|
|
||||||
|
Spelling and terminology table
|
||||||
|
| Term family | Variants found | Recommended form | Locations |
|
||||||
|
|---|---|---|---|
|
||||||
|
|
||||||
|
Priority revision plan
|
||||||
|
1. ...
|
||||||
|
2. ...
|
||||||
|
3. ...
|
||||||
|
```
|
||||||
|
|
||||||
|
## Word output boundary
|
||||||
|
|
||||||
|
For the Word manuscript:
|
||||||
|
|
||||||
|
- Add sentence-level citation suggestions only as DOI-only native comments.
|
||||||
|
- Do not put the full review reasoning inside Word citation comments.
|
||||||
|
- Broader missing-evidence, figure, format, spelling, and terminology findings
|
||||||
|
should go in the Markdown reviewer report.
|
||||||
|
|
@ -0,0 +1,92 @@
|
||||||
|
# Materials Evidence Chain
|
||||||
|
|
||||||
|
Use this file to audit whether the manuscript's claims are supported by the
|
||||||
|
provided characterization, controls, mechanism tests, and performance data.
|
||||||
|
|
||||||
|
## Claim-evidence checks
|
||||||
|
|
||||||
|
### Structure and composition
|
||||||
|
|
||||||
|
Typical claims:
|
||||||
|
|
||||||
|
- successful synthesis
|
||||||
|
- phase purity
|
||||||
|
- morphology control
|
||||||
|
- nanoscale architecture
|
||||||
|
- interface formation
|
||||||
|
- defect engineering
|
||||||
|
- oxidation state or coordination change
|
||||||
|
- dopant incorporation
|
||||||
|
|
||||||
|
Common evidence:
|
||||||
|
|
||||||
|
- XRD, SAED, Raman, FTIR, XPS, EDS, ICP, elemental mapping
|
||||||
|
- SEM, TEM, AFM, BET, contact angle, zeta potential
|
||||||
|
- thermal analysis, mechanical testing, spectroscopy
|
||||||
|
|
||||||
|
Risk flags:
|
||||||
|
|
||||||
|
- morphology shown without composition confirmation
|
||||||
|
- XPS peak fitting overinterpreted
|
||||||
|
- single image used as proof of uniformity
|
||||||
|
- no control sample for dopant/interface effects
|
||||||
|
|
||||||
|
### Properties
|
||||||
|
|
||||||
|
Typical claims:
|
||||||
|
|
||||||
|
- improved conductivity, charge transfer, ion transport, surface activity,
|
||||||
|
toughness, stretchability, adhesion, wettability, optical response, or
|
||||||
|
dielectric/piezoelectric/triboelectric behavior
|
||||||
|
|
||||||
|
Common evidence:
|
||||||
|
|
||||||
|
- EIS, I-V, Hall, four-probe, CV, GCD, LSV, Tafel, ECSA, PL/TRPL, UV-vis,
|
||||||
|
DMA, tensile tests, fatigue, bending/cycling tests
|
||||||
|
|
||||||
|
Risk flags:
|
||||||
|
|
||||||
|
- property improvement is reported but not linked to structure
|
||||||
|
- only one sample or no error bars
|
||||||
|
- no stability or repeatability for device claims
|
||||||
|
|
||||||
|
### Mechanism
|
||||||
|
|
||||||
|
Mechanism claims require a chain:
|
||||||
|
|
||||||
|
1. The material has the proposed structural/chemical feature.
|
||||||
|
2. That feature changes a relevant property.
|
||||||
|
3. The property change explains the performance trend.
|
||||||
|
4. Controls or perturbations reduce alternative explanations.
|
||||||
|
|
||||||
|
Acceptable wording:
|
||||||
|
|
||||||
|
- Direct evidence: `demonstrates`, `confirms`, `establishes`
|
||||||
|
- Indirect but coherent evidence: `indicates`, `suggests`, `is consistent with`
|
||||||
|
- Hypothesis: `may arise from`, `could be associated with`
|
||||||
|
|
||||||
|
### Performance and benchmarking
|
||||||
|
|
||||||
|
Check:
|
||||||
|
|
||||||
|
- benchmark metric and units are clear
|
||||||
|
- operating condition is stated
|
||||||
|
- control material/device is fair
|
||||||
|
- literature comparison uses comparable conditions
|
||||||
|
- stability, cycling, bending, humidity, temperature, pH, voltage window, or
|
||||||
|
rate/current density are relevant to the application
|
||||||
|
- sample size, error bars, and statistics appear when the claim depends on
|
||||||
|
reproducibility
|
||||||
|
|
||||||
|
Risk flags:
|
||||||
|
|
||||||
|
- `record-high` or `superior` without a controlled literature table
|
||||||
|
- application claim based only on lab conditions
|
||||||
|
- durability mentioned without cycle count or test conditions
|
||||||
|
|
||||||
|
## Output template
|
||||||
|
|
||||||
|
Use this compact map:
|
||||||
|
|
||||||
|
`Claim: ... | Evidence: Fig. xxx / data xxx | Status: supported / partial /
|
||||||
|
needs evidence | Fix: ...`
|
||||||
|
|
@ -0,0 +1,60 @@
|
||||||
|
# Target Journal Positioning
|
||||||
|
|
||||||
|
Use this file when the target journal is missing, uncertain, or relevant to
|
||||||
|
literature screening and manuscript tone.
|
||||||
|
|
||||||
|
## First ask
|
||||||
|
|
||||||
|
If the target journal is absent, ask:
|
||||||
|
|
||||||
|
`你希望冲哪个目标期刊或期刊层级?如果还没确定,我可以根据材料体系、器件方向、创新强度、数据完整度和故事类型推荐 3-5 个选择。`
|
||||||
|
|
||||||
|
If the user asks for recommendations, classify the manuscript by:
|
||||||
|
|
||||||
|
- material system and novelty
|
||||||
|
- device/application field
|
||||||
|
- mechanism depth
|
||||||
|
- performance and benchmarking strength
|
||||||
|
- figure completeness
|
||||||
|
- breadth of generalization
|
||||||
|
- target audience: materials generalist, device specialist, chemistry,
|
||||||
|
energy/catalysis, biomaterials, nanotechnology, flexible electronics
|
||||||
|
|
||||||
|
## Materials journal tiers by story type
|
||||||
|
|
||||||
|
Use current knowledge cautiously and verify live if the user needs submission
|
||||||
|
rules, scope, fees, templates, or the latest editor policy.
|
||||||
|
|
||||||
|
High-impact broad materials:
|
||||||
|
|
||||||
|
- Nature Materials, Nature Nanotechnology, Nature Communications, Science
|
||||||
|
Advances, Advanced Materials, Advanced Functional Materials
|
||||||
|
|
||||||
|
Strong specialist or high-visibility materials:
|
||||||
|
|
||||||
|
- ACS Nano, Nano Letters, Advanced Science, Materials Horizons, Matter,
|
||||||
|
Small, Nano Energy, Energy & Environmental Science, Joule
|
||||||
|
|
||||||
|
Application-specific examples:
|
||||||
|
|
||||||
|
- energy storage: Energy Storage Materials, Advanced Energy Materials,
|
||||||
|
Journal of Power Sources
|
||||||
|
- catalysis: ACS Catalysis, Applied Catalysis B, Journal of Catalysis
|
||||||
|
- flexible electronics/sensors: Advanced Intelligent Systems, npj Flexible
|
||||||
|
Electronics, Sensors and Actuators B
|
||||||
|
- biomaterials: Biomaterials, Bioactive Materials, Advanced Healthcare
|
||||||
|
Materials
|
||||||
|
- membranes/environment: Environmental Science & Technology, Water Research,
|
||||||
|
Journal of Membrane Science
|
||||||
|
|
||||||
|
## Recommendation output
|
||||||
|
|
||||||
|
For each recommended journal:
|
||||||
|
|
||||||
|
- fit reason
|
||||||
|
- required evidence level
|
||||||
|
- likely reviewer concern
|
||||||
|
- how to tune title/abstract/introduction
|
||||||
|
- whether more data are needed before submission
|
||||||
|
|
||||||
|
Do not overpromise acceptance probability. Give tiered options.
|
||||||
|
|
@ -0,0 +1,145 @@
|
||||||
|
# Literature Routing with Zotero Notes and DeepSeek
|
||||||
|
|
||||||
|
Use this file when the user wants existing Zotero/Obsidian literature notes to
|
||||||
|
guide manuscript positioning, rewriting, citation planning, or reviewer-risk
|
||||||
|
analysis.
|
||||||
|
|
||||||
|
## Inputs
|
||||||
|
|
||||||
|
Collect as many as available:
|
||||||
|
|
||||||
|
- manuscript title, abstract, draft, figure captions, or key claims
|
||||||
|
- material system and aliases
|
||||||
|
- material family, device type, application, mechanism, and performance metrics
|
||||||
|
- target journal or journal tier
|
||||||
|
- Zotero collection, tag, saved search, Obsidian folder, or note source
|
||||||
|
- whether the notes were generated by DeepSeek/AwesomeGPT
|
||||||
|
|
||||||
|
If no target journal is given, ask the author. If they want recommendations,
|
||||||
|
open `journal-positioning.md`.
|
||||||
|
|
||||||
|
## Keyword extraction
|
||||||
|
|
||||||
|
Extract keywords in layers:
|
||||||
|
|
||||||
|
1. Exact material: e.g. `Ni-HHTP`, `MXene`, `BC`, `perovskite`, `MOF`, `COF`,
|
||||||
|
`Ecoflex`, `graphene`, `hydrogel`.
|
||||||
|
2. Material family: conductive MOF, 2D material, porous polymer, aerogel,
|
||||||
|
biomass cellulose, elastomer composite, metal oxide, sulfide, carbide.
|
||||||
|
3. Device/application: TENG, sensor, battery, supercapacitor, electrocatalysis,
|
||||||
|
photocatalysis, membrane, flexible electronics, photodetector.
|
||||||
|
4. Mechanism: charge transfer, ion transport, defect engineering, interface
|
||||||
|
polarization, hydrogen bonding, hydrophilicity, mechanical reinforcement,
|
||||||
|
piezoelectricity, triboelectric polarity, carrier separation.
|
||||||
|
5. Evidence: XPS, XRD, Raman, SEM/TEM, AFM, EIS, CV, LSV, tensile, fatigue,
|
||||||
|
cycling stability, humidity/temperature tests.
|
||||||
|
6. Target outlet: journal name, publisher family, impact level, audience.
|
||||||
|
|
||||||
|
Return a query pack:
|
||||||
|
|
||||||
|
- `must-match`: exact material, device, mechanism
|
||||||
|
- `should-match`: family, application, evidence type
|
||||||
|
- `context`: target journal, field, benchmark terms
|
||||||
|
- `exclude`: irrelevant homonyms or unrelated applications
|
||||||
|
|
||||||
|
## DeepSeek screening brief
|
||||||
|
|
||||||
|
Give DeepSeek a compact, structured task:
|
||||||
|
|
||||||
|
```text
|
||||||
|
You are screening my existing Zotero/Obsidian literature notes for a materials
|
||||||
|
science manuscript.
|
||||||
|
|
||||||
|
Manuscript profile:
|
||||||
|
- Material/system: xxx
|
||||||
|
- Material family: xxx
|
||||||
|
- Device/application: xxx
|
||||||
|
- Mechanism/property: xxx
|
||||||
|
- Target journal or tier: xxx
|
||||||
|
- Key evidence/figures: xxx
|
||||||
|
|
||||||
|
Screen the notes and return:
|
||||||
|
1. Strongly related papers: same material, same device, same mechanism, direct
|
||||||
|
benchmark, or same target-journal positioning.
|
||||||
|
2. Weakly related papers: same material family, adjacent device/application,
|
||||||
|
similar mechanism, characterization logic, or useful writing pattern.
|
||||||
|
3. For each paper: title, year, journal, DOI, Zotero key if present, relation
|
||||||
|
type, useful claim/evidence, and why it matters for my manuscript.
|
||||||
|
4. Do not include papers only because of a broad keyword match.
|
||||||
|
```
|
||||||
|
|
||||||
|
## Strong vs weak relation rules
|
||||||
|
|
||||||
|
Strongly related:
|
||||||
|
|
||||||
|
- same exact material or named composite
|
||||||
|
- same material family and same device/application
|
||||||
|
- same mechanism tested with comparable evidence
|
||||||
|
- same target journal or immediate competitor journal with close topic
|
||||||
|
- benchmark paper that reviewers will expect
|
||||||
|
- paper that directly defines the gap or limitation being addressed
|
||||||
|
|
||||||
|
Weakly related:
|
||||||
|
|
||||||
|
- same material family but different device
|
||||||
|
- same device but different material
|
||||||
|
- similar characterization chain
|
||||||
|
- similar introduction structure or mechanism language
|
||||||
|
- adjacent application with transferable design logic
|
||||||
|
- broader review or perspective useful for field framing
|
||||||
|
|
||||||
|
Reject:
|
||||||
|
|
||||||
|
- title-only matches with no useful mechanism or benchmark
|
||||||
|
- papers outside the application without transferable logic
|
||||||
|
- notes with insufficient metadata unless the user asks to repair metadata
|
||||||
|
|
||||||
|
## How to use results in writing
|
||||||
|
|
||||||
|
Strong papers:
|
||||||
|
|
||||||
|
- define novelty and gap
|
||||||
|
- anchor Introduction claims
|
||||||
|
- support direct benchmark comparison
|
||||||
|
- guide reviewer-risk fixes
|
||||||
|
- decide which references must be cited near major claims
|
||||||
|
- provide DOI-only Word comments when the user asks for citation placement in
|
||||||
|
`.docx`
|
||||||
|
|
||||||
|
Weak papers:
|
||||||
|
|
||||||
|
- broaden first Introduction paragraph
|
||||||
|
- provide mechanism vocabulary
|
||||||
|
- support cautious analogies
|
||||||
|
- suggest missing controls or characterization
|
||||||
|
- inspire section architecture
|
||||||
|
|
||||||
|
## Output template
|
||||||
|
|
||||||
|
`Keyword pack:`
|
||||||
|
|
||||||
|
`Strongly related papers:`
|
||||||
|
|
||||||
|
`Weakly related papers:`
|
||||||
|
|
||||||
|
`How this changes the manuscript:`
|
||||||
|
|
||||||
|
`Citation/positioning risks:`
|
||||||
|
|
||||||
|
## Word citation comments
|
||||||
|
|
||||||
|
When the final deliverable is an annotated Word manuscript, separate internal
|
||||||
|
planning from comment text.
|
||||||
|
|
||||||
|
Internal planning may include title, authors, Zotero key, relation type, and why
|
||||||
|
the paper supports the claim.
|
||||||
|
|
||||||
|
The Word comment itself must contain DOI strings only:
|
||||||
|
|
||||||
|
```text
|
||||||
|
10.xxxx/xxxxx
|
||||||
|
10.xxxx/yyyyy
|
||||||
|
```
|
||||||
|
|
||||||
|
Do not include explanations in the Word comment. Omit papers without DOI unless
|
||||||
|
the user explicitly allows title or Zotero-key fallback.
|
||||||
|
|
@ -0,0 +1,110 @@
|
||||||
|
# Materials Manuscript Architecture
|
||||||
|
|
||||||
|
Use this file when planning a complete materials-science manuscript, rebuilding
|
||||||
|
section logic, or deciding how the story should unfold.
|
||||||
|
|
||||||
|
## Core article shapes
|
||||||
|
|
||||||
|
### Mechanism paper
|
||||||
|
|
||||||
|
Best for work where the main contribution is explaining why a material or
|
||||||
|
interface produces a property.
|
||||||
|
|
||||||
|
Order:
|
||||||
|
|
||||||
|
1. Field problem and unresolved mechanism.
|
||||||
|
2. Material design that isolates the suspected factor.
|
||||||
|
3. Structural and chemical validation.
|
||||||
|
4. Property or performance change.
|
||||||
|
5. Mechanistic evidence and controls.
|
||||||
|
6. Boundary, limitation, and generality.
|
||||||
|
|
||||||
|
Risk: claiming causality from correlation. Require controls, comparative
|
||||||
|
samples, in situ/operando evidence, simulations, or targeted perturbation.
|
||||||
|
|
||||||
|
### Materials design paper
|
||||||
|
|
||||||
|
Best for new composition, morphology, interface, heterostructure, or processing
|
||||||
|
strategy.
|
||||||
|
|
||||||
|
Order:
|
||||||
|
|
||||||
|
1. Bottleneck in existing material designs.
|
||||||
|
2. Design principle.
|
||||||
|
3. Synthesis or fabrication route.
|
||||||
|
4. Structure/composition/interface evidence.
|
||||||
|
5. Property improvement.
|
||||||
|
6. Application performance and comparison.
|
||||||
|
7. Mechanistic rationale.
|
||||||
|
|
||||||
|
Risk: novelty is only synthetic variation. Make the design principle and
|
||||||
|
property-mechanism link explicit.
|
||||||
|
|
||||||
|
### Device/application paper
|
||||||
|
|
||||||
|
Best for flexible electronics, sensors, triboelectric/piezoelectric devices,
|
||||||
|
photodetectors, batteries, catalysis cells, membranes, or biomedical devices.
|
||||||
|
|
||||||
|
Order:
|
||||||
|
|
||||||
|
1. Application requirement and failure mode of existing devices.
|
||||||
|
2. Material/device architecture.
|
||||||
|
3. Device-relevant properties.
|
||||||
|
4. Benchmark performance.
|
||||||
|
5. Stability, durability, repeatability, and real-condition tests.
|
||||||
|
6. Practical boundary.
|
||||||
|
|
||||||
|
Risk: impressive peak metric without durability, reproducibility, or fair
|
||||||
|
benchmarking.
|
||||||
|
|
||||||
|
### Platform/generalization paper
|
||||||
|
|
||||||
|
Best when the method applies across multiple materials, substrates, ions,
|
||||||
|
analytes, reactions, or device formats.
|
||||||
|
|
||||||
|
Order:
|
||||||
|
|
||||||
|
1. General limitation across a class of systems.
|
||||||
|
2. Transferable principle.
|
||||||
|
3. Representative material examples.
|
||||||
|
4. Shared characterization and performance logic.
|
||||||
|
5. Limits of generality.
|
||||||
|
|
||||||
|
Risk: claiming universality from too few examples.
|
||||||
|
|
||||||
|
## Paragraph jobs
|
||||||
|
|
||||||
|
Each paragraph should do one job:
|
||||||
|
|
||||||
|
- `Context`: why the field or application matters.
|
||||||
|
- `Gap`: what existing materials fail to solve.
|
||||||
|
- `Design`: why this composition/interface/architecture should help.
|
||||||
|
- `Evidence`: what data prove the structure or property.
|
||||||
|
- `Mechanism`: why the observed change occurs.
|
||||||
|
- `Comparison`: how it differs from controls or literature.
|
||||||
|
- `Boundary`: what remains unproven or condition-dependent.
|
||||||
|
|
||||||
|
## Section-level order
|
||||||
|
|
||||||
|
Abstract:
|
||||||
|
|
||||||
|
`need -> bottleneck -> design -> evidence -> performance -> implication`
|
||||||
|
|
||||||
|
Introduction:
|
||||||
|
|
||||||
|
`field demand -> material limitation -> prior strategies -> unresolved gap ->
|
||||||
|
present design and proof`
|
||||||
|
|
||||||
|
Results:
|
||||||
|
|
||||||
|
`design/synthesis -> structure -> property -> mechanism -> application ->
|
||||||
|
stability/generalization`
|
||||||
|
|
||||||
|
Discussion:
|
||||||
|
|
||||||
|
`central advance -> evidence meaning -> relation to prior work -> limitation ->
|
||||||
|
future use`
|
||||||
|
|
||||||
|
Conclusion:
|
||||||
|
|
||||||
|
`contribution -> decisive evidence -> implication -> boundary`
|
||||||
|
|
@ -0,0 +1,70 @@
|
||||||
|
# Materials Manuscript Review Audit
|
||||||
|
|
||||||
|
Use this file for reviewer-style comments, pre-submission audits, novelty
|
||||||
|
checks, and claim-evidence risk review. If strongly related papers are
|
||||||
|
available, do not rely on standalone judgment; compare the manuscript with
|
||||||
|
those papers using `comparative-review-audit.md`.
|
||||||
|
|
||||||
|
## Severity order
|
||||||
|
|
||||||
|
1. Unsupported central claim or mechanism.
|
||||||
|
2. Missing control or unfair comparison.
|
||||||
|
3. Novelty unclear relative to prior materials.
|
||||||
|
4. Performance claim lacks operating conditions, statistics, or durability.
|
||||||
|
5. Structure-property relationship is asserted but not shown.
|
||||||
|
6. Section logic obscures the contribution.
|
||||||
|
7. Figure or caption problems.
|
||||||
|
8. Terminology, spelling, unit, or formatting inconsistency.
|
||||||
|
|
||||||
|
## Review questions
|
||||||
|
|
||||||
|
Central contribution:
|
||||||
|
|
||||||
|
- What exactly is new: composition, interface, morphology, processing,
|
||||||
|
mechanism, device architecture, or application demonstration?
|
||||||
|
- Would a reviewer see this as more than incremental optimization?
|
||||||
|
|
||||||
|
Evidence:
|
||||||
|
|
||||||
|
- Does each major claim have a figure, table, or method behind it?
|
||||||
|
- Are controls sufficient to isolate the claimed variable?
|
||||||
|
- Are mechanism claims direct, indirect, or speculative?
|
||||||
|
|
||||||
|
Benchmarking:
|
||||||
|
|
||||||
|
- Are literature comparisons under comparable conditions?
|
||||||
|
- Are units, test conditions, and sample dimensions clear?
|
||||||
|
- Is stability/reproducibility adequate for the claimed application?
|
||||||
|
|
||||||
|
Writing:
|
||||||
|
|
||||||
|
- Does the abstract state the bottleneck, design, evidence, and implication?
|
||||||
|
- Does the introduction narrow to a specific gap?
|
||||||
|
- Do results subsections open with claims rather than procedures?
|
||||||
|
- Does the discussion interpret instead of repeating results?
|
||||||
|
|
||||||
|
Figures and format:
|
||||||
|
|
||||||
|
- Does each figure answer one clear scientific question?
|
||||||
|
- Are panel labels, scale bars, axis labels, units, error bars, and statistical
|
||||||
|
descriptions complete?
|
||||||
|
- Are sample names, abbreviations, colors, and terminology consistent between
|
||||||
|
text, figures, captions, and methods?
|
||||||
|
- Are spelling, hyphenation, capitalization, and journal style internally
|
||||||
|
consistent?
|
||||||
|
|
||||||
|
## Output template
|
||||||
|
|
||||||
|
Use:
|
||||||
|
|
||||||
|
`Finding: ...`
|
||||||
|
|
||||||
|
`Why it matters: ...`
|
||||||
|
|
||||||
|
`Fix: ...`
|
||||||
|
|
||||||
|
`Suggested wording: ...`
|
||||||
|
|
||||||
|
Keep findings grounded in the user's supplied text and figures. Do not invent
|
||||||
|
missing experiments, but recommend controls or wording changes when evidence is
|
||||||
|
insufficient.
|
||||||
|
|
@ -0,0 +1,100 @@
|
||||||
|
# Section Patterns for Materials Papers
|
||||||
|
|
||||||
|
Use this file when drafting or revising a specific manuscript section.
|
||||||
|
|
||||||
|
## Title
|
||||||
|
|
||||||
|
Pattern:
|
||||||
|
|
||||||
|
`[Material/interface/architecture] enables [mechanism/property] for
|
||||||
|
[application]`
|
||||||
|
|
||||||
|
Good titles expose the material identity and the evidence-backed advance.
|
||||||
|
Avoid empty modifiers such as `novel`, `excellent`, `advanced`, or
|
||||||
|
`high-performance` unless the rest of the title says why.
|
||||||
|
|
||||||
|
## Abstract
|
||||||
|
|
||||||
|
Sentence jobs:
|
||||||
|
|
||||||
|
1. Application need or field bottleneck.
|
||||||
|
2. Specific materials limitation.
|
||||||
|
3. Design strategy.
|
||||||
|
4. Structural or interfacial evidence.
|
||||||
|
5. Key performance metric.
|
||||||
|
6. Mechanistic explanation or implication.
|
||||||
|
7. Boundary or application relevance.
|
||||||
|
|
||||||
|
Keep the abstract compact. Put numbers near the claims they support.
|
||||||
|
|
||||||
|
## Introduction
|
||||||
|
|
||||||
|
Paragraph jobs:
|
||||||
|
|
||||||
|
1. Why the application or field problem matters.
|
||||||
|
2. Why current materials or devices remain insufficient.
|
||||||
|
3. What prior strategies attempted and what they leave unresolved.
|
||||||
|
4. What design principle this paper uses.
|
||||||
|
5. What the paper demonstrates.
|
||||||
|
|
||||||
|
Do not write a literature list. Use mechanism-based grouping:
|
||||||
|
|
||||||
|
- composition engineering
|
||||||
|
- interface engineering
|
||||||
|
- defect or coordination control
|
||||||
|
- microstructure/morphology design
|
||||||
|
- device architecture
|
||||||
|
- processing/scalability
|
||||||
|
|
||||||
|
## Results
|
||||||
|
|
||||||
|
Subsection opening pattern:
|
||||||
|
|
||||||
|
`To test whether [design feature] can address [bottleneck], we prepared
|
||||||
|
[sample/device] and first examined [structure/property].`
|
||||||
|
|
||||||
|
Evidence pattern:
|
||||||
|
|
||||||
|
`[Technique] shows [observation], indicating [bounded interpretation]. In
|
||||||
|
comparison with [control], [sample] exhibits [quantitative difference], which
|
||||||
|
supports [claim].`
|
||||||
|
|
||||||
|
Mechanism pattern:
|
||||||
|
|
||||||
|
`Together, [evidence 1] and [evidence 2] suggest that [feature] promotes
|
||||||
|
[process]. This interpretation is supported by [control/diagnostic], although
|
||||||
|
[boundary] remains to be clarified.`
|
||||||
|
|
||||||
|
## Discussion
|
||||||
|
|
||||||
|
Use:
|
||||||
|
|
||||||
|
`central advance -> why the evidence matters -> relation to prior materials ->
|
||||||
|
practical limits -> next step`
|
||||||
|
|
||||||
|
Discussion can explain, compare, and limit. It should not repeat every figure in
|
||||||
|
the Results section.
|
||||||
|
|
||||||
|
## Conclusion
|
||||||
|
|
||||||
|
Use:
|
||||||
|
|
||||||
|
`We developed [material/design]. The key evidence is [structure/property/
|
||||||
|
performance]. These results show [bounded implication]. Further work is needed
|
||||||
|
to [limit].`
|
||||||
|
|
||||||
|
No new data. No unsupported application promises.
|
||||||
|
|
||||||
|
## Methods
|
||||||
|
|
||||||
|
Methods must make the work reproducible:
|
||||||
|
|
||||||
|
- precursor names and purity when needed
|
||||||
|
- ratios, concentrations, solvents, pH, temperatures, times
|
||||||
|
- substrate treatment, deposition, washing, drying, annealing
|
||||||
|
- instrument models and critical parameters
|
||||||
|
- sample dimensions and test conditions
|
||||||
|
- statistics, replicates, and software
|
||||||
|
|
||||||
|
Avoid vague phrases such as `standard method`, `appropriate amount`,
|
||||||
|
`optimized conditions`, and `good reproducibility`.
|
||||||
|
|
@ -0,0 +1,183 @@
|
||||||
|
# Submission Package Audit
|
||||||
|
|
||||||
|
Use this file when the user provides a full or partial submission package rather
|
||||||
|
than only one manuscript file.
|
||||||
|
|
||||||
|
Typical files:
|
||||||
|
|
||||||
|
- `Manuscript.docx`
|
||||||
|
- `Supplementary Information.docx`
|
||||||
|
- `Highlights.docx`
|
||||||
|
- `CoverLetter.docx`
|
||||||
|
- `Figures.pptx`
|
||||||
|
- `Supplementary Information.pptx`
|
||||||
|
- `TOC.pptx`
|
||||||
|
|
||||||
|
## Core rule
|
||||||
|
|
||||||
|
Audit the files as one submission package. The main manuscript and main figures
|
||||||
|
define the story; all other files must be consistent with them.
|
||||||
|
|
||||||
|
Do not check files independently if cross-file consistency matters.
|
||||||
|
|
||||||
|
## Recommended order
|
||||||
|
|
||||||
|
1. `Manuscript.docx`
|
||||||
|
2. `Figures.pptx`
|
||||||
|
3. `Supplementary Information.docx`
|
||||||
|
4. `Supplementary Information.pptx`
|
||||||
|
5. `Highlights.docx`
|
||||||
|
6. `CoverLetter.docx`
|
||||||
|
7. `TOC.pptx`
|
||||||
|
|
||||||
|
Rationale: the manuscript and main figures establish the scientific story, the
|
||||||
|
SI documents support the claims, and the highlights, cover letter, and TOC must
|
||||||
|
then align with that story.
|
||||||
|
|
||||||
|
## File-specific checks
|
||||||
|
|
||||||
|
### 1. Manuscript.docx
|
||||||
|
|
||||||
|
Check:
|
||||||
|
|
||||||
|
- central claim, novelty, target-journal fit, and story order
|
||||||
|
- title, abstract, introduction gap, results logic, discussion boundary
|
||||||
|
- claim-evidence alignment with figures and SI
|
||||||
|
- DOI-only citation comment placement if requested
|
||||||
|
- terminology, sample names, abbreviations, units, and spelling consistency
|
||||||
|
- whether strong related papers expose missing evidence or weaker positioning
|
||||||
|
|
||||||
|
Default output:
|
||||||
|
|
||||||
|
- annotated copy with Word native comments when editing is requested
|
||||||
|
- Markdown reviewer report for global issues
|
||||||
|
|
||||||
|
### 2. Figures.pptx
|
||||||
|
|
||||||
|
Check:
|
||||||
|
|
||||||
|
- main figure sequence matches manuscript Results order
|
||||||
|
- each figure has one clear conclusion
|
||||||
|
- panel labels, scale bars, axis labels, legends, units, and error bars
|
||||||
|
- sample names and colors match manuscript and SI
|
||||||
|
- resolution, font size, line width, contrast, cropping, and alignment risks
|
||||||
|
- whether any panel lacks explanation in the text
|
||||||
|
- whether any key claim in the text lacks a main or SI figure
|
||||||
|
|
||||||
|
### 3. Supplementary Information.docx
|
||||||
|
|
||||||
|
Check:
|
||||||
|
|
||||||
|
- SI figure/table numbering and order
|
||||||
|
- methods completeness and reproducibility
|
||||||
|
- experimental details, controls, statistics, and raw/supporting data
|
||||||
|
- cross-references from manuscript to SI
|
||||||
|
- whether SI evidence actually supports main-text claims
|
||||||
|
- consistency with `Supplementary Information.pptx`
|
||||||
|
|
||||||
|
### 4. Supplementary Information.pptx
|
||||||
|
|
||||||
|
Check:
|
||||||
|
|
||||||
|
- SI figures match `Supplementary Information.docx`
|
||||||
|
- figure numbering, captions, sample names, and units are consistent
|
||||||
|
- control figures and supplementary mechanism evidence are present
|
||||||
|
- image quality and visual style match main figures where appropriate
|
||||||
|
|
||||||
|
### 5. Highlights.docx
|
||||||
|
|
||||||
|
Check:
|
||||||
|
|
||||||
|
- highlights reflect the manuscript's true novelty
|
||||||
|
- claims are concrete and evidence-backed
|
||||||
|
- no mismatch with abstract, cover letter, or target journal positioning
|
||||||
|
- no empty phrases such as `excellent performance` without specifics
|
||||||
|
- each highlight is short, distinct, and not redundant
|
||||||
|
|
||||||
|
### 6. CoverLetter.docx
|
||||||
|
|
||||||
|
Check:
|
||||||
|
|
||||||
|
- target journal and article type are correct
|
||||||
|
- novelty and significance match manuscript evidence
|
||||||
|
- claims are not stronger than the data
|
||||||
|
- relationship to strong related papers is clear without sounding defensive
|
||||||
|
- required declarations are present if the journal requires them
|
||||||
|
- tone is professional and concise
|
||||||
|
|
||||||
|
If target-journal rules may have changed, verify the current journal page before
|
||||||
|
final submission advice.
|
||||||
|
|
||||||
|
### 7. TOC.pptx
|
||||||
|
|
||||||
|
Check:
|
||||||
|
|
||||||
|
- graphical TOC communicates material design, mechanism, and application at a
|
||||||
|
glance
|
||||||
|
- it is consistent with manuscript title, abstract, and main figures
|
||||||
|
- visual hierarchy is clear
|
||||||
|
- text is minimal and readable
|
||||||
|
- mechanism arrows, labels, material names, and device icons are accurate
|
||||||
|
- it does not introduce claims absent from the manuscript
|
||||||
|
|
||||||
|
## Cross-file consistency checks
|
||||||
|
|
||||||
|
Always check:
|
||||||
|
|
||||||
|
- title consistency across manuscript, cover letter, TOC, and highlights
|
||||||
|
- material names, sample labels, and abbreviations
|
||||||
|
- figure numbering and panel references
|
||||||
|
- SI numbering and manuscript callouts
|
||||||
|
- performance values and units
|
||||||
|
- target journal name and article type
|
||||||
|
- novelty wording across abstract, highlights, cover letter, and TOC
|
||||||
|
- terminology and spelling variants
|
||||||
|
- whether DOI citation suggestions align with the claims being cited
|
||||||
|
|
||||||
|
## Output package
|
||||||
|
|
||||||
|
Preferred outputs:
|
||||||
|
|
||||||
|
- `<manuscript-name>_comments.docx`: Word native comments for sentence-level
|
||||||
|
issues and DOI-only citation suggestions when requested
|
||||||
|
- `<manuscript-name>_reviewer_report.md`: global review, comparative audit,
|
||||||
|
figure/SI/package issues, and priority revision plan
|
||||||
|
- optional `<manuscript-name>_package_checklist.md`: concise cross-file checklist
|
||||||
|
|
||||||
|
Never overwrite original files unless the user explicitly asks.
|
||||||
|
|
||||||
|
## Report format
|
||||||
|
|
||||||
|
Use:
|
||||||
|
|
||||||
|
```text
|
||||||
|
Package inventory
|
||||||
|
- Manuscript:
|
||||||
|
- Main figures:
|
||||||
|
- SI document:
|
||||||
|
- SI figures:
|
||||||
|
- Highlights:
|
||||||
|
- Cover letter:
|
||||||
|
- TOC:
|
||||||
|
|
||||||
|
Priority issues
|
||||||
|
| ID | Severity | File | Location | Problem | Fix | Cross-file impact |
|
||||||
|
|---|---|---|---|---|---|---|
|
||||||
|
|
||||||
|
Cross-file consistency
|
||||||
|
- ...
|
||||||
|
|
||||||
|
File-by-file findings
|
||||||
|
- Manuscript:
|
||||||
|
- Figures:
|
||||||
|
- SI document:
|
||||||
|
- SI figures:
|
||||||
|
- Highlights:
|
||||||
|
- Cover letter:
|
||||||
|
- TOC:
|
||||||
|
|
||||||
|
Next revision order
|
||||||
|
1. ...
|
||||||
|
2. ...
|
||||||
|
3. ...
|
||||||
|
```
|
||||||
|
|
@ -0,0 +1,54 @@
|
||||||
|
# Word Citation Comments
|
||||||
|
|
||||||
|
Use this file when the user wants citation placement in a Word `.docx`
|
||||||
|
manuscript.
|
||||||
|
|
||||||
|
## Default rule
|
||||||
|
|
||||||
|
Do not directly insert Zotero Word fields. Add native Word comments at the
|
||||||
|
sentence or clause where the reference should be inserted.
|
||||||
|
|
||||||
|
The comment body must contain DOI strings only:
|
||||||
|
|
||||||
|
```text
|
||||||
|
10.xxxx/xxxxx
|
||||||
|
10.xxxx/yyyyy
|
||||||
|
```
|
||||||
|
|
||||||
|
## Rules
|
||||||
|
|
||||||
|
- One DOI per line.
|
||||||
|
- No title, author, journal, year, Zotero key, reason, priority, or explanation
|
||||||
|
inside the Word comment.
|
||||||
|
- If multiple references support the same sentence, put all DOI values in the
|
||||||
|
same comment, one per line.
|
||||||
|
- If a candidate reference has no DOI, omit it by default.
|
||||||
|
- Use a title or Zotero key fallback only if the user explicitly allows it.
|
||||||
|
- Save the annotated manuscript as a new copy, usually
|
||||||
|
`<original-name>_comments.docx`.
|
||||||
|
- Keep reviewer-style reasoning and claim-to-reference planning in a separate
|
||||||
|
Markdown report if needed.
|
||||||
|
|
||||||
|
## Placement guidance
|
||||||
|
|
||||||
|
Place DOI comments after:
|
||||||
|
|
||||||
|
- background claims in the Introduction
|
||||||
|
- material-family or mechanism claims
|
||||||
|
- benchmark or performance-comparison claims
|
||||||
|
- method precedent claims
|
||||||
|
- interpretation claims that rely on prior literature
|
||||||
|
|
||||||
|
Do not add DOI comments to:
|
||||||
|
|
||||||
|
- claims directly supported by the user's own figure unless prior work is needed
|
||||||
|
- obvious transition sentences
|
||||||
|
- unsupported speculative claims that should be rewritten or removed first
|
||||||
|
|
||||||
|
## Output summary
|
||||||
|
|
||||||
|
After annotating the document, report only:
|
||||||
|
|
||||||
|
- annotated `.docx` path
|
||||||
|
- number of DOI comments added
|
||||||
|
- any skipped candidates without DOI
|
||||||
|
|
@ -0,0 +1,90 @@
|
||||||
|
# Zotero-Obsidian Literature Note Subskill
|
||||||
|
|
||||||
|
Use this file when the user asks to use the previous Zotero/Obsidian workflow,
|
||||||
|
generate notes for newly imported papers, batch-process papers with DeepSeek, or
|
||||||
|
link generated notes into Obsidian.
|
||||||
|
|
||||||
|
## Core order
|
||||||
|
|
||||||
|
1. Zotero first: identify target items and generate/update Zotero child notes.
|
||||||
|
2. Obsidian second: link Zotero notes into the vault through Zotero Integration
|
||||||
|
and Dataview.
|
||||||
|
3. Manuscript third: use screened notes to rewrite positioning, introduction,
|
||||||
|
comparison, discussion, and citation placement.
|
||||||
|
|
||||||
|
Do not default to creating standalone Obsidian markdown notes when the user says
|
||||||
|
`文献笔记`; the default target is Zotero child notes.
|
||||||
|
|
||||||
|
## Safety and config
|
||||||
|
|
||||||
|
- Do not ask the user to paste API keys into chat.
|
||||||
|
- Load secrets from environment variables, then `config/config.local.json`, then
|
||||||
|
the local AwesomeGPT/Zotero profile if available.
|
||||||
|
- Keep `config/config.local.json` ignored and local-only.
|
||||||
|
- Do not print secret-bearing config or preference lines.
|
||||||
|
- Treat Zotero local API at `127.0.0.1:23119` as read-oriented.
|
||||||
|
- For child-note writes, require a configured write path: Zotero Web API,
|
||||||
|
connector helper, or an existing local helper script.
|
||||||
|
|
||||||
|
## Preflight
|
||||||
|
|
||||||
|
Before writing notes:
|
||||||
|
|
||||||
|
1. Check Zotero is running and the local/connector route is available.
|
||||||
|
2. Confirm the target collection, selected items, tags, or explicit item keys.
|
||||||
|
3. Check whether notes already exist and skip or update according to the user's
|
||||||
|
instruction.
|
||||||
|
4. Confirm the write route for Zotero child notes.
|
||||||
|
5. Confirm the DeepSeek/AwesomeGPT config is available without exposing secrets.
|
||||||
|
|
||||||
|
## Batch behavior
|
||||||
|
|
||||||
|
Batch work must be resumable:
|
||||||
|
|
||||||
|
- write a manifest with Zotero item key, title, DOI, note status, timestamp,
|
||||||
|
and error
|
||||||
|
- skip items with successful existing notes unless the user asks to regenerate
|
||||||
|
- process in batches, not one broad unbounded run
|
||||||
|
- preserve UTF-8 output for Chinese templates and notes
|
||||||
|
|
||||||
|
## New paper flow
|
||||||
|
|
||||||
|
When the user says they introduced new papers:
|
||||||
|
|
||||||
|
1. Identify new Zotero items by collection, tag, selected items, import time, or
|
||||||
|
explicit keys.
|
||||||
|
2. For each item, gather metadata, abstract, attachment text if available, and
|
||||||
|
existing child notes.
|
||||||
|
3. Send the note-generation prompt to DeepSeek/AwesomeGPT using the user's
|
||||||
|
template.
|
||||||
|
4. Create or update the Zotero child note.
|
||||||
|
5. Refresh or instruct Obsidian Zotero Integration linking only after Zotero
|
||||||
|
notes are created.
|
||||||
|
6. Update the manifest and report successes, skips, and failures.
|
||||||
|
|
||||||
|
## Manuscript integration flow
|
||||||
|
|
||||||
|
After notes exist:
|
||||||
|
|
||||||
|
1. Extract manuscript keyword pack.
|
||||||
|
2. Use `literature-routing.md` to classify strong and weak papers.
|
||||||
|
3. Build a source map linking paper -> useful claim -> manuscript section.
|
||||||
|
4. For Word citation help, add native Word comments containing DOI strings only,
|
||||||
|
one DOI per line.
|
||||||
|
5. Rewrite the manuscript section with citation placeholders only if the user is
|
||||||
|
not using the DOI-comment workflow.
|
||||||
|
6. Flag missing evidence, missing citations, and overclaim risks.
|
||||||
|
|
||||||
|
## Output template
|
||||||
|
|
||||||
|
`Preflight:`
|
||||||
|
|
||||||
|
`Processed Zotero items:`
|
||||||
|
|
||||||
|
`Generated or updated child notes:`
|
||||||
|
|
||||||
|
`Skipped existing notes:`
|
||||||
|
|
||||||
|
`Failed items and reason:`
|
||||||
|
|
||||||
|
`Next manuscript-use step:`
|
||||||
|
|
@ -0,0 +1,114 @@
|
||||||
|
#!/usr/bin/env python3
|
||||||
|
"""Create a manuscript keyword pack and DeepSeek screening prompt.
|
||||||
|
|
||||||
|
This helper is intentionally local-config only. It does not call DeepSeek or
|
||||||
|
Zotero by itself; it prepares a reproducible prompt that the skill can use with
|
||||||
|
the user's configured note-search route.
|
||||||
|
"""
|
||||||
|
|
||||||
|
from __future__ import annotations
|
||||||
|
|
||||||
|
import argparse
|
||||||
|
import json
|
||||||
|
import re
|
||||||
|
import sys
|
||||||
|
from pathlib import Path
|
||||||
|
|
||||||
|
|
||||||
|
MATERIAL_FAMILY_HINTS = [
|
||||||
|
"MOF",
|
||||||
|
"COF",
|
||||||
|
"MXene",
|
||||||
|
"perovskite",
|
||||||
|
"hydrogel",
|
||||||
|
"aerogel",
|
||||||
|
"cellulose",
|
||||||
|
"graphene",
|
||||||
|
"polymer",
|
||||||
|
"oxide",
|
||||||
|
"sulfide",
|
||||||
|
"carbide",
|
||||||
|
"nitride",
|
||||||
|
"composite",
|
||||||
|
]
|
||||||
|
|
||||||
|
DEVICE_HINTS = [
|
||||||
|
"TENG",
|
||||||
|
"triboelectric",
|
||||||
|
"piezoelectric",
|
||||||
|
"sensor",
|
||||||
|
"supercapacitor",
|
||||||
|
"battery",
|
||||||
|
"catalysis",
|
||||||
|
"photocatalysis",
|
||||||
|
"electrocatalysis",
|
||||||
|
"membrane",
|
||||||
|
"photodetector",
|
||||||
|
"flexible electronics",
|
||||||
|
]
|
||||||
|
|
||||||
|
|
||||||
|
def read_text(path: Path) -> str:
|
||||||
|
return path.read_text(encoding="utf-8", errors="replace")
|
||||||
|
|
||||||
|
|
||||||
|
def extract_terms(text: str) -> dict[str, list[str]]:
|
||||||
|
tokens = sorted(set(re.findall(r"[A-Za-z][A-Za-z0-9\-_/]{2,}", text)))
|
||||||
|
families = [term for term in MATERIAL_FAMILY_HINTS if re.search(re.escape(term), text, re.I)]
|
||||||
|
devices = [term for term in DEVICE_HINTS if re.search(re.escape(term), text, re.I)]
|
||||||
|
chemical_like = [
|
||||||
|
token
|
||||||
|
for token in tokens
|
||||||
|
if any(ch.isdigit() for ch in token) or "-" in token or token.isupper()
|
||||||
|
][:40]
|
||||||
|
return {
|
||||||
|
"exact_or_chemical_terms": chemical_like,
|
||||||
|
"material_family_hints": families,
|
||||||
|
"device_application_hints": devices,
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
def build_prompt(profile: dict[str, object]) -> str:
|
||||||
|
return f"""You are screening existing Zotero/Obsidian literature notes for a materials-science manuscript.
|
||||||
|
|
||||||
|
Manuscript profile:
|
||||||
|
- Material/system terms: {', '.join(profile.get('exact_or_chemical_terms', [])) or 'xxx'}
|
||||||
|
- Material family: {', '.join(profile.get('material_family_hints', [])) or 'xxx'}
|
||||||
|
- Device/application: {', '.join(profile.get('device_application_hints', [])) or 'xxx'}
|
||||||
|
- Target journal or tier: {profile.get('target_journal') or 'xxx'}
|
||||||
|
- Extra author notes: {profile.get('extra_notes') or 'xxx'}
|
||||||
|
|
||||||
|
Return:
|
||||||
|
1. Strongly related papers: same material, same material family plus same device, same mechanism, direct benchmark, or same target-journal positioning.
|
||||||
|
2. Weakly related papers: same direction, adjacent material family, same characterization logic, similar device architecture, or useful writing pattern.
|
||||||
|
3. For each paper: title, year, journal, Zotero key if present, relation type, useful claim/evidence, and why it matters for the manuscript.
|
||||||
|
4. Reject title-only broad keyword matches.
|
||||||
|
"""
|
||||||
|
|
||||||
|
|
||||||
|
def main() -> int:
|
||||||
|
parser = argparse.ArgumentParser()
|
||||||
|
parser.add_argument("--draft", required=True, help="UTF-8 text or markdown draft path")
|
||||||
|
parser.add_argument("--target-journal", default="")
|
||||||
|
parser.add_argument("--extra-notes", default="")
|
||||||
|
parser.add_argument("--json-out", default="")
|
||||||
|
args = parser.parse_args()
|
||||||
|
|
||||||
|
draft = Path(args.draft)
|
||||||
|
text = read_text(draft)
|
||||||
|
profile: dict[str, object] = extract_terms(text)
|
||||||
|
profile["target_journal"] = args.target_journal
|
||||||
|
profile["extra_notes"] = args.extra_notes
|
||||||
|
profile["screening_prompt"] = build_prompt(profile)
|
||||||
|
|
||||||
|
data = json.dumps(profile, ensure_ascii=False, indent=2)
|
||||||
|
if args.json_out:
|
||||||
|
Path(args.json_out).write_text(data + "\n", encoding="utf-8")
|
||||||
|
else:
|
||||||
|
sys.stdout.reconfigure(encoding="utf-8")
|
||||||
|
print(data)
|
||||||
|
return 0
|
||||||
|
|
||||||
|
|
||||||
|
if __name__ == "__main__":
|
||||||
|
raise SystemExit(main())
|
||||||
Loading…
Reference in New Issue