nsfc-budget

NSFC 予算説明書ジェネレーター

まず適用可否を判断する

• ユーザーが作業ディレクトリを指定していない場合：直ちに一時停止し、まず作業ディレクトリを提示するようユーザーに求めてください。
• ユーザーが「予算の書き方／原則」について尋ねているだけの場合：直接回答または提案し、このスキルは起動しないでください。
• ユーザーが 2026 青年 A/B/C で、状況が一括請負制に該当する場合：まず「通常、予算説明書は不要です」と明確に伝えてください。ユーザーが過去のテンプレート、特定機関の要件、または予算制の状況であると明確に説明した場合に限り、続行してください。

必要な入力

まず skills/nsfc-budget/references/info_form.md に従ってユーザーに情報を提示してもらってください。最低限、次の情報が必要です。

• 作業ディレクトリ（必須）
• 申請書本文またはその他の資料
• プロジェクトの種類：general | local | youth
• 予算の算定範囲：「申請総額」なのか「説明が必要な直接費の範囲」なのかを明記

ユーザーから情報がすべて提供されていない場合は、以下のルールに従ってください。

• 総予算が未提示：config.yaml:defaults.total_budget_wan のデフォルト値を使用します。
• 本文の目標文字数が未提示：config.yaml:defaults.target_chars の推奨範囲に従います。
• 各セクションの上限：config.yaml:defaults.per_section_max_chars に従います。
• テンプレートが未提示：config.yaml:defaults.template_id に従います。
• 予算モードの有効値：config.yaml:rules.budget_modes を参照してください。
• 予算の算定範囲の有効値：config.yaml:rules.budget_scopes を参照してください。

フロー

入力

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

実行手順

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

目標：申請書本文と補足資料に基づき、「財務面と学術面の双方から厳しく審査されても耐えうる」予算説明書を作成し、編集可能な LaTeX プロジェクトと budget.pdf を納品します。

run の初期化

まず、非表示の作業領域と budget_spec.json のひな形を作成してください。

python3 skills/nsfc-budget/scripts/init_budget_run.py \
  --workdir <workdir> \
  --project-type <general|local|youth> \
  --template-id 01

ユーザーから資料のパスが提示されている場合は、複数の --material <path> を追加できます。スクリプトは資料のスナップショットを .bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-budget/{yyyy-mm-dd-hh-mm}/input/materials/ にコピーします。 同じ分に初期化が重複した場合は、スクリプトが自動で接尾辞を追加してディレクトリ名の衝突を回避し、run ディレクトリ同士が相互に干渉しないようにします。

資料を精査し、「タスク－ニーズ－金額－根拠」のつながりを作る

本文と補足資料を読み込んだ後、まず非表示の作業領域内で判断をまとめてから、budget_spec.json に記入してください。

• 支出のすべてを具体的な研究タスクまでたどれるようにしてください。
• 各セクションで、なぜ費用が必要か、何に使うか、どう算定するか、なぜこの金額が妥当かを説明してください。
• 設備、協力機関、試験回数、出張頻度、人件費の対象人数、価格の根拠を捏造してはいけません。
• 根拠が不足している場合は、ユーザーに確認するか、保守的に「支出計上なし／協力機関への資金移転なし／その他の資金源なし」と記載し、捏造しないでください。

執筆原則は skills/nsfc-budget/references/budget-writing-rules.md を参照してください。

budget_spec.json の記入

スクリプトが生成する budget_spec.json は、唯一の構造化中間原稿です。最低限、以下を補完してください。

• meta：プロジェクト名、プロジェクトの種類、予算モード、作業ディレクトリ、出力ディレクトリ、テンプレート ID、文字数目標
• budget：予算総額の算定範囲、直接費総額（既知の場合）、設備費／業務費／人件費／協力研究への資金移転／その他の資金源の金額
• sections：5 つの部分の本文段落（配列）
• evidence：重要な算定根拠、必要な前提、確認事項

要件：

