polish-prose

文章を推敲する

AI 風の表現や大げさな表現を、慎重な研究者が書いたような文章に整えます。数字、主張、引用は一切変更しません。査読者は今や、LLM 特有の文体（delve や leverage のような語彙、「Moreover」で始まる段落の連続、連鎖する em ダッシュ、画一的な婉曲表現）を見抜きます。「Certainly! Here is...」や「[insert citation]」が残っているのは、投稿を即座に却下されてもおかしくない恥ずかしいミスです。このスキルはそうした表現をすべて決定論的に検出し、その後、規律ある人間参加型の書き直しを支援します。変えるのは表現であり、内容ではありません。

使用するタイミング

• 「論文が ChatGPT の文章みたいです」／「人間らしくして」／「AI っぽさを取り除いて」
• 「AI っぽい単語を削除して」／「delve や leverage を何度も使ってしまう」
• 「文章を引き締めて／磨いて」／「冗長すぎます」
• 「婉曲表現を直して」—貢献を過大に主張している、または結果が「かもしれない」だらけ
• 「貢献を示す文を能動態にして」（「ある手法が提案される…」→「私たちは提案します…」）
• 「用語に一貫性はありますか？」（dataset と data set、略語の使い方、英国式と米国式の綴り）
• 最終投稿前のチェックの一環として preflight-check の前に呼び出す場合、または LLM アシスタントを使った大量の下書きの後

入力

1. 下書き：.tex ファイル（プリアンブル、数式、verbatim は自動的にマスクされます）、.md／.txt ファイル、または stdin 経由で貼り付けたテキスト。
2. 任意：会議の会場プロファイル venues/conferences/<venue>-<year>.yml（スキーマは venues/schema.yml）—会場の分野に応じた文体規範と、AI 利用の開示義務を定める review.llm_policy を提供します。
3. 任意：プロジェクトの用語集（各行に canonical term = variant | variant の形式で記述）。チームで用語をすでに標準化している場合に使用します。

プロセス

1. まず技術的な内容を固定します。 編集前に変更禁止項目の一覧を作成します。すべての数値と単位、すべての \cite キー、記載されているすべての結果、データセット名、システム名が対象です。スナップショットを保存します。

   grep -oE '[0-9][0-9.,]*\s*(%|\\%|ms|s|GB|MB|x|×)?' draft.tex | sort | uniq -c > /tmp/numbers-before.txt
   

   同じコマンドを編集後（ステップ 9）にも実行し、同一の出力が得られなければなりません。推敲に主張の変更が必要になる場合は作業を止め、ユーザーに伝えてください。それは文体編集ではなく、内容に関する判断です。

2. 会場の文体と LLM ポリシーを確認します。 会場プロファイルが指定されている場合は、family（分野ごとの文体規範はこちら）と review.llm_policy を確認します。ポリシーを適用する前に、最新の cfp_url で必ず再確認してください。ポリシーは開催サイクルごとに頻繁に変わります。AI の支援を受けた文章を推敲しても、開示義務がなくなるわけではないことをユーザーにはっきり伝えてください。会場で AI 利用に関する記述が必要な場合は、正直な記述の作成を支援してください。このスキルを開示義務の回避策として説明してはなりません。

3. リンターを実行します（Python 3、標準ライブラリのみ、ネットワーク接続なし）。

   python3 scripts/prose_lint.py main.tex
   python3 scripts/terminology_check.py main.tex --allow GPS,SDK
   

   どちらも .tex、プレーンテキスト、または stdin を表す - を受け付けます。--json は機械可読形式の出力、--strict は検出項目が残っている場合に終了コード 1 を返します。終了コードは、0 が正常、1 が strict による失敗、2 が入力エラーです。--allow を使うと、コミュニティ内で広く知られているとみなされる略語について、未定義略語のチェックをスキップできます。--glossary FILE は用語表を適用します。検出項目は行番号付きの候補であり、自動置換は行いません。専門用語も AI らしい表現に見えることがあるためです（「leverage scores」、「robust statistics」など）。

4. RISK の検出項目はすぐに処理します。 チャットボットの痕跡（「As an AI model...」、「Certainly! Here is...」、「[insert X]」）は削除するか、内容を補ってください。未開示の LLM 出力を投稿の即時却下事由とする会場も複数あります。未記入のプレースホルダーも引用漏れに当たります。実際に必要な引用は verify-citations を通じて確認し、決してでっち上げてはなりません。

5. 編集パス A — 語彙および構成上の特徴。 references/llm-tells.mdを開き、セクションごとに作業します。 警告：専門用語である場合、または本当に最適な語である場合は、そのまま残してください （時折使う程度なら問題ありません。判断材料となるのは存在ではなく密度です）。 それ以外の場合は、書き換えパターンを適用します。「Moreover」「Furthermore」で始まる段落の連鎖は、接続語を削除して断ち切ります。論理が通らなくなる場合は、段落の順序が不適切だったということであり、把握しておく価値があります。余分な em ダッシュは、文を分けるか読点に置き換えて書き直します。編集案は差分（行番号付きの変更前 → 変更後）として提示し、ユーザーの承認を得た場合にのみ適用します。

6. 編集パス B — ヘッジ表現と主張。 references/hedging-and-claims.mdに沿って調整します。貢献、定義、完了した行為からはヘッジ表現を取り除きます（「提案します」とし、「提案しようと試みます」とはしません）。解釈、一般化、限界には、誠実なヘッジ表現を一つだけ残します。二重のヘッジ表現は一つにまとめます。「明らかに」「疑いなく」といった強調表現は削除します。根拠が主張を裏付けるか、そうでなければ何も裏付けません。貢献を述べる受動態の文は、何が新しいのかを明示する、能動態で具体的な主張に書き換えます。論文自体の根拠が裏付ける以上に主張を強めてはならず、ユーザーが測定した結果を弱めてもなりません。

