paper-write-sci

Paper Write SCI

• Write papers that feel more like the author themselves rather than generic AI templates
• Control the tone of SCI papers, use fewer colloquial explanatory sentences with colons, and prefer natural, progressively developed complete sentences
• In Introduction coordinate the frequency of the core viewpoint, core pain point, and core question, avoiding repeated restatement of the same claim that causes redundancy
• Strictly protect consistency of numbers, logic, and terminology during writing and revision
• By default, proceed directly with revisions; when the user needs human-AI collaboration, output only the plan and do not directly modify the paper
• Except for explicitly agreed external deliverables, converge all intermediate files into <paper_dir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/paper-write-sci/{yyyy-mm-dd-hh-mm}/

Input

Input item	Required	Description
Paper source code directory	Required	LaTeX paper project root directory
Figure/Table annotations	Required	Explain what argument each figure or table supports and what key numbers it contains
User requirements	Optional	For example, "only revise Results", "relatively conservative polishing", "strengthen Discussion"
Reference papers/reference author materials	Optional	Used to extract additional style signals; learn only the style, do not copy sentences
Run mode	Optional	The default value and aliases are subject to config.yaml:mode .
Style	Optional	The default value and available list are subject to config.yaml:style .

Flow

Input

Provide the necessary input according to the user request and configuration file; missing information should be clearly listed and steps that depend on that input should stop.

Execution steps

• For bugs caused by design flaws in this skill, first use bensz-collect-bugs to record them according to the specification in ~/.bensz-skills/bugs/, and do not directly modify the user's locally installed skill source code; if there is a workaround, record the bug first, then continue completing the task
• Only when the user explicitly requests public reporting such as "report bensz skills bugs", use the local gh to upload newly added bugs to huangwb8/bensz-bugs; do not pull or clone the entire repository

Used to write or optimize the main text of an SCI journal paper based on a LaTeX paper project, Figure/Table annotations, and additional user requirements.

During execution, prioritize delegating deterministic steps to scripts and leaving heuristic judgments to the AI:

• Initialize the workspace, normalize the mode, select the style, and name the plan file: use config.yaml:scripts.prepare_workspace
• Read long rule blocks on demand from references/ ; do not stuff all reference documents into the context at once

autonomous(default)

• Fix problems directly when they are found
• Adopt the principle of minimal necessary changes
• Before writing any new numbers, they must first pass numerical review
• Before finishing, it must pass the final review of section responsibilities, the final review of full-text consistency, and the final review of the logic tree

collaborative

• First read the paper completely, then summarize the defects and revision path

• The plan serves only as material for human review and does not write the main text

• The plan file name, topic slug,run_id and output directory are all based on config.yaml:runtime_outputs as specified

• The plan content includes at least: problem, evidence, recommended actions, affected sections, associated figures/tables, style anchors, section division-of-labor risks, and risk description

• Style directory:references/styles/

• Style template:references/styles/style-template.md

• The default style is based on config.yaml:style.default as specified

Current style:

Style	Domain	Role
bensz-01	Biomedical	Author style-centered, emphasizing problem orientation, method naming, strong numerical comparisons, detailed and non-domain-reader-friendly figure legends, and honest limitations
general-01	General SCI	Synthesizes official SCI writing advice, providing a robust default style when no domain is specified

Style usage principles:

1. Prioritize the style explicitly specified by the user
2. If the user provides reference papers or author materials, additional signals can be extracted on top of the selected style and saved to the current run directory's analysis/reference-style.md
3. If the user does not specify, use config.yaml:style.default
4. Style serves "being more human-like," not piling up fancy sentences
5. Style can only change the manner of expression, not facts, numbers, or logic
6. When the task is "comprehensive polishing," "rewriting the Discussion," or anything clearly involving Discussion requests for de-result-ification, first use general-01 to hold the bottom line of section division of labor, then layer on bensz-01 's authorial feel; do not let author style override section responsibilities

Preferentially read only the reference files needed for the current task:

• Style and section writing methods:references/writing-style-guide.md、references/styles/bensz-01.md、references/styles/general-01.md
• Execution guardrails and pass criteria:references/execution-guards.md
• Collaboration plan template:references/collaborative-plan-template.md
• Number review template:references/templates/number-check-template.md
• Section responsibility review template:references/templates/section-role-check-template.md
• Discussion audit template:references/templates/discussion-role-check-template.md
• Logic tree template:references/templates/logic-tree-template.md
• Logic review template:references/templates/logic-check-template.md

Reading recommendations:

