mcpField
N
nsfc-benzi-audit

nsfc-benzi-audit

github.com/jiankang1991ドキュメント12362 回インストール2 週間前に更新
リポジトリ

nsfc-benzi-audit について

NSFC Benzi Auditは、国家自然科学基金(NSFC)の申請書草稿を診断・改訂するスキルです。各節の論理と根拠を整理し、実行可能な指摘を優先しながら、主張や要件を捏造しない方針です。

主な機能

  1. 01問い・目標・方法・検証の対応付け
  2. 02論理と根拠の不足の診断
  3. 03適用される書式や規則の確認
  4. 04過去の指摘の再評価
  5. 05優先度付きの改訂提案

活用シーン

  1. 01提出前のNSFC申請書草稿の診断
  2. 02過去の指摘が反映されたかの確認
  3. 03研究上の問いと検証の対応不足の特定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/jiankang1991/nsfc-benzi-audit --skill nsfc-benzi-audit

インストール後、Claude Code で/nsfc-benzi-auditを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE
agents/
openai.yaml
assets/
report-template.md
references/
audit-surfaces.md
benzi-logic.md
current-rules.md
exemplar-learning.md
geospatial-remote-sensing.md
information-communication.md
kd-lookup.md
medical-biomedical.md
question-distillation.md
representative-works.md
scripts/
nsfc_ack_grants.py

詳細

NSFC ベンジー監査

提供された草稿に基づき、申請者向けの診断と改訂アドバイスを作成します。実質的な論理の破綻、根拠の弱さ、影響の大きい修正点を明らかにします。文献、結果、プロジェクト履歴、予算、公式要件を捏造しないでください。

このワークフローでは、申請者向けの改訂アドバイスを行います。ユーザーが正式なコミュニケーションのレビューを依頼した場合は、その別個の作業範囲を明確にし、適切なレビュー用スキルが利用可能な場合に限り使用してください。草稿内部の診断に付随するスキルは不要です。

