Paper Format Adapter

Overview

Transform a manuscript so its layout conforms to an externally supplied set of
formatting rules. The skill works in two stages:

1. Extract the rules from the requirements document into a single normalized
   JSON "spec".
2. Apply that spec to the paper, choosing the applier that matches the
   paper's file format.

It supports three paper formats (.docx, .tex, .md) and reads requirements
from .pdf, .docx, .md, .txt, or pasted text. Reformatting covers page
setup, body text, headings (H1–H6), title, abstract, captions, and the
reference list / citation style.

Note: The requirements parser is heuristic (keyword + regex), not an LLM. Always
confirm the extracted spec with the user before applying — see
references/extraction_patterns.md.

When to use

• "按这个格式要求改一下我的论文" / "format my paper to these guidelines"
• "把这个稿子改成 IEEE 模板要求" (guidelines supplied as a file)
• "参考文献按 GB/T 7714，正文用宋体小四" (rules given as text/checklist)
• Any task where a manuscript must be re-styled to match an uploaded spec.

Do not use for: content editing, translation, or plagiarism checks — this
skill only changes layout/formatting.

Workflow

Step 1 — Collect inputs

Identify the two artifacts:
- The requirements document (PDF/DOCX/MD/TXT, or pasted text).
- The paper to reformat (DOCX / TEX / MD).

If the requirements arrive as pasted text, save them to a .txt file first
(e.g. requirements.txt) so the parser can read them.

Step 2 — Parse requirements → spec

Run the parser:

python scripts/parse_requirements.py REQUIREMENTS_FILE -o spec.json
# or from pasted text:
cat requirements.txt | python scripts/parse_requirements.py - -o spec.json

This prints a human-readable summary. Read references/format_spec_schema.md
to understand every field.

Step 3 — Confirm the spec with the user

Show the summary. Pay special attention to meta.unrecognized (rules the
parser could not map) and any null values. Ask the user to confirm or supply
the missing numbers. A ready-to-edit template lives at
assets/requirements_template.json. The user may also hand-edit spec.json
directly. See references/extraction_patterns.md for limitations.

Step 4 — Apply the spec

Pick the applier by the paper's format:

# Word
python scripts/format_docx.py paper.docx spec.json -o paper_formatted.docx

# LaTeX (safe, guarded preamble edits + bibliographystyle)
python scripts/format_latex.py paper.tex spec.json -o paper_formatted.tex

# Markdown (normalizes headings/refs; optional styled DOCX via Pandoc)
python scripts/format_markdown.py paper.md spec.json -o paper_formatted.md --docx paper_formatted.docx

Step 5 — Report & hand back

Summarize what changed (page, margins, fonts, spacing, heading styles,
reference style, citation normalization) and flag anything left manual — e.g.
deeply custom per-figure styling or in-text citation rewrites beyond the
conservative patterns. Present the output file(s) to the user.

Scripts

Dependencies

The scripts need python-docx, pdfplumber, and a PDF fallback (pypdf /
PyPDF2). Install in an isolated venv:

python -m venv .venv && .venv/bin/pip install -r requirements.txt

The Markdown→DOCX styled output additionally requires Pandoc on PATH; if
absent, only the normalized Markdown is produced.

References

• references/format_spec_schema.md — full spec field reference.
• references/extraction_patterns.md — what the parser recognizes and its
  limits; how to handle unrecognized rules.
• assets/requirements_template.json — fillable starting spec.

Notes & caveats

• null in the spec means "leave as original"; appliers only override non-null
  fields.
• For Chinese papers set a CJK body.font (e.g. SimSun, SimHei) so the
  East-Asian font mapping is correct.
• DOCX in-text citation rewriting is conservative ((n) → [n] only); LaTeX
  \cite commands are left to the author.
• LaTeX edits are additive and guarded by a marker comment — re-running never
  duplicates the injected block.