• When involving section displacement,Discussion rewriting, or full-text final review, read references/execution-guards.md
• When only doing stylistic polishing or figure legend polishing, preferentially read writing-style-guide.md and the target style file
• When adding a new style, also read references/styles/style-template.md

Phase 0: Initialization

1. Confirm the paper directory, Figure/Table annotations exist and are readable
2. Locate the main entry tex, preferentially check main.tex
3. Scan \input{} and \include{}, establish section path mapping
4. Identify the build method and protected format files
5. Run python3 scripts/prepare_workspace.py --paper-dir <paper_dir> [--mode ...] [--style ...] [--topic ...] [--reference-material ...]
6. Based on the script output, confirm this round's {yyyy-mm-dd-hh-mm} directory, collaboration plan path, and hidden workspace root directory
7. If there are reference papers or reference author materials, extract supplementary style signals
8. If the task involves section responsibilities, numbers, abbreviations, or high-risk logic issues, read references/execution-guards.md

Phase 1: Understand the current paper

1. Read the full main text and key front/back matter
2. Against the Figure/Table annotations, extract the argument supported by each figure/table
3. Identify existing high-quality paragraphs, weak paragraphs, factual risks, and style inconsistencies
4. Flag section responsibility risks, especially Introduction leaking results,Results over-interpretation,Discussion Paragraph for restating the results
5. Mark Introduction the positions in which the core viewpoint, core pain point, and core question are repeatedly expressed, and determine which sentences should be merged, moved earlier, moved later, or deleted
6. Preliminarily construct the logic tree and write it into the current working directory's analysis/logic-tree.md
7. If the task involves full-text abbreviation governance, follow references/execution-guards.md to establish analysis/abbreviation-inventory.md

Stage 2: Decide the execution path

collaborative

• According to config.yaml:runtime_outputs.collaborative_plan_pattern Generate the plan file
• The plan should focus on "defects and repair suggestions," rather than directly providing the revised full text
• The plan must explicitly state section-role risk
• Stop here; do not modify the main text

autonomous

• Establish the internal revision order
• Prioritize correcting factual errors, numerical risks, and logical breaks
• Then perform structural optimization, language polishing, and style unification

Stage 3: Section-by-section writing or revision

Default order:

Introduction -> Methods -> Results -> Discussion -> Conclusion ->
Additional Information -> Figure Legends -> Supplementary Materials -> Abstract

When processing each section:

1. First read the existing text and the corresponding figure/table evidence
2. First determine the section's responsibilities, then use the selected style to judge "how it should be written to be more like the author"
3. When writing sentences, use fewer X: Y、This means: ...、The reason is: ... such colon explanatory sentences; except for necessary markers such as method labels, lists, and figure captions, prefer converting them into natural subordinate clauses, semicolons, or independent sentences
4. When writing Introduction , arrange the core question, core pain point, and core contribution each in the most appropriate single place for expansion; later text should only advance or conclude, and should not repeatedly restate the same claim with synonymous sentences
5. If long-rule judgments are involved, return to references/execution-guards.md
6. If new numbers are involved, first pass numerical review
7. If Discussion audit trigger conditions are met, complete the specialized review first, then start writing
8. If abbreviations are added, deleted, or rewritten, first check back with analysis/abbreviation-inventory.md
9. In autonomous mode, make the minimal necessary modifications to the target tex, and comply with config.yaml:tex_readability
10. Update the logic tree and necessary full-text consistency records to ensure that local changes have not damaged the whole

When handling Figure Legends or Supplementary Materials:

• For each panel, explain the minimal visual grammar needed to read the figure
• For terms or abbreviations that appear for the first time and are not intuitive enough, add the full name and give a short definition
• Keep only the necessary method details that help read the figure, and avoid repeating an entire Methods paragraph in the legend

Stage 4: Final review

1. Initiate section-role-check
2. Complete a full-text consistency review, including numbers, abbreviations, Figure/Table references, and figure caption consistency
3. Review whether colon explanatory sentences are too dense throughout the text, especially at the beginning of paragraphs, the end of paragraphs, and Introduction contribution sentences
4. Review whether Introduction repeatedly mentions the same core question, pain point, or contribution; if the repetition does not advance the logic, it should be merged or deleted
5. Rebuild the logic tree for the latest text and initiate a logic review
6. If there are blocking issues, review again after fixing them

Stage 5: Rendering and delivery

Detect the build chain according to the following priority:

1. The project's built-in one-click build or export script
2. scripts/manuscript_tool.py
3. Makefile
4. latexmk
5. Directly xelatex

If a Word export chain exists, it should also be attempted. Place build logs in the current working directory's render/。

