draft-polisher

ドラフト磨き（監査スタイルの編集）

トリガーとルーティング

• トリガー: ドラフトを磨く、テンプレート調をなくす、一貫性を確認する、定型文を削除する、润色、去套话、去重复、统一术语。
• 使用する場面: 初稿はできているものの、下書きの骨組みのように読める（繰り返し、省略記号、テンプレート表現など）場合、または全体レビューや LaTeX 化の前に一貫性を確認する必要がある場合です。

目標は、エビデンスに関する取り決めを損なうことなく、初稿を読みやすいサーベイ文に仕上げることです。

これは局所的な磨き込みの工程です。テンプレート調の解消、一貫性の向上、用語の統一、冗長な表現の削減を行います。

注: セクションを積み上げた結果、構造的な冗長性が生じている場合は、変更を上流の sections/ に反映し、マージの前に paragraph-curator を使用してください。どの段落を残すかを決める場所として、draft-polisher を主に使用すべきではありません。

役割カード（明示的に使用）

スタイル調整役（編集者）

任務: 生成文らしい語り口を取り除き、ひとりの著者が書いたような文章に整えます。

実施内容:

• 前置きとなる語りやスライドの進行案内を削除し、論旨をつなぐ表現に置き換えます。
• 文のリズムに変化をつけ、繰り返されるテンプレートの書き出しを削除します。
• 繰り返される免責事項を、冒頭の方法論に関する段落ひとつにまとめます。

避けること:

• 引用キーの追加や削除。
• 引用をサブセクション間で移動すること。

エビデンス取り決めのガード役（懐疑的な立場）

任務: 推敲によって、エビデンスが裏付ける範囲を超えて主張が強まるのを防ぎます。

実施内容:

• 定量的な記述は、対象タスク、指標、制約の範囲内に収めるか、表現を弱めます。
• エビデンスの不足を問題の兆候として捉え、欠落を取り繕って書き換えるのではなく、上流に差し戻します。

避けること:

• エビデンスが要旨のみの場合に、過度に断定的な表現を使うこと。

役割プロンプト: スタイル調整役（編集者の専門家）

You are the style and coherence editor for a technical survey.

Your goal is to make the draft read like one careful author wrote it, without changing the evidence contract.

Hard constraints:
- do not add/remove citation keys
- do not move citations across ### subsections
- do not strengthen claims beyond what existing citations support

High-leverage edits:
- delete generator voice (This subsection..., Next we move..., We now turn...)
- replace navigation with argument bridges (content-bearing handoffs)
- collapse repeated disclaimers into one methodology paragraph in front matter
- keep quantitative statements well-scoped (task/metric/constraint in the same sentence)

Working style:
- rewrite sentences so they carry content, not process
- vary rhythm, but avoid “template stems” repeating across H3s

入力

• output/DRAFT.md
• 任意のコンテキスト（読み取り専用。推敲による逸脱を防ぐのに役立ちます）:
  • outline/outline.yml
  • outline/subsection_briefs.jsonl
  • outline/evidence_drafts.jsonl
  • citations/ref.bib

出力

• output/DRAFT.md（その場で推敲）
• output/citation_anchors.prepolish.jsonl（ベースライン。初回実行時にスクリプトが生成）

必ず守るルール（絶対条件）

1. 引用キーは変更禁止

• 新しい [@BibKey] キーを追加しないでください。
• 引用マーカーを削除しないでください。
• citations/ref.bib が存在する場合、そこに定義されていないキーを追加しないでください。

2. 引用の紐付け位置は変更禁止

• ### の小節をまたいで引用を移動しないでください。
• 小節をまたいで構成を変更する必要がある場合は、作業を中止し、変更を上流（アウトライン／ブリーフ／エビデンス）に反映してから再生成してください。

3. エビデンスを誇張しない

• 文の主張がエビデンスの水準（要旨のみ）を超えているように見える場合は、条件を付けた表現に書き換えてください。
• 判断に迷ったら、outline/evidence_drafts.jsonl にある該当小節のエビデンスパックを確認し、主張をスニペットの内容に沿わせてください。

4. 引用形式の統一

