SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsnsfc-length-aligner

nsfc-length-aligner

General & other

View repository

Updated 10-15 22:14

About this skill

nsfc-length-aligner

Applicable Scenarios

  • You have an NSFC proposal and want to quickly determine whether "some sections are too short/too long"
  • You need to align with the template's hard length requirements (page count/word count/character count)
  • You want to expand or compress while changing the original meaning as little as possible (maintaining the main argument line and evidence chain)

Not Applicable Scenarios

  • You only need "word count" without caring about budget and rewriting closed loop (a simpler script suffices)
  • The proposal is not local (text/file/path cannot be provided)

Process

Input

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

Execution Steps

  • When a bug caused by a design flaw of this skill appears in the user's environment, prioritize using bensz-collect-bugs to record it to ~/.bensz-skills/bugs/according to the specification; it is strictly forbidden to directly modify the source code of skills already installed in the user's local Claude Code / Codex.
  • If the AI can still complete the user's task via a workaround, it should first record the bug, then continue completing the current task.
  • When the user explicitly requests public reporting actions such as "report bensz skills bugs", call the local gh and bensz-collect-bugs, uploading only newly added bugs to huangwb8/bensz-bugs; do not pull / clone the entire bug repository.

Goal: turn "length" from a subjective feeling into a quantifiable, closed-loop metric, and guide expansion/compression around the budget.

Lock the hidden workspace (do this first)

  • Using the proposal working directory as the root, uniformly use <workdir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-length-aligner/ to host all intermediate files and reports
  • Do not write length_report.*, temporary analysis drafts, or planning files to the root level of the working directory or other locations in the repository
  • If --out-diris explicitly passed in, prioritize using the relative path .bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-length-aligner; the script will resolverelative --out-dir to the working directory corresponding to --input , rather than the shell's current directory
  • If the working directory itself is not writable, first switch to a writable copy before running; do not scatter intermediate files outside the project just for convenience

Requirement Confirmation (Budget Caliber)

First confirm what the "hard standard" is that you need to align with:

  • The "golden ratio" from 2026 research consensus (General Program/Young Scientists Fund Category C, for proofreading purposes): Project Basis 30% (6–10 pages, about 8000–10000 words) / Research Content 50% (12–15 pages, about 12000–15000 words) / Research Foundation 20% (5–8 pages, about 5000–6000 words); total recommended ≤28 pages to leave buffer (in principle no more than 30 pages)
  • Page count (hard constraint): After the 2026+ revision, "in principle no more than 30 pages"; in practice, ≤28 pages is recommended to leave buffer; do not "squeeze page count" by reducing font size/line spacing
  • Character budget (proxy metric): Chinese characters / total characters, etc., used for the deterministic closed loop of "rewrite → recheck" (the final page count is verified by PDF)
  • Budget range: total length + budget for each part/key chapter (covering at least: Project Basis/Research Content/Research Foundation)

Note: This skill defaults to using config.yaml:length_standard 'sexample caliber (already aligned with 2026 research recommendations)You should proofread according to the guidelines/template of the relevant year before use.

Run length check (deterministic)

Run the check script on the target proposal directory (or a single file) to generate a report:

python3 scripts/check_length.py --input <目标标书路径> --config config.yaml

If you need to explicitly declare the output directory, use:

python3 scripts/check_length.py --input <目标标书路径> --config config.yaml --out-dir .bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-length-aligner

If your proposal is based on the NSFC_Young / NSFC_General template (the project root directory contains main.tex), it is recommended to point --input to the project root directory: the script will automatically follow the main.tex of \input/\include dependency tree to collect "the files that will actually be compiled into the PDF", and ignore commented-out \input{...}(to avoid mistakenly counting optional sections toward the length).

If you have already compiled the final PDF (recommended; page count is a hard constraint), pass the PDF in as well for page count statistics:

python3 scripts/check_length.py --input <目标标书路径> --config config.yaml --pdf <标书.pdf>

Output:

  • Console summary (total length, over/under-budget items)
  • <input>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-length-aligner/length_report.md(default output directory; can be customized with --out-dir )
  • <input>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-length-aligner/length_report.json(default output directory; can be customized with --out-dir )

Note:--out-dir If a relative path is used, it will be resolved to the working directory corresponding to <input> ; this prevents the report from being mistakenly written to the shell's current directory when the command is started from another directory.

After the run is complete,mustread length_report.md(if necessary, also read length_report.json), and use the "file-level deviation table + (optional) section-level statistics" as the input for step 3.

Interpret the gap (where the difference lies)

