SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsnsfc-abstract

nsfc-abstract

Writing & research

View repository

Updated 10-15 17:06

About this skill

NSFC Chinese-English Abstract Generator

Input (ask for information first; ask about whatever is missing)

Preferably have the user provide information according to the information table (see skills/nsfc-abstract/references/info_form.md). If the user has only given scattered information, first use 3-6 questions to fill in the most critical gaps:

  • Which category would you like the title to lean toward: "mechanism-oriented / method-oriented / translation-oriented / scenario-oriented"? (If unsure, you may not choose; by default, mixed candidates will be provided.)
  • What is the research object/scenario? (disease/material/system/task)
  • What are the field's pain points and unresolved scientific questions? (one sentence)
  • What are your key preliminary findings/pilot experiments/data points? (1-2 items, may be quantitative)
  • What is the scientific hypothesis/core judgment to be tested? (one sentence)
  • For the 3-4 research content points, what is to be done respectively, what methods will be used, and what verifiable results will be obtained?
  • What is the expected scientific significance/application value? (avoid empty talk)

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

  • When a bug caused by a design flaw in this skill appears in the user's environment, preferentially use bensz-collect-bugs to record it according to the specification in ~/.bensz-skills/bugs/; 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 continue to complete the user's task through a workaround, it should first record the bug, then continue to complete the current task.
  • When the user explicitly requests a public reporting action such as "report bensz skills bugs", call the local gh and bensz-collect-bugs, and upload only newly added bugs to huangwb8/bensz-bugs; do not pull / clone the entire bug repository.

Goal: write a five-sentence abstract that "reviewers can understand at a glance", achievingimportance、scientific question、feasibility evidence、research content、scientific significanceall five elements complete; and output a consistent English translation.

Length proportion principle: senior reviewers want to see the applicant "get to the point" as soon as possible; excessive background setup is a signal of insufficient professionalism. The target proportions for each sentence are as follows (compress if exceeded):

Sentence Function Target proportion
① Background Ticket to entry ≤ 15%
② Scientific question Locate the gap 15–20%
③ Preliminary research Establish credibility 20–25%
④ Research content Main body 35–40%
⑤ Significance Close the loop 10–15%
  1. Importance/background（≤ 15%）：Strictly 1 sentence, pointing out the importance of the research object and the core bottleneck, without expanding into a background review.
  2. Scientific question(15-20%): point out the key unknowns and current deficiencies (specific to gaps in mechanism/metrics/causal chain).
  3. Feasibility evidence (preliminary research)(20–25%): Provide 1-2 preliminary findings/pilot experiments (quantitative where possible), and accordingly propose a scientific hypothesis/core judgment.
  4. Research content (3-4 points)(35–40%): Start with verbs, and clearly state "what to do → how to do it → what to verify/what criteria to obtain" (the number of points defaults to config.yaml:limits.content_points_min/max ); this sentence is the main body of the abstract and should receive the most space.
  5. Significance/value(10–15%): Summarize the expected contribution (scientific mechanism + method/strategy/application potential), forming a closed loop with the problem in sentence 2.

