nsfc-reviewers

NSFC 申請書の専門家審査シミュレーター

• 「現在の版を今日提出した場合、どこにリスクがあり、何を先に修正すべきか」を専門家の視点で審査します。
• デフォルトでは複数グループによる独立審査を優先します。parallel-vibe を利用できない、無効化されている、または panel_count=1 の場合は、自動的に単一グループモードに切り替えます。
• このスキルでは読み取り、分析、集約のみを行います。デフォルトではコンパイルせず、申請書のソースファイルも変更しません。

入力

次のいずれかを最低1つ指定してください。

• proposal_path
• proposal_file
• proposal_zip

任意：

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

設定の基準は config.yaml に従います。特に次の項目に注意してください。

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

対象外

• 本文の修正は行いません。
• テンプレート、レイアウト、コンパイルの問題には対応しません。
• 新たな研究設計は作成せず、既存原稿のリスク、優先順位、修正方針の指摘のみを行います。

手順

入力

ユーザーの依頼と設定ファイルに基づいて必要な入力を指定します。不足情報は明示し、その入力に依存する手順を停止してください。

実行手順

• ユーザー環境で本スキルの設計上の欠陥に起因するバグが発生した場合は、まず bensz-collect-bugs を使用し、規定に従って ~/.bensz-skills/bugs/ に記録してください。ユーザーのローカル環境にインストール済みの Claude Code / Codex のスキルソースを直接変更することは厳禁です。
• AI が回避策を用いてユーザーのタスクを続行できる場合は、まずバグを記録してから現在のタスクを完了してください。
• ユーザーが「report bensz skills bugs」などの公開報告を明確に要求した場合は、ローカルの gh と bensz-collect-bugs を呼び出し、新規バグのみを huangwb8/bensz-bugs にアップロードしてください。バグリポジトリ全体を pull / clone しないでください。

事前確認

• 入力パスが読み取り可能か確認します。
• ディレクトリの場合は、proposal_files.patterns/exclude に従って審査対象の .tex を特定します。
• .tex の数が 0 の場合はその時点で失敗とします。ディレクトリが異常に大きい場合は、先に対象範囲を確認します。
• ファイル一覧の作成には、決定性のあるスクリプトの使用を推奨します。

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

全文の読解と構造化

• テーマ、科学的問題、仮説、目標、技術的アプローチ、独創性、研究基盤、チーム体制、期待される成果を抽出します。
• 以降の根拠を示すため、章ごとの索引を作成します。
• まずユーザーが明示した grant_type / funding_amount を使用し、その後、本文から資金提供に関する背景を慎重に特定します。

複数グループによる並列審査または単一グループへの切り替え

• まず effective_panel_count を計算し、[1, parallel_review.max_panel_count] の範囲に制限します。
• 次の場合は直接、単一グループモードに切り替えます。
  • parallel_review.enabled == false
  • effective_panel_count == 1
  • parallel-vibe が見つからない

並列モードの主な手順：

1. 中間ディレクトリを準備します。
2. references/expert_*.md と references/master_prompt_template.md に基づいて master prompt を生成します。
3. scripts/build_parallel_vibe_plan.py を使用して plan.json を生成します。
4. parallel-vibe を呼び出し、N グループによる独立審査を実行します。
5. 各グループの panel_output_filename を収集します。一部の thread が欠けていても、全体の集約は中断しないでください。

単一グループモードでも、7 人の専門家のプロフィールに基づく独立した判断を維持したうえで、グループ内で集約します。

集約と順位付け

• グループ間の集約ルールは references/aggregation_rules.md から読み込みます。
• 少なくとも ceil(N * consensus_threshold) グループが指摘した問題を、グループ間の共通見解とみなします。
• グループ間の共通見解に基づき重要度を引き上げることができます。同じ問題は統合し、最も強い根拠のアンカーを残します。
• 最終出力は必ず P0 → P1 → P2 の順とし、最小限の修正手順を提示します。

資金額による制約の特定

• まず「設計上の誤り」と「制約による妥協」を区別します。
• 欠陥が明らかに助成金額の制限に起因する場合は、根本原因を正確に記載し、単純に申請者の能力不足に帰属させてはいけません。
• 「資金制約」が原因とする弱点については、「資金に制約がなければ、より完全な設計をどのように行うべきか」を必ず補足します。
• 資金制約は免責事項ではありません。段階判定では引き続き、「現在の版を今日提出して通過できるか」を基準とします。

段階判定

