Method Topic Word Writer

Core contract

Treat the supplied paper as evidence, not automatically as the method itself or the narrator of the finished article. Before drafting, identify four layers in order:

1. Research topic: the scientific question or application domain.
2. Analysis family: the broad class, such as graph analysis, RSA, normative modeling, or multimodal fusion.
3. Transferable method: the reusable analytical framework.
4. Implementation variant: the paper-specific form, such as whole-brain searchlight multiple-regression RSA.

Use the narrowest name that is faithful to the actual analysis but still transferable beyond the single dataset. Read references/paper_to_method.md whenever the method name is uncertain or the source is primarily an application paper.

Required workflow

Store and read all Markdown, YAML, and text assets as UTF-8. On legacy Windows PowerShell, pass an explicit UTF-8 encoding instead of relying on the console default.

1. Inspect the user request, all supplied papers and supplements, and any retained sample DOCX. Separate hard constraints from preferences.
2. Read the abstract, method definition, analysis steps, result interpretation, figure legends, discussion, and relevant supplement sections. Do not rely on the abstract alone.
3. Create an evidence map covering method name, inputs, preprocessing, algorithm, outputs, inference, interpretation boundaries, applications, figure sources, and references.
4. Search for method-origin papers, validation/statistical papers, or high-quality reviews when they improve accuracy. Do not impose a minimum or fixed reference count and do not add weakly related papers to make the list longer.
5. Draft around the method. State the general analytical logic before any source-specific implementation detail; keep the supplied material's findings subordinate to the method explanation.
6. Follow templates/method_topic_outline_zh.md and references/wechat_method_topic_profile.md unless the user supplies a different authoritative template.
7. Select 3–6 source figures according to the paper's actual content. Every figure must explain a distinct point and appear near the relevant paragraph. Prefer original embedded figures or panels over full-page screenshots.
8. Build the DOCX with scripts/build_docx.py or task-specific python-docx code that implements the same profile.
9. Generate a fact-check table and figure list for internal QA. Deliver supporting files only when requested.
10. Run scripts/validate_docx.py, then prefer non-interactive headless rendering and inspect every generated page image. If no headless renderer is available, complete structural QA and disclose that visual render QA was unavailable. Do not open or control WPS by default; use WPS only when the user explicitly requests interactive visual review.

Writing rules

• Write a Chinese scientific method feature: more readable than a Methods section and more rigorous than popular science.
• Lead with the problem the method solves, then explain the conceptual move, workflow, interpretation, applications, and use boundaries.
• Do not create a standalone “局限” section by default. Integrate important cautions into interpretation and application sections.
• Explain formulas in ordinary Chinese unless formal notation is explicitly requested. Do not leave Markdown code, LaTeX, or code-like formulas in Word-facing prose.
• Distinguish necessary method steps from choices made only in one paper.
• Let the method, not the source paper, be the grammatical subject of title, headings, lead and narrative body. Do not use “作者”“本文”“本研究”“该研究”“该论文” or “研究者” there. Keep names of source papers and contributors in captions and references only.
• State the general decision rule first. When a source-specific setting is necessary, introduce it as one published implementation and immediately state what design, acquisition or stability consideration determines the setting elsewhere.
• Demonstrate that a method applies beyond one dataset through its data conditions, choices and applications; do not repeatedly label it “可迁移” as a rhetorical claim.
• Preserve established or user-specified technical terms rather than forcing a literal translation; for example, retain fMRI volume when that is the requested field terminology.
• Never invent results, parameters, brain regions, performance metrics, software settings, references, DOIs, or copyright terms.
• Use cautious language for clinical, predictive, or causal claims.
• Define each abbreviation once and keep terminology consistent.

Figure rules

• Use 3–6 figures as a default range, but choose the actual count from the evidence and document length.
• Prioritize experimental/method workflow, model architecture or RDM, critical interpretation maps, validation/robustness results, and complementary analyses.
• Do not include two figures that make the same point merely to reach a count.
• Extract embedded PDF images with scripts/extract_figures.py --extract-xref when possible. Use crops only when the original figure is vector content or contains unrelated page material.
• Keep figures centered and pair each with an adjacent caption that names the source paper, main/supplement location, year, and reuse/license note when available.
• Do not alter scientific labels, color scales, statistical thresholds, or panel meaning.
• Treat CC BY-NC-ND and other no-derivatives licenses conservatively: reuse the complete original embedded figure or a separately embedded original panel without annotations, recoloring, relabeling, or new crops. If a crop or composite would be needed, omit it or obtain permission instead of presenting it as licensed reuse.

Literature rules

• Prefer primary method papers, peer-reviewed validation/statistical papers, and authoritative reviews.
• Verify bibliographic details against the supplied PDF, DOI landing page, PubMed, Crossref, or the publisher.
• Use as few or as many references as the method genuinely supports. A new method may have only its origin paper; an established method may require several foundational sources.
• Keep every reference traceable and relevant to a concrete statement in the article.

Output profile

The default wechat-method-topic profile mirrors the retained example:

• A4 portrait; margins 2.4 cm left/right and 2.2 cm top/bottom.
• Chinese font 宋体; Latin letters and numbers Times New Roman.
• Body 11.5 pt, justified, 1.28 line spacing.
• Section headings 17 pt, bold, blue 1F4D78.
• Captions 9 pt, centered, gray; figures centered and normally 15.8 cm wide.
• Quiet centered footer; compact references.
• The default validator range is 2000–4000 Chinese characters; a user-specified target such as 3000–3800 overrides it.

Read references/wechat_method_topic_profile.md for exact tokens and component behavior.

Bundled resources

• references/paper_to_method.md: method-identification and evidence-mapping gate.
• references/wechat_method_topic_profile.md: exact structure and DOCX style contract.
• templates/method_topic_outline_zh.md: default Chinese article outline.
• templates/writing_style_rules.md: prose and claim-control rules.
• templates/fact_check_table_template.md: evidence table.
• templates/figure_list_template.md: figure selection and source tracking.
• templates/reference_template.md: reference verification checklist.
• templates/quality_checklist.md: final QA gate.
• scripts/build_docx.py: Markdown-to-DOCX builder using the WeChat profile.
• scripts/extract_figures.py: PDF preview, crop, embedded-image inventory, and xref extraction.
• scripts/validate_docx.py: structure, length, image, caption, source, font, layout, footer, and residue checks.

Dependencies and delivery

Use the workspace dependency runtime or a user-specified Python environment. Required packages are python-docx, PyMuPDF, and Pillow.

Automated validation is a structural gate, not proof that scientific claims, bibliographic records, or reuse permissions are true. Manually reconcile the fact-check table, DOI or publisher records, figure license, and every rendered page before delivery.

Before delivery, report the final DOCX path, body character count, figure count, font and residue status, reference traceability and numbering status, body-narrative check status, and whether headless visual page inspection succeeded. Before committing the skill, confirm .gitignore excludes PDFs, DOCX files, raw data, samples, private inputs, and generated artifacts.