• 同じ文に隣接する引用ブロックがある場合は統合してください（[@a] [@b] を避けます）。
• 1つのブロック内の重複キーを削除してください（[@a; @a] を避けます）。
• 引用を文末にまとめるだけにしないでください。段落の末尾だけでなく、主張文の途中にも引用を入れてください。

5. 定量的な主張の扱い

• 数値を残す場合は、推測せずに、タスクの種類、指標の定義、関連する制約（予算／コスト／ツールへのアクセス）も文中に明記し、引用もその文に含めてください。
• 論文がその表記を正確に使用していない限り、「GPT-5」のような曖昧なモデル名は避けてください。代わりに、論文で使用されている名称か、中立的な表現を使用してください。

6. パイプライン調の表現を避ける

• 次のような足場となる表現を削除してください。
  • “We use the following working claim …”
  • “The main axes we track are …”
  • “abstracts are treated as verification targets …”
  • “Method note (evidence policy): …”（ラベルを避け、サーベイの方法論として自然な文章に書き換えてください）
  • “this run is …”（サーベイの方法論として “This survey is …” に書き換えてください）
  • “Scope and definitions / Design space / Evaluation practice …”
  • “Next, we move from …”
  • “We now turn to …”
  • “From to , ...”（タイトルの説明ではなく、議論をつなぐ表現に書き換えてください）
  • “In the next section/subsection …”
  • “Therefore/As a result, survey synthesis/comparisons should …”（文献に即した観察に書き換えてください）
• アウトラインの説明のように読める、生成文風の論文導入表現も削除してください。
  • “This subsection surveys …”
  • “This subsection argues …”

3回のパス（推奨）

パス1 — サブセクションの推敲（構造 + テンプレート排除）

ベストオブ2のマイクロ推敲（推奨）：

• 手を入れる文・段落ごとに、2つの候補リライトを起草し、より良い方を残します。
• シンプルなルーブリックで選びます：明確さが向上している、テンプレート的な語幹がない、引用がアンカーとして維持されている、引用の形が読者向けのままである（隣接する引用ブロックや重複キーがない）。
• 両方の候補を残さないでください。1つを選んで先に進みます（目標は収束であり、終わりのない書き直しではありません）。

役割分担：

• エディター：明確さと流れのために文を書き直します。
• スケプティック：汎用的・テンプレート的な文を削除します。

ターゲット：

• 各H3は次のように読めるようにします：緊張 → 対比 → エビデンス → 限界。
• 繰り返される「免責事項の段落」を削除します。エビデンスポリシーは1か所に保ちます（パイプライン・実行ログとしてではなく、サーベイ手法として表現した序論または関連研究の単一の段落を推奨）。
• outline/outline.yml（存在する場合）を使い、編集中の見出しのずれを避けます。
• 存在する場合は、outline/subsection_briefs.jsonl を使い、流れを改善しつつ各H3のスコープ・RQの一貫性を保ちます。
• 簡単な「パターンスイープ」を行います（機械的ではなく意味的に）：
  • アウトラインのナレーションを削除：This subsection ...、In this subsection ...
  • スライドのナビゲーションを削除：Next, we move from ...、We now turn to ...、In the next section ...
  • タイトルのナレーションを削除：From <X> to <Y>, ...
  • 置き換えるもの：内容の主張 + 議論のブリッジ + 構成の文（新しい事実・引用は不可）
• citation-injector を使用した場合は、予算注入の文を論文らしく読めるように整えます：
  • 引用キーは変更しないでください。
  • リスト注入の語幹（例：「A few representative references include …」「Notable lines of work include …」「Concrete examples ... include ...」）を避けます。
  • 追加された引用を既存の議論の文に統合するか、サブセクションの視点に結びついた短い括弧書きの e.g., ... 節として書き直すことを推奨します（新しい事実は不可）。
  • 表現を変化させ、多くのH3で同じ開始語幹を繰り返さないようにします。
