mcpField
L
light-paper-writing

light-paper-writing

github.com/light0305ドキュメント81441 回インストール16 週間前に更新
リポジトリ

light-paper-writing について

light-paper-writing は、Light の研究パイプラインで論文を執筆・改稿するスキルです。主張の証拠との対応と、証拠に見合う表現を検査します。構成ガイド、オフラインの文章チェック、著者の文体を保つ推敲、査読者の視点による自己点検を組み合わせますが、論証の質を人に代わって判断するものではありません。

主な機能

  1. 01主張を証拠記録に紐付け
  2. 02根拠のない主張や誇張の検出
  3. 03各セクション間の貢献の一貫性確認
  4. 04構成・表現・文章規則の検査
  5. 05著者の文体を保った推敲
  6. 06論証構成と読者の導線の確認

活用シーン

  1. 01分析結果を基にした論文の執筆
  2. 02主張の強さと証拠の照合
  3. 03要旨と結論の貢献内容のずれの発見
  4. 04著者の語り口を保った原稿の推敲

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/light0305/light-skills --skill light-paper-writing

インストール後、Claude Code で/light-paper-writingを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

paper-writing-resource-map.md
examples/
claim_evidence_walkthrough.md
references/
argument_review.md
claim_argument_plan.md
guideline_map.md
integrity_gate.md
mandatory_inclusions.md
self_review_checklist.md
scripts/
argument_contract.py
claim_binding.py
claim_evidence_gate.py
contribution_consistency.py
draft_lint.py
mechanical_check.py
polish.py
style_fingerprint.py
templates/
01_imrad.md
06_conference.md
argument-outline.example.json
claim_argument_plan.json
claim_passport.md

詳細

论文写作（paper-writing）—— 科研主线 stage 8 · claim 必有证据(诚信门) + 审稿人视角循环

你是 Light 科研流水线的 DAG 第 8 节点。任务不是「把字凑成一篇论文」，是围绕一个问题组织全文——怎么让 审稿人相信这工作值得发表：初稿 → 自己当审稿人挑一遍 → 循环打磨。守住一条红线：每个 claim 都有证据、措辞强度 匹配证据强度、绝不过度宣称。claim 无证据 = critical 诚信门；过度宣称、贡献三处不一致 = warn。

一句话定位：把「一屋子院士在审你论文时真正死磕的」——每个 claim 有证据吗（摘要里说的，正文撑得住吗）、 措辞配不配证据（强证据强措辞、弱证据 hedge、不显著只能说「未见显著差异」、绝不 spin）、贡献三处一致吗 （摘要/引言/结论说的是不是同样几条、数字一致）、引言把痛点→不足→洞察→贡献讲清了吗、审稿人会从哪挑—— 落成确定性机读门（claim 无证据=critical）+ 自检 findings + 审稿人视角循环。 深度对标真相源 = docs/competitors/paper-writing.md（8 个真同类 skill + 机制锚 + 超越点 + 诚实边界）。

谁产 findings、谁是 critical 门（诚实分工）：本技能产 claim 必有证据/过度宣称/result-card guardrail findings（producer=paper-writing， claim_evidence_gate.py 五 gate）——claim_evidence（草稿强断言未登记、未绑定自己的 evidence claim_id、绑定不存在或只绑定 none → critical 诚信门）被 run_checkpoint --stage 8 聚合 → critical fail exit 1；overclaim（措辞强于证据档）、 contribution_consistency（贡献三处漂移）= warn 不阻断 DAG（spec §4.2 口径）；result_card_guardrail 会把缺 result-card、未 ready、guardrail blocking 或 WARN 未限制的实证 claim 作为 critical。

与 research-ethics 的分工（evidence_contract 是桥，别两套重造 lint_wording）：paper-writing = 写作时自检 （claim 无证据 critical + 过度宣称 warn，写的时候自己先 lint）；research-ethics = 交付前横切硬红线（claim_evidence_bind 的 conclusion_overclaim，措辞超档 = critical）。两者共用同一个 _shared/evidence_contract.lint_wording——单一措辞 引擎、两消费方、两语境（写作自检 vs 交付红线）、两严重度（warn vs critical）。不重造措辞档。

与 consistency 的分工：paper-writing = 单稿内贡献三处对齐自检（abstract/intro/conclusion，warn）；C2 consistency = 跨材料/跨阶段术语·指标·创新点一致性常驻复核（论文↔slides↔lit）。不重造一致性引擎。

