nsfc-abstract

NSFC 中国語・英語要旨生成器

入力（まず情報を確認し、不足があれば質問します）

ユーザーには、まず情報フォームに沿って情報を提供してもらいます（skills/nsfc-abstract/references/info_form.md を参照）。断片的な情報しか提供されていない場合は、重要な不足情報を補うため、まず次の質問を3～6個します：

• 題目は「メカニズム重視／方法重視／トランスレーショナル重視／場面重視」のどれに寄せたいですか？（決められない場合は選ばなくてもかまいません。デフォルトで複数の要素を組み合わせた候補を提示します）
• 研究対象・場面は何ですか？（疾患／材料／システム／タスク）
• 分野の課題と未解決の科学的問題は何ですか？（一文）
• これまでに得られた重要な知見／予備実験／データは何ですか？（定量値があれば1～2点）
• 検証する科学的仮説／中核となる見解は何ですか？（一文）
• 研究内容の3～4項目では、それぞれ何を行い、どの方法を用いて、どのような検証可能な結果を得ますか？
• 期待される科学的意義／応用価値は何ですか？（空疎な表現は避けてください）

手順

入力

ユーザーの依頼と設定ファイルに従って必要な情報を提供します。不足情報がある場合は、それを明示し、その入力に依存する手順を中止します。

実行手順

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

目標：審査員が「一目で理解できる」五文形式の要旨を作成し、重要性、科学的問題、実現可能性の根拠、研究内容、科学的意義の5要素をすべて含めます。さらに、それに対応する英訳も出力します。

分量の比率に関する原則：経験豊富な審査員は、申請者が早く本題に入ることを望みます。背景説明が過剰だと、専門性が不足している印象を与えます。各文の目標比率は以下のとおりです（超過した場合は圧縮します）。

文	機能	目標比率
① 背景	導入	≤ 15%
② 科学的問題	未解明点の特定	15–20%
③ 先行研究	信頼性の確立	20–25%
④ 研究内容	本文	35–40%
⑤ 意義	総括	10–15%

1. 重要性／背景（≤ 15%）：厳密に1文で、研究対象の重要性と中核となるボトルネックを示します。背景を詳しく説明してはいけません。
2. 科学的問題（15–20%）：重要な未知の点と現状の不足を指摘します（メカニズム／指標／因果関係のどこに欠落があるのかを具体的に示します）。
3. 実現可能性の根拠（先行研究）（20–25%）：先行研究の知見／予備実験を1～2点示し（できるだけ定量的に）、そこから自然につながる形で科学的仮説／中核となる見解を提示します。
4. 研究内容（3～4項目）（35–40%）：動詞で始め、「何をするか→どのように行うか→何を検証するか／どのような判定基準を得るか」を明確に記述します（項目数のデフォルトは config.yaml:limits.content_points_min/max に従います）。この文が要旨の本文となるため、最も多くの分量を割きます。
5. 意義／価値（10–15%）：期待される貢献（科学的メカニズム＋方法／戦略／応用可能性）をまとめ、第2文の問題に対する答えとなるよう総括します。

ユーザーが「中国語≤400文字／英語≤4000文字」などの厳格な制約を明示した場合は、必ず次の閉ループを実行します。まず検査し、次に圧縮し、再検査して、合格後に書き込みます。

1. まず、読みやすいものの制限を超える可能性がある初稿を作成します（5つの文の要素をすべて含めます）。
2. 決定論的なスクリプトで検査します（--json を必ず使用し、厳密な文字数カウントはハードコードされた処理に任せます）：
   • python3 skills/nsfc-abstract/scripts/validate_abstract.py - --json --diff --strict
   • stdin から入力できます（ファイルへの事前書き込みは不要です）。または、NSFC-ABSTRACTS.md に書き込んでからファイルを検査します。
3. 制限を超えている場合は、「圧縮の優先順位」に従って圧縮し、手順2に戻ります。最大3ラウンドまで行います。
4. 3ラウンド続けて制限を超える場合は、自動圧縮を中止し、現在の超過文字数（ZH/EN exceeded）をユーザーに伝えて、次のいずれかを選んでもらいます：
   • 一部の情報を削除することを許可する（削除可能な情報を指定）
   • 文字数上限を緩和する（config.yaml を変更）
   • より短い重要情報の要約をユーザーが提示する（例：最も重要な根拠を1点＋研究内容を3項目だけ残す）

圧縮の優先順位（上から順）

