nsfc-length-aligner

nsfc-length-aligner

適用シーン

• 国自然の申請書があり、「一部が短すぎる／長すぎる」かをすばやく判断したい
• テンプレートの厳格な分量要件（ページ数／語数／文字数）に合わせたい
• 論旨の主軸と証拠の連鎖を保ちながら、原意をできるだけ変えずに文章を増補または圧縮したい

適用しないシーン

• 「文字数の集計」だけが必要で、予算や書き換えの一連の確認に関心がない場合（より簡単なスクリプトで対応できます）
• 申請書がローカルに存在しない場合（テキスト／ファイル／パスを提供できない）

ワークフロー

入力

ユーザーのリクエストと設定ファイルに基づいて必要な入力を用意します。情報が不足している場合は明示し、その入力に依存する手順を中止してください。

実行手順

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

目標：分量を主観的な感覚から定量化して一連の確認が可能な指標へと変え、予算（budget）に基づいて文章の増補／圧縮を行います。

非表示の作業領域を固定する（最初に実施）

• 申請書の作業ディレクトリをルートとし、中間ファイルとレポートはすべて <workdir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-length-aligner/ にまとめてください
• length_report.*、一時分析原稿、計画ファイルを作業ディレクトリのルートやリポジトリ内の別の場所に書き込まないでください
• --out-dir が明示的に渡された場合は、相対パス .bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-length-aligner を優先してください。スクリプトは相対 --out-dir を、シェルのカレントディレクトリではなく --input に対応する作業ディレクトリを基準に解決します
• 作業ディレクトリに書き込み権限がない場合は、書き込み可能なコピーに切り替えてから実行してください。手間を省くために、中間ファイルをプロジェクト外に散在させないでください

要件の確認（予算の基準）

最初に、合わせるべき「厳格な基準」を確認してください。

• 2026 年の調査に基づく共通認識の「黄金比率」（面上／青基 C 類、校正用）：立項根拠 30％（6～10 ページ、約 8000～10000 字）／研究内容 50％（12～15 ページ、約 12000～15000 字）／研究基盤 20％（5～8 ページ、約 5000～6000 字）。合計は余裕を持たせるため、28 ページ以下を推奨します（原則として 30 ページを超えないこと）
• ページ数（厳格な制約）：2026 年以降の改訂後は「原則として 30 ページを超えないこと」です。実務上は余裕を持たせるため、28 ページ以下を推奨します。フォントサイズ／行間を小さくして「ページ数を押し込む」ことは避けてください
• 文字数の予算（代理指標）：中国語文字数／総文字数など。「書き換え→再確認」の確実な一連の作業に使用します（ページ数は最終的に PDF で確認します）
• 予算の範囲：全体の分量、および各パート／主要な章の予算（少なくとも立項根拠／研究内容／研究基盤を含む）

注：この skill は、デフォルトで config.yaml:length_standard の**サンプル基準（2026 年の調査に基づく推奨に準拠）**を使用します。当年のガイドライン／テンプレートに照らし合わせて確認してから使用してください。

分量チェックを実行する（確定的な確認）

対象の申請書ディレクトリ（または単一ファイル）に対してチェック用スクリプトを実行し、レポートを生成します。

python3 scripts/check_length.py --input <目标标书路径> --config config.yaml

出力ディレクトリを明示する場合は、次を使用してください。

python3 scripts/check_length.py --input <目标标书路径> --config config.yaml --out-dir .bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-length-aligner

申請書が NSFC_Young / NSFC_General テンプレートに基づいている場合（プロジェクトのルートディレクトリに main.tex がある場合）、--input にプロジェクトのルートディレクトリを指定することを推奨します。スクリプトは main.tex の \input/\include 依存関係ツリーをたどり、PDF に実際に組み込まれるファイルを収集します。また、コメントアウトされた \input{...} は無視するため、任意の章が分量に誤って計上されることを防げます。

最終 PDF をすでにコンパイル済みの場合は（推奨。ページ数は厳格な制約です）、ページ数の集計に PDF も一緒に渡してください。

python3 scripts/check_length.py --input <目标标书路径> --config config.yaml --pdf <标书.pdf>

出力：

• コンソールの概要（全体の分量、予算を超過／下回る項目）
• <input>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-length-aligner/length_report.md（デフォルトの出力ディレクトリ。--out-dir で変更可能）
• <input>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-length-aligner/length_report.json（デフォルトの出力ディレクトリ。--out-dir で変更可能）

注意：--out-dir に相対パスを使用すると、<input> に対応する作業ディレクトリを基準に解決されます。これにより、別のディレクトリからコマンドを起動したときに、レポートが誤ってシェルのカレントディレクトリに書き込まれるのを防げます。