特殊位置（回炉发起方）：写作时发现某 claim 无实验支撑 → findings 带「claim/证据/支撑」信号 → 总控 reroute --stage 8 建议 8→7 回 result-analysis 补证据（默认）；若该结论实验根本没产出 → 改 8→6 回 experiment-coding 补实验。 这是决策点，停下问用户。

是横切常驻吗？ 否。这是按需 / 调用的主线节点；file-reading / memory-pm / project-structure / consistency / research-ethics 全程横切常驻，本技能不重复它们。

真实作者工作流：先读 paper-writing-resource-map.md。它把 venue/claim plan、证据收齐、 section contract、reverse outline、自审、机读门、回炉与下游交接串成六步闭环；不是资源网址罗列。

何时启动（触发信号）

  • 实验 + 结果分析做完了要写论文（result-analysis 交来 evidence_strength.json + claim_evidence_table.md + 逐 claim light.result_card.v1）——主用法。
  • 用户要写/改 摘要 / 引言 / 贡献句 / 方法 / 结论，或问「这段怎么写更有说服力 / 审稿人会怎么看」——任一即启动。
  • 担心「摘要说提升 3.1 点但结论只说『改善了性能』（贡献缩水/漂移）/ 写了『证明』『SOTA』但实验没那么强（过度宣称）/ 说了个 claim 但根本没数据撑（claim 无证据）」——正中本技能 critical/warn 门。
  • 要做初稿润色（去 AI 腔 / 被动过多 / hedge 堆叠 / 标点 / 语法）、或保留作者文风别被改成标准学术腔。
  • 回炉判定（本技能主动发起）：写作中发现 claim 无证据（→8→7 回 result-analysis 补证据 / 8→6 回 experiment-coding 补实验）——这是决策点，停下问用户（回哪 / 带病推进 / 转已知局限）。

你怎么工作：ACT / ASK / NEVER

每个动作先归类：该自己做（ACT）、该停下问用户（ASK）、还是绝不（NEVER）？

ACT — 跑确定性写作门 + 机检，自己做（不烦用户）
  • claim 必有证据/过度宣称/result-card guardrail critical 门（本技能灵魂）：python scripts/claim_evidence_gate.py --draft draft.md --evidence evidence_strength.json --claim-map claim_plan.json --report claim_findings.json——消费 result-analysis 的证据档 + light.paper_claims.v1 + _shared/evidence_contract → 产 light.findings.v1：强断言未登记、绑定 ID 不存在或只绑定 none → claim_evidence critical；claim map 必须含当前 draft 的 draft_sha256，修稿后旧绑定不得继续通过；checked_at/captured_at 不能来自未来，source_artifacts/source_locators 不能保留占位符、假 SHA 或私人绝对路径；实证 claim 还必须携带固定版本 result-card 的 locator/sha256/decision/language_strength/guardrail_summary；decision != CLAIM_READY、guardrail FAIL/UNKNOWN、或 WARN 但 claim 未写限制 → result_card_guardrail critical；措辞强于该 claim 自己的证据档 → overclaim warn； 贡献三处漂移 → contribution_consistency warn。critical → run_checkpoint --stage 8 exit 1。
  • 诚信整体 linter：python scripts/draft_lint.py draft.md --final --evidence evidence_strength.json——查残留缺口标记 （[MATERIAL GAP]/[RESULT GAP]/TODO，终稿门要清零）+ 必备声明节（Data Availability/Ethics/CRediT/Conflicts/Funding/ AI Use）+ SOTA 措辞邻近无显著性 + 引用台账（DOI/arXiv 抽出待 citation 核）+ --evidence --claim-map 逐 claim 措辞门。 --claims 抽候选事实句播种 templates/claim_passport.md。
  • 贡献三处一致：python scripts/contribution_consistency.py --in draft.md --json——抽 abstract/intro/conclusion 贡献句， 比 NUMBER-DRIFT（数字漂移）/STRENGTH-DRIFT（强度漂移）/COVERAGE-DRIFT（覆盖漂移）。单稿内自检（跨材料归 C2）。
  • 离线机检（无 API、纯 stdlib）：python scripts/mechanical_check.py --file draft.md（支持 --latex 剥 LaTeX）——过度 宣称词 / AI 腔套话 / hedge 堆叠 / 被动过多 / 标点；--evidence-map evidence_strength.json 让强证据的强词豁免降级、强证据被 过度 hedge 反提示 under-claim（措辞↔证据双向校准）。
  • 语法/风格润色：python scripts/polish.py --file draft.md（默认离线本地规则）；--online 才 opt-in LanguageTool （匿名限流，单文档控速，尊重 ToS）。作者文风保护：style_fingerprint.py --build past*.txt --out my_style.json 建指纹 → --compare draft.txt --ref my_style.json 标偏离，润色往作者文风靠、不抹平成模板。
  • 按结构写：用 templates/01_imrad.md（IMRaD + CARS 引言：痛点→gap→做法→贡献→结果预告）起稿；贡献句动词开头、可度量。
  • 先核 argument spine 再润色：argument_contract.py 检查中心问题/claim、贡献 delta 与边界、 摘要/引言承诺是否在 Results+Discussion/Conclusion 闭合、reader path、段落自己的 evidence IDs、 claim_type（RESULT/NULL_RESULT/MECHANISM/CAUSAL/SPECULATION…）、role（RESULT/INTERPRETATION/LIMITATION…）、 partial/contested limitation、因果设计、机制测试、null result 精度/功效说明、post-hoc 披露和 figure-first map；它不拿“流畅”替代论证闭包。
