SuperAPI AI Directory

nsfc-research-foundation-writer

Writing & research

View repository

Updated 10-15 19:47

About this skill

NSFC (3) Research Foundation arrangement writer

Target output (contract)

  • Write destinations (2 files):
    • extraTex/3.1.研究基础.tex(including "Response Measures for Research Risks")
    • extraTex/3.2.工作条件.tex
  • Modification prohibited:main.tex、extraTex/@config.tex, any .cls/.sty
  • Core objective: Use an "evidence chain + condition correspondence + risk contingency plan" to answer the reviewers' three questions: Have you done it? Can you accomplish it? How do you provide a fallback if problems arise?

Parameters and output modes (explicit provision recommended)

  • project_root: proposal project root directory (e.g., projects/NSFC_Young)
  • output_mode(default apply):
    • preview: only output two copyable LaTeX main text drafts (and indicate the target file paths where they should be written), without writing to files
    • apply: only write the two target files (see "Target output"), without touching other files

Required input (minimum information table)

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, give priority to using bensz-collect-bugs to record it according to the specification in ~/.bensz-skills/bugs/, and it is strictly forbidden to directly modify the source code of an already installed skill 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 a public reporting action 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:
    • Verify whether project_root exists; if it does not, report an error and prompt the user to specify the correct path
    • Check whether the extraTex/ directory exists; if it does not, prompt the user to first initialize/copy the template project; if necessary, it may be created after user confirmation
    • Confirm project_root and output_mode(default is apply)
      • preview mode: only generate a content preview, do not write to files (suitable for debugging)
      • apply mode: write the generated content to extraTex/3.1.研究基础.tex and extraTex/3.2.工作条件.tex
    • Only edit these two files; modification of main.tex、extraTex/@config.tex, any .cls/.sty
  2. Generate 3.1 研究基础(evidence chain first):
    • Research accumulation: around the key tasks of 2.1 , list "what has been done/what is mastered/what existing platform is available".
    • Staged achievements: only write verifiable content (papers/patents/data/prototypes/preliminary experimental phenomena); use placeholders for uncertain details and ask the user to fill them in.
    • Four dimensions of feasibility: provide 1-3 supporting points each for theory/technology/team/conditions, and align them item by item with the research content.
  3. In 3.1 , explicitly write "Response Measures for Research Risks":
    • At least 3 risks (at least 1 each for technical/schedule/resource)
    • Each item: risk description → early signal (trigger threshold/phenomenon) → contingency/alternative route (including degraded objectives and deliverables)
  4. Generate 3.2 工作条件(conditional mapping to research content):
    • Conditions already in place: list them one by one; suggested format:
      • Platform: XXX platform (already available / accessible)
      • Data: XXX dataset (already obtained / publicly available)
      • Samples: XXX hospital/institution (cooperation agreement signed / ethics approval in progress)
      • Computing power: XXX server / GPU (already configured / shared use)
      • Team division of labor: Member A is responsible for XX, Member B is responsible for YY
      • Compliance path: ethics approval (XXX committee, cycle X months)
    • Conditions still lacking and solutions: list them one by one; suggested format:
      • Missing condition: XXX (impact: YYY)
      • Solution: procurement / cooperation / alternative data source / experiment degradation plan
      • Timeline and responsible person: if provided by the user, write it in; if not provided, mark with a placeholder
  5. Consistency check:
    • Check 1: check whether 3.2 工作条件 can support item by item 2.1 's key tasks
      • Method: list 2.1 's each key task, and confirm 3.2 has corresponding condition support
      • Example:
        • Task 1: XXX experiment → conditions: XXX platform, XXX samples
        • Task 2: YYY algorithm → conditions: YYY computing power, ZZZ data
    • Check 2: check whether the risk contingency plans are compatible with the annual plan
      • Method: list 2.3 's annual milestones, and confirm the risk contingency plans have corresponding degradation plans
      • Example:
        • Year 1: sample acquisition → risk: slow sample enrollment → contingency: alternative data sources and degraded validation plan
    • Handling when the check fails:
      • If inconsistency is found, mark it as [需补充:XXX] and prompt the user
      • If the user has not provided 2.1 or 2.3, skip the corresponding check and prompt the user

Q1: There is no extraTex/ directory in the project directory. What should I do?

A: It is recommended to first confirm that project_root points to the correct proposal project root directory; if it is indeed missing extraTex/, please create it manually:

mkdir -p "<你的project_root>/extraTex"

Q2: I have not yet written 2.1 研究内容. Can I directly write 3.1 研究基础 ?

A: Not recommended.3.2 工作条件 needs to align with 2.1 's key tasks. It is recommended to first use nsfc-research-content-writer to complete 2.1。

Q3: What should I do if some content in the information table is not convenient for me to disclose?

A: You can provide "verifiable clues" instead of the complete content. For example:

  • ❌ "We published paper XXX in Nature"
  • ✅ "We have published related papers (verifiable clues such as DOI/bibliographic record/acceptance letter number can be provided)"

Q4: Must 3 risk response items be written?

A: Yes, at least 3 items (at least 1 each for technical/progress/resources). Even if you think the risk is low, it is recommended to write 1 item for each of the three categories as "low risk + monitoring signal + contingency plan," to avoid reviewers thinking you lack a fallback mindset.

Q5: My information table has very little content. Can a complete research foundation be generated?

A: Yes. AI will generate content based on the information you provide, and will use placeholders where uncertain (e.g., [请补充:XXX]), which you should complete later.

  • The change history of this skill is recorded in this directory's CHANGELOG.md, and synchronized to the root-level CHANGELOG.md;SKILL.md only maintains the "AI Execution Specification."

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/. The same task reuses one task root directory; multi-Skill collaboration only creates shared/. Formal deliverables are not written to this directory; historical hidden directories only allow explicit compatibility reading, migration, or cleanup.

Validation

Quality contract validation (from config.yaml)

  • The research foundation must cover:
    • Research accumulation related to this project (evidence chain)
    • Phased results already achieved (verifiable)
    • Feasibility points (theory/technology/team/conditions)
    • Research risks and countermeasures (explicitly stated)
  • Working conditions must cover:
    • Conditions already available (platform/data/samples/computing power/team/compliance)
    • Conditions still lacking and solutions (time/budget/collaboration/procurement/alternatives)

Detailed checklist

See:references/dod_checklist.md

Optional script self-check (read-only)

  • Only validate the skill's own structural consistency:python3 skills/nsfc-research-foundation-writer/scripts/validate_skill.py
  • Also check a project's output files (existence + lightweight content heuristics):python3 skills/nsfc-research-foundation-writer/scripts/run_checks.py --project-root <你的project_root>

Failure and Recovery

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

Constraints

  1. Only edit the two extraTex/3.*.tex files; must not modify main.tex、extraTex/@config.tex, any .cls/.sty
  2. If the target file already contains a heading command (e.g., \\subsection{...} / \\subsubsection{...}),Only replace the body content, without changing the title and structural hierarchy
  3. When information is incomplete, ask questions first to fill the gaps; do not fabricate "real-looking" details such as paper titles/journals/patent numbers/sample sizes/metrics

Common Hard Constraints

  • When a task requires writing to disk, use a 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 saved 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 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 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。
  • Report only design flaws in the Skill or Bensz infrastructure itself to bensz-collect-bugs; first redact and write to ~/.bensz-skills/bugs/, the current task is not interrupted, public reporting occurs only when the user explicitly requests it, and directly modifying the source code of a Skill already installed by the user is prohibited.

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.