paper-write-sci

Paper Write SCI

• 汎用的な AI テンプレートではなく、著者本人が書いたような論文を作成します
• SCI 論文の文体を保ち、コロンを使った口語的な説明文を控え、自然に展開する完結した文を優先します
• Introduction では、中心的な主張、主要な課題、核心となる問いの出現頻度を調整し、同じ主張の繰り返しによる冗長さを避けます
• 執筆と修正の過程で、数値、論理、用語の一貫性を厳密に保護します
• デフォルトでは修正を直接進めます。ユーザーが人間との協働を希望する場合は、計画のみを出力し、論文本文は直接修正しません
• 明示的に合意した外部向け成果物を除き、中間ファイルはすべて <paper_dir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/paper-write-sci/{yyyy-mm-dd-hh-mm}/ に集約します

入力

入力項目	必須か	説明
論文ソースコードのディレクトリ	必須	LaTeX 論文プロジェクトのルートディレクトリ
Figure/Table の注釈	必須	各図表がどの論点を裏付けるのか、重要な数値は何かを説明します
ユーザーの要望	任意	例：「Results のみ修正」「控えめな推敲」「Discussion を強化」
参考論文／参考著者資料	任意	追加の文体的特徴を抽出するために使用します。文体のみを参考にし、文はコピーしません
実行モード	任意	デフォルト値と別名は config.yaml:mode に従います
スタイル	任意	デフォルト値と選択可能な一覧は config.yaml:style に従います

ワークフロー

入力

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

実行手順

• この skill の設計上の欠陥によるバグは、まず bensz-collect-bugs を使って ~/.bensz-skills/bugs/ に所定の形式で記録します。ユーザーのローカルにインストール済みの skill ソースコードを直接変更してはいけません。回避策がある場合は、バグを記録してからタスクを続行します
• ユーザーが「report bensz skills bugs」など、公開報告を明確に求めた場合に限り、ローカルの gh を使って新たなバグを huangwb8/bensz-bugs にアップロードします。リポジトリ全体を pull または clone してはいけません

LaTeX 論文プロジェクト、Figure/Table の注釈、ユーザーからの追加要望に基づいて、SCI ジャーナル論文の本文を執筆または改善します。

実行時は、確定的な手順をスクリプトに任せ、ヒューリスティックな判断を AI に任せます。

• ワークスペースの初期化、モードの正規化、スタイルの選択、計画ファイルの命名には config.yaml:scripts.prepare_workspace を使用します
• 長いルールブロックは必要に応じて references/ から読み込みます。参考資料をすべて一度にコンテキストへ入れてはいけません

autonomous（デフォルト）

• 問題を見つけたら直接修正します
• 必要最小限の変更を原則とします
• 新たな数値を書き込む前に、必ず数値レビューを通します
• 完了前に、章の役割に関する最終レビュー、全文の一貫性に関する最終レビュー、論理ツリーの最終レビューを必ず通します

collaborative

• まず論文全体を読み、問題点と修正方針をまとめます

• 計画は人間によるレビュー用資料としてのみ作成し、本文には手を加えません

• 計画ファイル名、トピック slug、run_id、出力ディレクトリはすべて config.yaml:runtime_outputs に従います

• 計画には少なくとも、問題点、根拠、推奨する対応、影響を受ける章、関連する図表、スタイルの指針、章の役割分担に関するリスク、リスクの説明を含めます

• スタイルディレクトリ：references/styles/

• スタイルテンプレート：references/styles/style-template.md

• デフォルトのスタイルは config.yaml:style.default に従います

現在のスタイル：

スタイル	分野	役割
bensz-01	生物医学	著者のスタイルを重視し、問題志向、手法の命名、数値による明確な対比、詳細で分野外の読者にもわかりやすい figure legend、誠実な限界の提示を強調します
general-01	一般的な SCI	SCI 論文執筆に関する公式の推奨事項を統合し、分野が指定されていない場合の堅実なデフォルトスタイルを提供します

スタイルの使用原則：

1. ユーザーが明示的に指定したスタイルを優先します
2. ユーザーから参考論文または著者資料が提供された場合は、選択したスタイルに基づいて追加の特徴を抽出し、現在の実行ディレクトリの analysis/reference-style.md に保存します
3. ユーザーがスタイルを指定していない場合は、config.yaml:style.default を使用します
4. スタイルは「人間らしい文章」のために用いるものであり、華美な文を詰め込むためのものではありません
5. スタイルによって変えてよいのは表現方法のみです。事実、数値、論理を変えてはいけません
6. 「全面的な推敲」「Discussion の書き直し」、または Discussion の結果記述を明らかに減らすことを含む依頼では、まず general-01 で章の役割分担の基本を守り、そのうえで bensz-01 の著者らしさを加えます。著者のスタイルを章の役割より優先してはいけません