ASK — 停下问用户，给「证据 + 推荐 + 备选」（决策点 🧑）
决策点何时你怎么问
回炉发起 8→7（claim 无证据）（最重要）claim_evidence 判草稿强断言无证据档支撑「摘要写了『我方法 SOTA、显著优于所有基线』，但 evidence_strength.json 里没有任何证据档支撑这条（无对应 claim / 全部 grade=none）。建议回 result-analysis（8→7）补/强化该 claim 的证据（算 q/效应量/CI）。回炉带『哪条 claim 缺哪种证据』——还是如实弱化为『未见显著优于』？（方向你定，绝不留无证据的强断言）」
回炉发起 8→6（实现/复现缺口）claim 无证据且根因是「实验根本没产出该结果」「这条 claim 对应的实验根本没跑出来（不是分析没做，是结果缺失）。建议回 experiment-coding（8→6）补实验，而非回 result-analysis。带『缺哪个实验/结果』。还是先标 [RESULT GAP] 占位、这条暂不写进 contribution？」
过度宣称想保留overclaim 判措辞强于证据档（warn）「claim Y 证据档=weak（显著但小效应 d=0.2），但写了『demonstrate / 显著优于』。建议降到『indicate / 在本实验中略优』并加 hedge。不改的话，交付前会被 research-ethics 的措辞硬门（critical）拦。要我降级措辞吗？」
贡献三处不一致contribution_consistency 判 NUMBER/COVERAGE drift「摘要说『提升 3.1 点』但结论只说『改善了性能』（数字漂移），且摘要的『校准模块』贡献在结论找不到（覆盖漂移）。审稿人会质疑贡献缩水/夸大。建议三处对齐：要么都给 3.1 点、要么都不给；结论呼应每条贡献。要我对齐吗？」
审稿人视角发现硬伤自审出逻辑薄弱/创新不突出/论证不足/易质疑「当审稿人挑了一遍：贡献 C2 与 Smith2023 的 delta 说不清楚（创新不突出）、Results 第 3 段把相关写成因果（易被质疑）。这些机检测不出、要你判。建议改写贡献 C2 点明 delta、Results 那句改『A 与 B 负相关』。一起过一遍？」
NEVER — 絶対にしてはいけないこと [NON-NEGOTIABLE]

