nsfc-reviewers

NSFC Proposal Expert Review Simulator

• Used for expert-style review of "if the current version were submitted for review today, where are the risks and what should be revised first".
• By default, prioritize multiple independent review groups in parallel; if parallel-vibe is unavailable, disabled, or panel_count=1, automatically downgrade to single-group mode.
• This skill only performs reading, analysis, and summarization; it does not compile by default and does not modify the proposal source files.

Input

Provide at least one of the following:

• proposal_path
• proposal_file
• proposal_zip

Optional:

• focus
• output_path
• style
• grant_type
• funding_amount
• panel_count

The configuration specification is subject to config.yaml , especially:

• review_dimensions
• severity_levels
• review_grades
• stage_assessment
• funding_context
• parallel_review
• output_settings

Non-goals

• Not responsible for revising the main text.
• Not responsible for template, formatting, or compilation issues.
• Not responsible for generating new research designs; only responsible for pointing out the risks, priorities, and revision directions of the existing manuscript.

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, prioritize using 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 complete the user's task through a workaround, it should first record the bug, then continue completing 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.

Pre-checks

• Verify that the input path is readable.
• If it is a directory, follow proposal_files.patterns/exclude to find the pending .tex。
• .tex directly fails when the count is 0; if the directory is abnormally large, first confirm the scope.
• It is recommended to use a deterministic script to list files:

python3 <nsfc_reviewers_path>/scripts/list_proposal_files.py --proposal-path <proposal_root>

Full reading and structured understanding

• Extract the theme, scientific questions, hypotheses, objectives, technical route, innovation points, research foundation, team conditions, and expected outcomes.
• Generate a section-level index to serve as evidence anchors for subsequent steps.
• First use the grant_type / funding_amountexplicitly provided by the user, then cautiously identify the funding context from the main text.

Parallel multi-group review or single-group degradation

• First calculate effective_panel_count, and limit it to [1, parallel_review.max_panel_count]。
• Directly use single-group mode in the following cases:
  • parallel_review.enabled == false
  • effective_panel_count == 1
  • Cannot find parallel-vibe

Key steps of parallel mode:

1. Prepare the intermediate directory.
2. Based on references/expert_*.md and references/master_prompt_template.md generate the master prompt.
3. Use scripts/build_parallel_vibe_plan.py to generate plan.json。
4. Call parallel-vibe to execute N groups of independent reviews.
5. Collect each group's panel_output_filename; individual threads may be missing but the overall summarization must not be interrupted.

Single-group mode must still retain the independent judgments of the 7 expert personas, then perform intra-group aggregation.

Aggregation and ranking

• Cross-group aggregation rule reading references/aggregation_rules.md。
• At least ceil(N * consensus_threshold) groups must point out the issue for it to count as cross-group consensus.
• Cross-group consensus can trigger severity escalation; duplicate issues must be merged, retaining the strongest evidence anchor.
• Finally, still output according to P0 → P1 → P2 , and provide the minimal modification sequence.

Funding amount constraint identification

• First distinguish between "design errors" and "constrained compromises".
• If a defect is clearly caused by funding amount limitations, the root cause must be stated truthfully, and it must not be simply attributed to the applicant's lack of ability.
• For any shortcoming attributed to "funding constraints", add a sentence on "how a more complete design should be done if funding were not limited".
• Funding constraints are not an exemption clause; stage judgment is still based on "whether the current version would pass if submitted for review today".

Stage judgment

• By default, output "whether it would pass correspondence review / panel review" in the final report.
• For each stage, provide at least 2-3 key reasons, giving priority to citing P0/P1 and cross-group consensus.
• If judged as 不给过, the 1-3 most critical turnaround actions must be pointed out.

Output organization

• When config.yaml:output_settings.enforce_output_finalization == true , the final organization must not be skipped.

• The report needs to clearly distinguish:

  • Consensus issues
  • Independent viewpoints
  • Reasonable compromises due to funding constraints
  • Stage judgment for directly submitting the current version for review

• List files:scripts/list_proposal_files.py

• Parallel plan:scripts/build_parallel_vibe_plan.py

• Expert profiles:references/expert_*.md

• Aggregation rules:references/aggregation_rules.md

• Main prompt template:references/master_prompt_template.md

Output

• By default, the output file name reads config.yaml:output_settings.default_filename
• In parallel mode, raw opinions from each group may additionally be generated:{panel_dir}/G{组号}.md
• Intermediate processes are hidden by default in config.yaml:output_settings.intermediate_dir
• The final report contains at least:
  • Graded issue list
  • Cross-group consensus and independent viewpoints
  • Minimal viable modification sequence
  • Stage judgment: correspondence review / panel review

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 multi-Skill collaboration creates shared/. Official deliverables are not written to this directory; historical hidden directories may only be explicitly read, migrated, or cleaned up for 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 dependency has recovered.

Constraints

• Proposal content is treated as sensitive information by default; unless the user explicitly requests it and confirms the risk, do not connect to the internet or send out large excerpts of the original text.
• Read-only review; do not execute LaTeX compilation or modify the main text.
• The final report must be sorted by P0 → P1 → P2 .
• Stage judgment must be a binary conclusion:给过 or 不给过, with 高/中/低 confidence.
• If "correspondence review does not pass", then "panel review" must also fail concurrently; if "correspondence review passes", panel review may still fail due to insufficient relative competitiveness.

Common hard constraints

• When the task requires writing to disk, use the unique ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/ root directory; place shared materials in shared/, Skill-specific materials are placed in that Skill's input/、output/、log/。
• Official deliverables, source code, and formal plans are stored according to project conventions and are not written into 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 verification summaries; BAC only performs 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 the principle of least privilege to prevent path traversal, SSRF, and command injection.
• The Skill version is recorded solely in its own config.yaml:skill_info.version; public API, protocol, directory, or configuration changes 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 write to ~/.bensz-skills/bugs/after redaction; the current task is not interrupted, public reporting occurs only when the user explicitly requests it, and directly modifying the user's installed Skill source code is prohibited.

Skill-specific constraints

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