transfer-old-latex-to-new

ChineseResearchLaTeX Content Migration Skill

Input Principles

Do not require the user to first organize input into a fixed input protocol. By default, accept and digest any reasonable input, for example:

• A complete old project directory
• Several .tex / .bib / .docx / .md / .txt
• PDFs, screenshots, images
• An existing template project path, plus some migration goal description
• Multiple types of input appearing mixed together

If the material is incomplete, do not first ask about a "standard input"; first determine the target product line, a suitable host project, which content can be placed directly into extraTex/*.tex or references/*.bib, and which requests already exceed the boundary of content migration. Only request additional information when missing information would cause the body text to be placed in the wrong position.

Output Principles

Do not interpret the output as "arbitrarily restructuring the repository". The valid outputs of this skill are usually only:

• Migrate the body text into the target project's extraTex/*.tex
• Migrate the references into the target project's references/*.bib
• Generate the necessary migration notes, risk warnings, and a list of items not yet placed
• Provide verification results after a successful build

The following actions are all beyond the boundary of this skill: template source code changes, style fixes, structural rewrites of the wrapper / main.tex / template.json / README, as well as public package extraction or package-level capability accumulation. By default, treat the user's original material as read-only and the target template as a read-only skeleton; only report style differences, do not secretly modify them.

The Role of the Legacy CLI

scripts/run.py、scripts/migrate.sh is still retained, but only as a fallback entry point for classic old/new directory migration. Even when using the legacy CLI, the hard boundaries of this document must continue to be observed: the old project may be read, the new project may only have its content layer written, and the CLI must not be used to bypass template protection.

Inapplicable Scenarios

Do not continue to use this skill to directly implement the following scenarios:

• The user wants to "make a new template"
• The user wants to "replicate the old style 1:1 into the current repository"
• The user wants to modify packages/bensz-*、projects/* the template entry points or style files in
• The user wants to add template host sites, cover structures, table of contents structures, profiles, classes, or styles

These should all be handed over to the template development chain.

Process

Input

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

Execution Steps

This skill still needs to identify the target product line, but the purpose is only to select the correct host project, not to determine "whether to modify packages/”。

• NSFC: select an appropriate projects/NSFC_*
• SCI paper: select projects/paper-sci-01/
• Graduation thesis: select the closest projects/thesis-*
• Resume: select projects/cv-01/

Then map the body text content from the old material into the content files of these ready-made projects; by default, prefer the closest existing project rather than creating a new one or reorganizing the template structure.

Identify the target product line and host project

First answer three questions: which product line the user should ultimately land on, which existing project in the current repository is most suitable as the hosting container, and whether this task is "content migration" or has already become "template development". If it has already become template development, hand it off immediately; do not continue pretending it is a content migration task.

Inventory migratable content

From the input, extract body paragraphs that can be directly reused, BibTeX, gaps that require manual confirmation, and out-of-scope requests that would trigger template modification requirements.

Do content-layer mapping

Only do mapping at the content layer:

• Old body text → extraTex/*.tex
• Old references → references/*.bib

Do not understand "mapping" as:

• Changing section commands
• Changing template title styles
• Changing the table of contents/cover/headers and footers
• Changing public package interfaces

Execute migration

During execution, only overwriting target content files, creating target content files (if the template already has a corresponding hosting slot), and writing or completing .bib。

If a requirement can only be completed by changing the template skeleton, do not continue making automatic modifications; clearly mark the blocked location and reason, and recommend switching to make-latex-model。

Official entry-point verification

After migration is complete, verify using the official entry point of the corresponding product line whenever possible:

• NSFC：python packages/bensz-nsfc/scripts/nsfc_project_tool.py build --project-dir <项目路径>
• SCI：python packages/bensz-paper/scripts/paper_project_tool.py build --project-dir <项目路径>
• Thesis：python packages/bensz-thesis/scripts/thesis_project_tool.py build --project-dir <项目路径>
• CV：python packages/bensz-cv/scripts/cv_project_tool.py build --project-dir <项目路径> --variant all

If the build fails and the cause comes from a gap in the template skeleton, do not modify the template without authorization; report it truthfully.

Read this file first. When legacy CLI details are needed, then check:

• scripts/README.md
• references/quickstart.md
• references/config_guide.md
• references/api_reference.md

When confirming boundaries, always prioritize following:

• Only migrate content, do not change the template skeleton
• Only report style differences, do not secretly change them

Output

Output the deliverables promised by the Skill description, and clearly specify the format, path, and failure return form.

Output management

Intermediate files for new tasks of this Skill are uniformly written to ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/. Reuse one task root directory for the same task; create shared/only for multi-Skill collaboration. Formal deliverables are not written to this directory; historical hidden directories may only be explicitly read, migrated, or cleaned up for compatibility.

This skill does only one thing: migrate content such as body text and references from old materials into an existing template project in the current repository 's content layer.

It is not a template development skill, nor a public package refactoring skill. Any task that requires changing template source code, styles,packages/bensz-*、projects/* skeleton files,main.tex、@config.tex、.cls、.sty, profiles, styles, or build scripts should be handed off to make-latex-model or the template development process of the corresponding product line.

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 dependencies have recovered.

Constraints

When handling tasks, you must always comply with:

• Never modify packages/ any public package source code, template implementation, profile, style, script, or shared resource under
• Never modify projects/ any template styles, entry skeletons, wrappers,main.tex、extraTex/@config.tex、.cls、.sty, Lua/Python build scripts under
• Content may only be placed in existing content-layer locations of the target project
• If the existing template has no suitable hosting slot, do not modify the template just to accommodate the content; instead, explicitly report "insufficient template slots, template development skill intervention required"

The only content layers writable by default in the current repository are extraTex/**/*.tex(excluding extraTex/@config.tex) and references/**/*.bib。

Unless the configuration whitelist of this skill is explicitly opened up in the future, all other paths are treated as read-only.

Common hard constraints

• When a task requires writing to disk, use the unique ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/ root directory; place shared materials in shared/, and place Skill-specific materials in that Skill's input/、output/、log/。
• Formal deliverables, source code, and formal plans are saved according to project conventions and are not written into 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 verification summaries; BAC is only for process auditing and does not replace attribution, responsibility, or compliance judgments.
• Do not record API Keys, access tokens, passwords, Cookies, environment/credential files, private Prompts, identity information, local usernames, hostnames, or unnecessary large 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 uniquely 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 Bensz infrastructure itself are handed over to bensz-collect-bugs; first write a sanitized entry to ~/.bensz-skills/bugs/, the current task is not interrupted, public reporting occurs only when the user explicitly requests it, and directly modifying the source code of a Skill already installed by the user is prohibited.

Skill-specific constraints

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