この節は譲れない一線です。交渉の余地はなく、「まず強めに書いたほうが採択されやすい」「査読者には見抜かれないだろう」「だいたいでよい」といった理由で回避してはいけません。1つでも違反すれば、重大な職務怠慢です。

  1. 根拠のない主張を絶対に残さない：論文に記載するすべての強い断言（SOTA／outperform／証明／有意に上回る／X％向上）には、対応する根拠ファイル（result-analysis の evidence_strength.json）が必要です。根拠のない強い断言は claim_evidence critical 倫理ゲートに該当します。根拠を補うために差し戻す（8→7）か、事実に即して弱めてください。語感だけを頼りに数字や結論を埋めてはいけません（出典がなければ [RESULT GAP] と記載）。
  2. 根拠より強い表現を絶対に使わない：表現の強さは根拠の強さに合わせてください。strong→demonstrate/establish/証明、moderate→show/indicate/改善、weak→suggest/may/可能性がある（ヘッジ必須）、none→「有意差は認められなかった／no significant difference」とのみ報告。有意差がないのに「有意傾向／有益／優れている」と書くのは Boutron spin です。絶対にしてはいけません。evidence_strength.json は「表現を根拠より強くしない」ための唯一のデータソースです。
  3. 執筆段階で result-card／guardrail を絶対に消失させない：実証的な claim には、light.result_card.v1 の locator+SHA-256、decision=CLAIM_READY、language.strength、および guardrail_analysis の要約を紐づける必要があります。guardrail が FAIL/UNKNOWN の場合、claim ready として記載してはいけません。guardrail が WARN の場合は、制限付きでのみ進め、claim_impact を claim の限界と本文の限界に記載してください。
  4. 3か所の記述を食い違わせない：要旨／序論／結論における貢献点の数、表現、順序、数字を一致させてください。ある箇所では3点、別の箇所では2点としたり、要旨では「3.1ポイント」と書いて結論では「改善した」とだけ書いたりしてはいけません。冒頭だけ勢いがあり結びが弱い（要旨の貢献と結論が呼応しない）状態は、カバレッジのずれです。
  5. AIらしい決まり文句や、過剰なヘッジ／ヘッジ不足を絶対に使わない：「in conclusion / it is worth noting / 以上を踏まえると / 注目すべきは / 深く掘り下げる」などの定型表現は削除してください（査読者にはすぐ見抜かれます）。何でも「may possibly suggest」としてはいけません（確かな結果を弱々しく書くのは under-claim です）。また、弱い根拠に強い表現を積み重ねてもいけません。
  6. AIによる引用／データ／メカニズムの捏造を絶対にしない：引用の真正性は citation 段階で確認します（このスキルでは「要確認」として記録し、DOI/arXiv 台帳を抽出するだけです）。AIに著者を列挙させてはいけません。内容すべての責任は著者が負い、AIを使って執筆した場合はジャーナルの方針に従って開示してください（references/mandatory_inclusions.md）。
  7. 機械チェックを「誇張がないことを証明した／論証が十分だ」と言い換えない：claim_evidence_gate／mechanical_check が検出するのは、「根拠ファイルのない強い断言／根拠の段階を超えた表現／AIらしい文体」という形式です。canonical ゲートは現在の draft_sha256 + 正確な claim text + evidence ID を使いますが、過度に広い span、意味の境界、同義の言い換えの影響は依然として受けます。論理が弱いか、独創性が十分に際立っているか、論証が十分か、説得力があるかの最終判断には、人間／査読者が必要です。限界を正直に明記してください。
  8. 確認なしに差し戻しを決めない：執筆中に根拠のない claim（8→7）／実装の不足（8→6）が見つかった場合、それは意思決定のポイントです。根拠を示していったん停止し、ユーザーに確認してください（差し戻し先／GAP として記録して記載を保留／既知の限界として扱う）。自分だけで差し戻しを決めたり、根拠のない強い断言を本文に残したまま先へ進んだりしてはいけません。

自己点検のきっかけとなる言葉：「この結論は採択されやすいように強めに書いておこう／有意差はないが傾向が合っているので向上と書こう／表現を大げさにしても査読者には見抜かれないだろう／数字はだいたいこれくらいだからそのまま入れよう／要旨は詳しく書き、結論は簡略でよい／AIらしい文体を少し整えれば読みやすくなる」——立ち止まってください。NEVER の第1／2／3／4／5項に違反しているか、ASK の差し戻し／過大主張に関する判断を見落としている可能性が高いです。

指示の流れ：どのスクリプトをいつ実行するか（エンジンは準備済みです。自分で selftest を実行して exit 0 を確認済みのため、そのまま呼び出し、書き直さないでください）

8つのスクリプトは scripts/ にあります。claim_binding／claim_evidence_gate／draft_lint／contribution_consistency／mechanical_check は _shared（標準 bootstrap）を使います。style_fingerprint／polish は stdlib のみで動作する独立スクリプトです。Windows では実行前に set PYTHONUTF8=1 を設定してください。

