nsfc-research-content-writer

NSFC（二）研究内容编排写作器

目标输出（契约）

• 書き込み先（3 ファイル）：
  • extraTex/2.1.研究内容.tex
  • extraTex/2.2.特色与创新.tex
  • extraTex/2.3.年度研究计划.tex
• 変更禁止：main.tex、extraTex/@config.tex、すべての .cls/.sty
• 構成の原則：まず 2.1 を「検証可能な閉ループ」として書き、次に 2.1 からイノベーションの要点を抽出して 2.2 を生成し、最後に 2.1 のタスクを3年間のマイルストーンに分解して 2.3 を生成します。

パラメーターと出力モード（明示的な指定を推奨）

• project_root：申請書プロジェクトのルートディレクトリ（例：projects/NSFC_Young）
• output_mode（デフォルトは apply）：
  • preview：ファイルには直接書き込まず、コピーして貼り付けられる LaTeX 本文の草稿を3つ出力し、書き込み先のファイルパスを明記します
  • apply：指定された3つのファイル（「目標出力」を参照）のみに書き込み、他のファイルには触れません

必須入力（最小限の情報フォーム）

• ユーザーから情報が提供されていない場合は、先に収集・補完してください：references/info_form.md

手順

入力

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

実行手順

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

1. プロジェクトと対象ファイルの特定：project_root を確認し、3つの extraTex/2.*.tex ファイルのみを読み取り・編集します。対象ファイルが存在しない場合は、まずテンプレートプロジェクトを初期化・コピーするようユーザーに案内してください。
2. 「サブ目標の三点セット」を定める：目標を3～4個のサブ目標に分けます（内部の計画では、自己点検や参照を容易にするため S1–S4 の番号を使用できますが、この番号を最終的な LaTeX 本文に含めてはいけません）。各サブ目標について、次の内容を必ず明記します。
   • 指標（判定・受け入れが可能なもの）
   • 比較対象／ベースライン（何と、どのように比較するか）
   • データの出所／検証方法（サンプル／実験系／評価方法）
3. 2.1 研究内容 を生成する（「問題→目標→内容→経路→検証」を軸にします）。
   • 分量の目安（推奨値であり、必須ではありません）：
     • 推奨ページ数：12～15ページ（図表を含む）、申請書全体（28ページ以内）の約50％
     • 推奨文字数：12,000～15,000字（本文のみ）
     • 図表の方針：通常、図を10～20点挿入しても本文の分量が大きく圧縮されることはありません。図は「品質向上」の重要な手段です
     • 基本原則：審査基準は「字数の制限」から「ページ数の制限」へ移行しています。字数を基準に分量を計画しないでください
   • 構成の論理的枠組み（研究の種類に応じて選択）：新版では構成案をあらかじめ定めていません。研究の内在的な論理に基づいて、自由に構成できます。
     • 基礎研究に推奨される枠組み：科学的課題の提示 → 研究仮説 → 検証方針 → 期待される結果
     • 応用研究に推奨される枠組み：技術的なボトルネック → 解決策 → 実験設計 → 効果の検証
     • 汎用の基本軸（上記に当てはまらない場合）：問題 → 目標 → 内容 → 経路 → 検証
   • 研究課題と全体目標（2段落以内。箇条書きではなく、流れのある段落で記述します）
   • 研究内容とタスクの展開（科学的なストーリーを軸にし、検証の論理を逐条的な三点セットとして記入するのではなく、文章の中に自然に織り込みます）
   • 技術経路と検証基準（比較・アブレーション・外部検証・データ漏洩防止・統計手法を、独立したリストにせず叙述に組み込みます）
4. 2.1 から 2.2 特色与创新 を抽出する：
   • 1～3項目で十分です。数を絞り、内容を磨いてください（調査報告では、イノベーションの要点は数ではなく説得力が重要だと強調されています）。各項目では、「なぜこの選択が必然なのか」を出発点に、既存のアプローチの限界、本プロジェクトの相違点、そしてその違いから何が期待できるのかを明確にします。審査員に、単にイノベーションの定型欄を埋めたのではなく、研究者が十分に検討したことが伝わるようにしてください。
   • 「初めて」「最先端」など、断定的な表現は避けてください。使用が必要な場合は、検証可能な根拠を示すか、査読に耐える相対的な表現に書き換えてください。
5. 2.1 から 2.3 年度研究计划 を導出する（3年間とし、年度をまたがないようにします）。
   • 各年度について、年度目標 → 主要タスク → マイルストーン（受け入れ可能なもの）→ 納品可能な成果（論文／データ／プロトタイプ／規範／ソフトウェアなど）を記載します。
   • マイルストーンはサブ目標に対応させる必要があります（対応していないと、審査員は「計画と研究内容が乖離している」と判断します）。
   • 進行の論理：研究の依存関係と段階的な進行が伝わるようにします。1年目に先に取り組む内容と、2年目に別の内容へ進める理由を示してください（「1年目は基礎研究、2年目は研究の深化、3年目は総括」という進行記録のような計画は避けてください）。