When the user explicitly requires hard constraints such as "Chinese ≤400 characters/English ≤4000 characters", the closed loop must be followed:First detect, then compress, then detect again, and only write after it passes。

  1. First generate a "readable but possibly over-limit" draft (with all five-sentence elements complete).
  2. Use a deterministic script to detect (must use --json, letting hardcoding handle precise counting):
    • python3 skills/nsfc-abstract/scripts/validate_abstract.py - --json --diff --strict
    • Input can be via stdin (no need to write a file first), or after writing to NSFC-ABSTRACTS.md , validate the file.
  3. If over-limit: perform compression according to the "compression priority", then return to step 2, for at most 3 rounds.
  4. If still over-limit after 3 consecutive rounds: stop automatic compression, explain the current overage to the user (ZH/EN exceeded), and ask the user to choose:
    • Allow deletion of certain information (which can be deleted)
    • Relax the character limit (modify config.yaml）
    • Manually provide a shorter summary of key information (for example, keep only the most critical 1 piece of evidence + 3 points of research content)

Compression priority (from top to bottom)

  • P0 (must be retained): research object/key scientific question gap/quantitative evidence (if any)/core method name/expected contribution closed loop
  • P1 (prioritize streamlining): degree adverbs, adjective modifiers, "we will/this study" subjects, procedural descriptions, prepositional phrases such as "through/using", repeated parallel expressions
  • P2 (prioritize deletion): the portion of background exceeding 15% (compress first), empty evaluations ("significant/important/leading" etc. without quantitative support), repeated sentences, background expansion unrelated to the scientific question

If deterministic writing/validation is needed, a script can be used:

  • Write:python3 skills/nsfc-abstract/scripts/write_abstracts_md.py <input> --strict
  • Validate:python3 skills/nsfc-abstract/scripts/validate_abstract.py NSFC-ABSTRACTS.md --json --diff --strict

Output

  • Both Chinese and English must be provided; English is afaithful translationof the Chinese (no expansion, no new assumptions, no introduction of new results).
  • The Chinese abstract uses Chinese punctuation。
  • Hard quotation mark constraint (cannot be bypassed): If quotation marks are needed in the Chinese abstract,the only legal formis Chinese curly quotation marks ” (U+201C) and ” (U+201D). The following formsare all prohibited: ASCII double quotes ”, full-width quotation marks ＂, corner brackets 「」 / 『』, single quotes ' / ', and any other alternative forms.
  • The Chinese abstract body is plain text: it must not contain Markdown markers (**、*、_、# , etc.), because the user will directly copy the body into a system that only supports plain text.
  • Numbers in the Chinese abstractdo not use thousands separators: write 1000, not 1,000 or 1，000。
  • A "Main Research Field" must be provided: placed after the English abstract,one sentence(number of Chinese characters ≤ 25), concisely expressing the core research direction; it must not be written as multiple items or a list.
  • When writing into NSFC-ABSTRACTS.md ,leave no blank line between the end of the Chinese abstract body and the English abstract section heading。
  • Title suggestions must be provided: follow the "winning title" structural preference of skills/nsfc-abstract/references/title-rules.md ; include at least:
    • 推荐标题：...(Chinese)
    • Recommended Title: ...(English, on the line immediately below the recommended title)
    • 1) ... —— 理由：... / EN: ...(at least 5 items; the number is subject to config.yaml:title.title_candidates_default ; each item ends with an English translation)
  • Chinese abstract: default ≤ 400 characters (including punctuation); 5 sentences recommended (subject to config.yaml:limits.zh_recommended_sentences ), with 1 function per sentence.
  • English abstract: ≤ 4000 characters (including punctuation); grammatically correct and consistent in terminology.
  • Do not use exaggerated/marketing-style expressions (such as "internationally leading/filling a gap/first of its kind") unless the user provides verifiable evidence and explicitly requests that they be retained.
  • Do not pile up background or list methodological terms; each method term must serve "what is to be verified."

Write in the following format into NSFC-ABSTRACTS.md(the title text is subject to config.yaml:output.zh_heading/en_heading ). At the end, provide a length self-check (character counting basis: count after collapsing consecutive whitespace into a single space, including punctuation):

# 标题建议
推荐标题：...
Recommended Title: ...
1) ... —— 理由：... / EN: ...
2) ... —— 理由：... / EN: ...
3) ... —— 理由：... / EN: ...
4) ... —— 理由：... / EN: ...
5) ... —— 理由：... / EN: ...

# 中文摘要
（正文）
# English Abstract
(translation)
# 主要研究领域
（一句话，≤ 25 个汉字）

### 输出管理

本 Skill 的新任务中间文件统一写入 `./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/`。同一任务复用一个任务根目录；多 Skill 协作才创建 `shared/`。正式交付物不写入该目录，历史隐藏目录只允许显式兼容读取、迁移或清理。

### 校验

- 中文摘要字符数：N/400
- 英文摘要字符数：M/4000

After writing the file, in the conversationdo not repeatedly paste the full text(unless the user explicitly requests it); only report:

  • The file path written (default ./NSFC-ABSTRACTS.md）
  • Whether the number of title candidates meets the default requirement
  • Chinese/English character counts and whether they exceed the limit

Failure and recovery

Retain 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 execute 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; 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 stored per project conventions and are not written into the task workspace; do not overwrite, delete, migrate, or write remotely without authorization.
  • 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 volumes of 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 solely 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 defects in the Skill or Bensz infrastructure itself are submitted to bensz-collect-bugs; first desensitize and write into ~/.bensz-skills/bugs/, the current task is not interrupted, public reporting is only done when the user explicitly requests it, and it is forbidden to directly modify the user's installed Skill source code.

Skill-specific constraints

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