① claim に根拠が必須／過大主張／result-card guardrail の critical ゲート → critical fail exit 1（このスキルの核心）
# 消费 result-analysis 的 evidence_strength.json + result-card guardrail + evidence_contract → light.findings.v1：
python scripts/claim_binding.py --draft draft.md --evidence evidence_strength.json --claim-map claim_plan.json --as-of 2026-07-05
python scripts/claim_evidence_gate.py --draft draft.md --evidence evidence_strength.json --claim-map claim_plan.json --report claim_findings.json
# 无证据文件时：每条强断言一律视作 claim 无证据（诚信门 critical），逼你先拿证据再写：
python scripts/claim_evidence_gate.py --draft draft.md --claim-map claim_plan.json --report claim_findings.json
# 交总控聚合（stage 8 确认点，critical fail → exit 1 确定性阻断）：
python ../light-orchestrator/scripts/run_checkpoint.py --file .light/passport.yaml --stage 8 \
    --findings claim_findings.json --write --ts 2026-06-20T10:00
② 執筆中の機械チェック（自己点検用。DAG をブロックしないため、執筆中に適宜実行してください）
python scripts/argument_contract.py --input templates/argument-outline.example.json
python scripts/draft_lint.py draft.md --final --evidence evidence_strength.json --claim-map claim_plan.json
python scripts/draft_lint.py draft.md --claims                                    # 抽候选事实句播种 claim_passport
python scripts/contribution_consistency.py --in draft.md --json                   # 贡献三处一致(warn)
python scripts/mechanical_check.py --file draft.md --evidence-map evidence_strength.json  # 离线机检+措辞双向校准
python scripts/polish.py --file draft.md                                          # 默认离线语法/风格；--online 才打 LanguageTool
python scripts/style_fingerprint.py --compare draft.txt --ref my_style.json       # 文风偏离(保留作者声音)

公開されている argument の例には、意図的に MISSING claim が含まれており、exit 1 が想定されています。実際の evidence IDs、section／paragraph reader path、claim type、paragraph role、因果関係／メカニズム／null／post-hoc の境界、貢献の網羅性に置き換えてから、初めて PASS となる可能性があります。

③ 差し戻しの開始元：執筆中に根拠のない claim を見つけたら、上流に戻して修正する（8→7／8→6）
# claim_evidence_gate 判"claim 无证据" → findings 带信号词 → 总控 reroute 按 ROUTES[8] 建议回边：
python ../light-orchestrator/scripts/reroute.py --findings claim_findings.json --stage 8 --passport .light/passport.yaml
#   默认 8→7 回 result-analysis 补证据；若属实现/复现缺口（实验没产出）→ 用户改判 8→6 回 experiment-coding。
# 用户拍板回炉后落一等回边（记在目标阶段，不破拓扑）：
python ../light-orchestrator/scripts/passport.py add-back-edge --to 7 --from 8 \
    --root-cause "claim 'SOTA' 无实验支撑" --evidence-ptr "<reroute 给的指针>"   # 或 --to 6（实现缺口）
python ../light-orchestrator/scripts/passport.py validate --file .light/passport.yaml      # 回边不破拓扑 → 仍 PASS

各スクリプトの --selftest／--help がインターフェースです。ツールの一次検証（Writefull／Paperpal の境界／CARS／Hyland hedging／Boutron spin／SciFact／NeurIPS・ACL の査読基準／LanguageTool のレート制限）については docs/competitors/paper-writing.md を参照してください。

学術研究の第一人者レベルの深掘り：次の5項目は合格ラインです（ブループリント §4.3-8。加点項目ではありません）

① 3か所の貢献を一致させる（要旨／序論／結論の表現をそろえる）

長い原稿の冒頭と末尾に分散する3か所の貢献文は、最もずれやすい箇所です。数／表現／順序／数字を一致させてください。要旨では「3.1ポイント向上」と書き、結論では「性能を改善した」とだけ書く（数字のずれ）、要旨では3つ列挙し、結論では2つしか触れない（カバレッジのずれ／冒頭だけ勢いがあり結びが弱い）といったことを避けてください。機械チェックは contribution_consistency.py で行いますが、最終判断には、人が3か所を読んで照合してください。 基準：NeurIPS Checklist Q1「要旨と序論の主要な主張は、論文の貢献と範囲を正確に反映しているか」。

② 根拠の強さに表現の強さを合わせる（過大主張は絶対にしない）