6. 整合性の確認：
   • 2.2 のイノベーションの要点を、2.1 の具体的なタスクと検証にさかのぼって確認します。
   • 2.3 のマイルストーンがすべてのサブ目標を網羅し、各年度に納品可能な成果があることを確認します。
   • 用語の統一：研究対象／略語／指標の名称は、可能な限り「（一）立项依据」および「（三）研究基础」と一致させます（プロジェクト内に該当する記述がある場合）。
   • 出力のクリーンアップ：最終的に .tex ファイルに書き込む前に、本文に S1／S2／Sx／Ty／Vz などの内部計画番号が含まれていないことを確認します。対応関係を表現する必要がある場合は、「最初の研究目標に対応する」など、自然な言い回しに置き換えてください。
7. タスク完了後のユーザーへの注意：
   • 技術経路図は研究内容の冒頭に配置することを推奨します。

2段階の作業モード：

• 計画段階（内部処理。本文には記載しません）：三点セット、S1–S4 の番号、検証基準の選択肢を用いて研究の論理を整理し、各目標に指標、比較対象、データの出所がそろっていることを確認します。
• 執筆段階（.tex に出力）：叙述モードに切り替えます。計画段階の結論を流れのある段落に溶け込ませ、表を埋めるのではなく、研究者が十分に検討したことが読者に伝わる文章にします。

専門的な文章の主な特徴：

• 科学的なストーリーの軸がある：研究者が「なぜこれを行うのか、なぜこの方法なのか、どうすれば正しく行えたと証明できるのか」を理解していることが伝わり、3つの独立した箇条書きにはなっていません。
• 検証の論理が叙述の一部になっている：「検証方法：比較／アブレーション／外部検証」と並べるのではなく、研究内容を説明する中で「……と……を比較し、……の影響を排除する」と自然に示します。
• イノベーションの要点に説得力がある：「Aと比べ、違いはXであり、Yが期待される」という定型に当てはめるのではなく、課題を出発点に、既存のアプローチではなぜ解決できないのか、本プロジェクトの選択がなぜ必然なのかを明確にします。
• 年度計画に進行の論理がある：3年間の定型的な構成を埋めるのではなく、研究の依存関係と段階的な進行を審査員に示します。1年目に先に取り組む内容と、2年目に別の内容へ進める理由を説明します。

判断基準：本文を書いた後、このプロジェクトを知らない同分野の研究者に読んでもらい、構成上の注釈を見なくても研究の論理を自然に理解できるでしょうか。できるなら、執筆は成功です。

• サブ目標の「三点セット」の例：references/subgoal_triplet_examples.md

• イノベーションの要点における「相対座標系」の例：references/relative_coordinate_examples.md

• 年度計画テンプレート（マイルストーンを受け入れ可能な形にする）：references/yearly_plan_template.md

• 3つの出力ファイルの最小構成のひな形（コピーして貼り付け可能）：references/output_skeletons.md

• 研究内容の分量調整の参考（ページ数／字数／図表の方針）：references/page_budget.md

• よくある執筆上のアンチパターンと書き換え例：references/anti_patterns.md

• 検証基準の選択肢（比較／アブレーション／外部検証／統計／データ漏洩防止）：references/validation_menu.md

• 用語統一表（章をまたいだ一貫性の確保）：references/terminology_sheet.md

• このスキルでは、本ドキュメント内に変更履歴を記録しません。ルートの CHANGELOG.md にまとめて記録します。

出力

Skill description で約束している成果物を出力し、形式、パス、失敗時の返却形式を明記します。

输出管理

本 Skill 的新任务中间文件统一写入 ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/。同一任务复用一个任务根目录；多 Skill 协作才创建 shared/。正式交付物不写入该目录，历史隐藏目录只允许显式兼容读取、迁移或清理。

校验

• 见：references/dod_checklist.md

失败与恢复

保留错误证据和已完成产物；仅在输入、环境或外部依赖恢复后从最近的失败步骤重试。

约束

1. 仅编辑三份 extraTex/2.*.tex 文件；不得修改 main.tex、extraTex/@config.tex、任何 .cls/.sty
2. 目标文件若已包含标题命令（如 \\subsection{...} / \\subsubsection{...}），只替换正文内容，不改标题与结构层级
3. 信息不全时先提问补齐，不要用“看起来像真的”的细节硬写

公共硬约束

• 任务需要落盘时，使用唯一的 ./.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。
• 仅将 Skill 或 Bensz 基础设施本身的设计缺陷交给 bensz-collect-bugs；先脱敏写入 ~/.bensz-skills/bugs/，当前任务不中断，只有用户明确要求才公开上报，禁止直接修改用户已安装的 Skill 源码。

Skill 专属约束

不得超出本 Skill description 和上方流程所声明的范围；不将未验证的信息伪装成确定结论。