Do 3 things based on the report:

  1. Locate the "overlong/too short" files or sections
  2. Determine whether the gap is:
    • Insufficient evidence chain (need to add data/comparison/limitations)
    • Logical leap (need to add transitions/definitions/assumptions)
    • Redundant repetition (need to merge/delete)
  3. Generate an action list (priorities for expansion/compression)

How to use section-level data (more precise localization):

  • If length_report.md contains a section table (or the JSON contains a sections field), prioritize locating the specific sections with the largest contribution within the "overlong/too short" files, and then make targeted rewrites, rather than only making average deletions and modifications at the file level
  • When a file is overlong/too short: compare its section statistics; if the gap is mainly concentrated in 1-2 sections, prioritize changing only these 1-2 sections (it is easier to preserve the original meaning and structural stability)

Reference:references/MEANING_PRESERVING_REWRITE_RUBRIC.md

Expansion/compression (try not to change the original meaning)

Expansion strategy (when too short)

  • First add "verifiable information density": definitions, assumptions, comparisons, ablations, risks, and alternative solutions
  • Then complete the "argumentation loop": why do it → how to do it → how to verify expectations → what to do if it fails
  • Avoid vague expansion: do not introduce new claims, do not pile up adjectives

Compression strategy (when too long)

  • Remove duplication: keep only the strongest expression of the same argument once
  • Remove background: compress general background into 1-2 sentences, and leave the space for "problem-method-verification"
  • Structural rewriting: split long paragraphs into bullet points (without changing the order of facts)

⚠️ After rewriting is complete,step 5 recheck must be performed, to confirm that the deviation has been eliminated. Failure to recheck is considered incomplete.

Usage (turn "static suggestions" into "triggered by gaps"):

  • First look at the deviation of the corresponding file in the report delta：+N indicates overly long (prioritize "trim");-N indicates too short (prioritize "thicken");OK indicates that this part does not need to be changed for budget reasons
  • delta the larger the absolute value, the higher the priority for handling; suggested handling order: first revise |delta| the largest file, then handle the next largest item

Project rationale (why do it):

  • Trim: textbook-style popular science, generalized overviews, weakly relevant "national needs" elaboration, repetitive significance, padding the literature
  • Thicken: Gap (blocking point) → Key Idea (breakthrough point) → value argument (why it is worth doing)

Research content (what to do / how to do it):

  • Trim: repeated statements, overly detailed operational details, list-style piling up of methods
  • Thicken: logical framework, key experimental design and controls/ablations, expected results and verifiable metrics, let figures speak

Research foundation (why you can do it):

  • Trim: piling up irrelevant achievements, excessive background buildup
  • Thicken: strongly relevant preliminary experimental data, core technical capabilities, platform conditions (aligned with the research content)

Recheck closed loop

After revising, you must run the script again to confirm "meets the standard and does not exceed it":

python3 scripts/check_length.py --input <目标标书路径> --config config.yaml
  • Do not reduce font size or line spacing to "squeeze the page count" (page count requirements are a review risk point)
  • Do not write all the way to 30 pages: it is recommended to keep a buffer of ≤28 pages
  • If the guidelines for that year require a statement on generative AI usage: be sure to explain truthfully as required (compliance item)

Output

  • The report is presented at the "file level + (optional) chapter level"
  • The budget uses config.yaml:length_standard as the single source of truth
  • Intermediate files are uniformly hosted in config.yaml:output_settings.intermediate_dir(default .bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-length-aligner）
  • All rewrites should follow the principle of "minimal changes, preserving the original meaning" (see references)

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 for multi-Skill collaboration is shared/created. Formal deliverables are not written to this directory; hidden historical directories may only be read, migrated, or cleaned up with explicit compatibility.

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

Comply with the following common constraints, and enforce this Skill's specific boundaries.

Common hard constraints

  • When a task requires writing to disk, use the unique ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/ root directory; put shared materials in shared/, and put Skill-specific materials in that Skill's input/、output/、log/。
  • Formal deliverables, source code, and formal plans are stored 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 is only for 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 raw data.
  • File paths must be normalized and restricted to within the authorized project scope; external URLs, subprocesses, and network access follow the principle of least privilege to prevent path traversal, SSRF, and command injection.
  • The Skill version is uniquely recorded 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 itself or the Bensz infrastructure are handed over to bensz-collect-bugs; first redact and write to ~/.bensz-skills/bugs/, the current task is not interrupted, public reporting is only done when the user explicitly requests it, and directly modifying the source code of a Skill the user has already installed is prohibited.

Skill-specific constraints

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