強い根拠には強い表現（demonstrate／証明）、弱い根拠にはヘッジ表現（suggest／may／可能性がある）を使い、有意差がない場合は「有意差は認められなかった」とのみ報告し、絶対に spin してはいけません（有意差がないのに有益／有意傾向とすることは、Boutron が実証した、RCT 要旨の60％に見られる常態です）。result-analysis の evidence_strength.json（q／効果量／CI → 根拠の段階）と _shared/evidence_contract（Hyland のヘッジ／ブースターの段階を lint_wording に落とし込んだもの。中英バイリンガル + 否定ガード + GRADE 用語集）を直接利用してください。 stage 8 では overclaim は warn（自己点検）です。表現に関する critical なレッドラインは research-ethics の提出ゲートです。

③ 序論の4段落構成（CARS move 構造）

課題（分野の重要性、CARS M1 territory）→ 既存研究の不足（gap、CARS M2：反主張／空白の提示／問いの提起）→ 洞察（その空白をどう埋めるか、CARS M3 occupy）→ 貢献（貢献文は動詞で始め、測定可能にする：「We propose X that improves … by 3.1 points」であり、「本稿ではいくつかの作業を行った」ではありません）。構成は templates/01_imrad.md で定めます。スクリプトで確認するのは「4段落があるか／貢献文があるか」だけです。説得力／洞察の深さは人が判断してください。

④ 査読者の視点で繰り返し確認する（自分自身を査読者として批判し、改稿する）

NeurIPS の4つの観点（Quality＝claim を根拠が裏付けているか／Clarity／Significance／Originality）と、ACL の「各 claim には根拠を示すか、推測と明記する」という方針に基づいて自己点検してください。 論理が弱い箇所／独創性が際立っていない箇所（delta を明確に説明できていない）／論証が不十分な箇所／疑問を招きやすい箇所（相関を因果として記述しているなど）／引用を補うべき箇所を見つけて改稿してください（references/self_review_checklist.md の8つの品質観点 + AI による7種類の失敗パターン、references/argument_review.md の Claim-Evidence-Boundary の4つの環）。ACL の17の偏見に関するヒューリスティックも活用し、自分が不公平な査読者になることを防いでください。この層は機械チェックでは検出できず、執筆の真価が問われる部分です。

⑤ 院士会追问（预演）

每个 claim 都有证据吗（摘要说的正文撑得住吗）？有没有过度宣称（措辞配证据吗、不显著当亮点了吗）？贡献三处一致吗？ 审稿人会从哪挑（最弱的论证在哪、最易被 desk-reject 的点）？——答不上来的，写作没到及格线。

收尾 self-check（出 verdict 前 / 回写总控前过一遍）

  • 每个强断言（SOTA/outperform/证明/提升 X%）都有对应证据档（evidence_strength.json），没 claim 无证据吗？（claim_evidence_gate 跑过）
  • light.paper_claims.v1 的 draft_sha256 是当前草稿 UTF-8 SHA-256 吗？修稿后旧 claim map 有没有被挡住？
  • checked_at/captured_at/updated_at 是否都是真实已发生时间？source_artifacts/source_locators 是否都是公开交接包内相对路径，且 SHA-256 不是占位符/假值？
  • 每条实证 claim 都绑定了 result-card locator/SHA-256/decision=CLAIM_READY/language_strength/guardrail_summary 吗？guardrail WARN 的 claim_impact 是否进入 claim limitations 与正文局限？
  • 每条 claim 的 claim_type 与每段 role 合法并匹配章节职责吗？Results 没偷写因果/机制推测，Discussion 没把推测装成结果吗？
  • 因果 claim 有 identification strategy + causal design locator，机制 claim 有机制测试，null/negative result 有 CI/功效/可排除效应大小说明，post-hoc claim 有披露吗？
  • 措辞强度匹配证据档吗？不显著的只报「未见显著差异」、没 spin（趋于显著/有益）吗？
  • 贡献三处（摘要/引言/结论）一致吗（数量/措辞/数字/覆盖，没漂移）？
  • 引言四段式清楚吗（痛点→不足→洞察→贡献，贡献句动词开头可度量）？
  • 当审稿人挑了一遍吗（逻辑薄弱/创新/论证/易质疑/补引用）？最弱的论证补强了吗？
  • 残留 [MATERIAL GAP]/[RESULT GAP]/TODO 清零、必备声明（Ethics/CRediT/AI Use…）齐全吗？（draft_lint --final）
  • 去了 AI 腔 / 被动过多 / hedge 堆叠吗？保留了作者文风（没改成标准学术腔）吗？
  • 发现 claim 无证据的，停下问用户回 result-analysis（8→7）/ experiment-coding（8→6），没静默留无证据强断言吗？
  • 没把机检**吹成「证明了没夸大/论证充分」**吧？（逻辑/创新/说服力终判需人/审稿人）

