lieflat-gongwen: a Chinese official-document writing skill built on 1.02 million characters of corpus statistics

What lieflat-gongwen solves, and the seven document types it refuses to cover

Most Chinese official-document tooling gives you templates and stock phrases: open with 根据……为……, close with 请遵照执行. This repository starts from the opposite premise. It counts what real documents actually do across 1.02 million characters of corpus, and the README reports that the template assumptions mostly fail against that data: 依据式 openings are only 6 to 8 percent, 75 to 87 percent of endings are natural closings rather than set formulas, and 60 to 72 percent of documents use no percentages at all. If the common advice is wrong that often, a template is not a neutral starting point.

The skill therefore targets only document types that have no fixed structure, split into two families. The 公文族 covers six types: 调研报告, 领导讲话, 工作意见, 经验材料, 工作方案 and 经验总结, with a median length of 2,500 to 3,700 characters and 2 to 5 first-level headings. The 党建族 covers one: thousand-character party-building and grassroots experience material, around 1,120 characters, with zero first-level headings, carried instead by verb-led paragraph openers and quoted speech from workers or residents. The README states plainly that the skill does not do 通知, 请示, 批复 or 函, because those have fixed bodies and there is no style left to distil. That exclusion is the honest part of the design: a statistics-driven style tool has nothing to add where the structure is already mandated.

How the parameters work: corpus statistics, a parameter card, and a self-check that only fails on hard conflicts

The mechanism is a measured parameter line per document type. The README lists the stable commonalities first: average sentence length of 53 to 56 characters, roughly half of all sentences being long, and a 顿号 density of 14 to 31 per thousand characters, four to five times that of self-media writing. The claim is that gongwen holds long sentences together with A、B、C、D enumerations, and that this is its strongest linguistic fingerprint. Type-level differences then become the discriminator: the 一是二是 construction differs sixfold between 工作意见 and 调研报告, and 工作方案 is the only type that uses large numbers of third-level headings.

Each type also has a skeleton formula and a DNA document under 公文语料/ or 党建语料/. Step 3 of the workflow requires reading the DNA document and a sample before writing anything, and the README calls this the dividing line between this skill and template tools, on the grounds that abstract parameters cannot explain how parallel elements stack or where a transition sentence belongs.

The self-check script is deliberately loose. scripts/check_params.py flags only hard conflicts, meaning a type-identification error such as giving a 工作方案 the heading hierarchy of a 调研报告. Everything else is advisory. The stated reason is that real good documents vary widely: the 一是二是 count in 调研报告 ranges from 0 to 20, a quarter of the corpus never uses it, and when the best examples were run through the checker one by one, none landed inside the common range on every parameter. The README's conclusion is that good writing is not tidy and tidy writing is often mediocre, so the script does not treat the mean as a pass line.

Installing the skill and running the six-step workflow

The README recommends using it inside Moxt, where workspace context helps with repeated reads and sentence-level rewriting of long documents. It also gives a local install path for Claude Code, and says you can drop the whole directory into your agent's skills directory. Core capability has no dependencies, and the self-check script uses only the Python standard library.

git clone <this-repo> ~/.claude/skills/lieflat-gongwen

The README writes the remote as a placeholder rather than a URL, so substitute the actual clone URL from the repository page. After cloning, the agent's entry point is SKILL.md, and the workflow has six steps.

1  判文体族 → 判文种 → 定参数行
2  读对应文种的骨架公式
3  读同文种的 DNA 文档 + 范文     ← 不可跳过
4  出骨架，停下等确认
5  按参数写正文
6  跑自检，按报告修正

Step 4 is a stop-and-confirm gate: the agent produces an outline and waits. Step 6 runs the checker. The README does not document the exact invocation, but the repository layout puts the checker at scripts/check_params.py, so a first run against a finished draft is the natural entry point.

python scripts/check_params.py

Expect a report that separates hard conflicts from advisory deviations. One more detail worth knowing before you write: the sample 工作方案 in the README contains 【待补：xx】 placeholders in the body. The README says these are intentional, not unfinished text. They mark spots where local figures belong, and the skill places a placeholder rather than inventing a number when it cannot verify one.

The corpus is not distributed, and the parameters cannot check whether you are right

The most concrete limitation is stated by the README itself: the corpus was removed in full for copyright reasons and does not ship with the skill, so no third party can directly re-verify the frequency numbers. That is a real defect, not a documentation gap. You are asked to trust statistics you cannot reproduce.