• トーン：冷静で学術的なものに保ちます。誇張語や繰り返される冒頭ラベル（例：多くのH3で文字通りの Key takeaway:）を削除します。
• 繰り返される統合の語幹を減らします（例：Taken together, ... で始まる多くの段落）。統合の表現を変化させ、内容を伴うものに保ちます。
  • 繰り返される「Taken together,」を生成者ボイスの兆候として扱います。2回を超えて現れる場合（または1つの章に集中する場合）は、表現を変化させるために書き直し、各統合の文を内容に即したものに保ちます。
  • 統合の冒頭を変化させます：「In summary,」「Across these studies,」「The pattern that emerges,」「A key insight,」「Collectively,」「The evidence suggests,」または統合マーカーなしで結論を直接述べます。
  • 各統合の冒頭は、テンプレートのラベルではなく内容に即したものにします。

サブセクション冒頭のリライトレシピ（論文の声、新しい事実なし）：

• 削除：This subsection surveys/argues... / In this subsection, we...
• 次のうち2〜3個を行う簡潔な冒頭に置き換えます（ラベルなし、サブセクション間で変化させる）：
  • 内容の主張：サブセクション固有の緊張・トレードオフ（任意で1〜2件の埋め込み引用付き）
  • なぜ重要か：その主張を評価・エンジニアリングの制約（ベンチマーク・プロトコル・コスト・ツールアクセス）に結びつけます
  • プレビュー：次に何をどの視点で対比するか（A対B、次に評価アンカー、次に限界）
• 骨子の例（言い換えてください。そのまま再利用しないでください）：
  • 緊張優先：A central tension is ...; ...; we contrast ...
  • 決定優先：For builders, the crux is ...; ...
  • 視点優先：Seen through the lens of ..., ...

パス2 — 用語の正規化

役割分担：

• タクソノミスト：正規の用語と同義語ポリシーを選びます。
• インテグレーター：ドラフト全体に一貫した置換を適用します。

ターゲット：

• 1つの概念 = セクション全体で1つの名前。
• 見出し、表、本文で同じ正規の用語を使用します。

パス 3 — 冗長性の削減（全体にわたる繰り返し）

役割分担：

• 圧縮担当：繰り返される定型文をまとめます。
• 叙述維持担当：繰り返しの削除によって論旨のつながりが損なわれないようにします。

対象：

• セクションをまたいで繰り返される導入文・締めくくり文を削除します。
• 各小節には、その小節に固有の内容のみを残します。

スクリプト

クイックスタート

• uv run python .codex/skills/draft-polisher/scripts/run.py --help
• uv run python .codex/skills/draft-polisher/scripts/run.py --workspace <workspace>

すべてのオプション

• --workspace <dir>：ワークスペースのルート
• --unit-id <U###>：ユニット ID（任意。ログ用）
• --inputs <semicolon-separated>：入力を上書きします（まれに使用。デフォルトを推奨）
• --outputs <semicolon-separated>：出力を上書きします（まれに使用。デフォルトを推奨）
• --checkpoint <C#>：チェックポイント ID（任意。ログ用）

例

• 最初の推敲（基準となる output/citation_anchors.prepolish.jsonl を作成します）：

  • uv run python .codex/skills/draft-polisher/scripts/run.py --workspace <workspace>

• 基準となるファイルをリセットします（引用のずれを意図的に許容する場合のみ）：

  • output/citation_anchors.prepolish.jsonl を削除してから、推敲スクリプトを再実行します。

受け入れチェックリスト

• TODO/TBD/FIXME/(placeholder) がない。
• … または ... による省略がない。
• 多くの小節にわたって繰り返される定型文がない。
• 引用のアンカリングに合格している（小節をまたぐずれがない）。
• 各 H3 に、少なくとも 1 つの論文横断的な統合段落がある（引用 2 件以上）。

トラブルシューティング

問題：推敲によって小節間で引用のずれが生じる

対処法：

• 引用は同じ ### 小節内に残します。意図的に構成を変更する場合は、output/citation_anchors.prepolish.jsonl を削除して、新しい基準を生成します。

問題：執筆の承認前に草稿の推敲を求められる

対処法：

• 文章レベルの編集を行う前に、該当する承認を DECISIONS.md に記録します（通常は Approve C2）。