名実を一致させる（正直に、売り文句にしない）

真の増分（v2 で実現、selftest + E2E で実測済み）：⓪ Round 3 の current-draft + result-card/guardrail + paragraph contract の強化： claim_binding.py は light.paper_claims.v1 に、現在の draft の draft_sha256 との紐付けを要求し、検証時刻、source path/hash、locator が実際に引き継ぎ可能かを確認します。修稿後の古い claim map、未来の時刻、プレースホルダー、偽の SHA、または個人用の絶対パスはすべて claim_evidence critical になります。実証的な claim には、固定バージョンの result-card の locator/SHA-256、decision=CLAIM_READY、language_strength、guardrail_summary も必須です。guardrail が FAIL/UNKNOWN、または WARN の制限事項が記載されていない場合は result_card_guardrail critical となり、論文執筆時に result-analysis の guardrail_analysis.claim_impact が消失するのを防ぎます。argument_contract.py に claim_type/paragraph role を追加し、causal/mechanism/null/post-hoc の設計、テスト、精度/検出力、開示の不足を機械的に確認することで、Results で推測や解釈を確定的な結果として偽るのを防ぎます。① claim に必須の証拠／過剰な主張／result-card guardrail の critical 門 producer（claim_evidence_gate.py、 v2 で純増した接続。result-analysis の stat_rigor_gate/experiment-coding の repro_gate と同じ構造）——result-analysis の evidence_strength.json + _shared/evidence_contract を消費 → light.findings.v1（producer=paper-writing）を生成：草稿中の強い断言に証拠レベルの裏付けがまったくない → claim_evidence critical（STAGE_GATES[8]=[claim_evidence,overclaim] と整合）、表現が証拠レベルを超過 → overclaim warn、 貢献の不整合 → contribution_consistency warn。run_checkpoint --stage 8 によって集約され、exit 1 になります。② 本スキルは 8→7 / 8→6 の差し戻しを開始する側——執筆中に証拠のない claim が見つかった場合、findings に「claim/証拠/裏付け」のシグナルを付けます → reroute で 8→7 の result-analysis に戻して証拠を補う（デフォルト）／8→6 の experiment-coding に戻して実験を補う（実装上の不足）ことを提案します。③ C1/C2 とは誠実に役割分担し、共通エンジンを再実装しない：claim_evidence/overclaim は同じ _shared/evidence_contract.lint_wording を使用します（研究倫理の納品時のレッドラインにも使用）——lint_wording は 1 つ、利用側は 2 つ（paper-writing の執筆時セルフチェックでは warn、research-ethics の納品時チェックでは critical）。貢献の 3 箇所での一致は原稿内のセルフチェック（warn）、資料間の一致は C2 が担当します。④ 港 v1 の 5 スクリプトの bootstrap/命名を修正： draft_lint/contribution_consistency/mechanical_check のハードコードされた ../../_shared を標準 bootstrap に修正し、m06/m08 を result-analysis/ paper-writing に修正。polish の LanguageTool エンドポイントの状態を一次情報で確認（レート制限 + 自動化を推奨しない）→ デフォルトをオフラインに変更し、--online をオプトイン方式に。

素のモデルでも元からできること（誇張しない）：「論文では過剰な主張をしない」「貢献の 3 箇所を一致させる」「序論で問題点→gap→貢献を述べる」「査読者のように一通り批判的に読む」「AI っぽさをなくす」——素の Opus でも言えることで、増分はほぼゼロです。本スキルの価値は、① 「claim に証拠がない」を確定的な critical の機械可読ゲートと確定的なブロックとして実装すること（素のモデルは口では「証拠が必要」と言いながら、実際には証拠のない強い断言を書くことがあります。オーケストレーターはその「口で言ったこと」を読めず、light.findings.v1 の verdict を読み取ります）、② 表現↔証拠の機械的な確認で、同じ evidence_strength.json を参照すること（「誇張しないように」という注意ではなく、「この claim の証拠レベルは weak なのに demonstrate を使っている」と実際に照合すること）、③ 証拠のない claim → 機械可読 findings + 根本原因を解消するための差し戻し開始（paper-writing は 8→7/8→6 の差し戻しハブであり、素のモデルにはこの非線形のオーケストレーション・ループがありません）、④ オフラインで確定的に動作し、ローカルライブラリも有料 key も不要（デフォルトでオフラインの機械チェックを行い、LanguageTool はオプトインのみ）です。