Sample depth is uneven. 工作方案 has 10 samples and 经验总结 has 8, which the README calls thin and says makes their parameters reference-only. The other types are not quantified in the README, so there is no way to tell from the repository's own description how deep their samples are.

The method has a known weak link. Feature extraction uses regular expressions, which match literal strings rather than parse meaning, and the README calls this the weakest part of the chain. Five statistics were overturned by independent review because of vocabulary defects: for example, 数字命名法 was corrected from 84 percent to 60 percent after quantifier contamination, and 群众归因 from 30 percent to 9 percent. The shared failure shape is that an operator's coverage is wider than the rule's definition, and the frequency number itself does not reveal that gap. The rule the authors drew from it is worth repeating: treat any keyword statistic above 80 percent coverage as contaminated until you check the hits one by one.

Finally, and most important for adoption: parameters answer whether a document looks like the type, not whether it is correct. The README states that content soundness and political phrasing are outside what the parameters can verify, and that classified material and external messaging must go through the unit's own reviewer. If you want a tool that tells you a draft is right, this is the wrong tool. It tells you a draft is shaped like a 调研报告 rather than a 工作方案.

How this differs from template-based gongwen tools and from general-purpose writing assistants

The obvious alternative is the template-and-phrasebook approach: hand the model a fixed opening, a fixed closing, a list of set expressions, and let it fill the middle. The difference is not cosmetic. A template encodes one assumed structure and applies it to every document, which is exactly the behaviour the corpus statistics contradict: no single opening strategy dominates, most documents close naturally, and the heading length that suits a 工作方案 (4 to 8 characters, a business label) is wrong for a 调研报告, where the README reports first-level headings average 17 characters and carry a judgement plus a turn.

A general-purpose writing assistant sits at the other end. It can produce fluent Chinese, but it has no parameter line for a document type and no checker, so nothing distinguishes a 工作方案 from a compressed 调研报告 except the user's own eye. The README's example of a type-identification error, giving a 工作方案 the hierarchy of a 调研报告, is precisely the failure that neither templates nor a general assistant will catch.

The cost of this approach is setup. You must route to the right family and type before writing, read the DNA document and a sample, and accept a stop-and-confirm gate in the middle. That is more work per document than pasting a template. The README's position is that the work is the point, because abstract parameters cannot convey how parallel elements stack. Whether that holds for your documents is something only your own drafts will show.

Licence, maintenance and what upgrading costs you

The licence is PolyForm Noncommercial 1.0.0, and the README is explicit that this is source-available, non-commercial software rather than OSI open source. Non-commercial use, modification and redistribution are permitted, and the README counts personal research, study, experiments, educational institutions, public research institutions and government agencies as permitted non-commercial uses. Selling the project is not allowed, nor is using it for paid writing or consulting, nor integrating it into a commercial product or service. Redistribution or adaptation must carry the licence or a link to it. Commercial use requires separate written permission from the author. Note the mismatch: the repository's licence field reads NOASSERTION while the README points at LICENSE for PolyForm Noncommercial 1.0.0, so confirm the terms with the author before relying on either. That is a factual observation about the repository, not legal advice.

On maintenance, the last push was on 2026-09-05 and the repository is not archived, so the codebase has moved recently. There are no retrieved releases, so there is no version history to upgrade against. Upgrading means pulling the branch again into your skills directory, and the cost of a pull is the possibility that the parameter card or a DNA document changed under a draft you already wrote. The self-check script depends only on the Python standard library, so there is no dependency surface to manage and no lockfile to reconcile. The real upgrade cost is re-reading 参数卡.md and the DNA documents after a pull, because those files, not the script, are where the style targets live.

Editorial conclusion

Adopt it if you write the seven non-templated gongwen types in Chinese and want an agent to hit measured style targets rather than fill a template; the parameter card and check_params.py give you something to verify against. Do not adopt it if you need notices, requests, replies or letters, if you need commercial rights, or if you expect the parameters to judge whether the content is correct. Verify first that your agent reads SKILL.md as its entry point, and confirm with the author what the NOASSERTION licence field means before you rely on the PolyForm Noncommercial 1.0.0 text in LICENSE.

Frequently asked questions

Official sources

1. Issues
2. larashero3-dotcom/lieflat-gongwen on GitHub
3. README