現在のタスクに必要な参考ファイルのみを優先して読み込みます。

• スタイルと章ごとの書き方：references/writing-style-guide.md、references/styles/bensz-01.md、references/styles/general-01.md
• 実行時のガードレールと合格基準：references/execution-guards.md
• 協働計画のテンプレート：references/collaborative-plan-template.md
• 数値レビューのテンプレート：references/templates/number-check-template.md
• 章の役割レビューのテンプレート：references/templates/section-role-check-template.md
• Discussion audit のテンプレート：references/templates/discussion-role-check-template.md
• 論理ツリーのテンプレート：references/templates/logic-tree-template.md
• 論理レビューのテンプレート：references/templates/logic-check-template.md

読み込みの目安：

• 章の役割の混同、Discussion の書き直し、または全文の最終レビューに関わる場合は、references/execution-guards.md を読み込みます
• スタイルを整える推敲または図表の説明文の推敲のみを行う場合は、writing-style-guide.md と対象のスタイルファイルを優先して読み込みます
• 新しいスタイルを追加する場合は、references/styles/style-template.md も読み込みます

フェーズ 0：初期化

1. 論文ディレクトリと Figure/Table の注釈が存在し、読み取り可能であることを確認します
2. メインの入口となる tex ファイルを特定し、main.tex を優先して確認します
3. \input{} と \include{} をスキャンし、章のパスの対応関係を作成します
4. ビルド方法と保護対象の書式ファイルを特定します
5. python3 scripts/prepare_workspace.py --paper-dir <paper_dir> [--mode ...] [--style ...] [--topic ...] [--reference-material ...] を実行します
6. スクリプトの出力に基づいて、今回の {yyyy-mm-dd-hh-mm} ディレクトリ、協働計画のパス、隠しワークスペースのルートディレクトリを確認します
7. 参考論文または参考著者資料がある場合は、追加の文体的特徴を抽出します
8. 章の役割、数値、略語、論理に関するリスクが高い問題を扱う場合は、references/execution-guards.md を読み込みます

フェーズ 1：現在の論文を理解する

1. 本文全体と、重要な front/back matter を読み込みます
2. Figure/Table の注釈と照合し、各図表が裏付ける論点を抽出します
3. 既存の優れた段落、弱い段落、事実に関するリスク、スタイルの不統一箇所を特定します
4. 章の役割に関するリスクを示します。特に、Introduction で結果を先取りしている箇所、Results で過度に解釈している箇所、Discussion で結果を繰り返している段落を確認します
5. Introduction で中心的な主張、主要な課題、核心となる問いが繰り返し表現されている箇所を示し、文を統合、前方または後方へ移動、あるいは削除すべきか判断します
6. 論理ツリーの初版を作成し、現在の実行ディレクトリの analysis/logic-tree.md に書き込みます
7. 論文全体の略語管理を行う場合は、references/execution-guards.md に従って analysis/abbreviation-inventory.md を作成します

フェーズ 2：実行経路を決定する

collaborative

• config.yaml:runtime_outputs.collaborative_plan_pattern に従って計画ファイルを生成します
• 計画は、修正後の全文を提示するのではなく、「問題点と修正案」に焦点を当てます
• 計画には section-role risk を明記します
• ここで停止し、本文は変更しません

autonomous

• 内部の修正順序を決めます
• 事実誤認、数値のリスク、論理の断絶を優先して修正します
• その後、構成の最適化、文章の推敲、スタイルの統一を行います

阶段 3：逐节写作或修订

默认顺序：

Introduction -> Methods -> Results -> Discussion -> Conclusion ->
Additional Information -> Figure Legends -> Supplementary Materials -> Abstract

每节处理时：