• P0（必ず残す）：研究対象／重要な科学的問題の未解明点／定量的根拠（ある場合）／主要な方法名／期待される貢献の総括
• P1（優先的に簡潔にする）：程度を表す副詞、形容詞による修飾、「私たちは～する予定です」／「本研究」などの主語、過程の説明、「～を通じて／～を用いて」などの前置き的な句、並列する重複表現
• P2（優先的に削除する）：15%を超える背景部分（まずここを圧縮）、根拠のない抽象的な評価（定量的裏付けのない「顕著な／重要な／先進的な」など）、重複した文、科学的問題と関係のない背景の補足

決定論的な書き込み／検査が必要な場合は、次のスクリプトを使用できます：

• 書き込み：python3 skills/nsfc-abstract/scripts/write_abstracts_md.py <input> --strict
• 検査：python3 skills/nsfc-abstract/scripts/validate_abstract.py NSFC-ABSTRACTS.md --json --diff --strict

出力

• 中国語と英語を必ず両方提示します。英語は中国語の忠実な翻訳とし、内容を膨らませたり、新たな仮説や新たな結果を加えたりしてはいけません。
• 中国語要旨には中国語の句読点を使用します。
• 引用符に関する厳格な制約（回避不可）：中国語要旨で引用符が必要な場合、唯一使用可能な形式は中国語の曲線引用符 ” （U+201C）と ” （U+201D）です。次の形式はすべて禁止です：ASCII二重引用符 ”、全角引用符 ＂、直角引用符 「」 ／ 『』、一重引用符 ' ／ '、その他の代替形式。
• 中国語要旨の本文はプレーンテキストにします。Markdown記法（**、*、_、# など）を含めてはいけません。ユーザーは、プレーンテキストのみを受け付けるシステムに本文をそのままコピーするためです。
• 中国語要旨では数字に千位区切りのカンマを使用しません。1000 と書き、1,000 や 1，000 と書いてはいけません。
• 「主要研究分野」を必ず記載します。英語要旨の後に一文で記載します（漢字数 ≤ 25）。中核となる研究の方向性を簡潔に表し、複数項目や箇条書きにしてはいけません。
• NSFC-ABSTRACTS.md に書き込む際、中国語要旨の本文末尾と英語要旨の区分見出しの間に空行を入れてはいけません。
• 題目の候補を必ず提示します。skills/nsfc-abstract/references/title-rules.md の「中国語題目」の構成上の方針に従い、少なくとも次の項目を含めます：
  • 推薦題目：...（中国語）
  • Recommended Title: ...（英語。推薦題目の次の行に記載）
  • 1) ... —— 理由：... / EN: ...（少なくとも5件。件数は config.yaml:title.title_candidates_default に従い、各候補の末尾に英訳を付けます）
• 中国語要旨：デフォルトで≤400文字（句読点を含む）。5文を推奨し（config.yaml:limits.zh_recommended_sentences に従います）、各文に1つの機能を持たせます。
• 英語要旨：≤4000文字（句読点を含む）。文法を正しくし、用語を統一します。
• 誇張や宣伝調の表現（「国際的に先進的」「空白を埋める」「世界初」など）は、ユーザーから検証可能な根拠が提示され、かつ明示的に残すよう求められている場合を除き、使用しません。
• 背景を過剰に説明したり、方法論の用語を列挙したりしません。各方法名は、「何を検証するか」を明確にするために使用します。

次の形式で NSFC-ABSTRACTS.md に書き込みます（見出しのテキストは config.yaml:output.zh_heading/en_heading に従います）。末尾に文字数の自己検査結果を記載します（文字数のカウント方法：連続する空白を単一のスペースに置き換えて数え、句読点も含めます）。

# 标题建议
推荐标题：...
Recommended Title: ...
1) ... —— 理由：... / EN: ...
2) ... —— 理由：... / EN: ...
3) ... —— 理由：... / EN: ...
4) ... —— 理由：... / EN: ...
5) ... —— 理由：... / EN: ...

# 中文摘要
（正文）
# English Abstract
(translation)
# 主要研究领域
（一句话，≤ 25 个汉字）

### 输出管理

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

### 校验

- 中文摘要字符数：N/400
- 英文摘要字符数：M/4000

ファイルへの書き込み後、会話で全文を再掲してはいけません（ユーザーが明示的に求めた場合を除きます）。次の項目だけを報告します：

• 書き込んだファイルパス（デフォルトは ./NSFC-ABSTRACTS.md）
• 題目候補の数がデフォルトの要件を満たしているか
• 中国語／英語の文字数と、上限を超えているかどうか

失敗時の復旧

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

制約

以下の共通制約を守り、本スキル固有の境界条件も適用してください。

公共硬约束

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