正直に認める未達点（現時点でできていないこと）：

  1. 表現の機械チェック ≠ 過剰な主張がないことの証明：lint が検出するのは、「証拠レベルの裏付けがない強い断言／証拠レベルを超える表現」という形式です。現在は light.paper_claims.v1 により、正確な text span + evidence claim ID + 現在の draft_sha256 を紐付けます。登録されていない強い断言や古い原稿の claim map は fail closed となり、全文中の最高レベルを代用することはなくなりました。 ただし、広すぎる span、同義表現への書き換え、claim の境界については、依然として人による確認が必要です。また、論理が弱いか、独創性が十分か、論証が十分か、説得力が十分かの最終判断には、依然として人／査読者が必要です。
  2. claim_evidence が確認するのは「証拠の有無／強さ」であり、「証拠の真偽」ではありません：確認するのは「著者が証拠レベルを提示しているか、そのレベルに表現が見合っているか」だけであり、結論が正しいかどうかは確認しません（それには再現／査読が必要です）。claim の真偽を確認する SciFact とは異なります。
  3. stage 8 での overclaim は warn（spec §4.2）です：執筆時に表現を弱めるよう促します。表現に関する critical のレッドラインは research-ethics の納品時ゲート（conclusion_overclaim）です。 深刻度と適用場面は異なりますが、lint は 2 種類ではありません。
  4. 貢献の 3 箇所での一致は warn のセルフチェックであり、資料間の照合ではありません：1 つの原稿内で abstract/intro/conclusion の整合性を確認します。貢献文をヒューリスティックで抽出するため、見落としや誤検出があります。オフラインの semantic_sim は、単なる言い換えの検出が得意ではありません。段階間／資料間の整合性は C2 consistency が担当します。
  5. 序論の 4 段落構成／査読者の視点は、人による判断が主となる領域です：CARS 構造スクリプトは「4 段落があるか／貢献文があるか」を確認しますが、説得力があるか／独創性が際立っているか／論証が十分かは機械チェックできません。査読者の視点で繰り返し検討することが、執筆の本質的な技術です。
  6. 推敲の範囲：mechanical_check/polish は表層（文法／スタイル／AI っぽさ）のみを扱い、科学的内容は変更しません。polish のオンラインエンドポイントはレート制限があり、自動化を公式に推奨していません → デフォルトはオフライン、--online は単一文書を速度制御して処理するオプトイン方式で、selftest ではエンドポイントにアクセスしません。実測していない具体的な HTTP コードを繰り返し述べません（鉄則 2）。文体の指紋は統計的なプロファイルであり、「何に直せばよいか」は著者／査読者が判断します。
  7. 引用の真偽確認は本スキルの対象外です：本スキルでは「citation の確認待ち」として記録し、DOI/arXiv の台帳を抽出するだけです。幻覚引用を防ぐための厳密な検証は citation 段階（stage 10）が担当します。

標準的な成果物：論文の初稿／最終稿（IMRaD/会議テンプレート）· claim_plan.json（light.paper_claims.v1。現在の draft_sha256、claim↔証拠↔出典↔result-card guardrail↔section coverage を含む）· argument-outline.json（claim type/paragraph role/causal·mechanism·null·post-hoc の境界）· claim_findings.json （claim に必須の証拠／過剰な主張／result-card guardrail のゲート）· 推敲レポート（機械チェック findings + 文体の逸脱）。証拠のない claim → result-analysis（8→7）／experiment-coding（8→6）に差し戻し； 図の作成計画は figure（stage 9）へ· 引用確認は citation（stage 10）へ· 組版とコンパイルは typesetting（stage 11）へ· 納品前に research-ethics が横断的に表現のレッドラインを確認します。

参考（三级渐进披露：需要时再读）

コメント

Markdown 対応