chinese-thesis-workbench treats a real project as the raw material for a thesis

Evidence as the input rather than the conclusion

The README opens by ruling out the obvious use. This is not a tool that generates a thesis in one click. It is a standardization workbench that breaks a dissertation into reviewable, reversible steps: collect material, choose a delivery path, build evidence, confirm the outline, write chapter by chapter, produce the DOCX, then run quality checks.

That framing explains the feature tables. Material intake grades what it finds as required, recommended or optional, and states the impact of each gap and whether work can continue. Project evidence extraction builds an index from source code, databases, APIs, tests and experiment data according to the thesis type. Literature governance runs PDF reference extraction into a candidate pool, then verification, then formatting, then a verification checklist.

The AIGC style governance row is the one that tells you the intended audience. The stated goal is to reduce vague phrasing and to avoid fabricating facts, which is a direct response to the problem of generated Chinese academic prose. A skill that is otherwise generous about fetching things stops short of adding an unverified reference to the bibliography.

The five control files written under paper-context/workflow are the visible side of this. user-dashboard.md holds progress and next steps, material-inventory.md grades the inputs, content-decisions.md records what became body text, what became an appendix and what was dropped, blocker-report.md explains stalls, and user-decisions.md archives what you confirmed, including the delivery path. For a process run by an AI assistant on your behalf, that audit trail is the feature.

Why M3 keeps your university's template intact

Version 1.0.0 introduced four DOCX delivery paths, and they are chosen during intake and written into user-decisions.md. The differences are about who owns the formatting.

M1 generates a brand new .docx from Markdown using a built-in default style, described as SimSun for body text at size four and SimHei for headings. M2 is a lighter approximation that analyzes a sample paper and merges high-confidence font sizes, fonts and indentation into those defaults. M3 copies the school template's .docx and fills it. M4 edits an existing draft in place, changing only paragraph text.

The README is explicit that M3 is the recommended path for schools with strict formatting, and the reason is mechanical rather than cosmetic. It copies the template's OOXML base and only replaces placeholder text and inserts chapter bodies, leaving styles.xml, headers, footers and section breaks untouched. M2, by contrast, makes no promise to reproduce the template. M4 is the narrowest of the four, changing paragraph text while leaving pPr, rPr, sectPr and comments alone, and it errors out when an anchor matches zero times or more than once.

That anchor rule is a good sign. Silent near-misses in a replace operation would corrupt a draft invisibly, and refusing to proceed on an ambiguous match turns a formatting bug into a loud failure.

M3 also emits a report listing replaced placeholders, unmatched fields, chapter insertion points and items needing manual review, so you can see what the tool did not manage to match rather than discovering it after submission.

Getting the workspace running from a clean checkout

Setup is four steps and the third one is the part people skip. From a clean checkout:

pip install -r requirements.txt
python scripts/workspace/init_thesis_workspace.py <你的论文项目目录>

Then you edit the profile at thesis-ai-standard/templates/standard-profile.yaml inside your project directory, and load the skill in Claude Code with an instruction like asking it to organize the project into a structurally complete thesis. The badge at the top of the README marks this as a Codex skill, and the documented host is Claude Code.

The M3 template fill path is a separate sequence, and it starts by analyzing the template rather than writing to it:

python scripts/docx/analyze_docx.py 学校模板.docx --json-out result.json
python scripts/docx/apply_textual_edits.py --from-template 学校模板.docx \
  --thesis-md paper-output/<论文标题>.md \
  --spec thesis-ai-standard/templates/thesis-ai-spec.yaml \
  --out paper-output/<论文标题>.docx

The README states plainly that the original template file is not modified. M4 takes the same editing script in positional form instead, which is the shape to reach for when you have a draft from your supervisor and only want specific paragraphs changed:

python scripts/docx/apply_textual_edits.py draft.docx draft-edited.docx \
  --replace "原文锚点" "新文本" \
  --insert-after "锚点段落" "新增段落" \
  --delete "要删除的段落锚点"

Every deliverable is named after the thesis title, which keeps a multi-chapter rewrite from producing a directory of final-final-v2 files.

Four Python packages and a separate Node toolchain

The Python dependency list is short enough to read in one glance:

pdfplumber
pypdf
python-docx
PyYAML

