nsfc-research-foundation-writer

NSFC（三）研究基盤執筆オーケストレーター

目標出力（契約）

• 書き込み先（2 ファイル）：
  • extraTex/3.1.研究基础.tex（「研究リスクへの対応策」を含む）
  • extraTex/3.2.工作条件.tex
• 変更禁止：main.tex、extraTex/@config.tex、すべての .cls/.sty
• 主要目標：「証拠の連鎖＋条件の対応付け＋リスクへの備え」によって、審査委員の次の3つの問いに答えることです。これまでに取り組んだことがあるか？実行できるのか？問題が起きた場合、どう対処するのか？

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

• project_root：申請書プロジェクトのルートディレクトリ（例：projects/NSFC_Young）
• output_mode（デフォルトは apply）：
  • preview：コピー可能な LaTeX 本文の草稿を2つだけ出力し、書き込み先のファイルパスを明記します。ファイルには書き込みません。
  • apply：対象の2ファイル（「目標出力」を参照）のみを書き換え、他のファイルには触れません。

必須入力（最低限の情報表）

• ユーザーから提供されていない場合は、先に収集または補完してください：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 が存在することを確認し、存在しない場合はエラーを返して、正しいパスを指定するようユーザーに案内します。
   • extraTex/ ディレクトリが存在することを確認します。存在しない場合は、テンプレートプロジェクトを初期化またはコピーするようユーザーに案内してください。必要に応じて、ユーザーの確認後に作成できます。
   • project_root と output_mode を確認します（デフォルトは apply）。
     • preview モード：内容のプレビューのみを生成し、ファイルには書き込みません（デバッグに適しています）。
     • apply モード：生成した内容を extraTex/3.1.研究基础.tex と extraTex/3.2.工作条件.tex に書き込みます。
   • この2つのファイルのみを編集し、main.tex、extraTex/@config.tex、すべての .cls/.sty の変更は禁止です。
2. 3.1 研究基盤 の生成（証拠の連鎖を優先）：
   • 研究の蓄積：2.1 の主要タスクに沿って、「何に取り組んだか／何を習得しているか／どのようなプラットフォームがすでにあるか」を列挙します。
   • 段階的な成果：検証可能な内容（論文／特許／データ／プロトタイプ／予備実験で確認された現象）のみを記載します。不確かな詳細にはプレースホルダーを使用し、ユーザーに補完を求めます。
   • 実現可能性の4つの側面：理論／技術／チーム／条件について、それぞれ1～3個の根拠を挙げ、研究内容と個別に対応させます。
3. 3.1 に「研究リスクへの対応策」を明記する：
   • リスクを少なくとも3つ挙げます（技術／進捗／リソースから各1つ以上）。
   • 各項目には、リスクの説明 → 早期兆候（発動基準／現象）→ 対策／代替ルート（目標の引き下げと納品可能な成果を含む）を記載します。
4. 3.2 作業条件 の生成（研究内容に条件を対応付ける）：
   • すでに整っている条件：項目ごとに列挙します。次の形式を推奨します。
     • プラットフォーム：XXX プラットフォーム（整備済み／アクセス可能）
     • データ：XXX データセット（取得済み／公開データとして取得可能）
     • サンプル：XXX 病院／機関（協力協定の締結済み／倫理審査中）
     • 計算リソース：XXX サーバー／GPU（設定済み／共同利用）
     • チームの役割分担：メンバー A は XX、メンバー B は YY を担当
     • コンプライアンス対応：倫理審査（XXX 委員会、所要期間 X か月）
   • 不足している条件と解決策：項目ごとに列挙します。次の形式を推奨します。
     • 不足している条件：XXX（影響：YYY）
     • 解決策：購入／連携／代替データソース／実験の縮小案
     • スケジュールと責任者：ユーザーから提供された場合は記載し、提供されていない場合はプレースホルダーで示します。