• 設備費 + 業務費 + 人件費 = 直接費総額（直接費の算定範囲が明確な場合）
• budget.*_wan と sections.*.amount_wan は必ず一致させ、金額の参照元が二重化して食い違うのを防いでください。
• 協力研究への資金移転 は、前の3項目と論理的に矛盾しないようにしてください。
• その他の資金源 は、資金源と用途を明記してください。該当しない場合は「なし」と明示してください。
• 金額、文字数上限、許容差などの数値を負数にしてはいけません。不正な値がある場合は、問題を抱えたままレンダリングするのではなく、まず JSON を修正してください。

レンダリング、検証、反復

スクリプトを使って JSON を LaTeX プロジェクトにレンダリングし、検証レポートとコンパイルログを非表示ディレクトリに保存してください。

python3 skills/nsfc-budget/scripts/render_budget_project.py \
  --spec <workdir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-budget/{yyyy-mm-dd-hh-mm}/budget_spec.json

スクリプトは以下を行います。

• テンプレートを <workdir>/<output_dirname>/ にコピーします。
• 5 つの section を対応する extraTex/*.tex に書き込みます。
• 金額の整合性、段落の長さ、可視文字数、テンプレート／パスの制約を検証します。
• budget_spec.json が引き続き <workdir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-budget/ に存在することを検証し、非表示の作業領域に関する取り決めが守られていることを確認します。
• よく使われる LaTeX 特殊文字（%、#、&、_ など）を自動でエスケープし、自然言語の本文によるコンパイル失敗を減らします。
• 非表示ディレクトリに validation_report.md/json を保存します。
• 検証に失敗した場合、端末に最初のエラー概要と validation_report.md のパスを直接表示します。
• budget.pdf をコンパイル出力します。

検証に失敗した場合は、まず budget_spec.json を修正してからスクリプトを再実行し、合格するまで続けてください。

納品前の手動確認

納品前に、最低限以下の点を確認してください。

• 予算の算定範囲が明確か：申請総額か、直接費か
• 設備／試験／出張／人件費が実際に研究タスクと一対一で対応しているか
• 「詳細に書かれているが根拠がない」文がないか
• 「金額は合っているが、論理が合っていない」という潜在的な問題がないか
• 「なし」と記載すべきところに、無理に文章を付け足した形跡がないか

標準では、以下の構造化方針を採用してください。

• 総論は厳密に：まず予算が政策との整合性、目標との関連性、経済的合理性に従っていることを説明します。

• 項目ごとに具体化：各セクションで少なくとも「用途＋算定＋必要性＋根拠」を明確に説明します。

• 空疎な表現を避ける：「プロジェクトを円滑に進めるため」「重要な意義がある」といった情報量のない文は、その後に具体的なタスクと支出が続かない限り、記載しないでください。

• 金額はタスクに沿わせる：説明書は「財務に関する散文」ではありません。すべての段落が研究計画に結び付いている必要があります。

• 数を揃えるために書かない：資料が不足している場合は、まず保守的に対応し、確認し、境界を明確にしてください。憶測で補わないでください。

• skills/nsfc-budget/references/info_form.md

• skills/nsfc-budget/references/budget-writing-rules.md

• skills/nsfc-budget/scripts/init_budget_run.py

• skills/nsfc-budget/scripts/render_budget_project.py

• skills/nsfc-budget/models/01/.template.yaml

出力

最終出力には、以下を必ず両方含めてください。

• <workdir>/<output_dirname>/：完全な LaTeX プロジェクト
• <workdir>/<output_dirname>/budget.pdf

中間ファイルは以下に保持してください。

• <workdir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-budget/{yyyy-mm-dd-hh-mm}/

出力管理

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

検証

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

失敗と復旧

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

约束

• 所有中间文件只能放在 <workdir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-budget/。
• 不要把草稿、日志、计划、截图、临时 JSON、编译中间文件散落到工作目录其它位置。
• 最终可见交付物只放在 <workdir>/<output_dirname>/（默认值见 config.yaml:defaults.output_dirname）。
• template_id、output_dirname、.template.yaml 里的 section_files/latex_entry/pdf_name 都必须是相对安全路径；不得包含绝对路径、. / .. 越界段。
• output_dirname 不得指向工作目录根路径，也不得与隐藏工作区 <workdir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-budget/ 重叠。

公共硬约束

• 任务需要落盘时，使用唯一的 ./.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 和上方流程所声明的范围；不将未验证的信息伪装成确定结论。