7. 編集パス C — 用語。 compound-variant、spelling-mix、および頭字語の検出結果はすべて、一行の判断事項にします。各表記の件数を示し、ユーザーに標準表記を選んでもらいます（既定では最多の表記を採用し、綴りは投稿先の表記規則に従います）。その後、全体に適用します。判断内容は用語集ファイルに記録し、再実行します。

   python3 scripts/terminology_check.py main.tex --glossary glossary.txt
   

   頭字語の運用も修正します。初出時に一度だけ定義し、一貫して展開形を使用し、以降使われない定義は削除します。

8. 編集パス D — 投稿先の表記規則。 references/venue-register.mdにある分野別の規則、すなわち人称と文体の慣例、時制の使い分け、綴りの規則、短縮形の方針、および ML、システム、HCI、LNCS の投稿先における文体の違いを適用します。プロフィールが指定されていない場合は、一貫したアメリカ英語の綴りと、原稿ですでに優勢な慣例を既定とします。

9. 技術的な内容に変更がないことを確認します。 両方のリンターを再実行します（問題がない状態、または残った検出結果をユーザーがそれぞれ認識したうえで受け入れている状態にします）。ステップ 1 の数値スナップショットを再実行して差分を確認します。差異があれば編集パスの不具合なので、元に戻さなければなりません。\citeの数とキーが変わっていないことを確認します。パス B で主張の強さが変わった各文について、変更前と変更後を示す簡潔な表を提示し、ユーザーの承認を得ます。

10. CI または投稿前に任意で実施するチェック： prose_lint.py main.tex --strictは、RISK/WARNが残っていると終了コード 1 を返します。最終確認としてpreflight-checkと併せて実行すると便利です。

出力

• 行番号付きの検出結果を含む 2 つの lint レポート（Markdown または--json）。
• 差分形式の編集案。適用するのは承認後に限り、一度に 1 つのパスのみ。
• 用語判断表と、再利用可能なglossary.txt。
• 数値と引用の差分がないこと、主張の強さが変わった箇所の一覧、および受け入れ済みの検出結果を記載した検証メモ。

このスキルの対象外

• AI 検出回避ツールではありません。 目的は文章の質と誠実な文体であり、分類器を欺くことではありません。開示を義務づけている投稿先に対して、LLM の使用を隠すことがユーザーの実際の目的である場合は、その目的には応じず、投稿先のllm_policyを提示し、代わりに開示文の作成を提案します。
• 内容の編集ツールではありません。 議論の構成変更、引用の追加、論文の主張の変更は行いません。論旨の再構成にはtailor-to-venue、要旨にはwrite-abstract、参考文献にはverify-citationsを使用します。

他のスキルとの関係

• write-abstract — アブストラクト固有の構成と投稿先のメタデータに関する規範です。
• preflight-check — デスク・リジェクトを防ぐためのチェックです。推敲後に実行してください。
• anonymize-paper — 身元が特定される情報の漏洩に対応します。このスキルでは扱いません。
• verify-citations — ここで明らかになった引用の要確認事項は、すべてそちらに回してください。

専門分野に合わせる

不自然さを示す語句の辞書は分野を問わず使えますが、文体は分野によって異なります。対象分野の学術誌に合わせて references/venue-register.mdを複製・調整してください（英国式スペリングや三人称での記述を義務付ける学術誌も多くあります）。 コミュニティで使われる略語を--allowリストに追加し、prose_lint.pyのTELL_PATTERNSテーブルに分野固有の不自然さを示す表現を追加してください。

ガードレール

• 数値、結果、主張、引用、技術的な記述は決して変更しないでください。変更するのは表現だけです。必ず毎回、ステップ9の差分で確認してください。
• 辞書による検出結果を自動適用しないでください。WARNはすべて判断を要する項目であり、「leverage scores」のような専門用語に問題はありません。
• 「[insert X]」のプレースホルダーに文章を捏造して補わないでください。実際の内容をユーザーに尋ねるか、引用に関する内容はverify-citationsに回してください。
• 結果を「検出不可能」または「人間が書いたもの」として提示しないでください。AIの使用に関する開示要件を回避する手助けはしないでください。review.llm_policyを提示し、最新のcfp_urlに基づいて再確認してください。
• ユーザーに代わって、いかなるシステムにも絶対に提出しないでください。
• レポートで引用するのは、問題として指摘された行までにしてください。出力に論文の大部分を再掲しないでください。

メモリー

このスキルでは、ユーザーの論文ディレクトリ内で、共通の.paper-memory/規約を使用します （仕様全文：paper-memory-convention.md）。

• 開始時： .paper-memory/lessons.mdとprofile.ymlを読み込んでください。writing_preferences（文体の特徴、スペリング、文体上の視点）を使って目標とする文体を設定し、記録済みのrecurringな文章上の癖（例：「貢献について受動態の文で書きがち」）があれば、最初にそれを取り上げて、説明を繰り返すのではなく、まず注意を向けてください。
• 終了時： 共通形式- [YYYY-MM-DD] (polish-prose | <scope>) pattern -> recommendationで、再利用できる知見を追記してください（reflect-and-improveのreflect_log.py appendを使うと、重複を除去して日付を付けられます）。複数の草稿で見られた不自然な表現や癖はrecurring、一度限りの修正はthis-paperとして記録してください。通常の一度限りの編集は記録しないでください。
• .paper-memory/がなければ必要に応じて作成し、プロジェクトの.gitignoreに追加するかユーザーに確認してください。このディレクトリはローカル専用です。アップロードしたり、このリポジトリにコピーしたりしないでください。