実行後は、length_report.md を必ず読み、必要に応じて length_report.json も参照してください。「ファイル単位の差異表＋（任意の）章単位の統計」を手順 3 の入力にします。

差異を読み解く（どこに差があるか）

レポートに基づき、次の 3 つを行います。

1. 「長すぎる／短すぎる」ファイルまたは章を特定する
2. 差異が次のどれに当たるかを判断する：
   • 証拠の連鎖が不十分（データ／比較／限界を補う必要がある）
   • 論理の飛躍（つなぎ／定義／仮説を補う必要がある）
   • 冗長な重複（統合／削除が必要）
3. 実行項目リストを作成する（増補／圧縮の優先順位）

章単位のデータの使い方（より正確な特定）：

• length_report.md に章の表がある場合（または JSON に sections フィールドがある場合）は、「長すぎる／短すぎる」ファイル内で、差異への寄与が最も大きい具体的な章を優先して特定し、ファイル単位で一律に削除するのではなく、該当箇所を絞って書き換えてください
• あるファイルが長すぎる／短すぎる場合、その章別統計を比較してください。差異が主に 1～2 章に集中している場合は、まずその 1～2 章だけを修正してください（原意と構成を保ちやすくなります）

参考：references/MEANING_PRESERVING_REWRITE_RUBRIC.md

増補／圧縮（原意をできるだけ変えない）

増補の方針（短すぎる場合）

• まず「検証可能な情報密度」を補います：定義、仮説、比較、アブレーション、リスクと代替案
• 次に「論証の一連の流れ」を補います：なぜ行うのか → どう行うのか → 何をもって検証するのか → 失敗した場合にどうするのか
• 抽象的な増補は避けます：新たな主張を持ち込まず、形容詞を積み重ねないでください

圧縮の方針（長すぎる場合）

• 重複をなくす：同じ論点は、最も強い表現を一度だけ残します
• 背景を削る：一般的な背景説明は 1～2 文にまとめ、分量を「課題・方法・検証」に充てます
• 構造化して書き換える：事実の順序を変えずに、長い段落を箇条書きに分けます

⚠️ 書き換え後は、必ず手順 5 の再確認を実行して、差異が解消されたことを確認してください。再確認しない場合は、未完了とみなします。

使い方（「固定的な提案」を「差異に応じた対応」に変える）：

• まずレポート内の該当ファイルの差異 delta を確認します：+N は超過（「削る」ことを優先）、-N は不足（「増やす」ことを優先）、OK は予算に合わせるための修正が不要です
• delta の絶対値が大きいほど、優先度が高くなります。処理順は、まず |delta| が最大のファイルを修正し、次に差が大きい項目へ進むことを推奨します

立項根拠（なぜ行うのか）：

• 削る：教科書的な解説、一般化されたレビュー、関連性の薄い「国家ニーズ」の説明、研究意義の繰り返し、文献数合わせ
• 増やす：Gap（ボトルネック）→ Key Idea（突破口）→ 価値の論証（なぜ取り組む価値があるのか）

研究内容（何を／どう行うのか）：

• 削る：重複した記述、細かすぎる操作上の詳細、手法の羅列
• 増やす：論理的な枠組み、主要な実験設計と比較／アブレーション、期待される結果と検証可能な指標、図を活用した説明

研究基盤（なぜ実施できるのか）：

• 削る：関連性のない成果の羅列、背景説明の過剰な前置き
• 増やす：研究内容に密接に関連する予備実験データ、中核となる技術力、プラットフォームの条件（研究内容に対応させる）

再確認の一連の作業

修正後はスクリプトを再実行し、「基準を満たし、上限を超えていない」ことを確認してください。

python3 scripts/check_length.py --input <目标标书路径> --config config.yaml

• ページ数を「押し込む」ためにフォントサイズや行間を小さくしないでください（ページ数要件は審査上のリスク要因です）
• 30 ページぎりぎりまで使わないでください。余裕を持たせるため、28 ページ以下を推奨します
• 当年のガイドラインで生成 AI の使用状況の申告が求められる場合は、必ず要件に従って正確に記載してください（コンプライアンス要件）

出力

• レポートは「ファイル単位＋（任意の）章単位」で提示します
• 予算の唯一の正となる情報源は config.yaml:length_standard です
• 中間ファイルはすべて config.yaml:output_settings.intermediate_dir（デフォルトは .bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-length-aligner）にまとめて保管します
• すべての書き換えで「最小限の変更で原意を保つ」という原則に従います（references を参照）

出力管理

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

検証

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

失敗時の復旧

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

制約

以下の共通制約を遵守し、この Skill 固有の境界条件も適用してください。

公共硬约束

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