Four packages, one per job. pdfplumber and pypdf cover PDF reference extraction, python-docx covers the DOCX side, and PyYAML covers the spec and profile files. Nothing here is a language model client, which is consistent with a skill that expects the host assistant to supply the writing.

Screenshots are a different toolchain. package.json declares Playwright as the only Node dependency and exposes two scripts:

"install:browsers": "playwright install chromium",
"capture:screenshots": "node scripts/screenshots/browser/capture_screenshots.mjs"

So the README's claim of Playwright-driven figure screenshots is accurate, and it also means a Python-only install cannot produce the screenshot assets. The figure pipeline accepts Mermaid, PlantUML and draw.io sources, and the assets directory ships six draw.io diagram templates.

Formula handling has the same either-or shape: keep LaTeX as text, or render it as an inserted image. Chapter word budgets are set before writing and counted afterward, with automatic compression when a chapter runs long.

For supervision feedback there is a dedicated path: extract the comments your supervisor left in the Word file, revise item by item, and record a change log. Combined with the repository's nine core contract tests, this is the part of the skill most oriented toward surviving a review cycle rather than producing a first draft.

Where the README's directory listing and the tree disagree

The repository name is chinese-thesis-workbench-skill. The README's own heading, the SKILL.md routing entry it points to, and the package.json name field all drop the suffix and call the thing chinese-thesis-workbench. Both are true at once, and the distinction is worth holding: the -skill name is how the repository is filed, while chinese-thesis-workbench is the artifact name used inside the project. Anyone installing or referring to it will use one or the other, so check which spelling a script expects before assuming a missing file.

The README also carries a directory section listing SKILL.md, README.md, requirements.txt, package.json, the references tree broken into workflow, standards, evidence, writing and delivery, the scripts tree broken into workspace, evidence, literature, docx, figures, screenshots and review, the assets templates and drawio directories, and tests. That listing has no agents/ entry. The repository tree at the top level does include one, alongside .gitignore, LICENSE, README.md, SKILL.md, assets/, package.json, references/, requirements.txt, scripts/ and tests/.

Neither the README nor the repository metadata resolves it. The operative test is simple: if you are looking for agent configuration, look in agents/ at the top level, and do not conclude it is absent because the README's directory section omits it.

There is a third naming detail. The repository records no homepage field, and the README's external links point at the badge host codex.claude.ai rather than at a project site. So this project has documentation inside the repository and SKILL.md, and nothing hosted alongside it.

Two releases on the same afternoon

The release history is two entries long. v0.1.0, described as the initial public release of the skill, published on 2026-05-07 at 13:16 UTC. v1.0.0, which added the M1 through M4 delivery modes along with sample-style generation, school-template copy fill, existing draft text edits, sparse-material handoff and expanded core contract tests, published the same day at 16:29 UTC.

Three hours separate them. Read together with the README's claim that four delivery paths arrive with version 1.0.0, the picture is a project that went public and reached its feature-complete form on the same afternoon, which is consistent with a long private build and a short public window rather than with a year of incremental releases. The last push was also on 2026-05-07.

The open issue count is 1 on a repository of 564 stars, which is unusually low and suggests very little public triage activity. The MIT licence and the LICENSE file at the top level are the terms to read if you intend to adapt the reference documents, and nothing in the README restricts use of the generated work.

One limitation is stated by the project itself. It is aimed at students with a real project, experiment or survey, and it explicitly says it does not fit someone who wants a thesis generated from nothing. For a purely humanities paper the process can be borrowed, but the evidence chain has to be rebuilt, which is the right warning given that the evidence index is the spine of the whole approach.

Editorial conclusion

This skill is built for the specific case where a student already has a finished project and needs a dissertation attached to it, and its strongest feature is the one that costs the most care to use: M3 copies the university template's OOXML base and only replaces placeholder text, which is why the school's styles, headers and section breaks survive. Two things to check before committing to it. First, a Python install is not enough on its own, because screenshots run through Playwright on the Node side. Second, the repository name carries a -skill suffix that the README, SKILL.md and package.json all drop, and the repository tree holds an agents/ directory the README's own listing leaves out, so treat the README directory section as a partial view. Install the dependencies, edit standard-profile.yaml, then decide M1 through M4 before any writing begins, because the choice is recorded in user-decisions.md and everything downstream follows it.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. ZyhSechub/chinese-thesis-workbench-skill on GitHub