nsfc-research-content-writer

NSFC (2) Research Content Arrangement Writer

Target Output (Contract)

• Write Destinations (3 files)：
  • extraTex/2.1.研究内容.tex
  • extraTex/2.2.特色与创新.tex
  • extraTex/2.3.年度研究计划.tex
• Prohibited Changes：main.tex、extraTex/@config.tex, any .cls/.sty
• Arrangement Principles: First write 2.1 as a "verifiable closed loop", then extract innovation points from 2.1 to generate 2.2, and finally split the tasks of 2.1 into three-year milestones to generate 2.3。

Parameters and Output Modes (Explicit Provision Recommended)

• project_root: Proposal project root directory (e.g., projects/NSFC_Young）
• output_mode(default apply）：
  • preview: do not write directly to files; output three copy-pasteable LaTeX main text drafts, and mark the target file paths they should be written to
  • apply: only write the three target files (see "Target Output"), without touching other files

Required Inputs (Minimum Information Table)

• If the user does not provide them, first collect/complete:references/info_form.md

Process

Input

Provide the necessary inputs 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 prohibited to directly modify the installed skill source code in the user's local Claude Code / Codex.
• If the AI can still 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 public reporting actions such as "report bensz skills bugs", call the local gh and bensz-collect-bugs, and only upload newly added bugs to huangwb8/bensz-bugs; do not pull / clone the entire bug repository.

1. Locate the project and target files: confirm project_root, read and edit only the three extraTex/2.*.tex files; if the target files do not exist, prompt the user to first initialize/copy the template project.
2. Fix the "sub-goal trio": split the goal into 3-4 sub-goals (during internal planning, S1–S4 numbering may be used for self-check traceability,this numbering is only for AI internal planning and is prohibited from appearing in the final LaTeX main text), and for each sub-goal forcibly write clearly:
   • Indicators (judgeable/acceptable)
   • Comparison/baseline (compared with whom, how to compare)
   • Data source/verification plan (samples/experimental system/evaluation method)
3. Generate 2.1 研究内容(with the main line of "problem → goal → content → route → verification"):
   • Length control principles(recommended values, not mandatory):
     • Recommended page count: 12-15 pages (including figures and tables), about 50% of the total proposal page count (≤28 pages)
     • Recommended word count: 12000-15000 words (pure text portion)
     • Figure and table strategy: inserting 10-20 figures usually does not significantly compress the text length; figures are an important means of "quality improvement"
     • Core principle: The review criteria have shifted from "word count control" to "page count control"; do not plan the length based on word count.
   • Organizational logic framework (choose according to research type): The new version no longer presets an outline; you may organize it autonomously according to the internal logic of the research:
     • Recommended framework for basic research:科学问题提出 → 研究假说 → 验证思路 → 预期结果
     • Recommended framework for applied research:技术瓶颈 → 解决方案 → 实验设计 → 效果验证
     • General main line (fallback):问题 → 目标 → 内容 → 路线 → 验证
   • Research question and overall objective (no more than 2 paragraphs, using coherent paragraphs rather than bullet points)
   • Research content and task development (driven by scientific narrative, naturally weaving the verification logic into the writing, rather than filling in the three-piece set item by item)
   • Technical route and verification criteria (comparison/ablation/external validation/leakage prevention and control/statistical methods, integrated into the narrative rather than listed separately)
4. From 2.1 extract 2.2 特色与创新：
   • 1–3 items are sufficient; fewer but better(The research report emphasizes: the number of innovation points is not what matters; persuasiveness is); each item should start from "why this choice is inevitable," clearly explaining the limitations of existing routes, how this project differs, and what this difference is expected to bring—so that reviewers feel the researcher has truly thought it through, rather than filling in an innovation point template.
   • Avoid absolute wording (such as "first" or "leading"); if it is truly necessary to use it, verifiable evidence must be provided or it must be rewritten as a relatively phrased statement that can withstand review.
5. From 2.1 derive 2.3 年度研究计划(three years without crossing years):
   • Each year: annual objectives → key tasks → milestones (verifiable) → deliverable outcomes (papers/data/prototypes/specifications/software, etc.)
   • Milestones must be tied to sub-goals (otherwise reviewers will think "the plan is disconnected from the research content")
   • Progression logic: Let reviewers see the dependencies and progressive rhythm of the research—why this is done first in the first year, and why that can be done in the second year (avoid the流水账 [running account] of "basic research in the first year; in-depth research in the second year; summary in the third year")
6. Consistency check：
   • Check whether the 2.2 innovation points can be traced back to the specific tasks and verification of 2.1 ;
   • Check whether the 2.3 milestones cover all sub-goals and whether there are deliverables every year.
   • Terminology alignment: research objects/abbreviations/metric naming should be kept as consistent as possible with （一）立项依据、（三）研究基础 (if already present in the project)
   • Output purification: Before finally writing into the .tex file, confirm that the main text does not contain any S1/S2/Sx/Ty/Vz or other internal planning numbers; if the corresponding relationship needs to be expressed, use natural language instead (such as "for the first research objective")
7. User reminder after task completion：
   • It is recommended to place the technical roadmap at the beginning of the research content.

Two-stage working mode：

• Planning stage(internal, not written into the main text): Use the three-piece set, S1–S4 numbering, and verification criteria menu to think through the research logic clearly, ensuring that every objective has indicators, comparisons, and data sources.
• Writing stage(output to .tex): Switch to narrative mode. Melt the conclusions from the planning stage into coherent paragraphs, so that readers feel the researcher has truly thought it through, rather than filling out a form.

Core characteristics of expert writing：

• There is a scientific story主线: readers can perceive the internal logic of "why do this, why do it this way, and how to prove it was done right," rather than three parallel bullet points.
• The validation logic is part of the narrative: not "validation plan: control/ablation/external validation," but rather naturally explaining, while describing the research content, that "we will compare ... with ... to rule out the interference of ...".
• The innovation points are convincing: not filling in the formula "relative to A, the difference lies in X, expected Y," but rather starting from the problem and clearly explaining why the existing route does not work and why this project's choice is inevitable.
• The annual plan reflects the logic of progression: not filling in a three-year four-level structure, but letting reviewers see the dependencies and progressive rhythm of the research—why do this first in the first year, and why that can be done in the second year.

One criterion: After writing, show the main text to a peer who does not understand this project. Can they naturally understand the logic of this research without looking at any framework annotations? If so, the writing is successful.

• Example of the sub-goal "three-piece set":references/subgoal_triplet_examples.md

• Example of the innovation point "relative coordinate system":references/relative_coordinate_examples.md

• Annual plan template (ensuring milestones are verifiable):references/yearly_plan_template.md

• Minimum structural skeleton of the three output files (copy-paste ready):references/output_skeletons.md

• Reference for research content length control (pages/word count/figure and table strategy):references/page_budget.md

• Common writing anti-patterns and rewrites:references/anti_patterns.md

• Validation scope menu (control/ablation/external validation/statistics/leakage prevention and control):references/validation_menu.md

• Terminology alignment table (consistent across chapters):references/terminology_sheet.md

• This skill does not maintain a change history within this document; it is uniformly recorded at the root level CHANGELOG.md。

Output

Output the deliverables promised by the Skill description, and specify the format, path, and failure return form.

Output management

Intermediate files for new tasks of this Skill are uniformly written to ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/. Reuse one task root directory for the same task; create shared/only when multiple Skills collaborate. Official deliverables are not written to that directory; hidden historical directories are only allowed to be explicitly read for compatibility, migrated, or cleaned up.

Validation

• See:references/dod_checklist.md

Failure and recovery

Preserve error evidence and completed artifacts; retry from the most recent failed step only after the input, environment, or external dependency has recovered.

Constraints

1. Only edit three extraTex/2.*.tex files; must not modify main.tex、extraTex/@config.tex, any .cls/.sty
2. If the target file already contains a title command (such as \\subsection{...} / \\subsubsection{...}），only replace the body content, do not change the title or structural hierarchy
3. If information is incomplete, ask questions first to fill it in; do not force writing with details that "look true"

Common hard constraints

• When a task needs to be written to disk, use a 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/。
• Official deliverables, source code, and official plans are stored according to project conventions and are not written to the task workspace; do not overwrite, delete, migrate, or write remotely without authorization.
• Project maintenance change checks BAC availability and records requirements, AI outputs, tool results, file changes, and validation summaries; BAC only performs 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 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 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。
• Report only design flaws in the Skill or the Bensz infrastructure itself to bensz-collect-bugs; first redact and write to ~/.bensz-skills/bugs/, the current task is not interrupted, only report publicly when the user explicitly requests it, and it is forbidden to directly modify the source code of a Skill already installed by the user.

Skill-specific constraints

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