• デフォルトでは最終レポートに「書面審査／会議審査を通過するか」を出力します。
• 各段階で少なくとも 2～3 件の重要な理由を挙げ、P0/P1 およびグループ間の共通見解を優先して引用します。
• 「不通過」と判定した場合は、逆転に最も重要な 1～3 件の対応を必ず示します。

出力の整理

• config.yaml:output_settings.enforce_output_finalization == true の場合、最終整理を省略してはいけません。

• レポートでは次の項目を明確に区別する必要があります。

  • 共通見解の問題
  • 独立した意見
  • 資金制約による妥当な妥協
  • 現在の版をそのまま提出した場合の段階判定

• ファイル一覧：scripts/list_proposal_files.py

• 並列計画：scripts/build_parallel_vibe_plan.py

• 専門家プロフィール：references/expert_*.md

• 集約ルール：references/aggregation_rules.md

• マスタープロンプトテンプレート：references/master_prompt_template.md

出力

• デフォルトの出力ファイル名は config.yaml:output_settings.default_filename から読み込みます。
• 並列モードでは、各グループの生の意見を追加で生成できます：{panel_dir}/G{组号}.md
• 中間処理はデフォルトで config.yaml:output_settings.intermediate_dir に隠して保存します。
• 最終レポートには少なくとも次の項目を含めます。
  • 重要度別の問題一覧
  • グループ間の共通見解と独立した意見
  • 最小限の実行可能な修正手順
  • 段階判定：書面審査／会議審査

出力管理

本 Skill の新しいタスクで生成される中間ファイルは、すべて ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/ に保存します。同じタスクでは 1 つのタスクルートディレクトリを再利用し、複数 Skill が連携する場合にのみ shared/ を作成します。正式な納品物はこのディレクトリに保存しません。過去の隠しディレクトリは、明示的な互換読み込み、移行、または削除の場合に限り使用できます。

検証

完了後、本 Skill に既存の静的チェック、スクリプト検証、または手動確認を実行し、合格基準を記録します。

失敗と復旧

エラーの証拠と完了済みの成果物を保持します。入力、環境、または外部依存関係が復旧した後に限り、直近の失敗手順から再試行します。

制約

• 申請書の内容はデフォルトで機密情報として扱います。ユーザーが明確に要求し、リスクを確認しない限り、インターネットへの接続や大量の原文の外部送信を行いません。
• 審査は読み取り専用とし、LaTeX のコンパイルを実行せず、本文も変更しません。
• 最終レポートは必ず P0 → P1 → P2 の順に並べます。
• 段階判定は「通過」または「不通過」の二択とし、確信度を 高/中/低 で併記します。
• 「書面審査が不通過」の場合、「会議審査」も必ず不通過とします。「書面審査が通過」の場合でも、相対的な競争力が不足していれば会議審査は不通過となる可能性があります。

共通の必須制約

• タスクの成果物をディスクに保存する必要がある場合は、一意の ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/ ルートディレクトリを使用します。共有資料は shared/ に、Skill 固有の資料はその Skill の input/、output/、log/ に保存します。
• 正式な納品物、ソースコード、正式な計画はプロジェクトの取り決めに従って保存し、タスク作業ディレクトリには保存しません。許可なく上書き、削除、移動、またはリモートへの書き込みを行ってはいけません。
• プロジェクトの保守変更では BAC の利用可否を確認し、要件、AI の出力、ツールの結果、ファイル変更、検証の概要を記録します。BAC はプロセス監査のみを行い、著者表示、責任、コンプライアンスの判断に代わるものではありません。
• API Key、アクセストークン、パスワード、Cookie、環境／認証情報ファイル、非公開 Prompt、個人を特定できる情報、ローカルユーザー名、ホスト名、または不要な大容量の生データを記録してはいけません。
• ファイルパスは正規化し、許可されたプロジェクトの範囲内に制限します。外部 URL、サブプロセス、ネットワークアクセスには最小権限を適用し、パストラバーサル、SSRF、コマンドインジェクションを防止します。
• Skill のバージョンは自身の config.yaml:skill_info.version にのみ記録します。公開 API、プロトコル、ディレクトリ、または設定に変更がある場合は、ドキュメントと CHANGELOG.md も併せて更新します。
• bensz-collect-bugs に報告できるのは、Skill または Bensz インフラストラクチャ自体の設計上の欠陥に限ります。まず情報を秘匿化して ~/.bensz-skills/bugs/ に書き込み、現在のタスクを中断してはいけません。公開報告はユーザーが明確に要求した場合のみ行い、ユーザーがインストール済みの Skill ソースを直接変更してはいけません。

Skill 固有の制約

本 Skill の description および上記の手順で定めた範囲を超えてはいけません。未検証の情報を確定的な結論として示してはいけません。