• Run the preparation script:scripts/prepare_workspace.py
• Execution guardrails:references/execution-guards.md
• Style template:references/styles/style-template.md
• bensz-01：references/styles/bensz-01.md
• general-01：references/styles/general-01.md
• Collaboration plan template:references/collaborative-plan-template.md
• Section writing guide:references/writing-style-guide.md
• Numerical review template:references/templates/number-check-template.md
• Section responsibility review template:references/templates/section-role-check-template.md
• Discussion audit Template:references/templates/discussion-role-check-template.md
• Logic tree template:references/templates/logic-tree-template.md
• Logic review template:references/templates/logic-check-template.md

Output

autonomous

• Directly modify the target main text file
• Write analysis, review, and rendering logs to the current working directory <paper_dir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/paper-write-sci/{yyyy-mm-dd-hh-mm}/
• If an available build chain is detected, attempt to re-render PDF and Word

collaborative

• Output only the plan file, with the filename pattern based on config.yaml:runtime_outputs.collaborative_plan_pattern as the standard, by default including this round's run_id
• The plan summarizes the paper's defects, evidence, recommended fixes, affected files, and risks
• Do not directly modify the paper content
• Intermediate files other than the plan are still written to the current working directory <paper_dir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/paper-write-sci/{yyyy-mm-dd-hh-mm}/

Output management

Intermediate files for new tasks of this Skill are uniformly written to ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/. The same task reuses one task root directory; only multi-Skill collaboration creates shared/. Formal deliverables are not written to this directory; historical hidden directories only allow explicit compatibility reading, migration, or cleanup.

Except for the following "explicitly agreed external deliverables," all other intermediate files must be placed in <paper_dir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/paper-write-sci/{yyyy-mm-dd-hh-mm}/：

• plans/{collaborative_plan_pattern}
• The paper's final build artifacts, such as the project's existing PDF and Word outputs

It is prohibited to use the old directory .write-paper-sci/ and the earlier .write-paper/。

Validation

After completion, execute the Skill's existing static checks, script validation, or manual review, and record the pass criteria.

Failure and recovery

Preserve error evidence and completed artifacts; retry from the most recent failed step only after the input, environment, or external dependency has recovered.

Constraints

• Do not modify artifacts/、*.sty、*.cls、*.bst、*.bbx、*.cbx、latexmkrc
• Do not change main.tex structure unless the user explicitly requests it
• Do not fabricate numbers
• Do not downgrade abbreviation checking to "current file self-consistency"
• Do not allow the same concept to use conflicting abbreviations, conflicting full names, or definitions that appear and disappear across different tex files
• Do not arbitrarily create new abbreviations for local brevity; if a new abbreviation will not be stably reused throughout the text, prefer not to use it
• Do not rearrange unrelated paragraphs or entire sections for "tidy typesetting" .tex
• Do not write SCI main text as colon-driven colloquial explanations; colons are only used for genuinely necessary labels, lists, figure caption structures, or journal format requirements
• Do not, in Introduction repeatedly restate the same core viewpoint, pain point, or issue; each occurrence must serve a new logical advancement function
• When the user requests "only modify a certain section," strictly limit the scope of changes
• When the user requests collaboration mode, strictly prohibit directly modifying the paper

Common hard constraints

• When a task needs to be persisted to disk, use a unique ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/ root directory; shared materials go into shared/, and Skill-specific materials go into that Skill's input/、output/、log/。
• Formal deliverables, source code, and formal plans are saved according to project conventions and are not written to the task workspace; without authorization, do not overwrite, delete, migrate, or write remotely.
• Project maintenance changes check BAC availability and record requirements, AI outputs, tool results, file changes, and validation summaries; BAC only performs process auditing and does not replace attribution, responsibility, or compliance judgment.
• Do not record API Keys, access tokens, passwords, Cookies, environment/credential files, private Prompts, identity information, local usernames, hostnames, or unnecessary large volumes of raw data.
• File paths must be normalized and restricted to the authorized project scope; external URLs, subprocesses, and network access follow least privilege to prevent path traversal, SSRF, and command injection.
• The Skill version is recorded solely in its own config.yaml:skill_info.version; changes to public APIs, protocols, directories, or configurations are synchronized with the documentation and CHANGELOG.md。
• Only design flaws in the Skill or the Bensz infrastructure itself are reported to bensz-collect-bugs; first redact and write to ~/.bensz-skills/bugs/, the current task is not interrupted, and public reporting occurs only when the user explicitly requests it; directly modifying the source code of a Skill already installed by the user is prohibited.

Skill-specific constraints

Must not exceed the scope declared in this Skill's description and the process above; do not disguise unverified information as definitive conclusions.