5. 整合性の確認：
   • 確認 1：3.2 作業条件 が 2.1 の主要タスクを個別に支えられるか確認します。
     • 方法：2.1 の各主要タスクを列挙し、3.2 に対応する条件による裏付けがあることを確認します。
     • 例：
       • タスク 1：XXX 実験 → 条件：XXX プラットフォーム、XXX サンプル
       • タスク 2：YYY アルゴリズム → 条件：YYY 計算リソース、ZZZ データ
   • 確認 2：リスクへの備えが年度計画と両立するか確認します。
     • 方法：2.3 の各年度のマイルストーンを列挙し、リスクへの備えに対応する縮小案があることを確認します。
     • 例：
       • 1年目：サンプル取得 → リスク：サンプル登録の遅れ → 対策：代替データソースと縮小した検証計画を用意
   • 確認に失敗した場合の対応：
     • 不整合が見つかった場合は、[要補足：XXX] と記し、ユーザーに案内します。
     • ユーザーから 2.1 または 2.3 が提供されていない場合は、該当する確認を省略し、その旨をユーザーに案内します。

Q1: プロジェクトディレクトリに extraTex/ ディレクトリがない場合はどうすればよいですか？

A: まず、project_root が正しい申請書プロジェクトのルートディレクトリを指しているか確認することをお勧めします。本当に extraTex/ がない場合は、手動で作成してください。

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

Q2: 2.1 研究内容 をまだ書いていませんが、直接 3.1 研究基盤 を書けますか？

A: お勧めしません。3.2 作業条件 は 2.1 の主要タスクと対応させる必要があります。先に nsfc-research-content-writer を使用して 2.1 を完成させることをお勧めします。

Q3: 情報表の一部の内容を公開しにくい場合はどうすればよいですか？

A: 内容をすべて公開する代わりに、「検証可能な手がかり」を提示できます。例：

• ❌ 「Nature に論文 XXX を発表しました」
• ✅ 「関連論文を発表しています（検証可能な手がかりとして、DOI／書誌情報／採択通知番号などを提示できます）」

Q4: リスクへの対応は必ず3項目書く必要がありますか？

A: はい、少なくとも3項目（技術／進捗／リソースから各1項目以上）が必要です。リスクが低いと考える場合でも、審査委員に備えがないと思われないよう、3つの分類ごとに「低リスク＋監視信号＋対策」を1項目ずつ記載することをお勧めします。

Q5: 情報表の内容が少なくても、研究基盤の全体を生成できますか？

A: できます。AI は提供された情報に基づいて内容を生成し、不確かな箇所にはプレースホルダー（例：[要補足：XXX]）を使用します。後から補完してください。

• このスキルの変更履歴は、このディレクトリの CHANGELOG.md に記録し、ルートレベルの CHANGELOG.md にも同期します。SKILL.md では「AI 実行規範」のみを管理します。

出力

Skill description で約束されている成果物を出力し、形式、パス、失敗時の戻り値を明示します。

出力管理

この Skill の新しいタスクで使用する中間ファイルは、すべて ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/ に書き込みます。同じタスクでは同じタスクルートディレクトリを再利用します。複数の Skill が連携する場合にのみ shared/ を作成してください。正式な成果物はこのディレクトリに書き込まず、過去の隠しディレクトリは明示的な互換読み込み、移行、またはクリーンアップの場合にのみ使用できます。

検証

品質契約の検証（config.yaml に基づく）

• 研究基盤には、次の内容を含める必要があります。
  • 本プロジェクトに関連する研究の蓄積（証拠の連鎖）
  • これまでに得られた段階的な成果（検証可能なもの）
  • 実現可能性の要点（理論／技術／チーム／条件）
  • 研究リスクと対応策（明記する）
• 作業条件には、次の内容を含める必要があります。
  • すでに整っている条件（プラットフォーム／データ／サンプル／計算リソース／チーム／コンプライアンス）
  • 不足している条件と解決策（期間／予算／連携／購入／代替案）

詳細チェックリスト

references/dod_checklist.md を参照してください。

オプションのスクリプトによるセルフチェック（読み取り専用）

• スキル自体の構造整合性のみを確認します：python3 skills/nsfc-research-foundation-writer/scripts/validate_skill.py
• プロジェクトの出力ファイルも確認します（存在確認＋簡易的な内容ヒューリスティック）：python3 skills/nsfc-research-foundation-writer/scripts/run_checks.py --project-root <あなたのproject_root>

失敗と復旧

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

约束

1. 仅编辑两份 extraTex/3.*.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 和上方流程所声明的范围；不将未验证的信息伪装成确定结论。