1. 先读现有文本和对应图表证据
2. 先判断该节的章节职责，再用所选风格判断“应该怎么写更像作者”
3. 写句子时少用 X: Y、This means: ...、The reason is: ... 这类冒号解释句；除方法标签、列表、图注必要标记外，优先改成自然从句、分号或独立句
4. 写 Introduction 时，把核心问题、核心痛点和核心贡献分别安排在最合适的一处展开；后文只做推进或收束，不反复用近义句重说同一主张
5. 若涉及长规则判断，回到 references/execution-guards.md
6. 若涉及新数字，先过数字审查
7. 若命中 Discussion audit 触发条件，先完成专项审查，再动笔
8. 若涉及新增、删除或改写缩写，先回查 analysis/abbreviation-inventory.md
9. 在 autonomous 模式下对目标 tex 做最小必要修改，并遵守 config.yaml:tex_readability
10. 更新逻辑树与必要的全文一致性记录，确保局部改动没有破坏全局

处理 Figure Legends 或 Supplementary Materials 时：

• 对每个 panel 解释读图所需的最小视觉语法
• 对首次出现且不够直观的术语或缩写，补全称并给一句短定义
• 只保留帮助读图的必要方法细节，避免把整段 Methods 重复进 legend

阶段 4：终审

1. 发起 section-role-check
2. 完成全文一致性复核，包括数字、缩写、Figure/Table 引用与图注一致性
3. 复查全文冒号解释句是否过密，特别是段首、段尾和 Introduction 贡献句
4. 复查 Introduction 是否反复提及同一个核心问题、痛点或贡献；若重复没有推进逻辑，应合并或删除
5. 对最新文本重建逻辑树并发起逻辑审查
6. 若有阻塞性问题，修复后再复审

阶段 5：渲染与交付

按以下优先级检测构建链：

1. 项目内置一键构建或导出脚本
2. scripts/manuscript_tool.py
3. Makefile
4. latexmk
5. 直接 xelatex

若存在 Word 导出链，也应尝试执行。构建日志放入当前运行目录的 render/。

• 运行准备脚本：scripts/prepare_workspace.py
• 执行护栏：references/execution-guards.md
• 风格模板：references/styles/style-template.md
• bensz-01：references/styles/bensz-01.md
• general-01：references/styles/general-01.md
• 协作计划模板：references/collaborative-plan-template.md
• 章节写作指南：references/writing-style-guide.md
• 数字审查模板：references/templates/number-check-template.md
• 章节职责审查模板：references/templates/section-role-check-template.md
• Discussion audit 模板：references/templates/discussion-role-check-template.md
• 逻辑树模板：references/templates/logic-tree-template.md
• 逻辑审查模板：references/templates/logic-check-template.md

输出

autonomous

• 直接修改目标正文文件
• 将分析、审查、渲染日志写入当前运行目录 <paper_dir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/paper-write-sci/{yyyy-mm-dd-hh-mm}/
• 若检测到可用构建链，尝试重新渲染 PDF 和 Word

collaborative

• 只输出计划文件，文件名模式以 config.yaml:runtime_outputs.collaborative_plan_pattern 为准，默认带上本轮 run_id
• 计划中总结论文缺陷、证据、建议修复方案、影响文件和风险
• 不直接修改论文内容
• 计划以外的中间文件仍写入当前运行目录 <paper_dir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/paper-write-sci/{yyyy-mm-dd-hh-mm}/

输出管理

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

除下列“明确约定的对外交付物”外，其余中间文件都必须放在 <paper_dir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/paper-write-sci/{yyyy-mm-dd-hh-mm}/：

• plans/{collaborative_plan_pattern}
• 论文最终构建产物，例如项目已有的 PDF 和 Word 输出

禁止再使用旧目录 .write-paper-sci/ 与更早的 .write-paper/。

校验

完成后执行 Skill 已有的静态检查、脚本验证或人工复核，并记录通过标准。

失败与恢复

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

约束

• 不修改 artifacts/、*.sty、*.cls、*.bst、*.bbx、*.cbx、latexmkrc
• 不改 main.tex 的结构，除非用户明确要求
• 不编造数字
• 不把缩写检查降级成“当前文件自洽”
• 不允许同一概念在不同 tex 中使用冲突缩写、冲突全称或忽有忽无的定义
• 不要为了局部简洁随意新造缩写；若新缩写不会在全文稳定复用，优先不用
• 不为“排版整齐”而重排无关段落或整节 .tex
• 不把 SCI 正文写成冒号驱动的口语化说明；冒号只用于确有必要的标签、列表、图注结构或期刊格式要求
• 不在 Introduction 中反复重提同一个核心观点、痛点或问题；每次出现都必须承担新的逻辑推进功能
• 用户要求“只改某节”时，严格限制改动范围
• 用户要求协作模式时，严格禁止直接修改论文

公共硬约束

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