ワークフロー

  1. ソースを選択し、レビューの範囲を定めます。

    • ユーザーが明示的に指定したソースと改訂版を優先します。対象草稿、採択例、過去の報告書、テンプレート、メモは区別してください。Markdown ファイルの中で最も大きいものや、full.md/output.mdという名前のファイルを理由に草稿を選んではいけません。
    • 抽出済みテキストは、タイトル、改訂版、内容を選択した原本と照合してから再利用します。ソースのパス/バージョンと抽出の来歴を記録してください。複数の草稿が候補になり、区別できない場合は、どれを使用するかユーザーに確認してください。
    • PDF/DOCX の場合は、利用可能な抽出/OCR ツールを使い、見出しと表を保持してください。抽出手段がない場合は、その制約を明記し、提示されていて読める資料を用いて作業してください。存在しないツールをでっち上げたり、名前を指定した付随スキルを必須としたりしてはいけません。
    • 視覚的な論理や根拠(予備的な結果を含む)を評価する際は、元の図を確認してください。変換された Mermaid/OCR は権威ある情報源ではありません。抽出の欠落は重大な制約ですが、申請者がその内容を記載していない証拠ではありません。
    • 申請年度、正確なプロジェクト区分(判明している場合は青年 A/B/C を含む)、申請書のバージョン/出典、資金管理方式(包干制/予算制/要確認)、研究属性、申請コード、ソースの完全性を記録します。過去の例の年度と対象年度は分けて扱ってください。
    • 質問、目標、方法は、どの箇所に記載されている場合でも分析の観点として扱います。該当する申請書の様式で必須の場合に限り、個別の見出しを求めてください。年度または様式が不明な場合も内容の診断を続け、ルールの適用可否は未確定と明記してください。
    • 簡易レビューでは、タイトル、要約、科学的な問い、研究内容、独創性、研究基盤に重点を置きます。完全な診断では、提供された全セクションを対象とします。特定範囲の依頼(1 章、1 つの問いなど)は、その範囲内にとどめます。添付資料がないことや抜粋が省略されていることを、元の申請書における確定的な欠陥として報告してはいけません。
    • 長文または複数ファイルの草稿では、読み進めながらセクション/ページの位置情報と、位置情報を添えた指摘候補の一覧を記録してください。終了前に未解決の候補だけを再確認し、読み取れなかったソースの範囲があれば報告してください。
  2. 関連する参考資料を読みます。

    • 論理の診断、文章作成の助言、および各指摘で用いる「シグナル → 反対検証 → 評価」の表については、必ず references/benzi-logic.md を読みます。
    • 書式、年度・カテゴリーの適合性、研究属性、申請コード、予算、倫理または研究公正の要件を判断する前に、references/current-rules.md を読みます。ここには2026年を基準とした日付付きの情報が記載されています。対象年度と段階の規則を確認してください。
    • 全体的な診断、図、検証、年度計画、成果、予算、文献または書式の確認には、references/audit-surfaces.md を読みます。
    • 問いの出典と抽象化の質、または「独創性/独自の切り口/ボトルネック/学際性/分野横断の類推」の主張については、references/question-distillation.md を読みます。その強い形式は、草案が実際にその主張をしている場合に適用します。すべての草案で必須の見出しではありません。
    • 草案に代表的な研究業績が列挙されている場合、または刊行物を根拠としている場合は、references/representative-works.md を読みます。提供されたPDFを優先し、その後、利用可能なDOI/出版社/プレプリント検索ツールを使います。文献・引用検索スキルは、インストールされていれば任意で連携できます。書誌情報の確認、要旨の閲覧、研究手法全体の確認を区別し、根拠が未確認の項目は未核实と記録します。
    • テーマの重複、コードの調整、成果の比較、または申請者が依頼した自身の研究との重複確認には、references/kd-lookup.md を読みます。ポータルでの検索は申請者が実施します。ログインやCAPTCHAを自動化してはいけません。重複確認では、まず scripts/nsfc_ack_grants.py を実行し、論文の謝辞に記載された進行中の批准号を候補として絞り込みます。網羅性について主張する前に、モジュール、検索語、年度欄、日付、エラー/該当なしの状況、件数を記録します。
    • 採択・成功事例や申請書サンプルを用いた改善については、references/exemplar-learning.md を読みます。状況が合致する事例、匿名化したパターン、他の案件に適用する際の限界を用い、対象の申請書に事実や特徴的な表現を転載してはいけません。
    • 情報科学、通信、ネットワーク、応用AI、セキュリティ、量子通信、または関連する情報工学については、references/information-communication.md を読みます。
    • リモートセンシング、GIS、SAR/InSAR、光学/ハイパースペクトル画像、DEM/地形、点群、空間データベース/グラフ、軌跡、ビデオGIS、または都市の3Dモデルについては、references/geospatial-remote-sensing.md を読みます。
    • 医学、コホート/検体、疾患メカニズム、細胞/動物/オルガノイドモデル、バイオマーカー、介入、倫理、またはバイオセーフティについては、references/medical-biomedical.md を読みます。
    • ユーザーが別の形式を指定していない限り、報告書の構成を調整する際は assets/report-template.md を使用します。
  3. 論理と根拠の対応関係を整理します。

    • 対象/シナリオ、問題/目標、方法/道筋、独創性、検証、期待される意義を抽出し、タイトル、要旨、研究背景、内容、目標、問い、研究計画、基礎の各項目を通じて追跡します。
    • 該当する場合は、実際の研究属性と、過去の科学的問いに関する記述を含めます。異なる版の書式を混同してはいけません。
    • 問い・内容・目標・検証の間に、多対多の対応関係を整理します。項目数の不均衡ではなく、対応する問いがない項目や、科学的な役割が説明されていない作業を指摘します。補助的な手法や検証作業が、同じ問いに対応する場合もあります。
    • 問いの出典(文献、理論、観察、自身の研究、需要)と、申請者がその問いに取り組む能力を区別します。申請者自身の貢献、利用可能なリソース、予備的な根拠を、分野に適した形で評価します。筆頭著者のSCI論文や事前実験を一律に必須とする基準は設けません。
  4. ファイルまたはチャットで以前のレポート/リストが提示されている場合は、過去の所見を再確認します。

    • まず、同じ申請書に関するものか照合します。以前の各必改項目について、新しい本文と該当する根拠/規則の両方を確認してから、通常どおり現行の草稿を診断します。旧 ID は維持し、新たな問題には未使用の ID を付与し、統合または分割した項目は相互参照します。
    • 已解决/部分落实/仍存在/改动无效/原意见撤销或不再适用/材料不足无法判断を使用します。撤回、対象範囲の変更、根拠の不備について説明します。旧項目を黙って削除したり、以前のレポートに記載されているという理由だけで誤った所見を維持したりしてはいけません。
  5. 影響度に基づいて診断し、具体的な対応策を示します。

    • 新規性、研究の道筋、申請者の貢献、研究資源を評価します。これらは診断の観点であり、固定された採点基準や採択予測ではありません。
    • 参照フラグを積極的に活用します。これらは審査員が繰り返し問題視する点を示しています(タイトルと要旨の乖離、研究の根拠が収束していない、内容を目的として記述、作業にとどまる研究課題、実質のない「首次/填补空白」、装飾的な修飾語、説明のないテーマの切り替え、定量化されていないボトルネック、具体化されていない類推)。該当する点はすべて候補として扱い、benzi-logic.md の反証確認を行ったうえで、必改/待核实/建议改/可润色に分類します。
    • 必改:重要な問いに答えていない、研究の中核的な革新性を裏付けていない、研究範囲に欠落がある、重要な手順が実行不可能である、タイトル/要旨で約束した内容を本文で実現していない、または公式ルール違反が確認された場合。建议改:審査員が気づく可能性の高い、セクション単位の構成や根拠の弱さ。可润色:表現や見せ方の好みに関する提案です。項目数、見出しの書式、図の数だけで必改にはしません。
    • 根本原因となる問題ごとに、変更しない ID を1つ付与し、説明をまとめます。セクションごとの注記ではその ID を参照します。各所見では、該当箇所/短い引用、懸念される影響、最小限の具体的な修正案を示します。公式要件として確認済みの事項、論理/根拠に関するリスク、表現上の提案を区別します。所見を水増ししてはいけません。必改項目がない草稿もあり得ます。
    • 事実関係の確認を前提とした修正用のひな型を、プレースホルダー付きで提示し、架空の結果や申請書にそのまま使える主張は作りません。提案する表現には、申請者による確認が必要であることを明記します。
  6. レポートを作成し、根拠の履歴を保持します。

    • 既定のファイル名は 本子诊断报告.md とし、選択した草稿と同じ場所に保存します。そうできない場合はチャットで回答します。既存レポートを置き換える前に、一意の日付/改訂版ファイル名で保存し、どの旧レポートと比較したかを記録します。
    • 対象範囲、全体評価、1ページの論理マップ、優先順位を付けた所見一覧、該当する場合は過去の指摘の再確認、必改項目の書き換え用ひな型を含めます。完全な診断では、対応表(不足している項目のみ)と、実際に確認した観点ごとの1行ステータスも簡潔に付けます。所見一覧にすべての説明をまとめ、他の各セクションは1行の判定にとどめます。所見一覧以外で同じ ID を複数回記載してはいけません。ユーザーから求められた場合に限り、章ごとの注記を付けます。ユーザーが短い回答(1段落、1章、チャットメッセージ)を求めた場合は、その長さに合わせます。診断の深さとレポートの長さは別々に調整します。
    • 任意のセクションは関連する場合に限り記載します。各観点について、已核查/部分核查/未核查/不适用を、根拠の範囲、参照元、日付とともに記録します。制約事項は実際に行った作業に基づいて記載し、定型の免責事項をそのまま転記してはいけません。
    • 指示がない限り、簡体字中国語で記述します。助言は申請者向けとし、引用は根拠となる短い箇所に限ります。必改と可润色は区別します。

コメント